The full specification. Published before the implementation.
We publish the spec before the code because we want it to be the thing that gets criticized, broken, and improved. If you find something wrong, we want to know.
ML-DSA-65 from genesis — the canonical cryptography reference.
Why post-quantum matters now (harvest-now-decrypt-later), why we picked ML-DSA-65 specifically, the alternatives we rejected (Falcon-512, SLH-DSA, hybrid schemes), and the honest cost accounting — sigs are ~52× larger than Ed25519 and that drives every other architectural choice.
Key decisions
- —NIST FIPS 204 ML-DSA-65 for all signatures, from genesis
- —No hybrid schemes — PQC-only commitment
- —Bounded committee size to fit sig overhead in residential bandwidth
- —PQClean as reference impl, version-pinned in protocol spec
Citations
Plain JS, immutable by default, reentrancy structurally impossible.
Four locked-in design decisions told as one story. Cross-contract calls are async message-passing. Contracts are immutable by default, with proxy upgradeability opt-in and labeled. Source verification is a single hash compare — no compiler to trust.
Key decisions
- —D18 — Async message-passing (no reentrancy possible)
- —D19 — Immutable by default, opt-in labeled proxies
- —D20 — First-class source verification via hash compare
- —D21 — Cold-load surcharge rewarding small modular contracts
Citations
The whole stack at a glance — JSON-RPC down to the wire.
HTTP peer fan-out for block sync and vote gossip, Tendermint-style BFT with a rotating ~100-validator committee, Sparse Merkle Tree state over LevelDB, Hardened JavaScript VM, and a JSON-RPC interface compatible with the Ethereum tooling ecosystem. Tuned for the median consumer PC.
Key decisions
- —HTTP peer fan-out for block sync and vote gossip
- —Sparse Merkle Tree state over LevelDB
- —Tendermint-style BFT with validator-only consensus overlay
- —Hardened JavaScript (SES) for contract execution
Citations
Cosmos-style delegated PoS with shared slashing.
Anyone holding ASE can delegate their stake to a consensus validator and share in the rewards — and the slashing risk. The shared-slashing model is what forces delegators to actually care about validator quality. No liquid staking in v1: it keeps the centralization vector closed.
Key decisions
- 01Cosmos-style shared slashing — delegators have skin in the game
- 02Maximum 20% commission, 24h commission-change cooldown
- 031 ASE minimum delegation — anyone can participate
- 04No liquid staking in v1
What we are building, and what we are not.
The non-negotiables: Node.js reference node, JavaScript contracts, post-quantum signatures, consumer-hardware tuning with a Pi 4 supported floor, single-binary CLI install, and a bounded bandwidth budget. The non-goals are equally important: no raw-TPS chase, no EVM bytecode compat, no ZK in v1, no sharding, no bridges.
Key decisions
- —4-core consumer PC tuning target, Pi 4 supported floor
- —≤ 50 GB/month bandwidth budget per validator
- —< 20 GB steady-state disk for v1
- —Single-binary CLI install via one-line command
Every locked-in design decision, with rationale.
Twenty-plus locked-in technical decisions, each with the reasoning, the alternatives we considered, and what we would revisit. The honest record of how the protocol got designed.
Consensus
Tendermint-style BFT, ~100 validators in rotating committee.
Token economics
1B max supply, EIP-1559 burn, decaying inflation schedule.
Block time
Under active tuning; 2s on current testnet.
Bootstrap
4-phase rollout: devnet → public testnet → incentivized → mainnet.
Serialization
SSZ (Simple Serialize), inherited from beacon-chain research.
Found something wrong? We genuinely want to hear it.
We publish the specification before the implementation because the specification is the thing we want criticized. If you spot a flaw in the cryptography, the consensus, the contract model, or the economics — get in touch. The earlier we hear it, the more useful it is.