Aomi Labs Research · Agentic finance

Three gates from
intent to settlement

Who can stop an agent's transaction, and does that decision hold?

Intent

Build0.5

Sign1

Settle23

four checkpoints between a request and a settled transaction

About Aomi Labs

Execution harness for onchain finance.

Bring your preferred models and product APIs. Aomi turns intent into policy-checked onchain execution by building and simulating transactions, routing them through your signing controls and verifying the results. Non-custodial and wallet-agnostic.

10+chains · EVM + SVM

33protocols integrated

0keys held

1,734accounts in production

33apps live on the runtime

34.5kSDK downloads · npm

Trusted by teams in production

Sommelier

Para

Khalani

World Markets

Swig

Molinar

Backed by

Anagram

Nascent

Empower your agents onchain

Install Aomi into the agent you already use.

Claude Code, Codex, Cursor, OpenCode or Hermes. The harness is reachable over CLI, MCP or plain API calls. The chat embed is one surface among others, not the product.

› npx skills add aomi-labs/skills

CLIMCPAPIReact embedTelegramDiscordSlack

Ethereum · Arbitrum One · OP Mainnet · Base · Polygon · Linea · Monad · Robinhood Chain · MegaETH · Solana · Across · CoW · dYdX · GMX · Hyperliquid · Jupiter · LI.FI · Morpho · Polymarket · Yearn · 0x · 1inch …

What is an execution harness

Domain-specific harness enables secure execution even with cheap models

harnessed

Runtime workflow

1Research — already there, out of the box

Loads the skills the intent needs: lido, aave, common_erc20
Its own node plus a DB of contract code: addresses, ABIs, proxies already resolved
Reads live state directly: 10 ETH, nonce 2751, 1 stETH → 0.8059 wstETH
Knows Aave takes wstETH, not stETH, and routes through the wrap unprompted

2Take action — read ⇄ write against a fork

Chain RPCits own node across 10+ chains; no key to ask you for
Contract codeget_contract from the DB; no pasting ABIs by hand
Simulationeach leg on a fork of mainnet, then all 6 end to end: all pass
A revert comes back decoded, so it reads again and fixes the call

3Signing — one bundle, your wallet

6 txs → 1 bundle with account abstraction: stake, approve, wrap, approve, supply, borrow
One signature in your existing wallet; keys never leave it
Policy lives in the runtime, not the model: manual, auto-approve or bypass

A harness is the loop around the model: what it can read, what it can write, and what it takes to commit.

The problem

The risk landscape: attacks vs defects

We compare financial agents with coding agents to find the risk factors that matter when money moves. Both can get things wrong, but only a financial agent faces attackers paid to drain it, and today's execution stack can't prevent mistakes even with no attacker.

Coding agent

Intent

Build

Commit

Deploy

review · CI · merge: checked before it ships

Financial agentA signature isn't a review, and settlement can't be undone.

Intent

forged instruction

Buildwrong decimalsstale route

swapped payload

Sign

sandwich

Settle

Valid onchain.Wrong for the user.

attacksomeone corrupts the input or the tx mistakethe agent builds it wrong, no attacker needed

Same task, two worlds

Gate 0.5: Prevent mistakes at runtime

“Approve 500 USDC for the Uniswap router.”

Frontier model · no harness

Every step is the model's own work.

1Find the USDC contract addresswrong chain, wrong token

2Fetch the ABI

3Compute the selectorkeccak256(sig)[:4]

4ABI-encode spender and amountdecimals, padding

5Set gas, nonce, chain idunder-gas, stale nonce

6Sign

7Broadcast to the live chainfee is spent here

8Read the revert"execution reverted"

First error signal: step 8, on the live chain, after paying

Small model · integrated harness

The model writes one typed call. The harness does the rest.

Model emits

stage_tx {
  to: USDC, signature: "approve(address,uint256)",
  args: [router, "500000000"], kind: erc20_approve
}

Harness does

Resolve ABI from cache or fetch, follow proxies

Compute selector, ABI-encode, inject from and chain id

Execute on a forked chainrevert → readable error

Run guards on the simulationtarget, spender, selector

Stage into the pending queuenothing signed yet

Return a typed error on bad argumentstool failure → retry

Skills supply addresses and protocol procedure

First error signal: in the loop, before signing, no fee paid

Pink steps are where an honest mistake stays invisible until the chain rejects it. The harness moves every one of them behind a tool the model cannot get subtly wrong, and puts the first failure signal before authorization instead of after.

