Tagged: spec

Convex Architecture Documents

• CAD000: Design Principles Codifies the non-negotiable axioms every other CAD inherits from — immutable values, bounded resources, CRDT-safe idempotence, security-first cryptography. This is the constitution: why Convex refuses the shortcuts (mutable state, unbounded ops, bespoke crypto) that trap other decentralised platforms.
• CAD001: Convex Architecture Draws the line between the on-chain CVM (global consensus, root of trust) and the off-chain Lattice (unbounded CRDT data) while forcing them to share one encoding, one hash function, and one cryptographic identity. That shared substrate is what lets value and data flow between layers without the bridges, wrapping, and trust assumptions that fragment other stacks.
• CAD002: CVM Values Mandates that every value on the network is a pure immutable cell in a Merkle DAG — so hashes are stable identities, snapshots are O(1), and untrusted smart contracts can be handed references without defensive copying. This is the data-model prerequisite for everything the lattice does that a mutable-heap blockchain like Ethereum cannot.
• CAD003: Encoding Format Defines the one canonical byte encoding every cell collapses to, so any value hashes to exactly one global ID and peers can deduplicate, stream and merge state without coordination. This is the physics of the lattice — JSON has no canonical form, Protobuf needs schemas, ASN.1 can't bound buffer size; CAD3 solves all three at once.
• CAD004: Accounts Unifies user wallets and smart contracts into a single account primitive — each one a tiny sovereign Lisp machine with its own environment and Ed25519 key. Key rotation without changing address (something Ethereum externally-owned accounts cannot do) falls straight out of this model.
• CAD005: CVM Execution Specifies the deterministic state-transition function State' = f(State, Block) over a Merkle-tree global state, so any peer can re-derive consensus from a single 32-byte root hash. This is what allows fast peer sync and cheap state proofs instead of replaying every block from genesis.
• CAD006: Memory Accounting Makes on-chain storage an accounted, tradeable resource — users get a memory allowance, pay into a common pool for more, and are refunded for deletions. Directly attacks the state-bloat trap that makes running an Ethereum archive node increasingly impractical.
• CAD007: Juice Accounting Meters CPU and bandwidth per CVM op with hard upper bounds so an O(n) attacker cannot force O(n^2) work — DoS protection baked into the execution semantics rather than retrofitted. It plays the role Ethereum gas plays but is priced on actual worst-case resource use, and is called juice deliberately because it is a Convex concept, not a blockchain one.
• CAD008: Compiler Puts a full expander + compiler on-chain, so smart contracts can legitimately write and deploy smart contracts using CVM ops as the target IR. Any language that lowers to Convex Lisp or CVM ops becomes a first-class on-chain language — Solidity-style single-language lock-in is structurally avoided.
• CAD009: Expanders and Macros Brings Dybvig-Friedman-Haynes expansion-passing-style macros on-chain — more general than traditional macro systems and strong enough to host entirely new languages or DSLs inside a single eval. Contract authors can extend the language itself rather than routing around its limits.
• CAD010: Transactions Pins down the signed transaction envelope — Ed25519 signature, origin address, strict incrementing sequence number — so replay attacks are structurally impossible and every state change has a cryptographically attributable author. The narrow interface is what lets clients from any language submit work into consensus.
• CAD011: Error Handling Gives every CVM expression exactly three outcomes (success, error, exceptional exit) with try granting atomic rollback on catch — errors become data, not undefined behaviour. Fixes the Solidity-era mistake where a revert in a dependency silently poisoned whole contract flows.
• CAD012: Numerics Provides a full numeric tower — arbitrary-precision integers up to 32 Kbits plus IEEE754 doubles — so prediction markets, AMM maths and share-pool division work natively on-chain without fixed-point hacks. Ethereum's integer-only VM forces all of this into library gymnastics.
• CAD013: Metadata Attaches a structured map to every defined symbol — docstrings, type hints, access flags — readable by tools, IDEs and explorers without a separate registry. Makes on-chain code genuinely self-describing so that wallets and agents can introspect contracts they have never seen before.
• CAD014: Convex Name System Provides trusted mutable human-readable references (@convex.trust → the current authoritative actor) so ecosystem-wide upgrades happen without touching caller source. DNS-for-smart-contracts: contract addresses stop being the API surface, names do.
• CAD015: Peer Communications Defines an asynchronous, transport-agnostic message format where every payload is a CAD3 cell and branches can be omitted for deltas — so a huge state can be transmitted as a tiny diff when the receiver already holds the rest. Gossip and lattice sync ride the same efficient wire.
• CAD016: Peer Staking Separates operational peer stake (slashed if the hot key leaks) from delegated stake (slashed only if the controller account is compromised), so coin holders can back good operators without running infrastructure themselves. Cleaner fault model than Ethereum validator staking, where one key loss loses everything.
• CAD017: Peer Operations Sets the concrete hardware, network, and key-management bar for running a peer — 1000 CVM minimum stake, offline controller keys, commodity 8-core box. Deliberately keeps peer operation achievable by individuals, not just data centres.
• CAD018: Scheduler Lets actors schedule CVM code to execute at a future timestamp with guaranteed execution and pre-paid juice, with hard O(log N) overhead to block DoS. Unlocks autopay, auctions, vesting and deadlines natively instead of relying on off-chain keeper bots like most EVM chains require.
• CAD019: Asset Model One polymorphic asset/transfer that accepts fungible tokens, NFT sets, derivative contracts and asset types not yet invented — generic contracts can handle anything ownable. Replaces the ERC-20/721/1155/4626 zoo with a single universal SPI.
• CAD021: Observability Pluggable opt-in observability hooks on every peer (client transactions, ordering events, state changes) so operators can pipe metrics to Kafka, Prometheus or custom pipelines without patching the peer. Monitoring stops being a fork-and-instrument exercise.
• CAD022: Trust Monitors Composable on-chain subject-action-object authorisation modules based on the TCSEC B3 reference-monitor model — sandboxed, callable in query mode, reusable across contracts. Access control becomes a first-class shareable component instead of ad-hoc modifiers copied into every contract.
• CAD023: Keystore Standardises how peers, CLIs and wallets store Ed25519 keys — encrypted at rest, password not cached, in-memory only when needed, reusing proven formats rather than reinventing. Prevents the class of keystore bugs that have drained other ecosystems.
• CAD024: Data Lattice Specifies the off-chain CRDT substrate — content-addressed, lazily loaded, self-healing, garbage-collectable, structurally shared and JSON-superset typed. This is where Convex solves what IPFS handles clumsily: rich types, efficient deltas, and merges that just work instead of manual pinning and reconciliation.
• CAD025: Convex HD Wallets BIP39/BIP44/SLIP-10 compatibility with SLIP-0044 coin type 864 for Convex — users get hardware-wallet and multi-chain-wallet support on day one without bespoke seed formats. Key recovery is a solved problem reused, not reinvented.
• CAD026: Convex Lisp A Clojure-inspired homoiconic Lisp tuned to the CVM's immutable persistent data structures, compiling on-chain and supporting REPL-driven development against a live network. General-purpose languages aren't deterministic enough and Solidity can't express the CVM's richer account model — Lisp is the pragmatic fit.
• CAD027: Event Logging A built-in log function emits verifiable events without requiring peer instrumentation or re-running historical state — auditors, wallets and indexers can subscribe to exactly what contract authors declare is meaningful. Cleaner than screen-scraping EVM logs with ABI guessing.
• CAD028: Data Lattice File System A POSIX-compatible self-sovereign file system on the lattice — CRDT merge means editing the same file on two offline devices reconciles automatically, with Merkle verification and peer-to-peer sync. Dropbox/iCloud with the provider removed and the data still yours.
• CAD029: Fungible Token Standard The CAD19-conformant replacement for ERC-20/ERC-777 — integer balances, decimals, mint/burn, all accessible through the universal asset API rather than duplicated interface boilerplate. Writing a new token is defining the rules, not re-implementing transfer.
• CAD031: NFT Metadata Puts NFT metadata on-chain as native CVM maps (JSON-compatible, per-NFT, optionally generated dynamically) instead of relying on off-chain IPFS URLs that rot. Fixes the chronic ERC-721 problem where NFT art disappears because someone stopped pinning.
• CAD032: CVX Reader Defines the textual .cvx syntax via an ANTLR grammar covering CVM literals, data structures, addresses and doubles — an unambiguous print/parse round-trip shared by REPLs, tooling, and file storage. The Lisp equivalent of having a real spec instead of vendor-specific dialects.
• CAD033: Convex CVM Types The registry of CAD3 extension tags for CVM-specific values (booleans, addresses, syntax objects, etc.) — nails down exactly which byte means which type so every implementation agrees. Without this the wire-format promises of CAD003 would drift across peer versions.
• CAD034: Curated Registry A generic on-chain registry pattern with CAD22 trust-monitor gating — one actor can host many registries for DAO memberships, verified token lists, accredited organisations. Lets ecosystems publish lists with controlled curation instead of every dApp shipping its own allow-list contract.
• CAD035: Lattice Cursors A thin mutable pointer layer over immutable lattice values — applications get atomic compareAndSet, updateAndGet, nested navigation, and sync/fork, while the underlying Merkle DAG stays pure. This is how applications use CRDT data without thinking about CRDT merges.
• CAD036: Lattice Node A lightweight non-consensus server that just replicates CRDT lattice data over the network — no CPoS, no staking, minimal resources. The right tier for CDNs, collaborative apps and hybrid dApps that need lattice sync without the cost of running a full Convex peer.
• CAD037: KV Database A Redis-style per-owner signed KV store on the lattice — multi-writer, offline-first, convergent without leader election because merge is mathematical, not negotiated. Gives hybrid dApps the shared mutable state that a global blockchain cannot afford to host.
• CAD038: Lattice Authentication Makes the merge step itself the security boundary — every incoming signed value is verified against its owner key (public key, Convex address, or DID) at O(delta) cost. You cannot inject data into a namespace you don't own, no matter what transport delivered it.
• CAD039: Convex SQL Typed SQL tables on the lattice with Apache Calcite as the query planner — full SELECT/JOIN/aggregate over decentralised, CRDT-replicated rows. Bridges relational thinking to CRDT storage, so existing SQL tooling plugs into a decentralised backend.
• CAD040: Lattice Queue A Kafka-style append-only log on the lattice — stable offsets, independent consumer positions, CRDT-convergent replication, and truncation that preserves offset identity. Event streaming without a central broker, paired with CAD037's state to cover both halves of distributed-system data.
• CAD041: Model Context Protocol Exposes peer capabilities (queries, transactions, watches, signing) as Model Context Protocol tools at /mcp with SSE streaming — so any MCP-aware LLM can transact, read state and subscribe to changes with no bespoke adapter. Convex becomes an economic substrate AI agents speak natively.
• CAD042: x402 Protocol Implements the HTTP 402 payment protocol over CVM and CAD29 tokens — APIs can gate access per request with a header-level payment, no OAuth, accounts or invoicing. Micropayments for agents and APIs without the Stripe detour.
• CAD043: Decentralised Identity Maps did:convex, did:key and did:web to Convex accounts via the shared Ed25519 key, so an identity issued off-chain can become an on-chain account without migration. Convex identities plug straight into the broader W3C DID world.
• CAD044: JSON on the Lattice JSON is a strict subset of CVM types, so any JSON payload rides through the CVM and the lattice with zero adaptation — keywords map to strings, maps to objects, vectors to arrays. Web APIs and existing JSON tooling work unchanged, removing the usual serialisation wall between web and chain.
• CAD045: Lattice Applications A four-layer pattern (API / cursors / lattice types / node infrastructure) for decentralised apps that compose LWW, Index, Map and Set lattices into correct, signed, mergeable domain models. Turns raw CRDT primitives into a repeatable recipe, so self-sovereign apps don't each reinvent merge semantics and silently lose data.
• CAD046: CellExplorer Budget-bounded JSON5 rendering of arbitrarily large CVM cells with truncation annotated in comments, using CAD3 storage bytes as the cost proxy. Exactly what LLM context windows, debuggers and API previews need — explore a gigabyte lattice in a few KB of output.