At a glance

Executive Summary

Sunima is a privacy chain that talks to the legal system instead of running from it.

Privacy and regulatory clarity have traditionally been presented as a forced choice. Pure-anonymity protocols have faced sustained regulatory friction; fully-surveilled custody systems protect nothing but counterparty ledgers and routinely leak user data through breaches and subpoenas alike. Legitimate users — individuals, small businesses, treasuries — are asked to choose between being surveilled and being treated as criminals for wanting privacy at all. Both options leave real users worse off.

Sunima proposes a third path. Balances are cryptographically encrypted at the protocol layer; third parties see that a user transacted, never how much. Disclosure exists, but only through a protocol-native court-order gateway that produces zero-knowledge proofs of solvency, transaction history, or sanctions compliance — never raw state, never at the custodian's discretion, never outside judicial review. Disclosure is gated by no single custodian or notary. Approval requires a quorum vote of the anonymous validator set — each validator bonded at the moment the order was submitted, one vote apiece inside a fixed voting window — followed by k-of-N threshold decryption shares. There is no single office to coerce: an attacker must reach a quorum across a distributed, anonymous set, not lean on one party. Machine-verifiable judicial signatures, where a jurisdiction issues them, are a Stage 5+ enhancement layered on top; until courts sign verifiably the quorum evaluates the served documentation itself — see §13 for the explicit maturity map.

Our posture toward law enforcement is straightforward. Sunima does not hide from legitimate legal process and does not obstruct properly-formed investigations. When an investigator or prosecutor approaches the Foundation with formal documentation — a served order, a judicial subpoena, a sanctions determination with supporting evidence — the protocol has a defined cooperation path. That path is narrow, threshold-approved, and cryptographically verifiable, but it is a real path. What the protocol does not do is offer speculative access: without formal documentation, user privacy remains the default, because user privacy is the product. If an agency believes a specific address is connected to an investigation, we ask only that the request come through the formal channel. We will help. We will not pre-emptively surveil the users who came to this protocol for the privacy they were promised.

The system is architected as a nested defense: a public-facing monitor layer (Layer 1, disposable), six concentric living-defense layers (Layers 2–7) managed by an internal security brain called PRION, and a two-room fortress at the core that separates operational logic from custody. The fortress custody room is sealed behind a FROST k-of-N threshold-signing lock distributed across geographic, physical, digital, and human vectors. Final k and N are set when the Stage 4 validator programme ships from operator-cohort coverage. No single compromise vector can reach the threshold alone.

Stages 1–3 are closed and live on Arbitrum Sepolia. Stage 1 — Paillier additive homomorphic encryption — at 0xe5254A5E21403Ae07a6925071796d596451f7f86 as the immutable reference vault. Stage 2 — EC-ElGamal on BN254 — at 0x3a0d9A52416847D984a17D0dBe849cdF6492209E as the proof-of-concept encrypted-balance vault, 12–18× cheaper than Paillier. Stage 3 — Halo2-KZG Predicates v3 — at 0x1840e8E2EF53e8AaA846941aa628d7bd70E27396, on-chain encrypted range, comparison and conditional verify-and-consume. Stage 4 Part 1 (privacy deposit layer) is live; the FROST 2-of-3 threshold-MPC PoC is verified end-to-end on-chain. Stage 4 closes when the validator-programme distribution of MPC share custody and the sovereign chain coordinator are both production-grade; Stage 5 ships the sovereign Cosmos chain — Cosmos-SDK + CometBFT consensus; the mainnet privacy layer is built on Halo2-KZG shielded notes.

1. The Dichotomy

Privacy and compliance in cryptocurrency are treated as opposing forces. Every project picks a side. The industry has produced two camps and a wide, unserved middle.

1.1 Pure-Anonymity Protocols

A generation of privacy-focused protocols has delivered strong cryptographic anonymity at the network layer. These designs succeed at the cryptography and fail at the political economy: they were built on the implicit assumption that regulators would eventually accept cryptographic proof of legitimate use as a substitute for procedural cooperation. That substitution has not held. Exchange delistings, developer enforcement actions, and categorical sanctions against specific protocols have made pure-anonymity positioning a high-cost stance even where the technology is mathematically sound.

The failure mode is not a failure of cryptography — it is a failure of the positioning. A protocol that has no cooperation interface at all leaves regulators with only one tool: pressure the perimeter (frontends, listings, developer identities). The result is that legitimate users bear the compliance cost of the design choice without gaining any of the protections a cooperation channel would have preserved.

1.2 The Compliance Camp

Coinbase, Fireblocks, BitGo, and institutional custody providers deliver legal clarity. They do so by acting as trusted intermediaries with complete visibility into every balance and every transaction they custody. Users receive IOUs, not coins. The privacy profile is identical to — and in some respects worse than — a regulated bank:

• Every balance is known to the custodian and every regulator the custodian reports to.
• Every transaction is logged, timestamped, and subject to subpoena without judicial process (in many jurisdictions).
• Account freezes are a matter of internal policy, not cryptographic impossibility.
• The custodian's solvency is the user's solvency. See: FTX, Celsius, Voyager, BlockFi.

1.3 The Gap

Between the two camps sits a demographic that no current product serves: individuals and institutions who want financial privacy from third parties while retaining demonstrable compliance with legitimate legal process. This is the historical role of the Swiss bank — confidentiality by default, disclosure under judicial subpoena. That model existed in fiat for two centuries. It has never existed in crypto.

Sunima is an attempt to construct it, not as a policy promise, but as a protocol guarantee.

2. The Sunima Thesis

Four premises define the protocol:

Premise 1. Privacy is a default, not a feature. Every balance on Sunima is encrypted at the protocol layer from account creation. There is no "shielded pool" to opt into. Plaintext balances are not a supported state — they do not exist in contract storage. External observers can see addresses interact; they cannot see amounts, net positions, or patterns beyond the structure of the graph.

Premise 2. Disclosure is possible, but only through the protocol. A dedicated court-order gateway accepts served judicial orders; the anonymous validator quorum evaluates the accompanying documentation rather than trusting any single verifier. The gateway produces zero-knowledge proofs — not raw balance exports — that answer specific, bounded questions: "Did address X receive funds from sanctioned source Y between dates A and B?" The answer is cryptographic, auditable, and limited to the scope of the request.

Premise 3. The fortress is separate from the storefront. Operations (DEX, lending, staking, vault) and custody (the ETH, tokens, and master keys) live in physically different contract boundaries. Operations never hold user funds. Custody never executes user-defined logic. The two communicate only through a narrow signed-note channel. A full breach of operations produces zero custody loss.

Premise 4. Trust comes from code, not from biography. Sunima Labs operates without publicly disclosed core-team identities, without paid advisors, and without VC-mandated public marketing. The whitepaper, the source-verified contracts, and the live deployments are the credentials. Progressive decentralization replaces operator trust with validator-set trust; validator-set trust replaces itself with threshold cryptography.

3. The Matryoshka Architecture

Sunima is structured as seven concentric layers surrounding a two-room fortress. The layering is not ornamental. Each layer is a distinct contract boundary with its own defensive posture, its own embedded monitors, and its own escalation path. An attacker breaching Layer 2 faces a different defensive system at Layer 3, and so on inward.

3.1 Layer 1 — The Monitor

Layer 1 is a public-facing smart contract (or set of contracts) that exposes a view of system state to external consumers — balances, TVL, vault addresses, fingerprint hashes. It is analogous to a monitor connected to a computer by an HDMI cable: breaking the monitor reveals nothing about the machine behind it.

L1 is not part of Sunima's security boundary. Third-party products — decentralized exchanges, lending markets, staking derivatives, NFT primitives — interact with Sunima through L1. This is intentional: the protocol team does not build the full DeFi suite. Third-party teams build products on top of L1, following the Ethereum/Cosmos pattern where core protocol and ecosystem products are developed separately.

3.2 Layers 2 through 7 — The Living Defense

Each of Layers 2 through 7 is a living defensive cell. The term is deliberate. Each layer:

• Receives attacks and responds in real time.
• Records the attack vector, payload, and outcome.
• Auto-patches discovered vulnerabilities by deploying a modified contract through a layer-internal upgrade path.
• Shares intelligence with all other layers — an attack that succeeds against L3 immediately informs L4, L5, L6, L7.
• Evolves over time as PRION synthesizes attack patterns into permanent defensive primitives.

Defensive intensity increases inward:

Every layer embeds monitor agents — small, read-only programs that observe call traffic and escalate anomalies to PRION. Agents have no authority to modify state; they only report. The distinction matters: a compromised agent can lie about what it sees, but it cannot steal or corrupt funds.

3.3 The Fortress — Ops Room & Core Vault

Inside the seventh layer is the fortress. Two rooms.

Ops Room (Room 2)

Contains all operational logic: balance accounting, access control lists, user metadata, compliance flags, order matching for exchange primitives, collateralization checks for lending primitives. The ops room holds no user funds. It computes; it does not custody.

A successful breach of the ops room yields computation rights — the attacker can issue requests to the core — but every request is a signed note with explicit authorization, and the core verifies signatures independently. Breaching ops without breaching the signing authority is useless.

