Executive Summary

Sunima is the first blockchain where privacy and regulatory compliance coexist by design.

Existing privacy blockchains (Zcash, Monero, Tornado Cash, Aztec, Aleo) offer anonymity at the cost of regulatory rejection. Existing compliance solutions (CEX custody, traditional banking) offer legal clarity at the cost of user privacy. Every project to date has treated these as opposing forces.

Sunima resolves the contradiction through five coordinated innovations:

1. Defense-in-Depth Architecture — A focused suite of four privacy-first DeFi products (DEX, Staking, Lending, Bridge), each engineered with multiple independent validation, authorization, and settlement layers. The full internal topology is documented for verified node runners and auditors.
2. TFHE by Default — Every balance, transfer, and internal state variable is encrypted using Torus Fully Homomorphic Encryption. Users interact with encrypted data without ever exposing plaintext to any party, including the protocol itself.
3. Quantum-Proof Distributed Custody — The master threshold key is split across 100 Shamir shares, distributed across five independent layers (node runners, smart contracts, user wallets, founder infrastructure, and physical paper backups). No single compromise vector can reconstruct the key.
4. Programmable Compliance via AI Sentinel — A three-tier monitoring system filters 99% of transactions through static rules, 0.9% through lightweight machine learning, and 0.1% through full HYDRA consensus audit. Gray-market transactions are respected; black-market transactions (OFAC sanctions, terror financing, ransomware) are flagged and subject to court-ordered selective disclosure.
5. Code Over Identity — Sunima Labs operates without a public team roster, without VC backing, and without paid advisors. The protocol is the team. The whitepaper is the resume. The audited contracts are the credentials. Trust comes from open code and verifiable cryptography, not from biographies.

1. The Problem: Privacy and Compliance as False Dichotomy

1.1 Existing Privacy Solutions Fail Institutions

Privacy in cryptocurrency today exists on a spectrum, but every point on that spectrum fails one critical constituency:

• Monero, Zcash: Maximum anonymity, but unusable by institutions because compliance reporting is technically impossible.
• Tornado Cash: Strong privacy via mixing, but was sanctioned by OFAC in 2022 precisely because it had no disclosure mechanism.
• Aztec, Aleo: Privacy via zero-knowledge proofs, but no built-in legal framework for selective disclosure.
• Zcash with view keys: Centralized trust in key holders; viewing keys are single points of failure.
• Fhenix, Zama fhEVM: Excellent FHE primitives, but no end-to-end compliance stack.
• Traditional custodians (Coinbase, Fireblocks): Full compliance, zero privacy. Every transaction is visible to the custodian, which means visible to any subpoena.

Institutional investors managing billions of dollars have a simple requirement: they want the ability to transact privately while maintaining the ability to prove, when legally required, that their funds are not connected to sanctioned entities or criminal activity. No existing blockchain provides this.

1.2 Existing Compliance Solutions Fail Users

Traditional financial institutions offer compliance, but at a cost:

• Banks expose all transaction data to regulators by default.
• Centralized exchanges suffer from custodial risk (FTX, Celsius, Mt. Gox).
• Freezes and seizures happen unilaterally, without user consent.
• Know-your-customer requirements expose user identity to every counterparty.

The Sunima thesis is that compliance should be programmable, selective, and consensus-based — not centrally enforced by any single party.

1.3 The Gray Market Reality

Approximately 80% of global wealth sits in the "gray market": legal but unregistered, offshore but compliant, private but not criminal. Freelancers paid in crypto, families supporting relatives across borders, businesses shielding trade secrets, individuals in authoritarian regimes protecting their savings.

Sunima treats gray-market users as the primary customer base. We do not surveil them. We do not flag them. We provide the same privacy guarantees to a Brazilian freelancer as to a Swiss family office.

Sunima treats black-market users (sanctioned entities, terror financiers, ransomware operators) as an adversary. We flag them algorithmically and cooperate with legitimate legal processes under strict multi-party consensus.

2. The Sunima Vision

2.1 Philosophical Foundation

Sunima is built on three convictions:

