CAD023: Keystore

CAD

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.

Related projects

CAD025: Convex HD Wallets Convex Architecture Documents 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.
CAD038: Lattice Authentication Convex Architecture Documents 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.
CAD000: Design Principles Convex Architecture Documents 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.
CAD004: Accounts Convex Architecture Documents 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.
CAD007: Juice Accounting Convex Architecture Documents 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.
CAD010: Transactions Convex Architecture Documents 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.

Machine-readable

JSON — full project metadata
Markdown — LLM-friendly summary

Links

Related projects

Machine-readable