Right column reflects our own runtime as documented in AomiBench v0.1, Section 2.3 and Section 4.

What actually happens · the loop

Back pressure that enforces correctness

Test-driven development keeps traditional software correct, and coding models write good code because CI pushes back when tests fail. Financial agents need the same back pressure, and it can only come from a financial sandbox. Blockchains give us one: every encode_and_call runs as an eth_call on a fork of live state, and only a green run gets committed.

Aomi — the fork runs the call; the chain only sees what passed

Coding agent — CI runs the code; main only gets what passed

Gate 1 · Wallet policy

Gate 1: Signing policy after agents commit

The signing module should stand on its own. An action the model commits is only a request for a signature, and the signing module decides by itself whether to sign it or send it to the user for review.

intent

user-controlled policy

signature · denial · user review

Application trust boundary

Agent runtime

Builds the exact signing request

chain · account · destination
calldata · value · policy reference

No private-key access

The agent proposes an action.
It cannot sign or change an independently administered wallet policy.

signing request

Wallet provider

Trusted execution environment

Private key

Policy evaluatorchecks the exact request

manual

auto approve

bypass permission

The provider keeps the key and signs inside the enclave.
Use an established provider. No need to reinvent the wheel.

Privy

Para

Turnkey

Safe

Fireblocks…

sign?

✓ signed

Joint authorization, not joint custody

Agent request + authority rooted in user consent = signature. The key never enters the runtime.

Gate 2 · Onchain mandate

Gate 2: Onchain policy enforced by protocol

Signing policy is off-chain and configurable: each user picks manual review or bypass permission to suit their use case. An onchain guardrail adds a second layer that persists, is stricter, and holds even when the signing policy lets everything through.

1execTransaction

2checkTransaction

permit or revert

4checkAfterExecution

3external call

Requester

Agent or session accountholds delegated authoritybypass permission on

Target

Contract or EOAreceives the covered call

Safe smart account

Safe account logicauthorizes and executes

Safe account stateowners · threshold · modules
installed Guard · nonce

Any failed check revertsthe covered Safe transaction

Installed guard contract

Pre-execution checktransaction parameters
caller · target · value · calldata

Post-execution checksuccess and final state
after the external call

Guard statelimits · allowlists · invariants

tx → sanctioned address

✗ OFAC-listed recipient

revert

Example · OFAC compliance

The user is in bypass-permission mode, so the signer approves anything. The agent builds a transfer to a sanctioned address: the Guard's pre-execution check fails and the Safe reverts it onchain.

Gates 1 and 2 · who builds them today

Product landscape for wallet policy providers

Table 1 · Offchain signing policyDocumented controls are not a ranking. Independence is a property of the deployment's authority graph.

Provider	Documented signing control	Independence question
Privy	The enclave checks authorization keys, quorums and wallet policies before signing. Separate screening or simulation may run outside it.	Does the user or an independent quorum control the wallet, or does the application hold the decisive authorization key?
Turnkey	Policy evaluation and signing occur inside secure enclaves. Policies can constrain transaction structure and require approvals.	Who holds root authority to change policy or satisfy the approval quorum?
Coinbase CDP	Project- or account-scoped rules govern specified signing and sending operations.	Can the same application credentials edit the policy and initiate the transaction?
Fireblocks	MPC signing is paired with transaction authorization policy. Raw signing is blocked without appropriate rules.	Which workspace roles can change the policy, approve the request, or use a different vault path?

Table 2 · Onchain contract patterns“Onchain” describes where it is enforced, not whether every path to the asset is covered.

Contract pattern	What it can enforce	Boundary to test
Wallet-requested delegation: ERC-7715, ERC-7710	A wallet grants scoped authority to a session account. A delegation manager validates the permission context when that authority is redeemed.	ERC-7715 defines the request interface. The smart account and delegation contracts provide enforcement. Test alternate account paths and root authority.
Session policies: ZeroDev, Biconomy, Rhinestone	Installed validator and policy modules restrict a delegated key's calls, time, usage or spend.	Owner calls, alternative validators, upgrades and accounting across batches or fee tokens.
Account guards and roles: Safe, Zodiac	Rules check transaction parameters before execution or state after execution. Roles provide granular permissions.	Module routes, guard replacement authority and denial of service from an over-restrictive guard.
Delegated EOA: EIP-7702	Delegated code implements smart-account behavior, potentially including session validation.	The EOA root key can originate transactions and change or clear delegation. Not every path enters the session validator.