Conviction 1: Trust should come from mathematics, not from people.

Every major crypto failure of the past decade — FTX, Celsius, Terra/Luna, Ronin, Wormhole — traces back to human weakness: fraud, greed, social engineering, insider betrayal. The cryptographic primitives were never at fault. The humans managing them were.

Sunima minimizes human trust to the absolute theoretical minimum: the single human co-founder cannot unilaterally access user funds, cannot reverse transactions, cannot mint new tokens, and cannot pause the network. All privileged operations require multi-party consensus from geographically and organizationally distributed participants.

Conviction 2: Privacy is a fundamental right, compliance is a legitimate social contract.

These are not in conflict when implemented correctly. A Swiss bank gives you privacy from your neighbors but cooperates with criminal investigations. Sunima provides the same guarantees, implemented in code rather than in contract law.

Conviction 3: Code is the team. Identity is irrelevant.

Sunima Labs operates without a public team page, without LinkedIn farms, without "meet the founders" sections. We do not believe in the cult of personality. We believe in the cult of verifiable code. Every line is open to scrutiny. Every audit is published. Every protocol decision is recorded on-chain. If you want to know who built Sunima, read the code. If you want to know who is responsible if something breaks, read the protocol — the answer is "nobody, and that is the point."

2.2 Operating Model

Sunima Labs explicitly rejects the traditional crypto founding pattern of public team pages, VC raises, advisory boards, and influencer campaigns. The reasons are practical, not ideological:

• Public team pages create attack surfaces. Named individuals can be socially engineered, threatened, sanctioned, kidnapped, or coerced. Anonymous protocols cannot.
• VC raises distort incentives. Discounted token allocations to investors create dump pressure on retail buyers and align the protocol with short-term exit thinking.
• Advisory boards are decorative. Most crypto advisors are paid lobbyists who add brand prestige but no operational value.
• Influencer marketing is propaganda. A protocol that needs paid promoters is a protocol that cannot defend itself on technical merits.

The Sunima approach is to publish working code, working contracts, and working audits, then let the community evaluate the protocol on its own merits. We do not announce milestones — we deploy them. We do not promise features — we ship them.

This composition is non-negotiable and is part of the protocol's identity.

3. The Sunima Suite

3.1 Overview

Sunima offers a focused set of privacy-first DeFi primitives. Each is engineered to feel like a familiar product to anyone who has used Ethereum DeFi, but with end-to-end TFHE encryption built in from the ground up. Real liquidity, real users, real fees — and complete confidentiality of amounts, balances, and positions.

The user-facing surface consists of four products. Behind that surface, Sunima follows a defense-in-depth design philosophy: every protocol operation passes through multiple independent validation, authorization, and settlement layers before it touches user funds. The internal organization of these layers, including the specific module boundaries and access control topology, is documented in technical specifications available to verified node runners and protocol auditors. We do not publish the full internal architecture on the public website for the same reason that banks do not publish vault floor plans.

What we do publish — and what every user can verify — is the product surface, the cryptographic guarantees, the governance model, the compliance framework, and the audit results.

3.2 SunimaDEX — Confidential Trading

SunimaDEX is an automated market maker that lets users swap any supported asset against any other with confidential amounts. Functionally, the product feels like Uniswap V2: deposit a pair into a liquidity pool, earn a share of trading fees, swap between assets, withdraw at any time. Cryptographically, every swap amount is encrypted under TFHE before it touches the chain. Observers see that a swap occurred. They do not see the size, the direction, or the resulting balance change.

Liquidity providers earn fees in $SUN, the protocol's native token. Pool ratios are maintained through encrypted arithmetic, so the AMM curve operates correctly without any party — including the protocol itself — observing the underlying values in plaintext.

3.3 SunimaStake — Confidential Yield

SunimaStake is a yield-bearing vault that lets users deposit assets and earn rewards denominated in $SUN. The product is conceptually similar to Pendle, Curve gauges, or any other modern yield protocol: stake, accrue, claim, withdraw. The cryptographic difference is that all balances are stored as TFHE ciphertexts. An observer who reads the contract storage directly learns only the Merkle root of an encrypted balance tree. The individual stakes, the rewards earned, and the claim history are invisible to everyone except the staker.

