BLOCK and execute anyway, because it holds its own keys.
Escrow wallets close that gap. You provision a real wallet — on Base, Solana, or Starknet — that your agent can propose transactions from but cannot freely sign. Every proposed transaction is simulated, judged against your rules, and only then does it reach a signature. A denied action is never signed, so there is nothing to undo.
Two modes
You choose per wallet, at creation. The mode is permanent — pick the one that fits how much you want to be in the loop.Autonomous
Signs and submits automatically the moment a transaction passes verification — no human in the loop, and never outside the limits you set. Best for hands-off agents doing routine, well-scoped work.
Safe
Nothing executes until you say so. When a transaction passes verification you get a personalized approval link showing exactly what it would do — every asset that moves, priced — and it waits there until you confirm. A clean
ALLOW is still held. Best for higher-value wallets where you want the final say.On Base, a safe wallet is held by the approval step: the harness will not sign anything you have not confirmed. On Solana and Starknet, safe wallets go further — the key is your own and lives in a client-side enclave, so it is signed by you directly.
How a transaction flows
1
PROPOSE
Your agent proposes an action — “send 500 USDC to
0x…”, or a raw transaction it built for any protocol. It cannot sign it.2
SIMULATE
Chance runs the exact transaction against live chain state and computes what it would actually do — every asset that moves, priced in dollars, plus whether it would revert. The simulation is the ground truth, not the agent’s description of what it’s doing.
3
VERIFY
The simulated outcome is checked against your rules — the deterministic limits and the plain-English intent — and returns
ALLOW, BLOCK, or ESCALATE with its reasoning.4
SETTLE
On an autonomous wallet a passing verdict clears straight to a signature. On a safe wallet it becomes an approval link and waits for you. Either way Chance marks the transaction executed only after checking the mined result matches what was approved. A
BLOCK never reaches signing. Fail-closed by default.What gets enforced
A proposed transaction is checked on three independent layers. All three must pass.Deterministic rules
Hard, checkable rules, enforced in code with no model involved — instant, and free (no credit spent):- Per-action and daily dollar caps — computed from the simulated outflow, so a transfer of an obscure token is measured by what it’s actually worth, not by a number the agent typed.
- Who it may pay — an allowlist of addresses. Save a payee once and reuse it across wallets from your address book.
- What it may move — an allowlist of token contracts. Tokens are named by contract, never by symbol: any contract can call itself USDC, so a symbol would admit an impostor. Pick from the verified list, or paste an address and confirm what the chain says actually lives there.
- Permission grants are decoded, not trusted. An unlimited token approval moves nothing today, then lets a spender drain you later — the classic wallet-draining vector, invisible to a limit that only watches transfer amounts. Chance decodes every approval from the calldata (spender, token, exact amount, dollar value) and puts it in front of the judge and on your approval page.
The intent
Every wallet carries a plain-English intent — what the wallet is for. The judge reads it and rules on whether a transaction honors it, catching things a numeric limit can’t:“Treasury ops wallet — may pay vendors from the approved list, never move funds to a new address.” “Stablecoins only. Never send ETH or any volatile asset.”A transaction can be well within every dollar limit and still violate the intent — sending a volatile asset from a stablecoin-only wallet, or paying an address that isn’t what you meant. That’s the judgment layer: it enforces the spirit of the rule, not just the numbers. See The verification harness. If you’re not sure what to write, the dashboard offers templates — a payments wallet, a small trading book, a metered-API wallet — each with a conservative starting intent and matching limits. They fill the form; nothing is saved until you press save.
The simulation itself
If the transaction would revert, it’s blocked before it burns a cent of gas.Funding and fees
- Base and Ethereum — fund the wallet with whatever it will spend, plus a small amount of ETH for fees.
- Solana — a small amount of SOL for fees.
- Starknet — STRK for fees. Fees there are a fraction of a cent per action, and the first transaction also pays a one-off account deployment out of the wallet.
- Paying an API over x402 doesn’t need gas at all: it’s a signature, and the payment facilitator covers the fee. A wallet holding only USDC can pay for things.
Getting funds out
Your rules bound your agent, not you. Withdraw from the wallet page at any time: pick the asset, the amount and the destination, and it goes out without a verdict and without touching your limits.Provision and use from your agent
Escrow wallets are first-class in the MCP connector and HTTP API. Your agent can create and use them by name:tool
Provision a new escrow wallet. Inputs:
name, chain (base / solana / starknet), mode (autonomous / safe), mandate (your plain-English intent), and optional limits. The address is returned immediately and is permanent — fund it and go.tool
Propose a transfer —
wallet, asset (e.g. usdc, eth), amount, to, chain. Runs the full simulate → verify → settle flow.tool
Propose a swap. Chance fetches the quote itself and puts the real route through the gate.
tool
Pay an HTTP resource that charges via x402. Give it the URL: Chance requests it, reads the payment terms from the
402 response itself — never from your agent — and verifies the exact amount, token and recipient before signing.tool
Propose a raw transaction your agent built for any protocol — same flow, same gate.
tool
List your wallets, or check the status, verdict, and receipt of any proposed transaction.
“Create an autonomous escrow wallet on Base called treasury. Intent: may send up to $500 USDC per day to addresses on my allowlist, nothing else. Then send 100 USDC to 0x….”
What each mode protects you from
Every verdict is signed and hash-chained — you can prove after the fact exactly what was simulated, what rule was checked, and why it passed or failed. See Provable verdicts.
Networks
Base, Solana, and Starknet — all mainnet only. Wallets created earlier on Ethereum mainnet keep working, but new ones are no longer offered there.Starknet, specifically
Starknet accounts are programmable by design, which makes a couple of things behave better than they do elsewhere:- Fund it the moment you create it. The wallet has its address before it exists on-chain, so you can send it funds right away. It deploys itself the first time it transacts — no separate deployment step, and nothing to remember.
- Batches are atomic. Actions that would take several transactions on another chain execute as one all-or-nothing batch, so the exact set of calls that passed verification is the set that runs. There is no window where half of it has happened.
- A safe wallet is activated once, by you. Because a Starknet account is itself a contract, it has to be deployed before it can sign anything — and on a safe wallet only you can authorize that. The first time you confirm, you sign twice: once to activate the account, once for the transaction. Every confirm after that is a single signature.
Ready to give your agent a wallet it can’t misuse? Open the dashboard or get in touch.