Core Vault (Room 1)

Contains all user funds and master keys. Minimal surface: credit(user, amount), debit(user, amount), verify(proof), export(judicial_request). No business logic. No user-facing functions. Funds can only be moved in response to a valid signed note from the ops room, a valid judicial disclosure request, or a valid FROST k-of-N threshold-signing ceremony.

3.4 The Slit

The Slit is a narrow opening, like the mail slot in a locked door. It is the only communication channel between ops and core. Every message through the slit is:

• Cryptographically signed by an ops contract (not a user, not an external caller).
• Strictly typed: CreditNote, DebitNote, QueryNote, DisclosureNote.
• Idempotent and replay-protected by a monotonic per-ops nonce.
• Capped in size, frequency, and value scope.

Core accepts no other input. Not governance votes, not admin calls, not upgrade transactions — all of those pass through the slit as signed notes, subject to the same verification. The slit is the only vector of influence on the core, and it carries no executable code, only statements of authorized intent.

4. The PRION Security Brain

PRION is Sunima's internal security system. It is not a bug bounty program, not an audit service, not an external product. It is the nervous system of the matryoshka — the component that makes Layers 2 through 7 "living" rather than static contracts.

4.1 What PRION Does

• Classifies anomalies. Incoming call patterns are scored against a library of known-benign, known-malicious, and anomalous patterns. The classifier runs on GPU defender nodes and pipes judgments back to layers in near-real-time.
• Generates patches. When a novel attack vector succeeds at any layer, PRION synthesizes a Solidity patch, tests it in sandbox, and proposes deployment through a gated upgrade channel. No patch — including embedded-agent updates — is deployed autonomously. The target gating sequence (full form shipping in v0.5): (1) sandbox compilation and regression test against the full suite; (2) re-audit by an independent PRION instance (separate classifier, separate training cut); (3) 3-of-5 signature threshold from the rotating sentinel committee; (4) on-chain PRIONPatchGateway transaction with timelock — target parameters 24-hour for main-layer upgrades and 1-hour for embedded-agent updates. Current state (v0.3): PRIONPatchGateway substrate is deployed with a 1-hour delay on non-emergency operations; the full four-gate PRION pipeline (independent re-audit instance, extended timelock variants) is a v0.4–v0.5 integration task. The substrate already enforces that no layer upgrade proceeds without sentinel-committee signature quorum.
• Coordinates counter-attack. When L7 engages a hostile caller, PRION orchestrates the response: gas exhaustion paths, state pollution, alert propagation to other contracts the attacker has touched, and flagging of the attacker's address for future rate-limiting.
• Trains on real attacks. Dedicated attacker nodes (described below) continuously probe a sandbox clone of the fortress. Successful exploits become training data for future classifier updates.

Canary deployment — future option, not in current pipeline. A staged-rollout layer between the sandbox gate and the on-chain timelock — a continuously-synced production-mirror chain on which patches run under real state and real load before clearing for production — is a recognised industry practice for high-value contract deployments. It is not part of the current four-gate sequence: at present scale (testnet TVL caps under $1M, low expected patch frequency outside emergency security fixes) the additional latency it adds to an already 24-hour main-layer cycle is not justified by the marginal failure class it catches, and the operational surface of a second mirror chain is itself a non-trivial attack surface. The architecture leaves room to add a canary stage through governance once post-mainnet operational data justifies it — typically when TVL grows past the point where the cost of a single bad-patch incident exceeds the cost of running the canary infrastructure. We name the trade-off explicitly rather than pretending the four-gate pipeline subsumes it.

4.2 The Sentinel Committee

The "sentinel committee" referenced in §4.1 is a separate role from network validators. Validators produce blocks and participate in consensus; sentinels review and sign off on protocol upgrades and PRION-generated patches. The two sets must not overlap — a validator-sentinel union would allow the same parties to both approve malicious code and confirm its deployment.

Composition and protections:

• Separate key class. Sentinel keys are distinct from validator keys and are stored in hardware security modules (HSMs) or trusted execution environments (TEE — secure enclaves such as AWS Nitro, Intel SGX, or equivalent). The target v0.5 requirement is that sentinel signatures are produced only from attested TEE state; v0.3 ships with a softer requirement (cold-storage recommended, not enforced) pending tooling maturity.
• Jurisdictional distribution. The rotating committee is configured with members across independent jurisdictions. Legal compulsion against any single member does not produce a quorum.
• Rotation. Committee membership rotates on a defined cadence (target 6 months post-v0.5); compromise of an individual sentinel has bounded impact on future operations.
• No validator economic alignment. Sentinels are compensated from treasury on a flat retainer, not from validator block rewards. They have no direct incentive to approve upgrades that benefit the validator set.

Until HSM/TEE enforcement is tooled (v0.5), the economic security of the sentinel committee relies on procedural separation and rotation. This is explicitly listed in §13 as a current limitation.

4.2.1 Defense Against Sentinel Collusion — Founder Veto

A five-member committee with a 3-of-5 threshold is stronger than a single-key upgrade path, but it is not unconditionally safe. Three signers who decide to collude — whether through bribery, coercion, or drift in incentives — can in principle push an upgrade the rest of the network would reject. The protocol addresses this in two ways.

Structural (default, always on). Sentinel slots are not filled anonymously. Early-stage committees include pseudonymous Foundation-aligned personas, independent auditors, and grant-aligned partners; slot assignments are published on-chain and rotated on schedule (§4.2 rotation). A collusion against the protocol would require three heterogeneous parties — across different jurisdictions — to align against the very project their reputations are tied to. This is the same diversification logic that secures standard threshold committees in existing L1s.

Procedural (time-bounded Founder Veto). Until two years after Stage 5 mainnet launch, the Foundation retains a publicly-documented veto path on sentinel-approved upgrades. The veto is not a general-purpose override — it cannot force upgrades, only block them. Its mechanics:

• Every sentinel-quorum upgrade enters a 24-hour main-layer timelock (1-hour for embedded-agent patches). The Founder Veto key can cancel the queued upgrade during this window. Cancellation requires an on-chain transaction and is publicly auditable.
• The veto key cannot originate upgrades, mint tokens, change economic parameters, or unfreeze blacklisted wallets. It is a pure "stop" switch on the upgrade pipeline.
• Each veto event is emitted as an event and referenced in the next protocol release notes; the Foundation must explain its reasoning to the DAO.
• The veto key expires automatically at the block corresponding to Stage 5 mainnet + 24 months. After that block, veto calls revert; the sentinel committee is the sole upgrade authority.

The combination — diversified committee + bounded veto — means no group of three colluding sentinels can rug the chain during the period when the validator set is still bootstrapping, and after the veto sunsets, the committee has already matured past the early-risk phase (rotation cycles, expanded HSM/TEE enforcement, active DAO governance). This mirrors the transition used by Aptos, Sui, and early Optimism, which all began with a bounded founder-held veto and sunset it on schedule.

4.3 Why Internal, Not External

An earlier Sunima proposal positioned PRION as an external revenue product — an automated auditor deployed via Immunefi to compete with existing bug bounty services. Empirical testing against benchmark contracts (Spark, Sunima-Vault v0.3, Division) revealed a systematic weakness: PRION produced a high false-positive rate on cross-contract interactions it had not been fine-tuned against.

Rather than patch the external product, we repurposed the engine. PRION performs extremely well when given complete context on the system it monitors. Sunima's layers provide that context by design. The component is now Sunima's security organ, not a standalone service.

5. Signals & Fingerprints

Every interaction with Sunima traverses all seven layers, in both directions. A single user action is a signal. The accumulated history of a wallet's signals — signed and stamped by each layer — is its fingerprint.

5.1 The Signal Path

1. The user signs a request with their wallet key. The signature is the signal's root authority.
2. The signal enters L1, which forwards it inward.
3. L2 through L7 each verify the signature, check the wallet's fingerprint, and apply their layer-specific filters.
4. On reaching the ops room, the operation is computed.
5. If funds move, ops writes a signed note through the slit; core responds.
6. The response traverses outward: L7 → L6 → L5 → L4 → L3 → L2 → L1 → user.
7. On the return path, each layer stamps the signal. A complete fingerprint update receives six stamps — one per defensive layer.

5.2 Fingerprints as Reputation

A wallet's fingerprint is a vector of stamps accumulated over time. New wallets carry no stamps; suspect wallets carry stamps with warning flags; long-term legitimate wallets carry rich, consistent fingerprints across many interaction types.

Fingerprints are used by outer layers to:

• Rate-limit or refuse operations from cold or flagged wallets.
• Allow privileged fast-paths for wallets with verified long-term history.
• Feed PRION's anomaly classifier — a stamp sequence inconsistent with a wallet's prior history is a strong signal of key theft or compromise.

5.3 Storage & Unforgeability

Fingerprint state is distributed across three storage vectors, none of which exposes raw graph data:

