# Virtual addresses If you have ever used a bank's virtual account numbers, you already understand this. A bank gives a business one real account and lets it generate a different account number for every customer or invoice, all funneling into the same place, so the business always knows who paid without asking. A virtual address is that, on-chain.  You generate a fresh virtual address per payer, per invoice, per intent. Two things fall out of that for free. You get attribution: when money lands on `invoice_4471`'s address, you know exactly which invoice it was, with no reconciliation guesswork. And you get privacy: because each address is distinct, someone watching the host chain cannot tie all of a customer's deposits back to one identity, the same way virtual account numbers stop a counterparty from seeing your whole banking relationship. ```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", campaign: "march" }, }); // hand this address to the payer; the deposit that lands on it is self-attributing ``` Every deposit and every deposit webhook carries the `virtualAddress` and the `metadata` you attached when you claimed it, so matching a payment to its invoice needs no lookup table. :::tip Each virtual address is backed by a virtual forwarder, a tiny contract deployed lazily on the host chain the first time the address is funded. You can mint as many as you want without paying for them up front. :::