Gate 3 · Example: Phylax Credible Layer

Gate 3: Builder rejection at settlement

The block builder is the last gatekeeper before a transaction lands onchain. Even with offchain and onchain policies in place, an external gatekeeper can still drop unwanted transactions. Phylax-style assertions have already stopped DeFi attacks worth millions (vendor-reported).

1candidate tx

3validation report

4 · network applies its inclusion policy

activate

2 · load active rules and cached bytecode

Integrated network · block-production path

Network operator

Block builder or sequencerselects candidate transactions

Assertion enforcer · sidecar

finds the active rules for affected contracts

executes each triggered assertion

PhEVMsimulates the candidate transactionpre-state → post-state

Valid

eligible for inclusion

Invalid

excluded on this route

Assertion lifecycle · separate from the transaction hot path

Protocol team

Assertion releasewritten in Solidity and published

Credible Layer contracts

Active assertion registrymaps rules to protected contracts

Assertion DA

Code and artifactsavailable to the enforcer

tx

✓ valid

exploit tx

✗ invalid

Builder-route enforcement, not a base-consensus validity rule

It protects transactions on integrated builder routes. Source: docs.phylax.systems/credible/architecture-overview

Worked example

Summary: three Gates from Intent to Settlement

Same bad transaction, four checkpoints. Whether it's caught depends on what each one can see.

Intent

Build0.5

Sign1

Settle23

Real balance

Agent sees

3,000

4,000 (fake)

2,000 reserve

Keep 2,000 liquid. Deposit the rest.agent deposits 2,000 → only 1,000 left

0.5Runtime

reads the fake 4,000trusts the RPC feed

passes

1Wallet

checks the real reserveindependent balance check

blocks

2Vault mandate

sees a healthy depositrule is about the vault, not you

passes

3Builder

vault invariant intactsees state, not intent

passes

← knows more of what the user meant

sees the exact transaction →

Back to the risk landscape

Risks resolved

The same financial-agent path, now with the gates in place. Each risk is stopped at the gate that can see it.

Intent

Build

Sign

Settle

onchain

0.5

1

2

3

0.5Runtime

fork simulation reverts before anything is signed

1Signing policy

signs only the exact simulated bytes, within the user's limits

2Onchain guard

the Safe reverts it, even in bypass-permission mode

3Builder

an assertion drops it outside the price bound

wrong decimals

stale route

swapped payload

forged instruction

~forged instruction · partly

policy breach (OFAC)

sandwich

Valid onchain. Wrong for the user.→Only what passes every gate settles.

Beyond our gates · for every financial agent builder

Beyond our gates: Auth & Identity for general financial workflows

Much of this deck is DeFi-specific, but one invariant carries over. The user's canonical identity persists, and the authority they hand to agents is sessioned and capped. Guards wrap what goes out from each session wallet in a time window, so you can run the same checks in your own stack, whether that's a chain, a bank or an exchange.

authorizes

Canonical identity

The userKYC · main address 0x71c…9aEpersists

session 1Trading agent

swap only≤ $5k / day

24h left

session 2Payroll agent

allowlisted payees≤ $50k / month

30d left

session 3Research agent

read-onlyno transfers

7d left

Session checksscope · cap · time window

Your infrastructure

Onchainsmart account · signing policy · guard

Bankpayment rails · payee allowlists · limits

Exchangesub-accounts · scoped API keys · withdrawal caps

✗ out of scope

Canonical identity (KYC)+[ session wallet 1, 2, 3 … ]with scoped authority≈OAuth for money

Identity persists. Authority is sessioned and capped. Checks wrap the session.

aomi labs

Thank you · Aomi Labs Research

Follow us on X x.com/aomi_labs

Join our Discorddiscord.gg/A4S5eAFxF

Three gates fromintent to settlement

Execution harness for onchain finance.

Domain-specific harness enables secure execution even with cheap models

The risk landscape: attacks vs defects

Gate 0.5: Prevent mistakes at runtime

Back pressure that enforces correctness

Gate 1: Signing policy after agents commit

Builds the exact signing request

Gate 2: Onchain policy enforced by protocol

Product landscape for wallet policy providers

Gate 3: Builder rejection at settlement

Summary: three Gates from Intent to Settlement

Risks resolved

Beyond our gates: Auth & Identity for general financial workflows

aomi labs

Three gates from
intent to settlement