Two things that work together. MandateEscrow is an open, permissionless escrow contract on Arc: anyone can lock USDC for someone, the other side posts proof, and the funder releases it. The treasury agent is its first real user: it watches what a company owes and pays it on time, from an on-chain vault, with no human clicking approve.

One escrowed payment. A funder locks USDC in the contract for a named fulfiller, or leaves it open to whoever proves the work first. The fulfiller posts a hash of their proof. The funder then releases the money, all at once or split across several addresses in a single transaction. If nobody delivers before an optional deadline, the funder can take a refund. Every outcome updates an on-chain reputation record for the fulfiller.

Anyone. There is no owner, no allowlist and no fee. You do not have to be built on Arc, but the contract lives on Arc mainnet, so the transaction that calls it has to be sent there: you need a wallet with a little USDC on Arc. Use the dashboard with a browser wallet, the TypeScript SDK from code, or the MCP server from an AI agent.

The treasury the agent pays from. The money sits in a contract, not in the agent's wallet. The owner, a wallet you control, sets a per-payment cap, a daily cap that refills continuously, an optional list of payees the agent may pay, and a pause switch. The agent's wallet can call exactly one function, pay, inside those rules, and can never withdraw.

The damage is bounded by numbers the owner chose. Someone holding the agent's credentials can only pay inside the caps and to allowed payees, cannot withdraw, and can be cut off at once by pausing the vault or replacing the operator. If the owner wallet leaks, the vault is lost, which is why the owner should be a hardware wallet or multisig and the vault should hold a small balance.

Before paying, the agent flips the obligation from pending to scheduled with a conditional database update, matched only if it is still pending. A restarted agent only ever re-evaluates obligations still marked pending, so anything already claimed has fallen out of that set, and if two evaluation passes race, the database lets only one of them win the claim.

Once Circle has accepted the transaction, the code stops treating it as retryable: it only releases a claim back to pending if Circle never accepted the transaction at all, meaning nothing was ever submitted on-chain. A crash after that point cannot be mistaken for a failure and resubmitted. Each payment also carries the obligation's own id as its reference, hashed into the on-chain mandate too, so a payment always traces back to exactly one obligation.

The one honest gap: there is no automatic timeout that un-sticks an obligation if the process dies in the narrow window between claiming it and calling Circle. That needs a manual reset. It is a deliberate trade: stuck-but-safe over fast-but-double-paid.

Yes, and these are the real ways. A funder can withhold a release after a fulfiller has posted proof, because there is deliberately no arbitration. The contracts are not professionally audited. USDC is issued by Circle, which can freeze an address. And a wrong address or amount is final once it is on-chain. Start with cents.

No. It has been self-reviewed: static analysis with slither, unit and fuzz tests, a mutation check where the contracts were deliberately broken and the tests caught every break, and rehearsals against live chains. The source of both contracts is verified on Arc's explorer, so anyone can read exactly what runs. An independent review is on the roadmap.

That form spends the project's own treasury, so it needs an owner passcode. Everyone else uses the wallet panel at the top of the dashboard, which only ever spends their own money, or makes a payment-request link to get paid.

The live site runs on Arc mainnet, so yes, but the amounts can be tiny: a mandate of one cent works, and gas on Arc is paid in USDC and costs a fraction of a cent. For free experiments the SDK and scripts can target Arc testnet, where the faucet hands out test USDC.

The fulfiller submits a fingerprint, a keccak256 hash, of their evidence: a link, a description or a file's hash. Only the hash goes on-chain. Anyone who holds the evidence can paste it on the mandate's page and the browser checks it against the on-chain hash. Nothing is uploaded.

Yes. The MCP server exposes mandates and reputation as tools. In vault mode its only payment tool is vault_pay, which the vault's on-chain rules bound, so an agent can be given real spending power without being handed a whole wallet. The SDK offers the same from code.

Gas is paid in USDC, so the money being moved and the fee are the same asset, and finality is under a second. That makes a payment per mandate, and a balance check every few minutes, cheap enough to be practical.

Every payment links to Arc's explorer, both contracts' source is verified there, and the mandate, address and vault figures on this site are read straight from the chain, not from a database. The pitch deck lists real transaction hashes you can open.

Bills in currencies other than USDC are flagged but not auto-settled, because StableFX access is gated. The cross-chain top-up is disabled on mainnet until a funded source wallet exists. The roadmap above is the full list.