• On-chain commitments. Only cryptographic commitment hashes are published on-chain — never raw stamp contents. Each stamp is stored as H(stamp ‖ salt), where the salt is rotated per-wallet per-epoch. Reconstructing stamp semantics from commitments alone is infeasible without the opening value.
• On-chain encrypted state. Values and patterns (amounts, counters, rate limits) are stored as encrypted commitments — Halo2-KZG shielded notes on the sovereign chain, and additive-homomorphic ciphertext in the EVM proof-of-concept vaults. Balance arithmetic is verified in zero-knowledge or computed homomorphically; disclosure requires the Core Vault's threshold key.
• Client-side opening values. The wallet holds the openings (stamp plaintext + salt) needed to reveal its fingerprint to itself or to a counterparty under ZK proof. No third party — including Sunima contracts — can reconstruct fingerprints without client cooperation.

A single stamp can be forged if an attacker controls a layer. Six consistent stamps across six layers cannot be forged without controlling all six, which would require complete protocol compromise.

Acknowledged limitation — transaction graph topology. Every public ledger exposes transaction topology to any observer with RPC access: the bare fact that address A interacted with contract C at time t is visible. Sunima does not claim to hide this interaction graph — it hides amounts, balances, internal state, and fingerprint contents. Mitigation against graph-analysis deanonymization is layered: (1) invisible-UX relay wallets rotate user-facing addresses; (2) mixing pools at L4–L5 batch multiple signals into indistinguishable outputs; (3) stealth addresses at the recipient side. Users who require sender-graph unlinkability must operate through these relay mechanisms; naive direct transfers retain EVM-standard observability.

6. Cryptographic Foundations

Sunima composes four well-studied cryptographic primitives. None of them are novel inventions of this project. The novelty is the composition and the progressive decentralization path.

6.1 Paillier Additive Homomorphic Encryption

Stage 1 uses Paillier encryption — a partial homomorphic scheme where E(a) + E(b) = E(a+b) is computable over ciphertexts, without decryption. Sunima's first deployed vault (SunimaVaultPaillier, see §7) implements:

• Deposit: on-chain addPlaintext(E(balance), msg.value) — the contract increments an encrypted balance without ever knowing the prior balance.
• Withdraw: the organizer produces E(-amount) off-chain; the contract computes addCiphertexts(E(balance), E(-amount)).
• Encrypted transfer: the organizer produces E(-amount) for the sender and E(+amount) for the receiver; the contract applies both homomorphically.

Keys are 2048-bit, generated off-chain, with the public n, n², and g embedded in the constructor. Paillier is not fully homomorphic — it cannot compute arbitrary functions on ciphertexts — but it is sufficient for balance arithmetic and is dramatically cheaper than full ZK proving. It is the correct primitive for Stage 1.

Status — Stage 1 closed; Paillier is now historical reference, not the active primitive. The Paillier vault at 0xe5254A5E21403Ae07a6925071796d596451f7f86 remains immutable on Arbitrum Sepolia for reproducibility, but primary balance encryption migrated to EC-ElGamal over BN254 in Stage 2 Part 1 (§6.2), where the same homomorphic balance arithmetic runs at 12–18× lower gas cost measured on live transactions. NIST SP 800-57 recommends ≥3072-bit RSA-equivalent moduli for security past 2030; on EVM, a 3072-bit Paillier modulus would have raised each deposit to an estimated 5–6M gas (≈ (3072/2048)² × 2.3M), which is economically unviable on a per-user basis. The Stage 2 migration solves this not by upgrading Paillier in place, but by replacing it with a fundamentally cheaper primitive (EC-ElGamal, ~128-bit ECDLP security on BN254) under the same homomorphic balance interface. No 3072-bit Paillier upgrade is planned. Paillier 2048-bit is retained only as the Stage 1 reference deployment; no new vault composes against it, and the SunimaVaultPaillier contract accepts no further composition from active protocol surfaces.

6.1.5 A Note on Architectural Evolution

Sunima treats architectural evolution as a stated strength, not an embarrassment to be smoothed over in marketing. Each stage of the roadmap is an explicit, versioned upgrade path — primitives may be added, substituted, or retired as the threat model, gas economics, and post-quantum landscape evolve. We document what is currently composed, where the boundaries of each primitive lie, and what we expect to swap in the future. The protocols Sunima builds on top — matryoshka, legal-bridge, threshold MPC, governance — are designed to be primitive-independent, so that a curve change in 2027 or a ZK-library upgrade in 2028 is a substitution under a stable interface, not a redesign of the chain. Ethereum and Solana both evolved their core publicly through multiple major hard forks; Sunima follows the same posture from day one.

6.2 Stages 2–3 — Hybrid Cryptographic Composition (EC-ElGamal + Halo2-KZG)

Sunima does not bet on a single homomorphic primitive. Stage 2 establishes an explicit, publicly disclosed hybrid composition: each operation class is routed to the cryptographic primitive that fits it best. This is a deliberate engineering choice, not a hedge.

Stage 2 phasing. Stage 2 ships in two parts under one hybrid composition. Stage 2 — Part 1 is the EC-ElGamal vault: the additive backbone, production-tested under live conditions on Arbitrum Sepolia. Stage 2 — Part 2 is the Halo2-KZG integration for richer encrypted predicates — range proofs, conditional disclosures, encrypted comparisons — integrated as a native zero-knowledge proving system without external dependencies. Both parts compose under the same protocol surface; what differs is the order in which they ship.

The composition as of Stage 2:

• EC-ElGamal over BN254 — encrypted balance arithmetic on the vault: deposit, withdraw, transfer. The scheme is additively homomorphic (Enc(a) + Enc(b) = Enc(a+b)) and runs entirely through the EVM-native ecAdd and ecMul precompiles, which makes it cheap on every modern L2.
• Halo2-KZG — richer encrypted predicates that additive HE alone cannot express: range proofs, conditional disclosures, encrypted comparisons, and the on-ciphertext logic required for compliance gateways and automated compliance flows in later stages.
• Future primitives may be added or substituted as the threat model and gas economics evolve. Each addition is an explicit, versioned protocol change — not a quiet swap.

Measured impact (live on Arbitrum Sepolia). Against the Stage 1 Paillier 2048-bit vault on the same network, the deployed Stage 2 vault (0x3a0d9A52416847D984a17D0dBe849cdF6492209E, v0.7.1) delivers the following per-operation gas reductions, measured against real on-chain transactions: cold deposit 151,368 gas vs Paillier 1.9–2.3M (12–15× lower), warm deposit 56,065 gas (new metric, no Paillier equivalent), withdraw 88,789 gas vs ~1.6M (~18× lower), and encrypted transfer 222,318 gas vs ~3.4M (~15× lower). At Arbitrum mainnet gas prices (~$0.10 per million gas), this brings the per-deposit cost from approximately $0.20 to approximately $0.015. The original Stage 2 commitment was a 200–300K gas envelope across the three primitives — three of three landed under the lower bound of that envelope.

Where Sunima's original work actually lives. The cryptographic primitives composed in Stage 2 — Paillier, EC-ElGamal on BN254, Halo2-KZG, FROST, ZK range proofs — are all open, peer-reviewed constructions. Sunima does not invent new cryptography. The original engineering contribution is at the protocol layer: the matryoshka fortress topology, the legal-bridged disclosure gateway with court-order-only decryption, the threshold-MPC operator economy, and the governance model with a time-bounded founder veto and slashing curves with mercy fractions. Composing proven cryptography under a novel protocol is, by design, a smaller attack surface than inventing new primitives.

Status: Stage 2 closed; Stage 3 closed (May 2026), both live on Arbitrum Sepolia. SunimaVaultElGamal v0.7.1 at 0x3a0d9A52416847D984a17D0dBe849cdF6492209E requires a valid verifyAndConsumeRangeProof attestation from the Halo2-KZG worker on every withdrawal — Stage 2 balance arithmetic and Stage 3 attestations are composed end-to-end. Guardian role + circuit breaker (40% TVL / 10 min). Organizer key rotation is secured by a 3-day timelock (propose / accept / cancel). The active Stage 3 attestation verifier SunimaHalo2PredicatesV3 is deployed and source-verified at 0x1840e8E2EF53e8AaA846941aa628d7bd70E27396; it exposes verifyAndConsumeRangeProof, verifyAndConsumeCompare and verifyAndConsumeConditional on-chain. The contract verifies EIP-191-signed attestations from the off-chain Halo2-KZG worker and replay-protects each consumed attestation by (consumer, ctHash, chainid, verifier, validUntil); pause is bounded to a 30-day maximum with a 7-day cooldown and is held by an isolated guardian role with no custody surface. Measured on-chain: ~33K gas median per verify-and-consume. The predecessor verifier SunimaHalo2Predicates at 0x9e11c9840f17d799b11c03ba129676dde30b88d6 is retained as historical reference. Passed internal cold-eye review (PRION + independent multi-model LLM cold-eye jury), two rounds. Full Foundry suite passing across the live-stage suite, no regressions. The Halo2-KZG predicate worker has been benchmarked end-to-end across the three target predicates on production hardware. Full numbers, methodology, and per-op explanations: measured benchmarks.

6.3 Threshold Custody (Stage 5+)

