Agent swaps
Swaps placed from a chat, executed under caps you set here.
Connect a wallet to enable the agent.
Contract
0xcbB5EE050b60F7D6aB9686FADCaBC5C8F19406E0Keeper
A stolen keeper key can: execute swaps for every enabled wallet, up to each wallet's per-execution cap per transaction and per-day cap per UTC day per token, never more than the wallet's allowance, until the wallet's expiry or until the wallet revokes. It chooses the pools and the floor. It can therefore route a wallet's tokens through a pool it controls, or into a token it minted, at a price of its choosing, and the loss to that wallet on one day is bounded by the day's caps and by nothing else; across a UTC midnight, by two days' caps. It can do this at most 120 executions per UTC clock hour across all wallets, and up to 240 in the seconds either side of an hour boundary, which is the time users have to revoke: the caps bound what one wallet loses, the hourly limit bounds how many wallets are reached before the alarm below reaches the rest. Each of those executions sells at most one wallet's per-execution cap, so with caps of 10 USDC per execution one clock hour costs all wallets together at most 1,200 USDC, and the seconds either side of an hour boundary at most 2,400 (contracts/AUDIT.md F-01, F-08). It cannot: send the output anywhere but the owner's wallet, take a fee to any other address, change the fee, spend after expiry, spend a disabled wallet, spend a token the wallet gave no cap for, sell a wallet's last USDC, execute an order twice, or execute more than 120 times in a clock hour. It CAN also spend the hour's 120 executions on a wallet of its own, which holds every other wallet at the limit until the next hour: one wallet, enabled once, and 120 tiny swaps an hour that cost it only gas, and the alarm reads those executions as foreign on the first tick (contracts/AUDIT.md F-09). A stranger can fill the hour too, through this keeper, with a dozen wallets of their own and about three dollars of fee an hour at the 5 USDC minimum. The answer to that is the keeper's admission rule (5.2), off chain: once 80 of the hour's 120 executions are used, it sends only for wallets with a swap on vialiq at least a day old, at most two each, so the last 40 go to wallets with a history, but for the few sends that race the crossing of 80 (5.2). It makes spam wait a day, not stop: a swap of any size a day earlier, or the stranger's own orders the day before, gives their wallets a history too.
A malicious operator (vialiq itself, or whoever controls the keeper key and the database) can do exactly what a stolen key can do, and no more, because the contract does not distinguish them. What bounds it: your allowance, your caps, your expiry, the fee being fixed on chain, and the output address being fixed to you.
What is NOT bounded on chain, said plainly: the price. LdxFill bounds it because the maker signs a floor per order. A chat user cannot sign per order, Arc has no price oracle, and quoting the keeper's own route on chain proves nothing about the route it did not take. So this design claims no price bound it does not enforce. The honest advice, printed on the page: set caps at what you would accept losing on a bad day, set a short expiry, and read the receipts, which the page lists with what arrived beside what was quoted.
What else is not ours, said plainly. USDC on Arc is Circle's contract: Circle can pause it or blacklist an address, which stops agent swaps the same way it stops the site; canExecute reads both and the page prints them. Hooks can ask the router who is trading (IMsgSender): on the site that is you, on the agent path it is the contract, for everyone, so a pool whose hook limits or prices by wallet treats every agent user as one, and the agent will not trade it (2.6). And enabling is public: anyone can read from the chain which wallets enabled the agent, their caps and their expiry, and every executed swap names the wallet. The rewards side keeps a wallet's code private (proof.ts); this side cannot keep the mandate private without breaking the receipt proof, so it says so instead.
A stolen MCP credential can place orders for the linked wallet inside the same caps and read that wallet's agent order history, at most ten orders an hour and sixty tool calls a minute. It cannot change the mandate, the caps or an allowance. Revoking it is one click on the page, the revoke also cancels every order it placed that has not been sent, the page shows when it was last used, and a credential expires ninety days after it was made whatever the mandate does.
Nobody can stop it but you. The contract has no owner, no guardian and no admin function: no address can halt it, pause it or retire a keeper (2.1). The keeper set is fixed at construction: K0 hot in Vercel and the other three slots empty, the founder's choice (8.3). A LOST K0 (the env var and its offline backup both gone) means a new deployment at a new address, which every user must approve again. A STOLEN K0 cannot be retired either: the only answer is a new deployment, and until then the thief holds a valid keeper key. What tells you is the alarm: the keeper reads the contract's own Executed logs every minute (5.2), and any execution it did not send is evidence that a key is in someone else's hands. On the first one the keeper stops sending, the swap tool refuses to place, the status tool reports keeper.alarm: true, and this page shows a banner: "Revoke your allowances now. A swap this keeper did not send was executed from the agent contract." with the Revoke buttons under it. Then disable() or approve(0) from your wallet is the stop, and the hourly limit is what makes the alarm reach you before most wallets are touched. That is the trade the founder chose (section 11, Q1): a guardian who could stop the contract for everybody would also hold a form of custody over every setup, and there is none.
Enabling is public: anyone can read from the chain which wallets enabled the agent, their caps and their expiry, and every executed swap names the wallet.