25. Application Ecosystem & Developer Tooling
A blockchain is only as useful as what can be built on it. The repository contains the L1 node, SDKs, wallet components, L0 adapters, bridge code, and a collection of Solidity/WASM application prototypes.
25.1 Application Contracts
The application directories demonstrate intended integrations and provide testnet or local deployment tooling. They are not a blanket production deployment or an audit certificate.
| Area | Repository evidence | Status |
|---|---|---|
| DEX | solidity-contracts/dex/ and deployment scripts | Prototype/testnet integration |
| Lending and stablecoin | solidity-contracts/ modules and deployment scripts | Prototype; mainnet model is separately planned |
| Predictions, perps, NFT, launchpads and social modules | Individual Solidity projects and scripts | Varies by module; verify build and deployment artifacts per project |
| Bridges and L0 verifiers | base-bridge/, l0-relayer/, and bridge-relayer/ | Experimental/integration code with chain-specific trust assumptions |
| Vybss application suite | L1/solidity-contracts/insurance/VybssInsurancePool.sol, L1/solidity-contracts/memecoin/MemecoinLaunchpad.sol, L1/solidity-contracts/p2p/VybssP2PEscrow.sol, L1/solidity-contracts/predictions/VybssPrediction.sol, L1/solidity-contracts/profile-keys/VybssProfileKeys.sol | Prototype/testnet; verify build and deployment artifacts per contract |
A deployed address or successful local test proves a particular deployment path, not production readiness. Contract audits, upgrade policy, key custody, monitoring, and economic risk controls remain separate requirements.
25.2 Layer 0 SDKs
The cross-chain finality hub (Layer 0 Finality Hub section) is exposed to applications through two SDKs:
-
quantos-l0-sdk(Rust) andquantos-l0-sdk-js(TypeScript,@quantos/l0-sdk) provide a uniform client for fetching, verifying, and relaying L0 finality proofs. An application fetches the latest proof, verifies it off-chain with a stake-weighted threshold check (e.g. 2-of-3), and optionally submits it for on-chain verification on any of the supported target chains. -
Chain adapters: The SDK abstracts fourteen chain families behind a common interface —
EvmAdapter(Ethereum, Base, Monad, Arbitrum),SolanaAdapter(SVM),SuiAdapter/AptosAdapter(Move),NearAdapter,CosmosAdapter,PolkadotAdapter(Wasm/ink!),StellarAdapter(Soroban),TonAdapter,CardanoAdapter,StacksAdapter(Bitcoin),CantonAdapter(Canton Network), andIcpAdapter(Internet Computer). Each adapter knows how to call its chain's verifier contract and read back verification and relay status.Status note: The
base-bridge/repository contains all fourteen adapter stubs. The EVM-family adapters (Ethereum, Base, Monad, Arbitrum) have deployed verifier contracts and tests. The non-EVM ports (Sui, Aptos, Solana, NEAR, Stellar, Bitcoin/Stacks, Canton, ICP, Tron) are present in the repository and follow the same adapter interface; their per-chain compilation, deployment and integration coverage should be verified against the exact repository commit before being treated as production-ready.
The data flow is: Quantos L1 → FinalityHub → L0FinalityProof → RelayDispatcher → chain adapter → target-chain verifier contract → application (bridge, DEX, DAO, oracle).
25.3 PQC-Guard SDK
The PQC-Guard area includes a TypeScript SDK whose canonical serialization and per-chain authorization-digest code is intended to reduce repeated client implementations. Supported runtimes, test coverage and deployment status must be checked against the exact repository commit and target-chain matrix.
25.4 Wallet Infrastructure
Post-quantum keys are larger and structurally different from ECDSA keys, so the wallet stack is purpose-built rather than retrofitted:
quantos-wallet-core(Rust) — the core key-management and signing library, with WASM artifacts for browser and mobile integration.quantos-wallet-extension— a browser extension wallet that manages the repository's post-quantum-compatible account keys, signs transactions, and speaks the node's JSON-RPC interface.quantos-wallet-server— supporting server-side wallet services.
These components support wallet and key-migration workflows in the repository. Production use still depends on the active migration protocol, key custody, extension security, RPC authentication, guardian policy and deployment configuration.
25.5 Explorer API
The explorer-api/ repository is a standalone REST API (Hono / TypeScript) backed by Supabase Cloud (SaaS — no local Postgres) and an indexer that polls the L1 node's qnt_* JSON-RPC interface and indexes the results. It exposes a read-only surface for wallets, block explorers and dashboards:
- Health / info / metrics —
GET /v1/health,GET /v1/info,GET /v1/metrics. - Accounts —
GET /v1/accounts/:address,/balance,/transactions,/tokens,/nfts. - Transactions —
GET /v1/transactions,GET /v1/transactions/:hash. - Blocks —
GET /v1/blocks,GET /v1/blocks/:height,GET /v1/blocks/:height/transactions. - Validators —
GET /v1/validators,GET /v1/validators/:address,/stats. - Contracts —
GET /v1/contracts/:address,GET /v1/contracts/:address/verify,POST /v1/contracts/call. - Stats —
GET /v1/stats,GET /v1/stats/:key. - DAG —
GET /v1/dag/tips/:shardId,GET /v1/dag/vertices/:hash.
The API enforces API-key authentication, rate limiting, and CORS, and is deployed via Docker (docker-compose.yml service explorer-api). It is an off-chain indexing service; consistency with the L1 is eventual and depends on indexer lag. It is not a consensus component and must not be trusted for transaction validity — only the L1 node's qnt_* interface is authoritative.
25.6 Quantos SDK
The quantos-sdk/ repository ships a TypeScript package (@quantos/sdk) for application and wallet integration:
client.ts— full RPC client (getBalance,getTransaction,sendTransaction,getBlock, etc.) wrapping theqnt_*namespace.subscriptions.ts— WebSocket subscriptions (newTransactions,newBlocks,newVertices,pendingTransactions).types.ts— TypeScript types for all Quantos structures (vertices, transactions, accounts, consensus state, DAG).utils.ts— helpers (address validation, hex conversion, etc.).
The SDK is a client convenience layer; correctness depends on the node's RPC schema, which must be pinned to a compatible L1 release. Like the explorer API, it does not validate consensus state and must defer authority to the L1 node.
25.7 Node Interface
The node exposes JSON-RPC handlers for account, transaction, DAG, slot/epoch, finality, chain and metric queries. The exact namespace and enabled methods must be verified against the active RPC server and network configuration before being treated as a stable public API.