Now
What is building. What comes next.
A live page tracking what Sunima is actually doing. Recently shipped lists facts with dates and on-chain links. Active development lists what is being built right now, without delivery dates — the project doctrine is announce when shipped, not when promised. Coming next lists committed work that has not started. Updated whenever state changes.
Each item is verifiable on the Sunima testnet or on Arbitrum Sepolia. Updated 2026-10-25. Component-by-component state: Status.
Season 1 — quests, points and the path to a validator
Anyone can start with one command: the installer sets up the node and registers an operator with a free 15,005 SUNA testnet grant. Becoming a validator is earned: 500 quest points unlock an 11,010 SUNA validator grant. Points can also be exchanged for foundation stake delegated to the holder's own validator (50 SUNA per point, capped at 1 % of bonded stake per validator) — weight and rewards, but not transferable. A validator that stays bonded, unjailed and signs ≥95 % of blocks earns +5 points every day. Start at sunima.uk/testnet/quests.html.
Bridge v2 contracts on Arbitrum Sepolia
New bridge stack deployed: FrostVerifier (BIP-340 Schnorr verification on chain) 0xd9B0…BBA0, SunimaBridge v9 0x1721…Ff98 and the btUSD test token. Every admin action on the bridge needs a threshold Schnorr signature with a strict nonce — there is no single owner key. Governance proposal #4 turns on the Sunima-side fast tier (stake-weighted attestations by validators, 67 % quorum).
v17 upgrade — key groups, bridge v2
Coordinated upgrade by governance vote, rehearsed first on a copy of live state. Key groups ship switched off and are enabled one by one by governance.
v15 / v16 — signed upgrades and the court-order disclosure key
All validators run under cosmovisor with signed release kits, so upgrades apply at the voted height without manual steps. v15 switched off the ICS20 precompile (ASA-2026-002). v16 re-issued the court-order disclosure key as a threshold key: 6 of 8 validators (75 %) must cooperate to decrypt, and every validator holds one share.
Operator installer and network safety
One-command installer (operator.sh): node, cosmovisor, signed upgrade kit, CURARE sensors and operator registration. Re-runs are safe and roll back on failure. Restarts are guarded against double signing, a watchdog restarts a node only when its validator has really stopped signing, and alerts no longer depend on a single server.
Current testnet: chain-id sunima_8081-2
On 2026-09-02 the testnet moved to chain-id sunima_8081-2 (EVM chain id 8081) — a continuation of sunima_8081-1 with its state carried over, not a fresh start. Entries below dated before that are from the same network under its earlier chain-id. Since then it changes only through governance upgrades (now v20). Public RPC at sunima.uk/chain-rpc, REST at sunima.uk/chain-rest, explorer at scan.sunima.uk.
Address freezing removed from the protocol
Shipped in v14. Address freezing was removed from the code at v14. Court orders lead to disclosure of specific data through the threshold committee; freezing funds by court order is planned, not in the code today. x/sanctions blocks sending from a flagged address. Chain-wide halt and per-module pause remain for incidents.
Chain stress test on sunima_8081-1
Stress testing on sunima_8081-1: surfacing anomalies, edge cases, and error paths against the live testnet, in parallel with module-level hardening and preparation for the next phase transition. Specifics released only when each milestone is ready to ship — no module-level disclosure or timeline commitments ahead of delivery. During these runs, the testnet may show occasional elevated latency on RPC endpoints, transient timeouts on the public explorer at scan.sunima.uk, and spikes in mempool depth. Block production and finality remain unaffected. Every anomaly surfaced feeds back into module hardening before the next milestone is unlocked.
Clean regenesis — sunima_8081-1 established
The sovereign testnet was rebuilt in a clean regenesis at genesis time 2026-05-20T01:40:08Z, establishing chain-id sunima_8081-1. It continues as sunima_8081-2 since 2026-09-02 (see above). Public RPC at sunima.uk/chain-rpc, REST at sunima.uk/chain-rest, live validator dashboard at sunima.uk/network.
L1 testnet migrated to full Sunima chain — V4.2 operator module live
The sovereign chain transitioned from vanilla Cosmos-SDK to the full Sunima binary in a coordinated re-genesis. chain-id sunima_8081-1 was established later, in the clean regenesis on 2026-05-20 (above). Validator set bonded post-migration, joining via the V4.2-1 staking hook (auto-link verified live). The x/operators module ships the V4.2 family end-to-end: bond + probation pool (V4.2-2), 50/50 reward intercept via local distribution replay (V4.2-2b), staking-hook auto-link (V4.2-1), governance ante denylist for probation validators (V4.2-3), and stale-link prune in BeginBlocker (V4.2-4) — all shipped on the testnet binary after internal cold-eye review. A small bootstrap operator group is grandfathered in genesis (probation_end=0, bond=0); subsequent entrants register via MsgRegisterOperator with a 25,000 SUNA bond and serve the configured probation window. The x/courtorder module ships alongside as the Cosmos-native equivalent of the Solidity gateway (intake + disclosure + revocation, passed internal cold-eye review). x/turnstile and x/twomode are in-binary with full test coverage. Genesis: sunima.uk/chain/genesis.json. Stage 5 mainnet remains gated on external audit, the Halo2-KZG privacy layer, the validator decentralisation gate, and the threshold-MPC operator cohort.
Sunima Chain testnet live
Sovereign Cosmos-SDK + CometBFT chain came up in its first bootstrap cohort — the start of Stage 5 — sovereign L1 testnet. This early chain was later rebuilt in the clean regenesis on 2026-05-20 (above) into chain-id sunima_8081-1 (continued as sunima_8081-2 since 2026-09-02). Validator application form at docs.sunima.uk — setup instructions issued to approved operators directly. Mainnet remains pending external audit and validator decentralisation.
CourtOrderGateway v1.0.0 — first V3 consumer on Arbitrum Sepolia
Auditable disclosure registry implementing the legal-bridged privacy doctrine on top of SunimaTFHEPredicatesV3.verifyAndConsumeConditional. Deployed on Arbitrum Sepolia at 0x01fea626…da039, source verified on Sourcify (match/match). Lifecycle: registerOrder (judge-only) → discloseConditional (anyone, requires two worker signatures bound to the order) → revokeOrder. Internal cold-eye review iter 1 caught a HIGH cross-order replay surface (worker signature did not bind orderId), v1.1 added a gateway-level binding signature with a disjoint domain byte. Full test suite passing, no regressions. Open: the gateway is a testnet primitive only — no real court order has been processed; the off-chain Rust worker v0.3.0 endpoint /conditional_with_order_binding still needs to be added before the end-to-end disclosure flow is functional.
Audit-pass redeploy of six contracts
Five governance and privacy-deposit contracts went through 4 audit iterations (PRION + cold-eye) and 9 confirmed real-bug fixes before clearing the gate with zero findings ≥ MEDIUM. Full forge regression suite passing, no regressions. Six artefacts deployed and source-verified: SunimaGovernance v1.0.1 · PRIONInvariants v1.0.1 · PRIONPatchGateway v1.0.1 · SunimaDefWallet v1.0.2 · SunimaCollectionPool v1.0.2 · DefWalletAdapter v1.0.2.
Whitepaper fee-distribution model finalized (§11.5)
Operator economics published in full in whitepaper v1.6 (§11.5): a 24-month linear ramp from Year 1 to Year 3+, burn 30→50% · validator pool 50→35% (no GPU required) · treasury 20→15% · multi-signal bear-market trigger (volume + organic-traffic + volatility + validator-income floor) · 2x staking APY multiplier for node-runners · slashing three-tier with mercy percent · seven open iteration items tagged with resolution windows · explicit non-changes documented with reasoning. Three external review rounds applied. Model now in operational-validation phase — further iteration deferred until testnet telemetry surfaces real-world signal.
FROST signing quorum reached end-to-end
Signing onboarding flow shipped end-to-end: pre-built binary + single-command setup + background-process supervision. Operators joined via the internal onboarding path and contributed to threshold signing. Cleanup path verified.
FROST cold-storage round-trip verified
Lossless age-encrypted backup tested end-to-end: keygen → age encrypt → delete plaintext → restore → sign → verify. Format is ciphersuite-agnostic. USB bundle ≈10 MB. Validates the cold-backup path for production threshold custody.
Stage 4 privacy-deposit layer live
SunimaDefWallet + SunimaCollectionPool + DefWalletAdapter deployed with guardian + pause + commit-reveal flow. Hub re-wired to the new adapter. Stage 2 vault SunimaVaultElGamal v0.7.1 deployed in parallel with circuit breaker and Predicates v3.
FROST 2-of-3 MPC end-to-end
PoC FROST 2-of-3 across two trust domains, auto-failover under node loss, withdraw transaction on Arbitrum Sepolia accepted the Schnorr signature in _verifySchnorr. Validates the threshold MPC migration path off the single-organizer key.
Stage 3 closed — TFHE Predicates V3 live
SunimaTFHEPredicatesV3 deployed: range-proof + compare + conditional. Sourcify match/match. Passed internal cold-eye review over two rounds. End-to-end encrypted-transfer flow verified the same day.
Architecture v3 finalized
Metro + Fortress architecture committed: matryoshka outer layers (L1–L7), inner metro lines and depot. Depot is the v2 fortress with two rooms (OPS + CORE). Two-way compliance handles. Documented internally and reflected in the public architecture page.
Public channels online
@SunimaLabs on X and the Discord server launched. First thread reached 177 views inside 24 hours. Frame: legal-bridged privacy and binary user choice.
No delivery dates. The doctrine is to announce when shipped, not when promised. Each item is real, scoped work that the team is touching this week.
Bridge v2 go-live
Fast tier enabled by governance vote, attester agents on every validator, first btUSD transfers both ways. Then: move bridge administration from a temporary threshold key to the validator key group, and switch on the Ethereum light-client final tier so large transfers are proven, not just attested.
Halo2-KZG shielded-notes privacy layer
The mainnet privacy layer on Halo2-KZG shielded notes — the core that carries balances and transfers privately at the protocol layer. Confidential deposits and transfers already run on the testnet; hardening continues. The Stage 1–4 Arbitrum Sepolia contracts proved the primitives and remain as reference.
Turning on validator key groups
Enable the v17 key groups by governance one at a time and run key generation across all validators: court-order disclosure moves from the 6-of-8 key to a key held by every validator at 75 %, re-shared automatically as validators join and leave; the validator half of the vault door key (Key_A) follows. No group key ever exists in one place.
Operator program scale-up
Season 1 is open: install a node with one command, register as an operator, earn the validator grant with quests. Hardware floor: 8 CPU cores, 10 GB RAM, 300 GB NVMe. Guide: node setup. Goal: many independent operators in many jurisdictions; today most stake still sits on foundation-run nodes.
Review as a permanent gate
Every chain, installer, bridge and money change goes through independent read-only review rounds until reviewers agree it can ship, and through a rehearsal on a copy of live state before an upgrade. Solidity is additionally checked with public attack-vector methods. This is not a substitute for an external audit.
In-browser prover throughput
Confidential transfers build their Halo2-KZG proof in the sender's browser. Multi-threaded proving cut a shielded send from 144 s to 19.5 s (7.4×); work continues on reducing that further.
Admin-key migration to hardware-isolated multisig
Admin and guardian roles of the Arbitrum Sepolia contracts consolidate onto a hardware-wallet-backed multisig. Reduces concentration of authority over admin slots.
Items below are committed scope. They have not started yet because something else is in flight. They will move into active development when capacity opens — not when a calendar date arrives.
External competitive audit pre-mainnet
Independent audit of the chain modules, the bridge and the key ceremonies on top of internal review. Continuous bug bounty after launch.
Bridge final tier — Ethereum light client
Large or late transfers settle only against a verified Ethereum light-client proof instead of validator attestations alone.
Repeatable Season points
Weekly activity and streak points on top of daily uptime, so long-running operators keep earning weight.
Genesis validator program
Testnet operators who keep a sustained ≥95 % uptime record during Season 1 and later seasons form the candidate pool for the mainnet genesis set. Selection criteria and any mainnet allocation are announced before mainnet, not promised now.
Mainnet target — milestone-gated
Sovereign mainnet launches when (a) the external audit is complete with all CRITICAL and HIGH findings resolved, (b) the genesis validator set spans many independent operators in distinct jurisdictions, (c) the Halo2-KZG privacy layer is production-ready, (d) court-order disclosure and the vault door key run on validator key groups, and (e) bridge v2 runs with its final tier. No date promise — we ship when the gates close.
This page is rewritten when state changes. Items move from Coming next to Active development to Recently shipped as work progresses, with the date stamped at ship time. Items that turn out to be wrong or unnecessary get removed with a short note. No silent edits.