The master decryption key for the core vault is designed to be held under a FROST k-of-N threshold-signing scheme. Both k and N are sized at activation from the actual operator cohort, geographic distribution, and institutional diversity present at that point. Activation is scheduled for Stage 5+, once the validator set is large and diverse enough to support a meaningful distribution. Until activation, the protocol operates under the Stage 1–3 multisig and threshold-MPC custody described in §6.4. A FROST 2-of-3 PoC has been validated end-to-end on testnet (offline keygen, distributed sign, on-chain Schnorr verification on Arbitrum Sepolia).

Current testnet configuration is explicitly bootstrap, not production. The signing nodes presently running the FROST 2-of-3 PoC are operated by initial bootstrap participants — a transient topology adopted because there is no independent operator cohort yet to distribute shares to. The protocol moves from bootstrap to production trust model when three independent conditions are met simultaneously:

• Operator supply. A sufficient pool of pre-registered candidates exists in the Stage 4 validator programme — across non-allied jurisdictions and with stake committed — to sustain a meaningful k-of-N committee with rotation.
• Testnet demand. A measurable cohort of distinct addresses has used the live vaults end-to-end (deposit, withdraw, attestation) on the order of hundreds, demonstrating real protocol exercise rather than synthetic load.
• External review. At least one named-firm audit is closed with no remaining critical or high findings on the live-stage suite.

When all three conditions hold, a fresh DKG (Distributed Key Generation) ceremony is run with the new cohort. Each independent operator generates their own share in that ceremony — existing bootstrap shares are not handed over, they are retired. Concrete thresholds for operator supply and testnet demand are tuned at activation against the actual cohort and usage data rather than fixed in this document; the audit condition is a binary gate. Until all three are met the bootstrap configuration remains in place. See Stage 4 milestone in §10.

At activation, signing shares will be distributed across multiple independent vectors — node operators, institutional partners across non-allied jurisdictions, hardware-secured offline backups held by the Sunima Foundation, and wallet-derived shares where appropriate. Final allocation across vectors will be ratified by the active validator committee and the DAO at the time of activation, based on the actual size and topology of the network. No single vector and no single operator will be able to reach the threshold alone.

To unlock the core without protocol consent will require k cooperating shares spanning at least three independent vectors. The lock is not administrative — it is cryptographic. By design, no validator set, no single jurisdiction, and no single attack vector can reach the threshold.

Adaptive thresholds. Not every operation carries the same impact, and not every operation requires the same degree of consensus. The headline threshold k covers the most sensitive class of action (selective disclosure under a court order). Lower-impact operations use a lower bar, and the most sensitive operations — those that would alter the lock itself — use a higher one. Concrete fractions are sized at activation; the proportional structure is fixed:

This adaptive design means security cost is proportional to impact: routine maintenance does not require the coordination overhead of a full court-order disclosure, and a court-order disclosure does not require the near-unanimous participation needed to alter the cryptographic structure itself.

6.4 Threshold MPC (Stage 4)

Stage 4 replaces the single-organizer model carried through Stages 1–3 with threshold multi-party computation. The Paillier or Halo2-KZG decryption key is sharded across N operator nodes using a threshold signature scheme. No single operator can decrypt user balances; a quorum must cooperate for every withdrawal or selective disclosure. Final committee size and threshold (the production k-of-N) are determined at Stage 4 validator-programme deployment from operator-cohort coverage measurements rather than fixed at design time. A FROST 2-of-3 (RFC 9591) PoC has been verified end-to-end on Arbitrum Sepolia (May 2026) — auto-failover under 200 ms, on-chain Schnorr acceptance — establishing the production scale-up baseline.

This is the operational foundation of progressive decentralization. Stages 1–3 require trusting a single organizer. Stage 4 requires trusting that fewer than (N − k + 1) operators are simultaneously corrupt, where N and k are set when the cohort is finalized. Subsequent stages can increase N without protocol changes.

FROST + VRF blind aggregation. The threshold-signing primitive is FROST ("Flexible Round-Optimized Schnorr Threshold"), composed with a per-epoch VRF ("Verifiable Random Function") seeded from block_hash and epoch_number. Every operator continuously partial-signs every court-order request it observes, locally, using its FROST share. The VRF deterministically selects which partial signatures enter the final aggregation for that epoch; the others are dropped at the protocol level. An operator cannot tell whether their share was used in any given disclosure — they simply always sign. This eliminates the targeted-coercion attack: there is no identifiable "the committee" to threaten, only post-hoc math selecting from a continuous stream. Committee membership rotates on a 24-hour base interval with a per-operator random offset of 1–23 hours; no two operators rotate in lockstep. Final committee size and rotation parameters are set when the Stage 4 validator programme ships.

6.5 Post-Quantum Layer

Paillier and Halo2-KZG secure the computation on ciphertexts, but the public-key operations that surround them — key exchange between nodes, digital signatures on petitions, share commitment between layers — rely on classical algorithms vulnerable to a sufficiently powerful quantum computer under Shor's algorithm. Sunima mitigates this "harvest now, decrypt later" risk with a hybrid post-quantum layer applied to all non-FHE operations.

The layer operates in hybrid mode: every classical signature or key exchange is co-signed with its post-quantum counterpart, so that the security reduces to the stronger of the two. If a cryptanalytic advance breaks either the classical or the post-quantum half, the other still protects the operation. Migration to pure post-quantum mode is scheduled for Stage 5+ once both NIST finalists and their production implementations have accumulated several years of real-world use.

7. SunimaVault — Stage 1 Testnet Demo

⚠️ Testnet demo. SunimaVault is the first publicly deployed Sunima primitive and the reference implementation of the encrypted-custody pattern. It is a standalone ETH vault where every user's balance is stored as a Paillier ciphertext. It is deployed, verified, and operational on Arbitrum Sepolia testnet. This is an MVP demonstration with a single-organizer trust model — not a production custody system. Do not deposit mainnet funds. Testnet ETH only.

Live cost on Arbitrum Sepolia today. A Stage 1 deposit consumes 1.9–2.3M gas (≈ $0.19–0.23 at current Arbitrum gas prices), depending on whether the operation hits cold or warm storage; withdraw and transfer consume ≈ 1.6M gas. These figures, measured directly on the live Stage 1 vault, are the baseline against which Stage 2 optimisations are compared. Stage 2 Part 1 (EC-ElGamal) reduced deposit gas to 151,368 — a 12–18× improvement — achieved with a richer programmability surface, since Sunima's vault performs full homomorphic balance arithmetic on every operation.

7.1 Contract Logic

The contract exposes three user operations and no administrative backdoors.

function deposit() external payable {
    bytes memory current = hasAccount[msg.sender]
        ? _encryptedBalance[msg.sender]
        : zeroCiphertext;

    _encryptedBalance[msg.sender] = Paillier.addPlaintext(
        publicKey, current, g, msg.value
    );
    totalLocked += msg.value;
}

deposit() performs a homomorphic increment. External observers see the fact of a deposit and its ETH value (mandatorily public under EVM semantics); they do not see the resulting balance or the relationship to the user's prior state.

function withdraw(
    uint256 amount,
    uint256 expectedNonce,
    bytes calldata encryptedNegAmount,
    bytes calldata signature
) external {
    // ... verify nonce, verify organizer signature ...
    _encryptedBalance[msg.sender] = Paillier.addCiphertexts(
        publicKey,
        _encryptedBalance[msg.sender],
        encryptedNegAmount
    );
    totalLocked -= amount;
    (bool ok,) = msg.sender.call{value: amount}("");
}

withdraw() uses the organizer's off-chain verification that the user's balance is sufficient, receives E(-amount), and applies it homomorphically. The contract never learns the plaintext balance. Replay is prevented by a per-user monotonic nonce; impersonation is prevented by ECDSA signature verification against the fixed organizer address.

encryptedTransfer() extends the same model to peer-to-peer transfers: the organizer produces both E(-amount) for the sender and E(+amount) for the receiver, and both are applied in a single transaction. Neither balance is ever revealed on-chain.

7.2 The Organizer Model & Progressive Decentralization

In the Stage 1 MVP, a single organizer address holds the Paillier private key. This is an explicit trust assumption, not a permanent state. The organizer can:

• Decrypt any user's balance (required to verify withdrawal eligibility).
• Refuse to sign withdrawals (a censorship vector).
• Leak balances to third parties (a privacy vector).

It cannot:

• Steal user funds — the contract only credits withdrawals to msg.sender.
• Forge balances — homomorphic arithmetic is verified on-chain.
• Bypass replay protection — nonces are contract-enforced.

Stage 4 replaces the single organizer with a threshold-MPC committee — a FROST 2-of-3 PoC has already been verified end-to-end on Arbitrum Sepolia (May 2026); production scale-up to the operator cohort follows. Stage 3 added zero-knowledge attestations through Halo2-KZG Predicates v3, allowing range, comparison and conditional checks on encrypted state without organizer involvement. Stage 5 migrates the primitive to the sovereign Sunima chain; the mainnet privacy layer is Halo2-KZG shielded notes.

7.3 Live Deployment

