A transaction signature on the chain we're building is 4,595 bytes. An Ed25519 signature is 64. A DER-encoded secp256k1 signature is about 70. That ~65× gap is the entry fee for making CRYSTALS-Dilithium-5 — a NIST category-5 lattice scheme — the default signature for every transaction and every block, rather than a hybrid bolted on the side. This post is the byte accounting of that choice, including the parts that hurt.
Where the bytes go. Round-3 Dilithium-5 public parameters: public key 2,592 B, private key 4,864 B, signature 4,595 B. Those aren't our numbers; check them against any round-3 implementation. On our chain, signature verification is a native protocol operation: the public key and the verification result are stored on chain. Validity is consensus state, not a client-side convention. We think that's the right call, and we also count the cost — every verification permanently adds bytes to state. State growth, not a free lunch.
The incompatibility nobody advertises. FIPS 204 (ML-DSA) went final in August 2024, and yes, it is the Dilithium family. But ML-DSA-87 signatures are 4,627 bytes, not 4,595. The schemes differ; a wider commitment hash is one of the changes. An implementation that speaks round-3 Dilithium-5 does not speak FIPS 204 on the wire. We ship round-3 Dilithium-5 today, and the ML-DSA-87 migration is an explicitly open item in our whitepaper — not something we wave off as "just a parameter set." That incompatibility is also the whole argument for freezing the signature layer at genesis: a post-launch swap re-negotiates canonical encodings, replay and domain-separation rules, and signer semantics everywhere at once.
Keys are the unglamorous half. A 4,864-byte private key doesn't fit the 32-byte assumptions most signer infrastructure was built around. Our current answer: a local signer (KMS-style), a remote signing API, and an MPC signing path, under a rule that AI components never see plaintext private keys. The remote path leans on an external KMS today — a centralization dependency we'd rather name than hide.
The honest costs.
- Interop: standard Cosmos tooling (Keplr, CosmJS) can read our transactions but can't sign them. Only our own SDK — still pre-release — produces valid signatures. That's real adoption friction; pretending otherwise wouldn't survive five minutes of testing.
- No public-network benchmarks exist yet. The figures we publish (5s block interval, 100 active validators) are design targets, labeled as such on the site — not measurements.
- The chain is pre-mainnet. Status is No-Go; the authoritative check is msgchain.org/status.json. Nobody should quote a launch date, including us.
I'm not aware of a major L1 with a category-5 lattice signature in the default position. If you know one, correct me — I'd rather be wrong in public than vague. If you'd rather tear into the design than take our word: the signature section is at msgchain.org/whitepaper, and qa.msgchain.org is a public question box where answering is a commitment.
Context: we work on MSG Chain (msgchain.org), the chain described above. That's the only promotional sentence here.
Top comments (0)