Skip to main content
The payer-side shield is a disposable virtual card for crypto. Three primitives:

Vault

Your main treasury. Holds USDC and funds disposable accounts. The funding leg is the one that becomes confidential under Arc Privacy Sector.

Disposable account

A single-purpose address, locked to one merchant, one cap, one expiry. Cloned per payment at a deterministic address. It stores no payer identity: the owner is bound only through the CREATE2 salt.

The Machine

The enclave co-signer. Runs policy plus the firewall and vetoes bad spends by withholding its signature.

​
The trust model

  • Outbound to a third party (the merchant): the co-signer authorizes each spend. A spend needs only “The Machine” signature, not a signature from you. This is safe because the funds are hard-locked to the pre-set target and capped by maxAmount: the co-signer can never steal or redirect, it can only push the exact payment you set up when you created and funded the account. It refuses a spend that fails policy or the firewall, so a bad payment is physically impossible, not merely warned against.
  • Return to your own vault: gated on the vault itself. The vault is stored only as a commitment (vaultHash); a sweep passes the vault address, the contract checks it against the commitment and requires msg.sender == vault, so the vault stays hidden until it sweeps and only it can trigger one. No co-signer signature is involved either way. After expiry the same call is open through sweepExpired, which is the liveness escape hatch: if the enclave goes dark, the payer still holds the vault key, so funds are never stranded.
    The sender gate is the point, not an inconvenience. vaultHash is a hash of a 20-byte address on a transparent chain, so it is crackable. Without the gate, whoever cracked it could sweep an expired box and publish the vault-to-box link the payer never chose to reveal. Bind the box to an address you can transact from: your own wallet, or the stealth address for a stealth box.
You sign nothing blind. Your only on-chain action is a normal, readable USDC transfer to fund the account; your wallet shows “Send X USDC to 0x…”, never an opaque hash. The account is a one-way valve: funds can only reach the locked merchant or the vault. There is no third exit.

​
What a veto stops

Because the target is locked on-chain, a script cannot redirect a payment. The co-signer adds the dynamic layer: it will not sign for a target the firewall flags as a drainer or a poisoning lookalike, an amount over the cap, or an expired window. In whole-wallet mode the same veto can gate every outflow, not just payments.

​
Privacy, honestly

The account surface leaks nothing about you. There is no owner variable and no owner() getter, so a merchant paid from the ephemeral address cannot read who funded it from the account; the deployment calldata and the AccountCreated event carry only ownerHash (indexed), not your address; and the vault is revealed only at the moment of a sweep, and only to whoever already knows it. That part is fully delivered now. What is not yet hidden is the funding transaction. Your wallet to the ephemeral account is a normal transfer on a transparent chain, so an observer can still trace you to the ephemeral address through that one transaction. This cannot be hidden today without confidential transfers. So the honest line is: the account itself reveals nothing about you, but the residual on-chain link is the funding transaction, which becomes confidential under Arc Privacy Sector. Full payer privacy (hiding the funding link and amounts) waits on APS. The security legs (policy, veto, sweep, one-way valve) are fully real now.
Roadmap: Arc Privacy Sector (APS). APS is Arc’s confidential execution environment (TEE-based, running alongside the public EVM). When it ships, the funding leg and account state move into APS and become confidential, and the same co-signer speaks the same language as Arc’s own privacy backend. The contracts are architected for this: custody behind an adapter, getter-first reads (not event-dependent), and clean function-level access boundaries.

​
Beyond one-off payments

The same account with MODE_PULL expresses recurring, policy-bounded spending:
  • Safe allowances / subscriptions. A merchant can pull up to a cap on an interval, every pull gated by the co-signer. A perPullMax field caps each single pull: a subscription sets it to the per-period amount, so even a misbehaving co-signer cannot drain the whole cumulative cap in one pull. That per-pull cap is the real subscription guarantee. Kill the subscription by sweeping the account; the co-signer stops signing. No infinite-approval drainer.
  • Agent wallets. Hand an agent a tightly-scoped disposable account; it transacts autonomously but cannot exceed policy, because the enclave vetoes.