Live users can transact directly today. The deployment serves two purposes: it is the first delivered primitive of the larger architecture, and it is an on-chain proof that homomorphic balance arithmetic is production-viable in existing EVM infrastructure.

8. The Legal Bridge

Sunima's distinguishing claim is that it works with the legal system. The concrete mechanism is a court-order gateway contract that accepts judicial disclosure requests and produces zero-knowledge proofs in response.

8.1 Gray Market vs Black Market

Not all off-KYC transactions are illegitimate. The distinction Sunima respects is:

• Gray market — transactions involving unregulated counterparties, tax-ambiguous situations, political donations, journalistic source protection, commercial confidentiality, and jurisdictional arbitrage. These are not violations of law and are not targets of disclosure.
• Black market — transactions involving OFAC-sanctioned addresses, active terror financing, child exploitation material, and adjudicated ransomware proceeds. These are legally established categories with judicial process for enforcement.

Sunima's compliance posture is narrow and specific: it does not voluntarily disclose anything. When a valid court order is presented through the gateway, it produces a cryptographic answer to a cryptographic question. The gateway does not export balances or transaction history; it proves specific assertions.

Black-market actors are not disclosed — they are denied entry. Before a new address interacts with Sunima for the first time, a Tier 1 compliance gate checks it against a continuously synchronized set of public registries:

• OFAC sanctions lists (SDN and sectoral), synchronized every four hours.
• UN Security Council Consolidated Sanctions List, EU Consolidated Financial Sanctions list, UK HM Treasury (OFSI) consolidated list, and FinCEN advisories with named-address content.
• FATF guidance and Targeted Updates on Virtual Assets are referenced as a methodology source for high-risk jurisdiction profiling — not ingested as an address-level sanctions list, since FATF does not publish enforceable address designations.
• Known ransomware payment addresses from public threat intelligence feeds.
• CSAM-linked distribution wallets identified through public threat-intelligence feeds and law-enforcement referrals.
• Addresses linked to specifically identified criminal operations by judicial order.

If an address matches any entry in these registries, the protocol silently rejects the interaction. No transaction is processed, no funds are accepted, no user data is collected — because the attempted interaction never reaches the stage where data would exist. There is nothing to disclose later, because nothing was ever stored.

The check is continuous, not one-shot, and Sunima operates its own detection layer on top of the public registries. The Tier 1 gate runs at every interaction, not only at first contact. Registry updates (most notably OFAC SDN additions) propagate to the active address set within the four-hour synchronization window: an address that was clean at deposit but is added to a sanctions list later is re-classified automatically, and any pending or subsequent interaction is suspended pending judicial review. Independently of the public registries, Sunima runs an in-protocol forensics layer maintained by the protocol itself rather than outsourced to a third-party screening service: lightweight graph embeddings detect mixer-hop patterns, structuring behaviour, and known threat-actor fingerprints (Lazarus-group flow signatures, bridge-drainer chains, ransomware payout topologies). Borderline addresses are escalated for higher-tier inspection rather than denied outright; objective registry hits remain the only basis for silent rejection. The combined effect is that the protocol does not merely consume the threat lists others maintain — it operates a continuous detection layer of its own and acts on its findings within the same narrow, registry-anchored criteria described above.

This design creates a critical distinction that sets Sunima apart from both pure-anonymity protocols and traditional custodians:

• The Tier 1 gate exists for the black market — actors who are known-bad before they ever touch the protocol. No proof is produced, because no interaction occurred.
• The Court Order Gateway (§8.2) exists for the gray zone — legitimate users whose specific transactions become relevant to a criminal investigation after the fact. It produces cryptographic proofs about completed, legitimate activity.

Sunima does not surveil gray-market users to detect black-market behavior. It surveils nothing. It simply refuses entry to addresses that are, by objective and publicly verifiable criteria, already known-bad. The threshold for this Tier 1 gate is deliberately high and based exclusively on objective registries maintained by jurisdictions and specialized organizations; an address is not denied because it is large, unusual, private, or politically inconvenient.

8.2 Gateway Mechanics

A judicial disclosure request enters as a served order with its supporting documentation. Rather than trusting a single verifier, the anonymous validator quorum independently evaluates the served documentation and votes; disclosure proceeds only on a quorum vote, followed by k-of-N threshold decryption. Where a jurisdiction issues machine-verifiable judicial signatures, on-chain signature verification against a governance-controlled, revocable key set is layered on top as a Stage 5+ enhancement — it strengthens the quorum's judgement but is never the sole gate. On a passing quorum, the core vault produces a zero-knowledge proof answering the request's specific bounded question:

• "Did address X receive funds from address Y between dates A and B?"
• "Is address X's balance above threshold T?"
• "Was the source of address X's current balance derived from any address in sanctions list L?"

The proof is published on-chain, auditable by the court and any observer, and bound to the request's scope. Raw balance history is never produced. Blanket disclosures are impossible. Fishing expeditions are mathematically refused.

Requests are verified, not trusted by default. A petition from a law enforcement agency does not automatically compel disclosure. The request itself is treated as an input to the same consensus mechanism that governs all privileged protocol operations. Node runners holding Layer 1 shares independently evaluate whether the request meets three criteria: jurisdiction recognition (is the issuing authority one the node runner's jurisdiction registry endorses?), statutory legal basis, and request proportionality. A petition that satisfies all three structurally passes to the validator quorum vote; one that fails any single criterion is structurally rejected, regardless of the political authority of the requesting agency. An agency submitting a request cannot know in advance whether the k-of-N disclosure threshold will assemble to approve it.

Disclosures are proofs, not data dumps. The agency that receives a disclosure also receives a cryptographic proof that the process followed the protocol exactly — not an administrative assertion, but a mathematically verifiable record. The evidence is admissible by construction, not by assertion. A court, a defense attorney, or any third party can independently verify that the disclosure was a legitimate response to a legitimate petition, without having to trust Sunima as an institution.

Disclosure is minimal by design. The proof attests to exactly what was released — and to what was not. The proof does not reveal:

• The full balance of the target address.
• The complete transaction history of the address.
• Other addresses that participated in related operations.

Each of these requires a separate, independently verified court order. The protocol enforces proportionality not through policy but through cryptography: it is technically impossible to extract more than the petition specifies.

Two-window processing. Every petition flows through two sequential 24-hour windows. Window 1 — review (24 h): automated checks (formal documentation, jurisdiction signature, scope boundaries) plus the FROST threshold vote on validity, statutory basis, and proportionality (§6.4). A petition that fails Window 1 is rejected and the rejection logged on-chain. Window 2 — challenge (24 h): any party may file an on-chain dispute, contesting either the petition's legitimacy or its targeting (the wallet owner can demonstrate that the order is misdirected). A dispute escalates the petition to a stricter cross-vote that either confirms the original outcome or reverses it. Worst-case latency from on-chain petition entry to disclosure is therefore 48 hours. (The Foundation's off-chain intake, authentication, scope-parsing and committee-review pipeline that precedes on-chain entry is bound separately — see /docs/regulators, "Procedural steps".) The two-window design is fixed by protocol; only the window durations are governance-tunable, and only within bounds set by the constitutional layer.

Anti-correlation protections. To prevent external observers from linking a specific court order to a specific disclosure event (a timing-correlation attack against user privacy), the gateway applies three countermeasures: (1) randomized processing delay of four to twenty-four hours between petition approval and proof generation; (2) batch publishing — multiple approved petitions bundled into a single on-chain transaction, hiding which petition triggered which proof; (3) synthetic traffic — the gateway continuously publishes decoy proof-generation events indistinguishable from real ones, making traffic analysis structurally infeasible.

Performance. Proof computation runs off-chain on a dedicated prover network; only the final proof — a compact, constant-size object — is submitted to the chain for verification. For high-frequency questions (most notably OFAC membership checks), verified answers are cached as signed attestations with a 24-hour time-to-live, automatically invalidated on every OFAC list update. This reduces Tier 1 latency for repeat addresses from milliseconds to microseconds and bounds the total compliance cost at industrial scale.

8.3 Stage

The legal bridge is a Stage 5 deliverable. Stages 1–4 focus on the cryptographic and architectural foundation; legal bridging requires a live sovereign chain, mature threshold MPC, and partnered judicial infrastructure. The design principles are fixed; the implementation follows mainnet.

9. Node Architecture

Sunima's operational topology recognizes four distinct node classes, each with different hardware requirements, economic incentives, and security postures.

The defender/attacker separation is a deliberate architectural choice. Mixing the roles creates collusion risk — an operator running both sides can withhold attacks to claim defender rewards while preserving exploit value. Separating the economic roles, and selecting operators by different criteria, removes this attack surface.

Beyond validators and defender/attacker nodes, Stage 2+ operation requires dedicated GPU compute capacity. Encrypted-state workers execute the homomorphic and ZK operations off-chain — generating zero-knowledge proofs for the Court Order Gateway and compliance attestations, and running heavier encrypted compute paths where applicable. Final hardware floors for these workers are calibrated against measured Stage 5 cost and published with the testnet open announcement; consumer-grade GPUs are explicitly accepted, with no datacentre-only tier. These roles are protocol-operated and are not paid from the gas-fee split, which has no compute channel — whether to open them as a paid permissionless role, and how to verify submitted work before paying for it, is an open item in §11.5.7(c).

