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 |
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.
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 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.