# MCP Server Source: https://docs.veil.cash/build-with-veil/mcp-server Expose Veil as agent tools with the @veil-cash/mcp server [`@veil-cash/mcp`](https://www.npmjs.com/package/@veil-cash/mcp) is a local MCP server that wraps `@veil-cash/sdk` and exposes Veil as Base MCP-compatible tools for agents. It runs **alongside Base MCP**: Veil prepares private and calldata actions, and Base MCP submits public transactions via `send_calls`. ## Install Add Veil MCP to your client's `mcpServers`, beside Base MCP: ```json theme={null} { "mcpServers": { "base-mcp": { "url": "https://mcp.base.org" }, "veil": { "command": "npx", "args": ["-y", "@veil-cash/mcp"] } } } ``` Use the npm package, not a GitHub install—it's versioned and resolves its `@veil-cash/sdk` dependency automatically. Pin a version with `@veil-cash/mcp@0.2.1` for reproducibility. For clients that start tools at session startup, install globally (`npm install -g @veil-cash/mcp`) and use `"command": "veil-mcp"` to avoid per-launch npm resolution. ### Hermes Agent [Hermes Agent](https://hermes-agent.nousresearch.com) users can add Veil MCP as a stdio server in `config.yaml`: ```yaml theme={null} mcp_servers: veil: command: veil-mcp connect_timeout: 10 ``` ## Enabling fund-moving tools The server starts **read-only** with no configuration (`veil_status`, `veil_x402_quote`, `veil_get_balances`). To enable `veil_pay_x402`, `veil_withdraw`, and `veil_transfer`, provide `VEIL_KEY` (and optionally a dedicated `RPC_URL`): ```json theme={null} { "mcpServers": { "veil": { "command": "npx", "args": ["-y", "@veil-cash/mcp"], "env": { "VEIL_KEY": "0x...", "RPC_URL": "https://your-base-rpc" } } } } ``` Configure `RPC_URL` with a dedicated Base RPC endpoint. Private balance and proof-building flows pull Merkle data, historical events, and queue state, which can exceed public RPC rate limits. Use `veil_init_keypair` to generate a random local keypair—it writes `.env.veil` and returns only the public deposit key. ## Tools | Tool | Purpose | | -------------------------- | ----------------------------------------------------------- | | `veil_init_keypair` | Generate and save a random local Veil keypair | | `veil_status` | Check key, relay, wallet, and registration status | | `veil_get_balances` | Read wallet, queue, and private balances | | `veil_deposit_status` | Check one queued deposit by pool and nonce | | `veil_wait_for_deposit` | Poll a queued deposit until accepted/rejected/refunded | | `veil_prepare_register` | Return Base `send_calls` calldata for registration | | `veil_prepare_deposit` | Return Base `send_calls` calldata for ETH/USDC deposits | | `veil_withdraw` | Submit a private withdrawal through the Veil relay | | `veil_transfer` | Submit a private transfer through the Veil relay | | `veil_consolidate_utxos` | Merge fragmented private UTXOs into fewer notes | | `veil_pay_x402` | Pay an x402 resource from private USDC via any facilitator | | `veil_x402_quote` | Probe an x402 resource for price/requirement without paying | | `veil_x402_receipts` | List local x402 spend history and total USDC spent | | `veil_x402_payer_balances` | Inspect USDC left on deterministic x402 payer EOAs | | `veil_subaccount_status` | Read subaccount status | ## Public vs private flows `veil_prepare_register` and `veil_prepare_deposit` return `{ chain, calls }` to pass directly to Base MCP `send_calls`—these are ordinary onchain transactions from your wallet: ```json theme={null} { "chain": "base", "calls": [{ "to": "0x...", "value": "0x0", "data": "0x..." }] } ``` Deposits treat `amount` as the net amount intended to land in Veil; the 0.3% protocol fee is included in the prepared calldata. After Base MCP confirms, the deposit enters the Veil queue. For addresses without instant verification, [0xbow screening](/intro/verified-users/0xbow-screening) applies first (typically \~15 minutes, up to 5 days for complex cases); once approved, queue processing into private balance is typically \~8–12 minutes. Track deposits with `veil_deposit_status` or `veil_get_balances`. See [Verified Users](/intro/verified-users) for instant paths. If `veil_prepare_register` returns `action: "alreadyRegistered"` with an empty `calls` array, skip `send_calls` and proceed to deposit or balance checks. Private actions (`veil_withdraw`, `veil_transfer`, `veil_pay_x402`) build proofs locally and submit through the Veil relay instead of Base MCP. ## x402 payments `veil_pay_x402` pays a standard x402 v2 Base USDC `exact` resource from your private USDC balance, with a spend cap, pre-flight probe, and funded-payer reuse. The full flow and scope are on the [Private x402 Payments](/build-with-veil/private-x402) page. Heavy x402 usage can fragment private UTXOs; when `veil_get_balances` reports `needsConsolidation`, call `veil_consolidate_utxos` to merge notes. ## Safety MCP responses never include `VEIL_KEY`, wallet private keys, proof arguments, nullifiers, encrypted outputs, x402 signatures, or private relay internals. `veil_withdraw`, `veil_transfer`, and `veil_pay_x402` require `confirm: true` because they submit through the Veil relay rather than Base MCP approval links. Verify a recipient is registered for Veil before a private transfer. # Overview Source: https://docs.veil.cash/build-with-veil/overview Build on Veil with the SDK, CLI, and MCP server Veil ships developer tooling so you can integrate private deposits, withdrawals, transfers, and payments into your own apps and agents. There are two surfaces, and the MCP server is built on top of the SDK. `@veil-cash/sdk` — a TypeScript library and `veil` CLI for keypairs, register, deposit, withdraw, transfer, merge, and subaccounts. `@veil-cash/mcp` — a local MCP server that exposes Veil as agent tools, running alongside Base MCP. ## Which one do I use? * **Building an app or script** → use the **SDK & CLI**. The CLI is the quickest path for most users; the SDK is for programmatic integration. * **Building an agent** → use the **MCP Server**. It wraps the SDK and exposes Veil as MCP tools, designed to run beside [Base MCP](https://mcp.base.org). ## Public vs private actions Veil splits cleanly into two kinds of action: * **Public** (register, deposit) — these are ordinary onchain transactions from your wallet. The SDK/CLI can emit unsigned calldata, and the MCP returns Base MCP `send_calls` calldata so your wallet (or Base MCP) submits them. * **Private** (withdraw, transfer, x402 payment) — these build a ZK proof locally and submit through the **Veil relay**, never exposing your private key or balance graph. ## Supported assets * **ETH** — 18 decimals, native (via WETH) * **USDC** — 6 decimals, `0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913` Both packages are published on npm: [`@veil-cash/sdk`](https://www.npmjs.com/package/@veil-cash/sdk) and [`@veil-cash/mcp`](https://www.npmjs.com/package/@veil-cash/mcp). # Private x402 Payments Source: https://docs.veil.cash/build-with-veil/private-x402 Pay x402 resources from your private Veil USDC balance using any x402 facilitator that supports this scope Veil supports **standard x402 payments** funded from your private Veil USDC balance. Instead of paying a metered API or paid resource from a public EOA you use elsewhere, Veil withdraws the exact amount to a **fresh, single-use payer address** and signs a standard x402 payment from it. The merchant sees an ordinary x402 payment and settles through any facilitator that supports this scope—nothing on their side changes. x402 support is built for **agents and developers** paying for resources programmatically, via the [SDK & CLI](/build-with-veil/sdk-cli) (`@veil-cash/sdk`) and the [MCP Server](/build-with-veil/mcp-server) (`@veil-cash/mcp`). It funds payments from your private USDC balance—no custom merchant integration required. ## How it works ```text theme={null} private Veil USDC → withdraw exact amount to fresh payer EOA → payer signs x402 payment → facilitator settles ``` 1. Your agent requests a paid resource and receives a standard **402** with x402 v2 payment requirements. 2. The SDK derives a **fresh payer address** deterministically from your Veil key and a payer index. 3. The SDK builds a normal Veil USDC withdrawal proof and funds that payer with the **exact** payment amount through the Veil relay. 4. The payer address signs the standard x402 payment, and the merchant's facilitator settles it onchain and pays gas for that leg. Each payment uses a fresh payer address (via a new `payerIndex`), which avoids reusing the same public address across payments. The Veil withdrawal to fund that payer and the x402 payment from it are still public onchain legs. ## Privacy boundaries Veil hides your **source wallet and private balance graph**. It does **not** hide the funding or payment legs. Still visible or correlatable: * the Veil pool withdrawal to the fresh payer address * the payer address's payment to the merchant * the USDC amount * timing between funding and payment * merchant and resource-server metadata * your agent's IP/session metadata, unless routed separately Fresh per-payment payer addresses reduce address reuse across payments, but they do **not** remove amount and timing correlation. Treat x402 payments as unlinkable from your wallet, not fully anonymous. ## Supported scope The MVP is intentionally narrow: * **Protocol:** x402 v2, `exact` scheme * **Network:** Base mainnet (`eip155:8453`) * **Asset:** Base USDC (`0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913`) * **Funding:** your private Veil USDC balance Requests for other schemes (`upto`, batch settlement), other networks, or non-USDC assets are rejected with a clear error **before any funds move**. ## Paying from an agent (MCP) The Veil MCP server exposes `veil_pay_x402` for agents: ```text theme={null} veil_pay_x402({ url, method?, body?, headers?, maxPayment?, payerIndex?, forceFresh?, confirm }) ``` * Requires `confirm: true`. * **Pre-flights** the endpoint before funding—if the unpaid probe does not return `402`, it withdraws nothing (useful for malformed requests). If the probe returns `402` but the merchant validates only after payment, the payer may still be funded while delivery fails; see [Recovery](#recovery). * Enforces a **spend cap**: `maxPayment` is a decimal USDC string (e.g. `"0.10"`), defaulting to and hard-capped at **10 USDC**. A requirement above the cap is rejected before funding. * **Reuses funded payers**: before a fresh withdrawal it scans already-funded payer addresses; if one holds enough USDC it offers reuse instead of withdrawing again. This recovers funds when a payment funded but delivery failed. Reusing a funded payer links both attempts to the same public EOA—MCP surfaces this as `reuse_available` rather than doing it silently. Use `veil_x402_quote` for a dry run, `veil_x402_receipts` for spend history, and `veil_x402_payer_balances` to check for funds stranded on a payer. See the [MCP Server](/build-with-veil/mcp-server) page for the full tool list and setup. Funding many small payments produces small change notes that can fragment your balance. `veil_get_balances` reports a per-pool fragmentation summary, and `veil_consolidate_utxos` merges notes via a private self-transfer. ## Paying from application code (SDK) ```typescript theme={null} import { payX402Resource } from '@veil-cash/sdk'; const result = await payX402Resource({ url: 'https://merchant.example/paid-resource', rootPrivateKey: process.env.VEIL_KEY as `0x${string}`, payerIndex: 42n, maxPayment: '0.10', // cap exposure; reject if the resource demands more relayUrl: process.env.X402_RELAY_URL, rpcUrl: process.env.RPC_URL, }); console.log({ status: result.response.status, payerAddress: result.payerAddress, relayTx: result.relayTransactionHash, paymentTx: result.paymentTransactionHash, }); ``` Use a fresh, persisted `payerIndex` for each payment. `quoteX402Resource()` probes a resource without paying; `getX402PayerBalances()` reports USDC held by each derived payer address (useful for recovering funds after a failed payment); and `reuseExistingBalance: true` retries a payment whose funding succeeded but whose delivery failed, paying directly from the already-funded payer with no new withdrawal. See [SDK & CLI](/build-with-veil/sdk-cli) for install and setup. ## Recovery If a payment fails after funding, the USDC stays on the payer address and is recoverable—the payer key is derived from your Veil key and the payer index. The MCP reuse flow and the SDK's `reuseExistingBalance` path recover these funds without a second withdrawal. For the underlying tooling, see [SDK & CLI](/build-with-veil/sdk-cli) and [MCP Server](/build-with-veil/mcp-server). For how your keys work, see [Veil Keypair](/technical/veil-keypair). # SDK & CLI Source: https://docs.veil.cash/build-with-veil/sdk-cli Integrate Veil programmatically with @veil-cash/sdk and the veil CLI [`@veil-cash/sdk`](https://www.npmjs.com/package/@veil-cash/sdk) is a TypeScript SDK and CLI for Veil privacy pools on Base. Generate keypairs, register, deposit, withdraw, transfer, and merge ETH and USDC privately—plus deterministic subaccounts and x402 payments. ## Install ```bash theme={null} npm install @veil-cash/sdk # or: yarn add @veil-cash/sdk / pnpm add @veil-cash/sdk ``` For global CLI access: ```bash theme={null} npm install -g @veil-cash/sdk ``` The CLI binary is `veil`. The SDK is the entry point for programmatic integration; the CLI is the quickest path for most users. ## CLI quick start ```bash theme={null} # 1. Set your Ethereum wallet key export WALLET_KEY=0x... # 2. Derive and save your Veil keypair veil init # 3. Register your deposit key (one-time) veil register # 4. Check your setup veil status # 5. Deposit (amount is what lands in your balance; 0.3% fee added on top) veil deposit ETH 0.1 veil deposit USDC 100 # 6. Inspect balances veil balance veil balance queue --pool usdc veil balance private # 7. Private actions veil withdraw ETH 0.05 0xRecipient veil transfer ETH 0.02 0xRecipient veil merge ETH 0.1 ``` The CLI is human-readable by default. Add `--json` for stable machine-readable output, and `--unsigned` to emit transaction payload JSON for automation and agents (no private key required—set `SIGNER_ADDRESS` for address-only flows). ## Deposits The amount you specify is the **net** amount that arrives in your Veil balance. A **0.3% protocol fee** is added on top automatically. ```bash theme={null} veil deposit ETH 0.1 # 0.1 ETH lands in pool (~0.1003 ETH sent) veil deposit USDC 100 # 100 USDC lands in pool (~100.30 USDC sent) veil deposit ETH 0.1 --unsigned --address 0x... ``` Deposits require compliance screening or an instant [Verified Users](/intro/verified-users) path—see [0xbow Screening](/intro/verified-users/0xbow-screening) for how non-verified deposits are processed. Shielded minimums are **0.01 ETH** and **20 USDC** (after the 0.3% fee); deposit slightly above the floor so the net amount still clears. See the [FAQ](/veil-cash-pools/faq) for details. After your wallet confirms the transaction, the deposit enters the Veil queue before it reaches your private balance. For addresses without instant verification, [0xbow screening](/intro/verified-users/0xbow-screening) typically takes about **15 minutes** (complex cases up to **5 days**, plus a holding period). Once approved, queue processing into your private balance is typically around **8–12 minutes**. ## Private actions Withdraw to a public address, transfer to another registered Veil user, or merge small notes. These build a ZK proof locally and submit through the Veil relay. ```bash theme={null} veil withdraw USDC 50 0xRecipient veil transfer USDC 25 0xRecipient # recipient must be a registered Veil user veil merge USDC 100 ``` ## Subaccounts Subaccounts are deterministic child slots derived from your main `VEIL_KEY` (Base mainnet only): ```text theme={null} root key → slot → child key → child deposit key → forwarder ``` ```bash theme={null} veil subaccount derive --slot 0 veil subaccount status --slot 0 veil subaccount deploy --slot 0 veil subaccount sweep --slot 0 --asset eth veil subaccount merge --slot 0 --pool eth veil subaccount recover --slot 0 --asset usdc --to 0xRecipient --amount 25 ``` See [Sub Accounts](/technical/subaccounts) for how these work end to end. ## x402 payments The SDK exposes `payX402Resource()` and helpers for paying standard x402 resources from a private USDC balance. See the dedicated [Private x402 Payments](/build-with-veil/private-x402) page. ## Environment The CLI uses two config files: `.env.veil` holds your Veil keypair (created by `veil init`); `.env` holds your wallet config. * `VEIL_KEY` — your Veil private key (ZK proofs, withdrawals, transfers) * `DEPOSIT_KEY` — your Veil deposit key (public; register/deposit) * `WALLET_KEY` — Ethereum wallet private key (signs transactions) * `SIGNER_ADDRESS` — Ethereum address for unsigned/query flows when signing is external * `RPC_URL` — Base RPC URL (optional; defaults to public RPC) * `RELAY_URL` — override the relay base URL * `X402_RELAY_URL` — x402 relay base URL (optional; defaults to `RELAY_URL + /x402` or hosted relay `/x402`) `WALLET_KEY` and `SIGNER_ADDRESS` are mutually exclusive. Use `WALLET_KEY` for commands that sign transactions, and `SIGNER_ADDRESS` for address-only agent flows like `status`, `balance`, and `register --unsigned`. ## Error handling Errors are standardized JSON with machine-readable codes so scripts can detect failures reliably: ```json theme={null} { "success": false, "errorCode": "VEIL_KEY_MISSING", "error": "VEIL_KEY required. Set VEIL_KEY env" } ``` Common codes include `VEIL_KEY_MISSING`, `INVALID_AMOUNT`, `INSUFFICIENT_BALANCE`, `USER_NOT_REGISTERED`, `NO_UTXOS`, `RELAY_ERROR`, `RPC_ERROR`, and `CONTRACT_ERROR`. Full programmatic API reference, browser proof generation, and AI-agent/signer integration notes live in the SDK guide (`SDK.md`) in the [`@veil-cash/sdk` repo](https://github.com/veildotcash/veildotcash-sdk). # Veil Cash Protocol Source: https://docs.veil.cash/index Veil banner ## Introduction Veil Cash is a privacy-preserving protocol on Base L2 for arbitrary-amount ETH and USDC deposits, transfers, and withdrawals. Privacy uses a UTXO model with Groth16 zero-knowledge proofs and Poseidon hashing. Users derive keys from an Ethereum wallet signature or import a private key. Shielded balances are encrypted UTXOs onchain; only the owner can decrypt and spend them. Before entering the pool, every deposit is screened for compliance. Users verified via Coinbase EAS, Binance BABT, or Ethos reputation are auto-approved; others are submitted to [0xbow](https://0xbow.io/). Approved deposits join the pool; declined deposits are rejected and refunded to the sender. See [Verified Users](/intro/verified-users) for supported eligibility options. Withdrawals and transfers are submitted through a relay, so users never need to hold gas to transact privately. #### Disclaimer *Veil.Cash is experimental software. Use it at your own risk, as the creators are not liable for any losses, damages, or legal issues that may arise. Ensure compliance with your local laws and understand the risks before interacting with the protocol.* # Onchain Privacy Source: https://docs.veil.cash/intro/onchain-privacy Public blockchains make transfers and balances easy to inspect: with an address, anyone can trace history onchain. **Onchain privacy** limits that exposure—shielded value, private sends, or both—while activity still settles onchain. **Veil Cash** applies this on Base L2 for ETH and USDC—see the [introduction](/). ## Why it matters Network-wide transparency keeps execution verifiable, but a public graph of every transfer is a weak default when you need discretion—personal spending, treasury flows, or relationships you do not want fully linkable onchain. ## Common uses * **Day-to-day activity**: Reduce how clearly habits and counterparties map to one address onchain. * **Sending to others**: Fund people or new wallets without exposing your full history. * **Execution and liquidity**: Lower visibility into timing and flow relative to public observation. * **Gifts and donations**: Support causes without broadcasting identity-linked transfers. * **Less unwanted attention**: Limit scraping, profiling, and passive monitoring of your onchain footprint. **Next:** [How to use Veil Cash](/veil-cash-pools/how-to-use-veil-cash) covers account setup, deposits, private transfers, and withdrawals. # 0xbow Screening Source: https://docs.veil.cash/intro/verified-users/0xbow-screening 0xbow and Veil Cash bring privacy to more users on Base. 0xbow announcement image ## Screening overview Veil Cash integrates [0xbow](https://0xbow.io/) ASP so incoming deposits get **KYT** (Know Your Transaction) screening before they enter the pool. You can use **any Base address**; when screening applies, funds move through the **one-time** queue flow below until 0xbow clears them. 0xbow screening image ## About 0xbow [0xbow](https://0xbow.io/) builds compliant **onchain** privacy infrastructure for **peer-to-peer** transfers at scale. Their **Privacy Pools** protocol on Ethereum balances privacy for legitimate users with screening that excludes illicit actors. **ASP** runs **KYT** on deposits, adds passing funds to the **association set**, and supports the trust model Privacy Pools use across **L1s, L2s**, and other deployments—including Veil on Base. ## How screening works When a deposit comes from a user who is not yet verified, the following process applies: Queue flow ### Deposit to Queue The user's funds are first sent to a temporary queue contract, not directly into the Veil pool. This holding contract isolates the deposit until compliance checks are completed. Deposit queued screen ### KYT Screening Initiated Right after the deposit, Veil's deposit engine asks 0xbow to screen the funds. 0xbow runs **KYT** blockchain analysis on the funds' origin and history—including links to illicit activity or sanctioned addresses. **Most** screenings finish in about **15 minutes**; complex cases can take **up to 5 days**. ### Holding Period A 6-hour holding period is applied to screened deposits. During this time, 0xbow's off-chain checks are expected to complete. The user will see their deposit as pending in the queue. If 0xbow clears the deposit earlier, the funds can move forward before the 6 hours are up. Holding period screen ### Approval and Deposit If 0xbow approves the deposit, no risky or illicit source detected, the Veil operator address finalizes the deposit. The operator pulls funds from the queue contract into the Veil pool contract and credits the amount to the user's private balance. The underlying zk proof for the deposit is generated automatically by Veil's backend. The user does not need to generate or handle any proofs. Approved deposit screen ### Rejection and Refund If 0xbow declines the deposit, for example if funds are linked to a known illicit source or otherwise fail compliance rules, the deposit never enters the pool. The funds in the queue contract are returned in full to the original depositing address. No fee is collected and no privacy is provided on rejected deposits. ## Additional notes This 0xbow integration allows Veil to maintain its compliance-oriented privacy model even as it opens access to unverified users. Screening is performed using onchain transaction history only. 0xbow does not require government IDs, selfies, or other personal identity documents from users. Veil remains non-custodial throughout this process. Funds move between smart contracts controlled by the user and the protocol. Veil never takes ownership of user assets at any point in the screening or deposit flow. If a user's funds are clean, the deposit enters the pool with the same anonymity guarantees as any other deposit. Once inside the pool, deposits from screened addresses are indistinguishable from deposits by pre-verified users. If the funds fail screening, the deposit never joins the pool and is returned in full to the original address, with no protocol fee charged and no privacy benefit provided. # Binance BAB Token Source: https://docs.veil.cash/intro/verified-users/binance-bab-token Binance BAB Token banner Mint or manage a BAB token from Binance: [binance.com/en/BABT](https://www.binance.com/en/BABT). ## What it is **Binance Account Bound (BAB)** tokens are onchain credentials Binance issues after identity verification (KYC). They are **soulbound** on **BNB Smart Chain** (non-transferable, revocable by Binance, one per user). Veil never receives your KYC details; eligibility is only whether your wallet is a BAB holder when a deposit is processed. BAB token example screen ## How to get a BAB token 1. Complete Binance identity verification (KYC). 2. Open the [BAB token page](https://www.binance.com/en/BABT) while signed into Binance. 3. Connect a wallet on **BNB Smart Chain** (for example MetaMask or Trust Wallet). 4. Mint BAB to that wallet. You need a small amount of **BNB** for gas. Use the **same 0x address** you will use on **Base** with Veil (one key, two networks). ## How Veil uses it When your deposit is handled, Veil **checks in the background** whether you qualify—including whether your wallet **still holds a BAB** on BNB Smart Chain, together with any other verification paths that deployment supports (for example Coinbase). You **do not** need to register or re-confirm in the app first. If your address is a BAB holder at the time that check runs, your deposit can be **accepted on the verified path** without you doing anything extra in Veil. ## Next steps Mint BAB to the wallet you use with Veil on Base, then deposit as usual. For the full flow, see [How to use Veil Cash](/veil-cash-pools/how-to-use-veil-cash). Other eligibility paths are on [Verified Users](/intro/verified-users). # Coinbase Onchain Verification Source: https://docs.veil.cash/intro/verified-users/coinbase-onchain-verification Coinbase Onchain Verification banner Complete onchain verification at [coinbase.com/onchain-verify](https://www.coinbase.com/onchain-verify). **Coinbase Onchain Verification** links a self-custodial wallet to a verified Coinbase account using Ethereum Attestation Service (EAS) on Base. Veil reads those attestations so an eligible wallet counts as **pre-verified** for pool deposits—no 0xbow path for that wallet when the attestation is valid. ## What it is Coinbase issues an onchain attestation that the connected address maps to a verified Coinbase identity. That gives a trust anchor without Veil holding Coinbase data directly. More background: [Onchain Verification (Coinbase Help)](https://help.coinbase.com/en/coinbase/getting-started/verify-my-account/onchain-verification). ## How Veil uses it The app checks EAS contracts on **Base**. If your wallet has a current Coinbase verification attestation, the frontend treats you as verified for deposits into Veil's pools. ## Next steps Connect the verified wallet in Veil and deposit as usual. For the full product flow, see [How to use Veil Cash](/veil-cash-pools/how-to-use-veil-cash). Other eligibility paths are listed on [Verified Users](/intro/verified-users). # Ethos Verified Users Source: https://docs.veil.cash/intro/verified-users/ethos-verified-users You need an Ethos **score of 1400 or higher** (inclusive) for the Ethos verification path. Ethos banner ## What it is [Ethos Network](https://ethos.network) is a reputation and credibility platform. Instead of uploading KYC to Veil, you can qualify when **Ethos recognizes your wallet** and your **score** meets Veil's current threshold. For deposits, Veil only uses that **score** (and whether Ethos returns a profile for your address)—not identity documents. ## How Veil uses it When your deposit is handled, Veil **checks in the background** whether you qualify on Ethos **and** any other verification paths that deployment supports (for example Coinbase or Binance BAB). You **do not** need to register or re-confirm Ethos inside Veil first. If your wallet meets the **score requirement at that moment**, your deposit can be **accepted on the verified path** without you doing anything extra in Veil. If Ethos has no profile for your address, or your score is below the threshold, that path will not count as verified. ## Requirements * **Score:** **1400** minimum, inclusive. The product may raise or lower this over time. * **Building your score:** see [Ethos](https://ethos.network)—Veil does not control how scores are earned. ## Next steps Use the same wallet on Base that is linked to your Ethos profile, then deposit as usual. Walkthrough: [How to use Veil Cash](/veil-cash-pools/how-to-use-veil-cash). Other paths: [Verified Users](/intro/verified-users). # Verified Users Source: https://docs.veil.cash/intro/verified-users/index Veil limits pool deposits to **verified** addresses. You qualify through **pre-verification** (Coinbase, Binance, or Ethos) or, when that does not apply, **0xbow** screening on the deposit. That **vetted-user** model balances strong onchain privacy with responsibility: only eligible addresses or deposits that pass KYT screening reach the pool—unlike a fully open mixer, but still private for legitimate use. ## Verification options | Provider | Waiting period | Details | | ----------- | ------------------------ | ------------------------------------------------------------------------------------ | | Coinbase | Instant | [Coinbase Onchain Verification](/intro/verified-users/coinbase-onchain-verification) | | Binance | Instant | [Binance BAB Token](/intro/verified-users/binance-bab-token) | | 0xbow | Usually under 15 minutes | [0xbow Screening](/intro/verified-users/0xbow-screening) | | Ethos Score | Instant | [Ethos Verified Users](/intro/verified-users/ethos-verified-users) | For how deposits fit into the rest of the protocol, see the [introduction](/). # Deployments Source: https://docs.veil.cash/technical/deployments Contract addresses for Veil Cash ### Veil Pool Contracts * `Veil Entry - 0xc2535c547B64b997A4BD9202E1663deaF11c78a5` * `ETH Pool - 0x293dCda114533FF8f477271c5cA517209FFDEEe7` * `USDC Pool - 0x5c50d58E49C59d112680c187De2Bf989d2a91242` * `ETH Queue - 0xA4a926A2E7a22c38e8DFC6744A61a6aA8b06B230` * `USDC Queue - 0x5530241b24504bF05C9a22e95A1F5458888e6a9B` Deprecated * `cbBTC Pool - 0x51A021da774b4bBB59B47f7CB4ccd631337680BA` * `cbBTC Queue - 0x977741CaDF8D1431c4816C0993D32b02094cD35C` ### Helper Contracts * `Hasher - 0x2460da3AcdA8A3BDbB2149c948363233D3453ac2` * `Verifier2 - 0x69013e62EF76BF1A7B980957607c944C9BD4FDF5` * `Verifier16 - 0xB5e025044b09cAe75bace1c8dB9701aE383792e4` * `Onchain Verify - 0xb5B3C6192E1871c613e0C415108Ba3934237F360` ### Contracts Repository View the Veil pool contracts repository on GitHub ### Audit Veil Cash's live ETH and USDC privacy pools completed a collaborative audit with [Sherlock](https://www.sherlock.xyz/) on March 10, 2026, covering the pool contracts and core ZK components. Read the final audit report Veil Pool builds on [Tornado Cash Nova](https://github.com/tornadocash/tornado-nova), introducing only minimal, well-scoped changes related to pool entry. Nova underwent a full audit by Zeropool in 2021. *** ### Token Contracts * `VEIL Token - 0x767A739D1A152639e9Ea1D8c1BD55FDC5B217D7f` * `Staking Contract - 0x7Bc834b3D64662eB2fFF868F55d3A9994D4252a0` # Sub Accounts Source: https://docs.veil.cash/technical/subaccounts Receive funds privately using unique deposit addresses derived from your main wallet Sub Accounts main view Sub Accounts give you **separate deposit addresses** under one wallet. Each address is unique and **unlinkable** to your main Veil address, so you can receive ETH or USDC privately before those funds are shielded into the pool. Sub Accounts are in **beta**; you can have up to **three** slots today. That cap may rise later. ## How Sub Accounts work Each slot is derived **deterministically** from your main key. When you pick a Sub Account slot, the app shows the deposit address for that slot. Senders send ETH or USDC there. The Veil relayer deploys the **onchain forwarder** when needed, then **sweeps** funds into the deposit queue so they follow the same screening and pool path as a normal deposit. The same slot always yields the same address, so you can **reproduce** it on a new device from your main key—no extra secret per Sub Account. ## Creating a Sub Account You can use up to **3** slots (Account 1–3). Open **Sub Accounts** in the wallet panel, choose a slot, and copy the address it shows. Share that address with whoever is paying you. ## Depositing 1. Choose the Sub Account slot you want to fund. 2. Send ETH or USDC to the address shown for that slot. 3. After funds arrive, run **Deploy & Sweep** the first time the forwarder is needed, or **Sweep to Queue** if it is already deployed—this moves value into the Veil deposit queue. 4. From there, the deposit is screened and accepted into the pool like any other deposit. Minimum sweep amounts: **0.01 ETH** and **20 USDC** (after the deposit fee). Sweeps below that fail. ## Merge and withdraw * **Merge** — move a Sub Account’s shielded balance into your **main** Veil balance inside the pool. * **Withdraw** — send from a Sub Account straight to an external address using a signed recovery flow in the app. ## Privacy and security Sub Accounts improve **deposit-side** privacy: each public address is its own surface, separate from your main Veil deposit identity. Every slot is still tied to your **main** private key—back it up before holding real value. See [Veil Keypair](/technical/veil-keypair). For fees and minimums, see the [FAQ](/veil-cash-pools/faq). # Veil Keypair Source: https://docs.veil.cash/technical/veil-keypair How your Veil keypair works — deposit key, private key, and backup Your Veil **keypair** is what controls access to funds in the pool. It has two parts: a **deposit key** (public) and a **private key** (secret). Keys are derived and kept on your device; the private key never leaves the client and can be encrypted at rest with a password. ## Deposit key (public) The deposit key comes from your private key and identifies you for **private transfers**. When you register, you publish it **onchain** and tie it to your Ethereum address. Senders encrypt transfer outputs to your deposit key so only you can decrypt them. It is safe to share in that sense—it is already linked to your wallet in the Veil Entry contract. ## Private key The private key decrypts incoming deposits and transfers and authorizes spending your shielded balance. **Anyone with it controls your pool funds**—keep it secret. ## How you get a keypair 1. **Sign a message** — for **EOA** wallets, the app derives a keypair deterministically from a wallet signature. The same wallet always yields the same keypair, so you can recover from another device. 2. **Passkey** — WebAuthn **PRF** derives a keypair bound to the Veil origin and your connected address. Works wherever that passkey syncs (e.g. iCloud Keychain, Google Password Manager, 1Password). 3. **Import** — paste or load a private key you generated elsewhere; the app derives the rest of the keypair from it. Each path above produces a **different** keypair for the same wallet (passkey ≠ signature ≠ import). Stick to one method, or **reveal and securely store** a copy of your private key if you plan to switch. ## Key Management Under **Account**, open **Key Management**. You’ll see tiles for your **EVM wallet**, **deposit key**, and **private key**. Use **Reveal Private Key** to show the key (and **copy** it from there if you need a backup). **Remember Key** walks you through a password so the key is **encrypted and saved on this device**—only use it on hardware you trust, and never share what you reveal. If you cannot recover your private key (lost device, lost password, lost wallet access, or broken passkey sync), you can **lose access to shielded funds**. Treat key handling like custody of a hot wallet. Key Management under Account For separate deposit addresses that still derive from your main key, see [Sub Accounts](/technical/subaccounts). Sign-in options and wallet support are summarized in the [FAQ](/veil-cash-pools/faq). # FAQ Source: https://docs.veil.cash/veil-cash-pools/faq **ETH and USDC** pools: either submit the deposit for compliance screening (e.g. [0xbow](https://0xbow.io/)) and enter if approved, or meet an instant path under [Verified Users](/intro/verified-users) (Coinbase EAS, Binance BABT, Ethos). Minimums are the **shielded amount after** the **0.3%** deposit fee—deposit slightly above the floor so the net amount still clears. * **ETH:** 0.01 ETH shielded minimum * **USDC:** 20 USDC shielded minimum **0.3%** on deposits, taken in the same deposit transaction in the app. **Withdrawals and private transfers** use Veil's relayer with **no extra relay fee**. Any wallet the app supports (MetaMask, Coinbase Wallet, Rainbow, WalletConnect, Ledger, and others). **Sign message** — EOAs only (deterministic signature for key derivation).\ **Passkey** — WebAuthn (biometrics or security key), tied to your wallet and this site; one passkey per wallet; sync depends on your passkey provider (e.g. iCloud Keychain, Google Password Manager, 1Password).\ **Private key** — works for any wallet type, including smart accounts (export from the smart wallet if needed). Each method derives a **different** Veil keypair for the same wallet—pick one and stay on it, or back up/import keys to switch. Use **Key Management** in the wallet UI to back up your key. Any Ethereum address can **register** to receive private transfers; receiving does not require deposit verification. The recipient must be registered before someone can send to them. Veil's **relayer** submits them so you do not pay gas yourself, and it helps keep your deposit identity separate from shielded activity. **No.** Shielded balances and transfers are encrypted; only you can decrypt them. # How to use Veil Cash Source: https://docs.veil.cash/veil-cash-pools/how-to-use-veil-cash Veil runs on Base. Connect a wallet, sign in to derive your Veil keypair, then use the Deposit, Transfer, and Withdraw tabs to move ETH or USDC through the privacy pool. Contract addresses are on [Deployments](/technical/deployments). ## Connect your wallet Use any wallet the app supports (MetaMask, Coinbase Wallet, WalletConnect, Ledger, and others). Stay on Base with enough ETH for gas on transactions you sign yourself. The relayer still submits private transfers and withdrawals, so you do not pay gas for those. ## Sign in (derive your keypair) Click Login, then pick one path: 1. **Sign a message** — EOA wallets only. No funds move; one signature derives your keys client-side. 2. **Passkey** — WebAuthn PRF; works across devices where the same passkey syncs. 3. **Import** — paste a Veil private key (works with smart accounts too). Each method produces a **different** keypair for the same wallet. Do not mix methods unless you understand recovery; see [Veil Keypair](/technical/veil-keypair). Use Account → Key Management in the header when you need your deposit key, Reveal Private Key, or Remember key. Details: [Veil Keypair](/technical/veil-keypair). ## Deposit (shield funds) Your first deposit includes any onchain setup the protocol needs for your address (such as associating your deposit key). That runs in the same flow as the deposit—there is no separate Register step in the app. 1. Choose ETH or USDC in the pool selector. 2. Open the Deposit tab, enter an amount, and confirm. The UI shows the 0.3% fee and a total that includes it (same fee model as the [FAQ](/veil-cash-pools/faq)). 3. USDC may need a one-time approve for the entry contract before the queue transaction. 4. Funds go to the queue first. Verified paths and 0xbow screening follow the rules in [Verified Users](/intro/verified-users) and [0xbow Screening](/intro/verified-users/0xbow-screening). Minimum shielded amounts are after the fee—see the [FAQ](/veil-cash-pools/faq). Depositing into Veil Pool ## Private transfer Open the Transfer tab. The relayer submits the transaction; senders, recipients, and amounts are not published onchain in the clear. The recipient must already be able to receive shielded transfers (deposit key onchain; the app checks this). Pick the pool, amount, and recipient address the UI accepts. Private transfer ## Withdraw Open the Withdraw tab, choose an amount and any Ethereum destination address. The relayer submits the withdrawal. There are no fixed denominations—up to your shielded balance. Withdraw funds # Veil Staking Source: https://docs.veil.cash/veil-token/veil-staking Details about VEIL token staking Stake **VEIL** to earn a share of **100%** of protocol revenue: deposit-fee proceeds are converted to VEIL and **streamed** to stakers **over each 28-day period**, so rewards track real usage. ## Mechanics You earn when VEIL earns. * **No lock-up** — stake or unstake whenever you want. * **Rewards** — VEIL **streams** to stakers continuously **throughout each 28-day period**, based on your share of total VEIL staked (and **Boost Points** where they apply). * **Boost** — longer continuous staking earns extra yield via **Boost Points** (below). ## APR APR is your share of protocol revenue, annualized for comparison. Each **28-day** period, VEIL converted from collected fee revenue **streams** to stakers across that window. The rate you see **rises and falls** with how busy the protocol is (more usage → more fee revenue) and **how much VEIL is staked** (your slice of the pool). ## Boost Points Unstaking **burns** all accumulated Boost Points. Boost Points increase your reward share for staying staked: up to **100%** extra on rewards, building toward the cap over about **one year** of continuous staking. They are **non-transferable** and are wiped when you unstake. # Overview Source: https://docs.veil.cash/veil-token/veil-token Details about the VEIL token, the official token of veil.cash 20% of the VEIL Token supply was burned in May 2025. Total supply is now 80m tokens. ## Tokenomics 100 million total supply Contract address `0x767A739D1A152639e9Ea1D8c1BD55FDC5B217D7f` [Dexscreener](https://dexscreener.com/base/0x7f1a5b66ba3bb56c4b68cfc353a5e041c9763a4c) / [Basescan](https://basescan.org/token/0x767A739D1A152639e9Ea1D8c1BD55FDC5B217D7f) / [Uniswap](https://app.uniswap.org/swap?outputCurrency=0x767A739D1A152639e9Ea1D8c1BD55FDC5B217D7f\&chain=base) / [Aerodrome](https://aerodrome.finance/deposit?token0=0x4200000000000000000000000000000000000006\&token1=0x767A739D1A152639e9Ea1D8c1BD55FDC5B217D7f\&type=-1) / [CoinGecko](https://www.coingecko.com/en/coins/veil-token)