# Accept deposits This is one of the most powerful things a zone does, and it is worth seeing plainly. Anyone holding USDC on Base can send it to a virtual address, and it lands as a private balance inside your zone, credited to your user. The payer does nothing special: no Kakushi account, no wallet change, no bridge screen. They make an ordinary transfer on the public chain, and it arrives inside the zone, private. The same path lets a user bring their own Base funds into the zone to make them private.  ## How a deposit crosses the boundary A deposit is a one-way bridge from the public chain into your private zone. Three steps, and your code only touches the last one: 1. The payer sends USDC to the virtual address from any wallet on the host chain, exactly like any other transfer. 2. The portal locks the canonical USDC on the host chain and the zone mints a balance backed one to one to your user inside the zone. 3. From that moment the balance is private. It is visible to you and the account holder, and invisible to the public chain it came from. The payer can be a customer, an employer, an exchange, or the user themselves moving their own funds in. None of them need to know the zone exists. They see a normal address and make a normal payment. ## Issue a virtual address Give out a fresh virtual address per payer or invoice. The deposit that lands on it is then self-attributing, and distinct addresses keep the public chain from linking all of a customer's deposits together. ```ts import { privateKeyToAccount } from "viem/accounts"; // acme's account; the key lives in your secret store, the SDK never sees it const acmeAccount = privateKeyToAccount(process.env.ACME_PRIVATE_KEY as `0x${string}`); const { virtualAddress } = await kakushi.accounts.createVirtualAddress({ account: acmeAccount, metadata: { reference: "invoice_4471", dueDate: "2026-07-01" }, }); // hand `virtualAddress` to whoever is paying; they send to it from any host-chain wallet ``` ## React when funds land You get two events: `deposit.received` when the payment is seen on the host chain, then `deposit.credited` when it is minted into the zone account as a private balance. Both carry the `virtualAddress` and the `metadata` you attached at claim time (the node stores it against the account), so you match the payment to the invoice with no lookup table. ```ts if (event.type === "deposit.credited") { markInvoicePaid(event.metadata.reference, event.amount); // now a private in-zone balance } ``` Need the funder for compliance? Pull attribution directly: ```ts const attribution = await kakushi.deposits.getAttribution(event.depositId); // funder address, amount, host-chain tx hash, block, time ``` :::tip The account materializes on first deposit, so you can hand out a virtual address before the recipient has ever touched the zone. You can fund a user who does not yet "exist," and the sender never needs to know whether they do. ::: :::note This is the deposit side of the [portal](/concepts/the-portal): canonical assets are locked on the host chain and a one-to-one backed balance is minted inside the zone. To send that balance back out to the host chain, see [Process withdrawals](/guides/withdrawals). :::