<!--
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.
-->

# Run a zone

Most operators never run any infrastructure. Kakushi deploys and hosts the zone for you, and you administer it from the dashboard. Running the node yourself is an option for institutions that want the infrastructure inside their own environment.

**Two ways to run a zone.**

* **Managed (default).** Kakushi deploys, hosts, and operates the zone infrastructure for you. You create a zone with one click from the dashboard, configure it there, and start integrating with the SDK the same day. You hold operator authority and see your full ledger; we run the node, the batch submission, and the host-side plumbing underneath it.
* **Self-hosted (option).** You run the zone node in your own environment. Same software, same architecture, same dashboard for administration. This suits institutions with strict infrastructure or data-residency requirements that want the node inside their own perimeter.

![Deployment modes: a managed, Kakushi-hosted zone versus a self-hosted zone in your own environment.](/images/deployment-modes.svg)

**One-click deployment.** From the dashboard you create a zone in a single step. Kakushi deploys the host-side contracts (the portal through the `ZoneFactory`, plus config, inbox, and outbox) and stands up the zone node, then hands you a configured zone with its RPC endpoint, chainId, and portal address ready to use. What used to be a protocol deployment is a button.

**Configure from the dashboard.** Zone settings are managed in the dashboard, which signs the underlying host and zone transactions for you through its privileged signing surface: the canonical assets the zone represents, the zone gas rate, the recovery account, which tokens are enabled, and operator key rotation. Enabling a token provisions its in-zone representation through the system registry path, not a user contract deployment.

**Zone architecture.** Under the hood a zone has three parts: the zone node (the Rust process that executes transactions, produces blocks as the single sequencer, and submits batches to the host chain), the host-side contracts (portal, factory, config, inbox, and outbox), and the dashboard you administer it from. In managed mode Kakushi runs the first two for you. Self-hosting means you run the node, and everything else stays the same.

**The Kakushi Dashboard.** Administration and operations live in the dashboard, not in the SDK. It provides role-based access control, multi-factor authentication on privileged actions, an audit log, confirmation steps on irreversible operations, and a read-only status feed compatible with monitoring tools like Datadog and PagerDuty. It is also the privileged signing surface for deployment and configuration changes.

**Monitoring and operations.** The status feed surfaces batch submission health, withdrawal queue depth, and the reconciliation invariant (locked canonical assets versus zone supply) so you can alert on any divergence, whether the zone is managed or self-hosted.