10. Stage Roadmap

Sunima's development proceeds in five progressively decentralizing stages. Each stage is a cryptographic and economic strengthening of the previous.

Mainnet Readiness, Not Calendar Dates

Sunima does not announce mainnet dates. Mainnet ships when, and only when, every gating condition below is independently met and verified — not before. Calendar guesses early in a project age into broken promises, and a privacy-and-custody chain is the wrong place to ship on a clock instead of on artifacts.

Code velocity is what we control; audit cycles, operator recruitment, and validator decentralisation are not. We deploy artifacts as each stage is ready, on Arbitrum Sepolia and on the sovereign-chain testnet, and we publish measured numbers from those deployments. The mainnet announcement happens after the artifacts are public — not as a forward-looking promise.

Bootstrap Strategy — Solving the Anonymity-Set Cold Start

Privacy-preserving custody is structurally weaker the smaller its participant set. A vault with one user offers no anonymity at all — every transaction is trivially attributable. Most existing privacy chains face a chicken-and-egg problem at mainnet launch: users do not enter until the anonymity set is large; the anonymity set cannot grow until users enter. Sunima addresses this with a three-phase bootstrap explicitly designed before mainnet ship.

The combined effect: from day one of mainnet, the anonymity set is non-trivial because Phase 1 testnet graduates and Phase 3 long-locked positions are pre-committed before the chain opens to general traffic. Phase 2 organic inflow then compounds against an already-meaningful baseline rather than against zero. This is a structural answer to the cold-start critique that has historically constrained adoption of every privacy chain to launch with empty pools.

11. Token Economics — $SUNA

The native token of the Sunima sovereign chain is $SUNA.

11.1 Supply

Total supply: 100,000,000 (100 million) $SUNA, fixed at genesis, non-inflationary. The supply reflects a fixed-supply privacy store-of-value design and gives allocation flexibility across staking, node rewards, grants, and ecosystem incentives.

11.2 Utility

• Gas — all transaction fees on Sunima mainnet are denominated in $SUNA.
• Validator staking — CometBFT validators must bond $SUNA to participate in consensus. Slashing for downtime or equivocation.
• Defender/attacker node collateral — PRION nodes stake $SUNA; rewards and slashing are $SUNA-denominated.
• Governance — protocol parameter changes, gateway jurisdiction registry updates, and treasury disbursements are $SUNA-weighted votes.

11.3 Distribution

The 77% non-insider supply splits into three honest buckets — 17% users (retroactive airdrop, quarterly user rewards, freeze-insurance pool), 26% ecosystem (validator/security emissions, builder grants, bug bounty, community advocates), and 34% protocol (strategic reserve, treasury/operations, DEX liquidity, incentive reserve). Insiders are capped at 23% (team and seed/angel investors — no "strategic partner" tranche). No institutional VC rounds, no board seats, no governance control rights — the minority seed/angel allocation is issued as tokens-only with 5% TGE unlock, 36-month linear vesting on the remainder, and locked until mainnet. At 23% insiders, Sunima runs roughly half the insider weight of comparable Layer-1 launches (Starknet ~38%, Arbitrum ~44%) — while maintaining 0% institutional VC. No catch-all "community" label hiding what each allocation actually does.

11.3.0.5 Post-Mainnet Strategic Round — Rationale & Use of Proceeds

Sunima's supply structure is designed to minimize insider concentration while preserving the team's ability to onboard strategic participants post-launch. The 23% Insiders cap is intentionally below industry benchmarks (Starknet ~38%, Arbitrum ~44%).

This round does not exist because we need it. It exists because the right participant at the right moment — one who brings infrastructure, liquidity, or distribution rather than just capital — is worth having a mechanism for. That mechanism will not be used under pressure, on someone else's timeline, or at terms that compromise the network's independence.

The post-mainnet reserve is optional and may never be activated. Activation requires explicit on-chain authorization: prior to mainnet (Stages 1–4), a 3-of-5 Sentinel Committee vote with a 72-hour timelock; post-mainnet (Stage 5+), a DAO governance proposal with a minimum 67% approval threshold and a 48-hour timelock. In both cases, the activation intent is published on-chain no less than 14 days before any tokens are transferred. The founding team cannot activate this round unilaterally at any stage.

If activated, proceeds are allocated exclusively to:

• DEX liquidity provisioning — bootstrapping on-chain liquidity across primary trading pairs
• Ecosystem pools — grants and incentives for early protocol integrations and node operators
• Reserve backing — collateral buffer supporting network stability during early mainnet phases

No proceeds from this round are directed toward team compensation or operational expenses. All allocations are executed on-chain and publicly verifiable.

11.3.1 USD-funded liquidity programme — Two Complementary Pools

Sunima operates the USD-funded liquidity programme at two distinct layers, structurally separated by source-of-funds, governance, and trigger model. The two pools are complementary rather than redundant: one absorbs deterministic unlock pressure during the bootstrap window, the other handles long-horizon market distress.

The USD-funded liquidity programme purchases SUNA from the open market using stablecoin reserves and routes repurchased tokens into two channels: DEX liquidity pools (to deepen trading depth) and ecosystem allocations (builder grants, node operator incentives). This is not a burn mechanism — it is a recycling programme that returns purchased tokens to productive use within the network rather than permanently removing them from supply. The programme is funded from seed and angel round proceeds retained in stablecoins through SunimaRaiseV2. The specific reserve allocation is determined at round close and published on-chain prior to TGE.