Reward distribution is computed through encrypted arithmetic. The protocol can prove that rewards were calculated correctly without revealing which addresses earned how much.

3.4 SunimaLend — Confidential Lending

SunimaLend is a lending and borrowing protocol inspired by Compound V3. Users supply assets to earn interest, borrow against collateral, and get liquidated only when their collateralization ratio falls below the protocol's safety margin. The familiar mechanics work as expected.

The cryptographic difference is that position sizes, collateral amounts, and health factors are all encrypted. A liquidator bot scanning the chain cannot identify which positions are at risk by reading the public state. Liquidations are instead triggered through a dedicated authorization flow that grants liquidator bots selective access to specific positions when the encrypted health factor crosses the threshold, without revealing the rest of the user's portfolio.

3.5 SunimaBridge — Confidential Cross-Chain Transfer

SunimaBridge connects Sunima to other major chains (Ethereum, Arbitrum, Base, Fhenix, and others) through a validator attestation model inspired by Wormhole. Messages are signed by a rotating set of validators and verified on destination chains.

The cryptographic difference is that the message contents are encrypted end-to-end. The bridge validators sign attestations of message validity (the message was correctly formed, the source chain confirmed it, the cryptographic proofs are valid) without ever seeing what they are attesting to. This means even a complete compromise of the bridge validator set does not leak user data, and even a colluding majority of validators cannot construct fraudulent transfers without the underlying cryptographic material.

3.6 Defense in Depth

All four products share a common engineering philosophy: defense in depth. Every operation that touches user funds passes through multiple independent layers of validation, each responsible for a specific class of checks:

• Input validation — every parameter is verified against the protocol's invariants before any state changes are computed.
• Rate limiting — per-address and per-product limits prevent abuse, including Sybil attacks and high-frequency exploitation attempts.
• Sanctions and compliance filtering — every transaction is checked against the Sentinel compliance engine (described in Section 6) before settlement.
• Threshold authorization — operations above configurable size thresholds require multi-party approval from the node runner network.
• Settlement queues and circuit breakers — large outflows are subject to delayed settlement, and abnormal aggregate outflows trigger automatic protocol-wide pause until manual review by the compliance engine.

Each layer is engineered as an independent module with strict access control. A vulnerability discovered in one layer cannot cascade into the others. The full internal topology — module names, function signatures, storage layouts, access control matrices — is published only to verified auditors under standard audit engagement terms. This is intentional. Public disclosure of internal architecture provides material assistance to attackers without providing meaningful benefit to legitimate users, who interact with the protocol exclusively through the four product surfaces described above.

Sunima will publish all third-party audit reports in full, redacting only the specific module identifiers and address derivations that would enable targeted attacks. Users who want maximum verification can run a Sunima node themselves — node runners receive the full technical specification as part of the protocol software.

4. Cryptographic Foundations

4.1 TFHE as the Primary Encryption Scheme

Sunima uses Torus Fully Homomorphic Encryption (TFHE) as its primary cryptographic primitive. TFHE was selected over competing schemes (BFV, BGV, CKKS) based on an explicit optimization criterion: security multiplied by the square of speed.

TFHE's advantages for our use case:

• Programmable bootstrapping: Arbitrary functions can be computed on ciphertexts without noise budget degradation. Critical for long-lived encrypted balances that undergo millions of updates.
• Fast bit-level operations: TFHE excels at Boolean circuits and comparisons, which dominate our operation mix.
• Production-ready implementations: Zama's fhEVM and Fhenix CoFHE provide mature TFHE integration for EVM-compatible chains.
• TFHE-rs (Rust): The fastest TFHE implementation in the world, maintained by Zama. Used for off-chain computations and client-side SDK operations.

For specific batch-processing workloads (such as AI model inference in encrypted form), Sunima retains the option to use CKKS as a secondary scheme.

4.2 Shielded Pool with Merkle Tree of Notes

