Tagged: cvm
23 projects across the lattice ecosystem.
Videos & Talks
- Lisp for Lattice Technology Mike Anderson shows how Lisp — specifically Convex Lisp on the CVM — maps naturally onto lattice-based decentralised systems.
- Transaction Flow on an Internet Computer Transaction flow on an Internet Computer — how the Convex Virtual Machine processes transactions at web scale.
- CVM Hacks CVM hacks — techniques and patterns for programming the Convex Virtual Machine in Convex Lisp.
- Coding Common Features in Smart Contracts Coding common smart contract features on Convex — reusable patterns built with Convex Lisp primitives.
- Importance of Runtime The importance of runtime environments — why the CVM acts as a mini-OS for decentralised programs.
Convex Architecture Documents
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- CAD030: Torus DEX An on-chain AMM where any CAD29 token gets a market on first request, routing through a canonical actor rather than deployed-per-pool factory contracts. Shows the universal asset model paying off — one DEX speaks every token, invented or not.
- 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.