Compliance

Public chains expose every transaction. Pure mixers conceal everything and offer no engagement surface to legal process. Sunima sits between: cryptographic privacy by default, with a structured disclosure pathway for properly issued legal orders.

This is not pseudonymity (every chain offers that, and it has limits). It is not optional privacy where the default is public (every transaction stays exposed unless the user opts in). It is committed privacy with a structured lawful-process bridge that no single party — including the founder — can unilaterally open.

Three commitments shape the design:

• Sanctions screening at entry — addresses on ingested sanctions lists are blocked at the token-transfer layer with a fail-closed oracle, so a sanctions-bypass cannot be performed by taking the oracle offline.
• Targeted disclosure under court order — a binding order from a court of competent jurisdiction, scoped to specific addresses and a specific date range, can be executed by a threshold-signing committee. The committee does not act on agency requests, private parties, or unscoped fishing.
• Selective-disclosure proofs without full deanonymization — zero-knowledge proofs of solvency, sanctions-list non-membership, or threshold compliance, so users and exchanges can satisfy regulators without exposing the full transaction graph.

Active controls deployed and verifiable on Arbitrum Sepolia. Mainnet activation pends the disclosure-gateway design and Foundation entity setup described in the next section.

We publish the design before mainnet so it can be reviewed and criticized by counsel, regulators, and the security community before it is live. Each component below is documented in the whitepaper and will be externally audited before activation through a layered pipeline: PRION (the project's internal static-analysis pre-filter, RAG-grounded against the public audit corpus) ahead of independent competitive audit (Cantina / Code4rena / Sherlock) on the cryptographic core and the disclosure pathway contracts, with Immunefi running a continuous bug bounty after mainnet activation under a published severity-to-reward schedule.

A public, version-controlled mapping of the protocol against the cryptographic standards (NIST SP 800-57, FIPS 140-3, FIPS 203/204/205, NISTIR 8214) and financial-regulation regimes (OFAC, FinCEN BSA, FATF Recommendation 16, EU MiCA) that bear on a non-custodial protocol on a public blockchain. Sunima holds no certifications and pursues none — certifications target service providers, not public protocols. Alignment is shown by primitive selection and parameterisation, not by paperwork. Every claim below is auditable against the public source repository.

Financial-regulation regimes — protocol-vs-VASP perimeter

Financial-regulation regimes (FinCEN BSA, FATF Recommendation 16, EU MiCA, jurisdictional VASP/CASP frameworks) target service providers — Money Services Businesses, Virtual Asset Service Providers, Crypto-Asset Service Providers — not protocols. Sunima does not custody, transmit, or exchange user funds. Under FinCEN's 2019 guidance on convertible virtual currencies (FIN-2019-G001), an "anonymizing software provider" that does not itself accept and transmit funds is not classified as an MSB. The same architecture applies under FATF and MiCA: the Foundation is not a VASP/CASP. VASPs that interact with Sunima users carry their jurisdiction's obligations. Sunima exposes selective-disclosure proofs as the cryptographic cooperation surface for VASPs to satisfy Travel-Rule obligations on flows that pass through the protocol — a VASP can produce a proof of originator/beneficiary metadata for a specific transfer under a properly issued legal order, without breaking privacy for non-VASP transfers.

Standard-by-standard summary

Consolidated view: every standard named on this page, with how it relates to a non-custodial protocol on a public blockchain.

This describes the lifecycle of a binding disclosure order from intake to execution, once the FROST committee is operational at Stage 5. Each step has a stated owner, a stated time bound, and a defined output that is auditable after the fact.

1. 1. Intake. Order is delivered to the Foundation's registered agent for service of process. Operational legal correspondence channel: [email protected], forwarded to the registered agent for formal handling. Required: issuing court, certified copy of the order, named addresses, named date range, named predicates, verifiable contact at the issuing authority. Owner: Foundation legal counsel. Time bound: acknowledgement within 24 hours of receipt.
2. 2. Authentication. Counsel verifies the order is genuine, issued by a court of competent jurisdiction, and that the issuing authority is recognized under the laws of the Foundation's domicile, or via a mutual legal assistance treaty in force between the issuing authority and the Foundation's domicile (United States, European Union, United Kingdom by default; others on a case-by-case basis). Owner: Foundation legal counsel. Time bound: 48 hours from intake.
3. 3. Scope parsing. The order is reduced to a machine-checkable scope envelope: which addresses, which date range, which predicate fields. Anything not expressible as a scope envelope is sent back as a request for narrowing — this is a structural limit, not a discretionary one. Owner: Foundation legal counsel with technical review. Time bound: 48 hours after authentication.
4. 4. Challenge window. If the order is ambiguous or appears to overreach the cryptographic capability of the committee, the issuing authority is given 24 hours to clarify scope before the order is forwarded for signing. The challenge is procedural; the committee is not asked to evaluate substantive merits.
5. 5. Committee review. The scope envelope is broadcast to the FROST k-of-N committee. Each member independently verifies the order against published criteria (jurisdiction, scope expressibility, no extra-jurisdictional reach, no attempt to compel disclosure outside named addresses). Owner: each committee member individually. Time bound: up to 5 business days for off-chain individual review. Once committee outputs are submitted on-chain, the protocol's two-window pipeline (review 24 h, challenge 24 h — see whitepaper §8.2) bounds final disclosure to a further 48 hours.
6. 6. Signing or refusal. If k members sign the scope envelope within the review window, the disclosure transaction is composed and submitted on-chain, decrypting only the named state. If fewer than k members sign, no decryption occurs and the issuing authority is notified that the order did not reach threshold. Refusing members publish their refusal reasoning to the committee log; the substance of the order remains confidential until the public-disclosure cadence permits.
7. 7. Public log. The existence of an executed order — issuing court, scope class, date of execution, but not the decrypted contents — is added to a public, append-only committee log after a delay sufficient to protect ongoing investigations (default: 90 days, longer on request from the issuing authority with cause). The decrypted output is delivered only to the issuing authority through the formal channel that intake used.

Sunima's disclosure pathway is targeted by cryptographic construction, not by policy promise. The threshold-signing committee can only sign over commitments named in the scoped order — bulk surveillance hooks are not a feature that has been left out, they are a feature the design cannot express.

SUNA grants no equity, no profit-share, and no claim on Sunima Foundation reserves or treasury. The Foundation is structured as a non-profit-distributing legal entity; its reserves are deployed for protocol development, security audits, ecosystem grants, and the operational costs of the disclosure-pathway infrastructure described above. Use cases are functional: staking for validator selection, governance voting (subject to Foundation vetoes during mainnet bootstrap, see the governance documentation), gas payment, and access to certain protocol features.

The protocol is non-custodial. Users hold their own keys; the Foundation does not hold user funds. There is no admin pause on user balances at the token-contract level; the only mechanism that affects token movement is the deterministic sanctions oracle described above.

Final classification under any specific jurisdiction's law depends on that jurisdiction's tests. Where jurisdiction-specific advice is required, holders should consult local counsel. The project does not provide legal advice. Detailed allocation, vesting and release schedule: see Tokenomics.

We respond to legitimate inquiries from regulators, counsel acting on behalf of regulators, and law-enforcement authorities. We do not provide legal advice; we route inquiries to counsel where appropriate. Two channels are kept separate by design: [email protected] handles ongoing dialogue (questions on protocol controls, sanctions architecture, token structure, request-for-comment), and [email protected] handles the formal court-order intake pipeline that flows to the Foundation's registered agent. The split exists so that policy questions do not jam the formal pipeline, and so that the formal pipeline has a known channel that does not get diluted by general correspondence.

Short answers to the questions we are asked most often. Each is grounded in the cryptographic design, not in a policy promise.