The 8% seed/angel allocation is held and released through SunimaRaiseV2 at 0x809Dcbd660552FF4CAf67B7C9590c432A337e0d3 on Arbitrum Sepolia (Sourcify-verified). The contract converts the off-chain SAFT into on-chain enforcement: investor stablecoin deposits are isolated per round (no cross-round drainage), the founder cannot draw any tranche until vesting tokens are escrowed on-chain, milestone confirmations require 2 of 3 non-founder signers, and refunds for failed milestones use a per-investor basis-points accumulator (no shrinking shared pool — every investor's claim is independent of the order in which others refund). On milestone failure or multisig cancel, the corresponding $SUNA portion stays claimable by investors via partial-vesting scaling proportional to delivered milestones; the unreleased portion can be reclaimed by the founder once the round is fully resolved. Internal cold-eye review cleared after multiple zero-context cold-read iterations, with RAG retrieval against a large index of historical findings. The mainnet deployment of this contract is the canonical mechanism by which seed/angel tranches will be issued; the Sepolia instance is the audit-frozen reference.

11.4 Anti-Dump Structural Protections

The tokenomics is engineered to resist the post-TGE collapses common to L1 launches (Starknet, Wormhole, Pyth, Ethena all crashed >65% within 18 months due to insider and airdrop dumps). Sunima's protections:

• Low TGE circulating supply. Under approximately 2% of supply can be traded on launch day — airdrop's 10% TGE unlock (1M) + team TGE (~0.75M); seed/angel is locked until mainnet. The remaining ~98% is locked in vesting schedules, DAO reserves, and emission pools.
• Airdrop lockup. Only 10% of the retroactive airdrop unlocks at TGE; the remaining 90% vests linearly over 12 months, distributing sell pressure.
• Staking bonus. Users who lock their unlocked airdrop for 12 months receive a +20% bonus in $SUNA, paid from the strategic reserve. This structurally absorbs sell pressure.
• Claim window. Airdrop recipients have 12 months to claim. Unclaimed tokens return to the strategic reserve, preventing long-tail dumps from dormant addresses.
• No founder cliff exception. The founder's 1-year cliff is enforced on-chain, not by agreement. No tokens unlock for 365 days post-TGE regardless of circumstance.
• Investor lockup until mainnet. Seed and angel investors cannot receive any tokens until the sovereign L1 mainnet launch (Stage 5), even if TGE happens earlier on a Cosmos-SDK testnet.
• Maximum sell rate (post-cliff). Founder and core-team allocations are capped at 2 % per rolling 90-day window throughout the post-cliff period. Investor allocations are capped at 1.5 % per rolling 90-day window over the 3-year linear vest. Caps are enforced as a true rolling-window check inside SunimaVesting: any claim that would push the holder's 90-day claim total above the cap reverts at the contract level, not by off-chain agreement.
• DEX-only at launch. Mainnet day 1: Hyperliquid spot, Osmosis, and Uniswap. CEX listings are not part of the launch plan — any post-mainnet CEX migration requires a DAO vote and a security review. CEXes that mandate protocol-level KYC or custody are permanently excluded.

The combined effect: at TGE, Sunima launches with the lowest insider circulating supply of any recent L1, and the most transparent non-insider distribution since Hyperliquid — every bucket (users, ecosystem, protocol) labelled by what it actually does, no catch-all "community" hiding the breakdown. The narrative is straightforward — we are here to rebuild faith in crypto after the VC-dump era, not to extract from it.

11.5 Fee Distribution & Operator Economics

Sunima rejects token-emission inflation as a way to pay operators. The 7-year emission schedule (17% of supply, 17M SUNA) bootstraps validator security. After Year 7 emissions stop and operators are sustained purely by transaction fees plus bug-bounty payouts. Gas is governance-set on this chain and recalibrated to keep transactions cheap; the fee split below follows a committed 24-month ramp — the four channel shares interpolate linearly from their Year-1 values to their Year-3 values, clamped to the Year-1 values before launch and to the Year-3 values once the ramp completes. This is the committed §11.5 schedule implemented in the protocol's fee module for the sovereign chain mainnet.

Every gas fee paid on Sunima mainnet is split across three channels, each share interpolating linearly from its Year-1 to its Year-3 value over the 24-month ramp:

11.5.1 Ramp rationale

The ramp is deliberate bootstrap protection. In Year 1 only 30% of every fee is burned, the validator channel is at its widest (50% to operators), and the treasury takes 20% — so operators stay profitable while fee volume is still thin and the network is finding its footing. As the network matures the schedule normalises: burn climbs to 50% (deflation increases with maturity), and the validator and treasury shares step down toward their steady-state values (35% validator + 15% treasury). This sequencing exists to avoid deflating bootstrap-phase operators out of profitability before network volume stabilises — front-loading rewards while volume is scarce, then shifting weight toward deflation once volume can carry it.

The shares interpolate continuously over the 24-month window rather than stepping at annual boundaries, which removes any single transition date a coalition could game by timing artificial volume around a scheduled jump. Combined with privacy-violation slashing burn, the network is disinflationary while emissions run and net-deflationary at scale, as the ramping fee burn grows with usage beyond the fixed emission curve.

11.5.2 One operator class — by design

Consensus, block signing, chain-watching, RPC, and lite-PRION monitoring are one job on one class of machine, and the fee split pays for that job. Confidential compute runs off the consensus path on separate workers, which the protocol operates itself and which the fee split does not pay — accelerator hardware earns no fee income on this network.

A validator earns three streams: its share of the fee pool, the 2x staking-APY multiplier on its bonded SUNA, and SUNA bounty payouts for verified PRION pattern matches (drawn from the 3% Bug Bounty Pool in §11.3, not from the fee pool). Because no accelerator purchase is required, the cost floor an operator must clear is hosting rather than hardware.

11.5.3 What we explicitly do not do

• No token-emission inflation to pay operators after Year 7 — preserves long-term holder value.
• No free staking yield for non-stakers — prevents subsidy-by-others patterns.
• No KYC of operators — anonymity is a design property, not a workaround.
• No pre-committed per-operator floor payout — exact per-validator floor is calibrated empirically from Stage 3–4 testnet telemetry, published with the testnet open announcement. We do not pre-commit to numbers the protocol cannot guarantee.

11.5.4 Sybil-resistance dependency for CPU work-quality multiplier

The validator pool is specified to carry a work-quality multiplier on top of stake-weighting (uptime plus verified PRION pattern matches). This multiplier is gameable without sybil-resistance: a sophisticated attacker could spin up cheap permissionless nodes, manufacture pattern submissions, and farm the work-quality bonus. The multiplier therefore activates only after the PRION sybil-resistance shell ships — stake-weighted submission gating, two-of-three cross-validator confirmation on high-impact training samples, and anomaly detection on coordinated submission patterns. Until then the validator pool distributes purely by stake-weighting, with the work-quality multiplier zero. This dependency is published openly so operators see the activation condition before they commit stake.

11.5.5 Bear-market dynamic adjustment — multi-signal trigger

The bear-market trigger fires when any of four signals registers, not when a single volume threshold is crossed. A single-signal trigger is gameable: a coordinated coalition can sustain wash-trading volume above the threshold during a real downturn, keeping the burn high while real validators starve. Multi-signal triggers raise the cost of manipulation because every signal must be defeated simultaneously.

• Volume signal. Trailing 60-day network volume falls below the DAO-set bootstrap floor. (60-day chosen as compromise between 30-day noise and 90-day slowness; floor calibrated against testnet telemetry.)
• Organic-traffic signal. Trendline of unique sender-address counts drops below the rolling 90-day median by more than 40%. Sustaining wash-trading on the same address set keeps volume up but flattens this metric.
• Volatility signal. Network volume swings more than 5× in either direction within a 30-day window — a pattern that does not occur during normal organic growth and indicates either manipulation or genuine market stress.
• Validator-income floor signal. Average validator monthly income falls below the DAO-documented hosting-cost floor for two consecutive months. This signal fires regardless of network volume — even at high “volume”, if operators are not actually being paid enough, the protocol responds.

When any signal fires, the burn share (ramping 30% → 50%) is automatically reduced by 20 percentage points, and those 20 percentage points are redirected to the treasury. The treasury then has DAO authority — with 48-hour timelock — to apply those redirected funds as an operator-runway subsidy if the validator-income-floor signal also fires. The trigger and adjustment are protocol-level constants. The only discretionary step is the treasury-to-operator redirect, which the DAO can approve, deny, or partially apply. The mechanism reverses automatically when all four signals clear.

11.5.6 Profitability shape

The model is designed so that profitability scales with the network rather than depending on a fixed dollar floor. The protocol commits to shares of fee revenue, not absolute payouts; absolute operator income is whatever those shares produce against actual network volume in any given month.

• Validators at network maturity — receive a stake-weighted share of the validator pool (50% → 35%) against mature-network fee flow, by which point the share has ramped down to its 35% steady state. The channel is split stake-weighted across the active validator set and supplemented by the 7-year emission schedule during bootstrap.
• Validators in the early-mainnet phase — earn from the same pool, which sits at its widest 50% in Year 1, plus validator emissions while the network's volume is still growing. The wider early share is the bootstrap protection of §11.5.1: the intent is marginal-but-positive economics relative to server hosting cost so operators stay solvent during the network's growth window. Because no accelerator purchase is required, that floor is hosting rather than hardware, which is the main reason the target is reachable while volume is thin. If actual network volume falls below the level where this remains true, the §11.5.5 multi-signal trigger fires and the burn-to-treasury redirect activates the operator-runway path.
• Broad geographic coverage — pursued through the same pool rather than a separate lite-node channel. The bootstrap target is coverage rather than per-operator income maximisation. The work-quality multiplier (§11.5.4) — which selects for serious operators by amplifying rewards for verified PRION matches — activates only after the sybil-resistance shell ships.
• Treasury — sized to absorb prolonged bear-market action. The treasury share (20% → 15%) plus the §11.5.5 redirect mechanism provide structural — not discretionary — protection if network volume collapses.

The protocol publishes shares, not promises. Per-validator floor numbers are calibrated empirically from Stage 3–4 testnet telemetry and published with the testnet open announcement against measured network revenue, not pre-committed against revenue figures the protocol cannot guarantee.

11.5.7 Open iteration items

The model above is a starting point, not a final spec. The following parameters are deliberately left open. Each item is tagged with its expected resolution window so operators and integrators know when to expect closure.

• (a) Stake distribution parameters. Minimum stake to enter the validator set, maximum stake cap to prevent monopolisation, slash threshold that forces exit, restaking cycle for slashed validators returning to active duty. Resolution window: pre-mainnet via Sentinel Committee with publicly-reasoned decision (DAO governance becomes operative at Stage 5+, after mainnet launch).
• (b) Validator selection mechanism post-Garrison. The Garrison programme covers initial bootstrap selection. The mechanism for steady-state selection — permissionless join with stake floor, Sentinel approval, hybrid probationary path — is open. Resolution window: 6 months post-launch via DAO vote.
• (c) Whether confidential compute becomes a paid role. Compute workers are protocol-operated today and earn nothing from the fee split. Opening the role to a paid permissionless cohort requires a reward channel, and a reward channel requires verifying on-chain that submitted work was real — otherwise it pays for fabricated compute. Options: keep it protocol-operated; pay per verified proof from the treasury; or add a dedicated channel once work-verification is enforced. Resolution window: operational discovery, 12–24 months post-launch.
• (d) Slashing recovery path. After a Tier 1 (severe) slashing event: permanent exit, eligible to re-stake after a cooldown, reputation flag that decays, multiple-event compounding. Provisional default: re-stake after 30-day cooldown, reputation flag decays linearly over 12 months. Resolution window: operational discovery, 12–24 months post-launch.
• (e) Liquidity disposition for slashed stake. Burn portion immediate burn vs locked unstaking vs DEX auction. Provisional default: immediate burn for the burn share; whistleblower receives liquid SUNA; treasury and other-validator portions queued via existing unstaking schedule. Resolution window: 6 months post-launch via DAO vote.
• (f) Staking APY multiplier sliding scale. The 2x multiplier for node-runners is correct for bootstrap. At maturity it may concentrate stake on operators and hollow passive holders. A DAO-vote-driven slide from 2x toward 1.2x once active-operator count reaches a documented threshold. Resolution window: 6 months post-launch via DAO vote.
• (g) Validator collusion mitigations. A coordinated coalition holding ~30% of stake gains governance, consensus, and PRION false-flag attack surface. Mitigations under consideration: stake concentration cap (max % per detected entity), geographic-diversity requirements, jurisdictional isolation, validator rotation per epoch. Resolution window: pre-mainnet via Sentinel Committee with publicly-reasoned decision (DAO governance becomes operative at Stage 5+, after mainnet launch).

These items are published as open precisely because economic parameters that pretend to be final at design time tend to fail in practice. The Cosmos-chain governance histories of Cosmos Hub, Osmosis, and Polygon all show that initial economic parameters were renegotiated through DAO votes in the first 24 months post-launch. Sunima documents the parameters subject to change before launch rather than discovering them under stress, and tags each with its expected resolution window rather than leaving operators in scheduling limbo.

11.5.8 Explicit non-changes — and why

Two suggestions from external review were considered and rejected after analysis. The team publishes the rejection reasoning so operators see the argument, not just the decision.

Rejected: carving lite-nodes a separate dedicated fee share, or adding a stake-yield bonus. A separate channel would split one job across two pools and add an allocation argument between operator classes without adding security. The validator reward, scaled against the operator's marginal cost (an operator who already runs adjacent infrastructure — an unrelated VPS workload or a personal dev server — pays the fixed-cost portion of hosting once), produces a marginal-positive payoff that meets the broad-coverage objective without subsidising a hardware purchase. The work-quality multiplier (which selects for serious operators by amplifying rewards for verified PRION matches) activates only after the PRION sybil-resistance shell ships per §11.5.4. Until then, broad coverage is the correct optimisation target, and the single validator pool distributed purely by stake-weighting is sufficient.

Rejected: softening Tier 1 slashing severity in Year 1. Soft slashing during a launch window creates an “appeals to bad actors” period — Tier 1 violations (double-signing, malicious court-order vote, user-data disclosure without legal basis) are deliberate, not accidental. Softening severity for the launch period rewards exactly the operators the protocol is designed to repel. The 2% mercy fraction is already the design compromise that prevents complete financial annihilation; further softening introduces moral hazard. External round 1 review explicitly confirmed that 2% mercy at the current magnitude does not create moral hazard. The team holds the position.

12. Team & Governance

12.1 Operating Model

Sunima Labs operates under a private-stealth model. Core-team identities are not publicly disclosed. There are no public personal accounts attached to the project. All external engagement — grant applications, warm VC introductions, partner discussions — occurs through dedicated organizational channels.

Outreach for partnerships, grants, press and institutional enquiries is centralised at [email protected]. Technical community engagement — node-operator support, developer documentation, integration help — occurs through the public repository, the documentation site linked above, and the public Discord at discord.gg/AhqrrSKaC.

12.2 Progressive Decentralization

Stages 1–3 (live today) are operator-controlled: deployment keys, upgrade rights, and the cryptographic keys sit with the core team. Stage 4 transfers cryptographic authority to a threshold committee — a FROST 2-of-3 PoC has been verified end-to-end on Arbitrum Sepolia (May 2026), with the validator-programme distribution of share custody to follow. Stage 5 transfers protocol governance to $SUNA-weighted on-chain voting. Every stage reduces the core team's unilateral power; no stage increases it.

12.3 Governance (phased)

Protocol governance is deployed in two phases — a 3-of-5 Sentinel Committee multisig today and a token-weighted DAO at Stage 5+. Both phases retain a time-limited founder veto. This is the industry-standard "progressive decentralization" pattern used by Uniswap, Aave, and most production L1s.

Phase 1 — Stages 1 through 4 (Arb Sepolia deployment, pre-SAFT): governance is a 3-of-5 signer multisig (SunimaGovernance) with a 24-hour main-layer timelock (1-hour emergency, 72-hour rotation), founder-veto pre-sunset, and a 30-day Dead Man's Switch that elevates the rotation threshold to 4-of-5 if the founder is unreachable. Every admin action against CoreToken and SunimaVesting — including grant creation, minter authorisation, Layer5 rotation — originates from a committee proposal and passes through the timelock. This is the governance model live on Arb Sepolia (v0.5.3 deployment).

Phase 2 — Stage 5 onward (Sunima mainnet, Cosmos SDK): migration to token-weighted DAO with native on-chain voting (modeled on the ERC20Votes snapshot/checkpoint pattern). Any $SUNA holder can submit a proposal. Token-weighted voting (1 SUNA = 1 vote) requires 67% approval. Implementation requires fresh governance contract deploy (the current signer set is immutable by design — a known constraint acknowledged in the deploy record). For critical decisions — treasury disbursements above 5M SUNA, tokenomics parameter changes, slashing model updates, core protocol upgrades, validator set admissions, emergency measures — the founder multi-signature must also sign before execution. Without both (DAO majority AND founder signature), no critical change occurs.

Purpose: protection against hostile proposal swarms, short-term speculator-driven parameter attacks, and the "governance zero-day" pattern that has exploited undefended DAOs (Beanstalk 2022, various 2023 governance attacks).

Scope of veto: only critical categories. Ecosystem grants below 500K SUNA per project, community airdrop rounds below 1M SUNA, minor protocol parameter adjustments within pre-defined ranges — all operate as pure DAO without founder involvement.

Sunset: founder veto is enforced through Stage 5 mainnet launch plus 2 years. The clock starts the day mainnet ships — not on a pre-announced calendar date. After sunset, founder becomes a token holder equivalent to any other — no special authority, no emergency override, no reserved seat.

12.4 Slashing & Validator Accountability

Validator misbehavior is punished via graduated slashing with a mercy percent — a model unique to Sunima. Rather than the binary "full burn" used by some chains or the "no slashing" permissive posture of others (Solana, Avalanche), Sunima uses three tiers sized to severity, with a small residual returned to the slashed validator to avoid complete financial annihilation.

🔴 Severe violations (double-signing, voting against a legitimate court-order request, unauthorized data disclosure):

• 70% burned (deflationary — benefit to all $SUNA holders)
• 20% to the whistleblower who reported the violation (bug-bounty-style, incentivizes community monitoring)
• 8% to the protocol treasury
• 2% returned to the slashed validator (mercy — prevents total financial ruin, preserves future-deterrence incentive)

🟡 Moderate violations (persistent downtime, offline greater than 24 hours, repeated missed blocks):

• 50% returned to the validator upon reactivation (mercy — encourages rejoining the network)
• 30% redistributed to the remaining active validators (bonus for operators who stayed online)
• 15% to the protocol treasury
• 5% retained as unreturnable penalty (mercy tail)

🟢 Minor violations (occasional missed blocks, brief instability):

• 5% penalty redistributed to the remaining active validators
• No burn, no treasury allocation — the violation is not significant enough to warrant complex accounting

The mercy percent (2-5% returned to the slashed validator even in severe cases) is a deliberate Sunima-specific design decision. The operator retains a residual stake, which (a) preserves the economic incentive to avoid a second violation, (b) avoids the perverse "nothing left to lose" behavior seen in zero-recovery slashing regimes, and (c) signals that Sunima is punitive but not cruel. No known L1 uses this pattern; it is an intentional fork from the Ethereum/Cosmos default.

12.5 Reveal

The private-stealth model is a launch posture, not a permanent policy. The intended reveal is post-mainnet, at meaningful traction. The default narrative — published with deliberate delay — is that Sunima was built by a core team in close collaboration with frontier language models. The full story is held in reserve. Public identification of contributors is subject to their individual consent and strategic timing.

13. Risks & Mitigations

Every item below is an acknowledged limitation. Nothing here is concealed behind marketing language. Where a mitigation is aspirational (Stage 5+), we say so. Where a design is a conscious trade-off, we name the trade.

14. Conclusion

Sunima is a bet that privacy and compliance are not opposing forces. It is a bet that a protocol designed from day one to cooperate with legitimate legal process — while refusing to disclose anything outside of it — can serve the demographic that current privacy protocols and current custody protocols have both abandoned.

The architectural primitives are not new. Paillier encryption was published in 1999. Shamir Secret Sharing in 1979. Threshold cryptography is older than most of the team. Zero-knowledge proofs are mature. The novelty is in the composition: concentric defensive layers managed by a dedicated security brain, a physically separate custody fortress sealed by a combinatorially-distributed lock, and a narrow, protocol-native bridge to the legal system.

Stages 1–3 are closed and live on Arbitrum Sepolia, with Stage 4 Part 1 (privacy deposit layer) live and a FROST 2-of-3 threshold-MPC PoC verified end-to-end. The code is deployed. The keys are real. The vaults hold ETH. Third parties can transact today and observe first-hand that homomorphic balance arithmetic, on-chain Halo2-KZG attestations, and threshold-Schnorr verification are production-viable in ordinary EVM infrastructure. The remaining work — validator-programme distribution of MPC share custody, sovereign chain coordinator, and Stage 5 mainnet — is engineering, not research; each step builds on mature cryptography and established protocol patterns.

The work is public where it must be, private where it can be. The whitepaper is the resume. The contracts are the credentials. The fortress is the point.

© 2026 Sunima Labs · Whitepaper v1.6 · This document is subject to update as stages advance.
The information herein is provided for technical and investor review. It is not legal, financial, or tax advice.