<!--
Sitemap:
- [Welcome to Kakushi 隠し](/index): Kakushi is a private execution layer for institutions building on stablecoin rails.
- [What is Kakushi](/introduction/what-is-kakushi): Money is private.
- [Using Kakushi with AI](/introduction/using-kakushi-with-ai): Every page in these docs is available as plain markdown for use with language models.
- [Quickstart](/quickstart): This is the ten minute path.
- [Zones and the trust model](/concepts/zones-and-trust): A zone is a private blockchain only you can see inside, with a public chain's proofs underneath.
- [The portal](/concepts/the-portal): Money walks in as public USDC and becomes private the moment it crosses.
- [Accounts and custody](/concepts/accounts-and-custody): Your existing wallet address is already a Kakushi account. Nothing to deploy, nothing to enroll.
- [Bring your own address](/concepts/bring-your-own-address): A zone account is just an address, the one an auth key recovers to, with nothing deployed.
- [Virtual addresses](/concepts/virtual-addresses): Hand every customer their own address, the way a bank hands out virtual account numbers.
- [Private transfers](/concepts/private-transfers): Pay fifty thousand people and publish zero salaries.
- [Settlement and composability](/concepts/settlement-and-composability): Two institutions settle in real time without sharing a ledger or seeing each other's books.
- [Private deposits and withdrawals](/concepts/private-deposits-and-withdrawals): Soon, even the edges go dark.
- [Proofs and the verifier](/concepts/proofs-and-the-verifier): You cannot fake a balance, and you can prove you are solvent without showing a single customer.
- [Fees and gas](/concepts/fees-and-gas): Your users never hold ETH and never see gas. They pay in the dollars they are already sending.
- [Privacy and disclosure](/concepts/privacy-and-disclosure): The public sees nothing, you see everything, the regulator sees what the law entitles them to.
- [Zone policies](/concepts/zone-policies): Compliance is built into the zone. You configure your program; the substrate enforces it on every transfer.
- [Onboard a customer](/guides/onboard-a-customer): Two calls and a webhook, and your customer has a private on-chain account.
- [Accept deposits](/guides/accept-deposits): Anyone with funds on the host chain can pay into your zone, and it lands as a private balance for your user.
- [Make private transfers](/guides/private-transfers): One call moves money privately. One call pays a whole payroll.
- [Process withdrawals](/guides/withdrawals): Burn inside, release canonical USDC outside, in one call.
- [Settle between zones](/guides/settle-between-zones): Send money to another institution's zone like it is a withdrawal. It is interbank settlement.
- [Handle webhooks](/guides/webhooks): React to money moving. Do not poll for it.
- [Reconcile](/guides/reconcile): Two numbers that must always match. Assert it on a schedule.
- [Non-custodial integration](/guides/non-custodial-integration): The user signs on their device. You never hold the key, and you still cannot move their money.
- [Compliance and disclosure](/guides/compliance): You hold the whole record. Disclosure is an export, not a negotiation with the protocol.
- [SDK reference](/sdk-reference): The look-it-up layer.
- [Connect and EVM reference](/connect-and-evm-reference): The chain-level integration detail.
- [Run a zone](/run-a-zone): Most operators never run any infrastructure.
- [Protocol spec](/protocol-spec): The deep technical layer, for auditors and engineers integrating below the SDK.
- [Resources](/resources): See Key concepts for the working vocabulary, expanded throughout Core concepts.
-->

# Protocol spec

The deep technical layer, for auditors and engineers integrating below the SDK.

**Overview.** A zone is a private EVM with a single sequencer that settles to a host chain through a portal, gated by a proof-agnostic verifier. Deposits enter through a hash chain, withdrawals leave through a hash chain that resolves to a host-side queue, and batches commit aggregate state transitions verified on the host chain.

**Host-side contracts.**

* `ZoneFactory`: deploys and registers a zone and its portal.
* `ZonePortal`: locks canonical assets on deposit, releases them on withdrawal, validates batch submissions.
* `ZoneInbox` and `ZoneOutbox`: the in-zone mint and burn authorities. The inbox is the sole minter, the outbox the sole burner.
* `ZoneConfig`: holds zone parameters.

**Deposits.** Each virtual address is backed by a virtual forwarder, a host-chain contract deployed lazily via `CREATE2` the first time the address is funded. Deposits are recorded in a hash chain ordered newest-outermost, which makes appending O(1). Native ETH deposits are detected by balance scanning through Multicall3's `getEthBalance`. ERC-20 deposits are detected from the token contract's `Transfer` events filtered by recipient. A consequence worth knowing: plain-transfer deposit UX and event-based native detection are mutually exclusive at the EVM level, so native detection uses the balance scan by design.

**Withdrawals.** Withdrawals are constructed as a LIFO hash chain in the zone's outbox, which the host side processes into a FIFO ring buffer with a fixed capacity. Each withdrawal is processed against the portal, releasing the canonical asset.

**Batches and settlement.** The operator submits batches through `submitBatch`, which validates against an anchored host block using EIP-2935 historical block hashes. One proof amortizes across every transaction in the batch.

**State transition function.** The core is a pure `no_std` Rust function:

```rust
pub fn prove_zone_batch(witness: BatchWitness) -> Result<BatchOutput, Error>
```

`BatchWitness` carries everything the transition needs as input; `BatchOutput` commits the resulting state. The function is `no_std` so the identical code runs in a zkVM, a TEE, or the node, with no forked implementation of consensus-critical logic. In practice `no_std` here means no `std`, while still using `alloc` for `Vec` and map types with a backend-provided allocator.

**Proving and verification.** The on-chain verifier implements a minimal `IVerifier` interface and is proof-agnostic. V1 settles with real SP1 zero-knowledge proofs verified on-chain through that interface. Because the interface is proof-agnostic, a different backend, another zkVM or a TEE, can be plugged in later without changing the portal or the state transition function. The deployment-mode property (zkVM, TEE, or node) follows directly from the `no_std` state transition function.

**Security model and assumptions.** The operator is trusted to order transactions and to see zone state, and is not trusted for solvency, which the proof enforces. Canonical assets can only be released by a valid proof. Users trust the operator the way a bank customer trusts a bank, and that residual trust is named and bounded rather than implicit.