User balances are not stored as individual mappings. Instead, they are represented as "notes" in a growing Merkle tree, in the style of Zcash Sapling and Tornado Cash.

Each note contains an encrypted amount (euint64), a commitment to the recipient's stealth address, and a randomized nullifier. When a user deposits into the protocol, a new note is added to the tree. When a user withdraws, the corresponding note is marked as spent via its nullifier. Internal transfers execute by removing one note and adding another.

Key parameters:

• Tree depth: 20, providing an anonymity set of 1,048,576 notes.
• Hash function: Poseidon, chosen for efficiency in zero-knowledge proof circuits.
• Root updates: Batched. Multiple note operations combine into a single Merkle root update per block, reducing gas costs by approximately 100×.
• Growth: The tree grows dynamically. When full, a new tree is automatically allocated.

4.3 ERC-5564 Stealth Addresses with ERC-4337 Account Abstraction

Every withdrawal from the shielded pool goes to a fresh stealth address derived from the recipient's meta-address. No stealth address is ever reused.

The process:

1. Bob publishes a meta-address consisting of two public keys: a spending key and a viewing key.
2. Alice generates a random ephemeral private key.
3. Alice computes Bob's new stealth address as hash(Bob_spending_pubkey * ephemeral_privkey).
4. Alice creates a note in the shielded pool referencing this stealth address.
5. Bob scans the pool's encrypted announcement registry, discovering the note intended for him.
6. Bob can then spend from the stealth address by deriving the corresponding private key.

This stealth address is deployed as an ERC-4337 smart contract wallet. The wallet is created via CREATE2 at the moment of first use, can automatically forward its contents to a final destination, and can self-destruct in the same transaction (EIP-6780 compatible). This makes stealth addresses truly ephemeral.

The net effect: an external observer sees Alice deposit into a Sunima product contract, and later sees an ephemeral address appear with funds, but cannot cryptographically link the two.

4.4 HYDRA-Fast Stealth Discovery

One historical weakness of stealth address schemes is slow discovery. In Zcash, scanning for incoming notes can take minutes or hours. Sunima solves this with a dedicated off-chain relay network called HYDRA-Fast Stealth: encrypted announcement hints are posted on-chain, a decentralized relay network forwards them to subscribed meta-addresses via WebSocket, and Bob's wallet receives push notifications within 1-2 seconds of the transaction.

This gives users the UX of a traditional bank transfer while preserving the cryptographic privacy of a shielded pool.

5. Quantum-Proof Distributed Custody (QPDC)

5.1 The Custody Problem

Every custodial solution faces the same fundamental question: who holds the keys? The possible answers all have failure modes:

• User holds keys: Single point of failure. Lost seed phrases equal lost funds.
• Company holds keys: Single point of attack. FTX, Celsius, Mt. Gox.
• Multisig with N humans: Coordination difficulty, social attack surface.
• Hardware security module: Physical attack surface, manufacturer trust.
• MPC with validators: Better, but typically implemented with centralized validator sets.

Sunima takes a radically different approach: the master threshold key is never assembled in one place, on any device, at any time. Instead, it exists only as 100 Shamir secret sharing shares, distributed across five independent storage layers, with a threshold of 67 required for reconstruction.

5.2 The Five-Layer Distribution

The 100 shares are allocated as follows:

Layer 1 — Node Runners (40 shares). Node runners are permissionless: anyone can download the Sunima node software and run it on a machine anywhere in the world. Node runners are not employees, contractors, or partners of Sunima Labs. They are independent operators, analogous to Bitcoin miners or Ethereum validators. Because node runners are not legalized, licensed, or registered with any jurisdiction, Sunima Labs bears no legal responsibility for where they operate.

Layer 2 — Smart Contract Encryption (15 shares). Encrypted and embedded inside smart contracts on multiple blockchains. Public ciphertext, useless without the decryption key.

Layer 3 — Wallet-Derived User Shares (15 shares). Distributed to high-value depositors via HKDF:

share_i = HKDF(master_share, salt=wallet_address, info="sunima-recovery-v1")

