Architecture decisions and current boundaries
These decisions describe the registered public development-network profile. The profile is value-less and resettable; do not use real funds. Historical whitepaper designs and SDK symbols do not override the current registry entry, runtime provenance, or the boundaries below. Registration does not assert current liveness.
ML-DSA-65 at the native signing boundary
Section titled “ML-DSA-65 at the native signing boundary”The released account and consensus-signing posture uses ML-DSA-65. Choosing a standardized post-quantum signature avoids accumulating transaction history under a deliberately classical account scheme, at the cost of larger keys and signatures.
That bounded claim is not “the entire stack is quantum-proof.” The public mempool is plaintext, and there is no released SLH-DSA account, backup-key, or emergency-rotation path.
No on-chain governance
Section titled “No on-chain governance”The current product boundary has no token-weighted on-chain protocol vote. Community input and release governance are off-chain. Forking is the intended structural exit, but mono-core is internal and unpublished, so it is not an independently exercisable implementation exit today. This is a governance choice, not a claim that governance risk disappears.
No native perpetuals or margin
Section titled “No native perpetuals or margin”Leveraged derivatives add liquidation, oracle, and contagion risk. They are not part of the current native product boundary. Any later venue would require its own separately documented implementation, audits, activation evidence, and risk model.
Native Rust/RISC-V direction, not compatibility-VM execution
Section titled “Native Rust/RISC-V direction, not compatibility-VM execution”The architecture uses native Rust and a RISC-V contract direction rather than presenting compatibility-VM bytecode as the application execution identity. The trade is a smaller inherited application ecosystem in exchange for a more explicit native surface.
Cross-chain liquidity is not supplied by an in-tree bridge. There is no native bridge verifier or Foundation-operated production route; external-provider interoperability remains under evaluation.
ZK is not a consensus dependency
Section titled “ZK is not a consensus dependency”Consensus safety does not depend on an application proof verifier. No active zkML, bridge, or prover-market value path should be inferred from historical designs, reserved precompile names, or SDK encoders. A future proof system would require a separate release and activation record.
Starfish-C DAG-BFT
Section titled “Starfish-C DAG-BFT”The registered runtime identifies Starfish-C DAG-BFT and an approximately four-second target round profile. Vertices feed the DAG and committed anchors provide the application-facing sequence. Benchmark claims require a published workload and raw samples; a current-height probe is not a TPS or finality benchmark.
Four 10-position operator clusters in the registered profile
Section titled “Four 10-position operator clusters in the registered profile”The current registry entry pins four clusters with ten operator positions each and a 7-of-10 signature threshold, plus two relays. Each contributing operator signs independently with ML-DSA-65. This registered topology replaces older aspirational fleet sizes and is not a mainnet promise or liveness claim.
Deterministic ordering over a plaintext mempool
Section titled “Deterministic ordering over a plaintext mempool”The current mempool is plaintext. Deterministic DAG ordering is an integrity property, not transaction confidentiality: operators and other observers may see pending contents. Encrypted, sealed, private-send, and threshold-decrypted mempool designs are not released.
Typed bech32m addresses
Section titled “Typed bech32m addresses”User-facing addresses use released bech32m helpers with semantic HRPs and checksums. Applications should use the exact @monolythium/[email protected] address functions documented in the SDK guide rather than reimplementing byte layouts from prose.
Explicit product exclusions
Section titled “Explicit product exclusions”Agent-wallet custody, protocol spending policy, autonomous signing or submission, booking, payment, escrow, dispute, and review are planned or unavailable. Their presence in old architecture text or an SDK encoder does not establish an active economic path.