· four exchange APIs · rebuilt daily

The finding
Smart account session keys cap automated execution risks, but ai agent crypto payments still face unchecked liquidation when allowance limits fail.
Current implementations rely on ERC-4337 bundlers and ERC-7579 module validation.
Authorization revokes only onchain via a signed revocation transaction.
Liability for execution failure rests entirely on the key holder.
In smart account infrastructure, ai agent crypto payments execute through delegated session keys without requiring interactive user approval per transaction. The agent holds a restricted private key authorized to sign specific function calls on an ERC-4337 account abstraction wallet. A user delegates execution rights to the agent by installing a validator module on their smart account contract.
When an agent initiates a transaction, it constructs a UserOperation payload signed by its scoped key. Offchain bundler networks collect these operations, simulate validation, and batch them into standard Ethereum-compatible transactions submitted to an EntryPoint contract. The EntryPoint contract evaluates the signature against the smart account module. If the rules match, the transaction executes against exchange contracts or token balance contracts. Gas fees deduct directly from the user account balance or through a pre-funded paymaster smart contract.
Session keys specify destination addresses, approved function selectors, spend limits per transaction, and validity timeframes. Direct private key sharing or broad token approvals grant total wallet access. Smart account validation modules isolate agent access to defined scopes.
A session key configuration assigns clear spending caps per epoch. An agent configured for automated position adjustment might operate with a limit of 500 USDC per transaction and a cumulative ceiling of 2,000 USDC per 24-hour window.
Worth knowing
Session keys do not prevent bad execution prices; they only restrict target contract addresses and maximum token spend caps.
If an offchain agent enters an error loop and submits six consecutive 500 USDC transaction payloads within an hour, the first four complete successfully, consuming the full 2,000 USDC epoch limit. The fifth UserOperation fails at the EntryPoint validation step because the cumulative parameter check returns false. The automated smart account prevents further transfers, but gas spent on offchain bundler simulation and failed onchain validation is not recovered.
Autonomous trading agents that route market orders across perpetual venues incur execution fees on every balance adjustment. Taker fee schedules determine total capital drag when agents rebalance positions programmatically.
| Venue | Spot Maker | Spot Taker | Futures Maker | Futures Taker |
| Bitget | 0.0010 | 0.0010 | 0.0002 | 0.00030 |
| Bybit | 0.0010 | 0.0010 | 0.0002 | 0.00055 |
| MEXC | 0.0000 | 0.0005 | 0.0000 | 0.00020 |
| OKX | 0.0008 | 0.0010 | 0.0002 | 0.00050 |
For an agent adjusting a 100,000 USDC perpetual position using taker orders, venue selection establishes direct fee variance. A market order on Bybit at a futures taker fee of 0.00055 costs 55 USDC in fee drag. The identical order executed on MEXC at a futures taker fee of 0.00020 costs 20 USDC, while Bitget charges 30 USDC and OKX charges 50 USDC. Repeated automated loops widen this variance over time.
Terminating an agent requires an onchain state update. Stopping the offchain agent process prevents new signatures from being generated, but signed payloads already submitted to a bundler mempool execute normally.
Where this goes wrong
An agent loop executing taker orders reaches spend limits rapidly, incurring max taker fees before onchain revocation completes.
When an agent encounters a software failure and submits bad execution orders, financial liability rests with the owner of the smart account key. Neither paymasters nor transaction bundlers check trade execution quality or market impact before inclusion. If an agent executes market orders into low-liquidity order books, the smart account absorbs all slippage and execution losses.
What to do instead
Set strict hourly velocity limits inside the smart account module contract rather than relying on offchain agent software parameters.
Smart account validation modules check transaction parameters against contract rules before execution. If a transaction exceeds spending caps or targets unapproved smart contract methods, contract validation fails onchain.
The smart account owner pays all gas charges and execution fees incurred prior to transaction rejection. If an agent executes unintended orders on a venue, taker fees and order book slippage accrue directly to the backing margin balance.
Authorization is revoked by submitting an onchain transaction that overwrites or removes the module validator in the smart account contract. Shutting down offchain software prevents new signature generation, but signatures already in transit remain valid until onchain state changes confirm.
The smart account executes any signature that satisfies contract rules, regardless of execution quality. Maximum slippage limits must be encoded into transaction payload parameters to prevent execution at extreme order book prices.