To reconstruct the user's share, one needs both the wallet's private key and the original master share. Neither alone suffices. This binds the security of the protocol to the security of its largest users, creating a structural alignment of incentives.

Layer 4 — Founder Infrastructure (15 shares). Stored on persistent hardware-encrypted storage. RAM, GPU memory, and ephemeral storage are explicitly excluded.

Layer 5 — Paper and Metal Backups (15 shares). Paper printouts in bank safety deposit boxes, steel backup plates (fire and flood resistant), sealed envelopes held by trusted individuals in different countries. Fully air-gapped, quantum-resistant.

5.3 Threshold Reconstruction

To reconstruct the master key, 67 shares must be collected from the five layers in any combination. The Shamir scheme does not distinguish between shares from different layers; it only counts them.

Combinations that succeed:

• 40 from Layer 1 + 15 from Layer 2 + 12 from Layer 3 = 67 ✓
• 40 from Layer 1 + 15 from Layer 2 + 15 from Layer 4 = 70 ✓
• 30 from Layer 1 + 15 from Layer 2 + 15 from Layer 4 + 15 from Layer 5 = 75 ✓

Combinations that fail:

• 40 from Layer 1 alone = 40 ✗
• 40 from Layer 1 + 15 from Layer 2 = 55 ✗
• All shares from Layers 2-5 except user shares = 45 ✗

5.4 What QPDC Protects Against

The Sunima QPDC model provides protection against the following adversaries:

• Hackers (including state-level APT groups)
• Single governments — no single jurisdiction contains enough shares
• Protocol insiders (including the founder, who holds only 15 shares)
• OFAC sanctions — shares are distributed globally
• Validator collusion — even all node runners hold only 40 shares
• Social engineering — no single party holds the full key
• Physical theft — multiple redundant physical locations
• Fire, flood, earthquake — metal backups in geographically separated sites
• Founder death — emergency recovery via user and node runner shares
• Quantum computing — paper backups are air-gapped
• Smart contract exploits — core logic is immutable
• MEV and front-running — all amounts are encrypted
• Chain reorganizations — threshold consensus prevents reorg attacks

The only scenarios in which the protocol could fail are global thermonuclear war, permanent global internet shutdown, or a coordinated attack involving 67%+ of node runners in dozens of countries, the founder personally, multiple trusted individuals, and physical access to paper backups in multiple locations — all executed simultaneously. The mathematical probability of the third scenario is effectively zero.

6. Programmable Compliance

6.1 The Sentinel Architecture

Sunima's compliance engine is called the Sentinel. It is a three-tier monitoring system that observes all transactions on the protocol and makes real-time decisions about whether to allow, flag, or freeze them.

This tiered approach scales economically: even at 1 million transactions per day, the total compliance cost is bounded at approximately $5,000 per day — orders of magnitude less than the cost of a traditional KYC/AML department at a financial institution.

6.2 The Court Order Gateway

When a law enforcement agency obtains a legitimate court order targeting a specific address on Sunima, they submit the order through the Court Order Gateway — an on-chain contract that accepts signed petitions from pre-registered legal authorities.

The petition must include the jurisdiction, case number, target addresses, legal basis, and a statement of proportionality. Node runners vote on the petition, evaluating the issuing jurisdiction, legal sufficiency, and proportionality of the request.

If 67% of active node runners approve, the relevant shares are assembled and the specific information is decrypted and delivered. The petition, its approval, and its outcome are logged on a public transparency registry.

This process has several important properties:

• No single jurisdiction can compel compliance: A US court order alone cannot force disclosure, because US-based node runners are a minority.
• No single entity can abuse the process: The node runner network must collectively agree.
• Transparency: All approved disclosures are publicly logged.
• Proportionality is enforced: Mass-surveillance requests are structurally rejected.

6.3 Gray Market vs. Black Market

Sunima explicitly distinguishes between gray market and black market activity.

Gray market activity is not flagged or surveilled: unregistered freelance income, cross-border remittances outside formal banking channels, personal privacy in financial matters, business transactions shielded from competitors, individual savings protection in unstable jurisdictions, tax minimization through legal offshore structures. Gray market users are Sunima's primary customer base.

Black market activity is flagged and subject to disclosure: transactions involving OFAC-sanctioned addresses, ransomware payment patterns, terror financing, and transactions linked to specifically identified criminal operations.

The threshold for flagging a transaction as black market is high and based on objective criteria, not subjective judgment.

7. Token Economics

Sunima's native token is SUN. It serves three primary functions: gas payment, staking collateral, and governance voting. Total supply: 100,000,000 SUN, fixed and non-inflationary.

Initial distribution:

Notable omissions:

• No VC allocation. Sunima is not raising venture capital in the traditional sense. No seed round, no Series A, no strategic partners receiving discounted tokens.
• No advisor allocation. There are no advisors.
• No team allocation beyond the founder. There is no team beyond the founder.

Of the protocol's share of all fees, 50% is burned (permanently removed from circulation) and 50% is used to fund the treasury. This creates deflationary pressure on SUN supply as protocol usage grows.

8. Roadmap

Sunima is developed under a focused, sequential build cadence with deliberate phase boundaries. Every milestone ships a verifiable artifact: testnet contracts, audit reports, working demos. Nothing is announced before it is deployed.

9. Risks and Mitigations

We do not hide from risk.

• TFHE performance bottlenecks — Mitigated by using FHE only where strictly necessary, batch processing, precomputation, and eventual native precompiles.
• Audit costs — Mitigated by continuous internal auditing via HYDRA TERMINATOR, engaging specialized auditors only for final pre-mainnet review, and community bug bounty.
• Regulatory pushback — Mitigated by engaging with crypto-friendly legal counsel in multiple jurisdictions, publishing the Court Order Gateway specification for public review, and positioning Sunima as a privacy-preserving compliance tool rather than a privacy-maximizing anonymity tool.
• Competitive copying — Mitigated by execution speed, ecosystem effects, and a long technical roadmap. By the time a competitor could replicate the full defense-in-depth architecture and Distributed Custody, Sunima will already have node runner distribution and integration partnerships that are difficult to overcome.
• Founder burnout — Mitigated by the sustainable work cadence (30-50 weekly hours, not 80-100), parallel revenue streams, and the AI partner handling the majority of implementation details.
• Bootstrapping liquidity — Mitigated by modest initial liquidity (under $100,000), founder capital, parallel bug bounty revenue, and gradual track record building.
• Novel cryptographic combination — Mitigated by formal verification tools for critical invariants, external cryptographer review, and conservative design choices.

10. Comparison to Existing Projects

Sunima is the only solution that provides all nine properties simultaneously.

11. Conclusion

Sunima is an ambitious attempt to resolve one of cryptocurrency's oldest contradictions: the conflict between privacy and compliance. We believe these are not opposing forces but rather two legitimate values that can and should coexist in well-designed financial infrastructure.

Our approach combines proven cryptographic primitives (TFHE, Shamir secret sharing, stealth addresses, Merkle trees) with novel architectural patterns (defense-in-depth product design, the Sentinel compliance engine, Quantum-Proof Distributed Custody) and an uncompromising operating philosophy: code over identity, math over marketing, protocol over people.

We do not claim to have solved all the problems. We acknowledge the significant risks outlined in Section 9. We are aware that our timeline estimates may be optimistic. We know that regulatory attitudes may shift unfavorably.

But we also know that the alternative — continuing to accept the false dichotomy between privacy and compliance — is worse. The current ecosystem forces institutional investors to choose between regulatory safety and privacy, between custody and self-sovereignty, between public transparency and personal discretion. These choices should not be mutually exclusive, and Sunima is our attempt to prove that they are not.

We invite the crypto community, the privacy research community, the legal and regulatory community, and the machine learning community to review our approach, criticize our assumptions, and — if they find merit in what we are building — join us as node runners, depositors, or collaborators.

Sunima Chain — The First Compliant Privacy Blockchain
Sunima Labs · 2026 · Trust from math, not from people