Skills and guards

Aomi can read and call public smart contracts on supported chains when their ABI or IDL is available. Given a contract address and interface, a capable frontier model can often infer how to read state, construct calldata, and compose a transaction without protocol-specific guidance. That general approach is flexible, but it is not always efficient. Large interfaces consume context, repeated contract discovery adds latency, and subtle protocol conventions can make an otherwise valid call unsafe or incomplete. Skills make protocol execution faster, more token-efficient, and more reliable. A skill packages the context Aomi needs for a particular protocol or workflow:

official contracts and programs;
the relevant subset of functions or instructions;
a concise execution procedure;
supported chains;
specialized tools;
protocol-specific hooks and guards.

Aomi initially sees only a compact index of compatible skills. It activates the relevant one or two skills for the request, then loads their detailed instructions and skill-owned tools. This keeps unrelated protocol context out of the model while preserving Aomi’s ability to work with public contracts when no specialized skill is required.

How skills work

Skill selection changes which context and tools are available to the model. It does not bypass the normal transaction pipeline. Every skill-guided transaction still passes through construction, protocol guards, simulation, signing policy, and broadcast.

Skill bundle anatomy

Every skill is compiled into a common runtime format. The following excerpt is based on the generated Uniswap skill and is shortened for readability:

{
  "id": "uniswap",
  "name": "uniswap",
  "description": "Use when users want to swap tokens on Uniswap V3 or V2.",
  "tags": ["swap", "uniswap", "v3", "v2", "amm", "dex"],
  "tool_names": [
    "get_time_and_onchain_context",
    "encode_and_call",
    "simulate_batch",
    "evm_stage_tx",
    "evm_commit_txs"
  ],
  "injected_tools": [
    "encode_and_simulate_multicall"
  ],
  "source": "aomi_builtin",
  "activation_tokens": 1976,
  "instruction_md": "## Uniswap: Procedure\n1. Confirm the wallet and chain.\n2. Check the token balance and allowance.\n3. Build and simulate the swap.\n4. Inspect the guard result.\n5. Commit only after confirmation.",
  "tool_hooks": [
    {
      "tool": "simulate_batch",
      "pre_call": [],
      "post_call": ["uniswap-known-addrs"]
    },
    {
      "tool": "evm_stage_tx",
      "pre_call": [],
      "post_call": ["uniswap-known-addrs"]
    }
  ],
  "tools_namespace": "evm-core",
  "chain_ids": [1, 143]
}

Field	Meaning
`id`	Stable identifier used during activation.
`description`	Helps the model decide when the skill is relevant.
`tags`	Discovery terms describing supported intents and protocols.
`tool_names`	Base tools the current App must provide.
`injected_tools`	Skill-owned tools exposed only after activation.
`instruction_md`	Protocol procedure and critical execution rules.
`tool_hooks`	Checks applied before or after particular tool calls.
`tools_namespace`	Shorthand for a complete tool family such as `evm-core`.
`chain_ids`	Chains on which the skill can activate.
`activation_tokens`	Estimated context consumed when the skill is activated.

Discovery and activation

Discovery is scoped to the current thread. Aomi lists only skills whose required tools are available in the selected App. The compact index includes each skill’s intent, tags, and chain scope without loading its complete instructions. The model normally activates one or two relevant skills in the first pass of a request:

{
  "skill_ids": ["uniswap"]
}

Activation validates the skill ID, required tools, connected chain, and context budget. A successful result identifies what entered the request context:

{
  "activated": ["uniswap"],
  "rejected": []
}

Only active skills contribute detailed instructions, injected tools, hooks, and guard tables. Broad requests such as a portfolio overview can begin with general account tools and activate protocol skills only when a follow-up action requires them.

Base tools and skill-owned tools

An App provides the base tools that determine which skills it can support. A skill can also contribute specialized tools that remain inaccessible until activation.

App tools
├── encode_and_call
├── simulate_batch
├── evm_stage_tx
└── evm_commit_txs

Activated Uniswap skill
└── encode_and_simulate_multicall

This separation keeps the default tool surface small. The model receives a specialized tool definition only when the owning skill is relevant to the current request.

Instructions and execution procedures

The instruction_md field gives the model the protocol-specific procedure it should follow. For example:

## Uniswap: Procedure

Confirm the wallet, chain, and block context.
Check token balance and allowance.
Build and simulate an approval when required.
Construct the swap using the official router.
Inspect the guard result.
Commit only after user confirmation.

Instructions improve planning and calldata construction, but they do not enforce policy. Enforcement happens in hooks, guards, signing policy, and the transaction pipeline.

The guard system

Skills do more than tell the model how a protocol works. They also bind guard data and named checks to the tools that construct or simulate an action. The instructions help the model plan. The guards enforce what the action may contain. Each active skill can contribute three kinds of protection:

Layer	What it checks	What happens on failure
Activation	The guard table is valid and belongs to the selected skill.	Aomi rejects the skill as `invalid_guard`. Its instructions and tools do not enter the request.
Before a tool call	The proposed arguments, chain or cluster, slippage, and other declared limits.	The tool does not run. Aomi returns `hook_blocked` with the reason.
After a tool call	The actual contract or program, selector or discriminator, recipient, spender, and every step in a staged or simulated batch.	Aomi replaces the result with a blocked response before signing.

A hook binding declares where those checks run:

{
  "tool": "evm_stage_tx",
  "pre_call": [],
  "post_call": ["uniswap-known-addrs"]
}

The active guard table provides the exact values that the hooks compare. EVM guards can restrict contract addresses, function selectors, approval spenders, chain IDs, and declared limits. SVM guards can restrict program IDs, instruction discriminators, clusters, and declared limits. Protocol-specific guards can also inspect decoded arguments. Depending on the protocol, they can enforce:

known contract and program addresses;
allowed function selectors or instruction discriminators;
recipient and approval-spender constraints;
slippage ceilings;
supported chains;
required routing and multicall patterns.

Guard outcomes

Guards classify findings by severity:

Critical: block the action because it would likely send funds to the wrong place or violate a hard protocol constraint.
Warning: attach a visible warning when the action may be intentional but needs attention.
Info: attach context that helps explain the result without blocking it.

Hooks can pass, narrow or modify a call, annotate the result, or block it. A failed guard is not necessarily a construction error. It means the proposed action falls outside the skill’s permitted execution envelope.

Guards fail closed

Aomi resolves a skill’s guard table when the skill activates. If an address, selector, program ID, discriminator, or other guard value is invalid, Aomi deactivates that skill. It does not continue with the instructions while dropping the protection. The same rule applies at dispatch. A critical pre-call finding stops the tool before it runs. A critical post-call finding stops the staged or simulated result from moving to signing. The agent receives a structured block reason that it can explain to you or use to construct a safer alternative. Skill instructions cannot weaken these checks. Updating the wording or procedure for a skill does not replace its compiled guard bindings or protocol safety data.

App and chain compatibility

A skill must pass several gates before it can activate:

Result	Meaning
`invalid`	The requested skill ID is not in the catalog.
`missing_tools:<tools>`	The selected App does not provide every required base tool.
`wrong_chain:<details>`	The connected wallet is on an unsupported chain.
`token_budget_trim`	Activating the complete selection would add too much context.
`invalid_guard`	The skill’s guard data could not be resolved, so activation failed closed.

When the wallet chain is known, a chain-scoped skill activates only on one of its declared chain_ids. Chain-agnostic skills omit that restriction.

Protocol catalog

The built-in catalog currently contains protocol skills for:

Swaps and DEXs: Uniswap, 1inch, Curve, SushiSwap, Aerodrome, Jupiter, Raydium, and LiFi.
Lending: Aave, Compound, Morpho, and Kamino.
Staking, restaking, and yield: Lido, Rocket Pool, Ether.fi, EigenLayer, Renzo, Kelp, Pendle, Yearn, Convex, and Marinade.
Bridges: Across, CCTP, Stargate, Arbitrum, Optimism, Base, zkSync Era, and deBridge.
Markets: Avantis, Drift, OpenBook, and tokenized Robinhood assets.
Solana protocols: Jupiter, Raydium, Kamino, Marinade, Meteora, Sanctum, Squads, and OpenBook.
Wallet and asset utilities: native balances, ERC-20 holdings, allowances, and account inspection.

The catalog can expand without making every request carry every protocol’s interfaces and instructions.

Skills and Apps

An App supplies the thread’s permanent tool surface and policy. Runtime skills add task-specific protocol guidance and temporary tool access. Activating a skill cannot replace or weaken the App’s policy. The App’s own manifest policy remains in scope for every turn that runs the App. It is separate from catalog skills, which have discovery and activation semantics. When both apply, their constraints compose and can only narrow what the transaction may do.

Transaction pipeline

Follow an action from construction through simulation, signing, and broadcast.

Architecture

See how Apps, tools, models, and execution fit together.

Transaction safety

Understand the checks that prevent unsafe execution.

Multi-chain support

Review the EVM and SVM execution surfaces.

Try Aomi

Integrate Aomi

Concepts

Security

Payments

Multi-chain Support

Case Studies

Resources

Skills and guards

How skills work

Skill bundle anatomy

Discovery and activation

Base tools and skill-owned tools

Instructions and execution procedures

The guard system

Guard outcomes

Guards fail closed

App and chain compatibility

Protocol catalog

Skills and Apps

Transaction pipeline

Architecture

Transaction safety

Multi-chain support

​How skills work

​Skill bundle anatomy

​Discovery and activation

​Base tools and skill-owned tools

​Instructions and execution procedures

​The guard system

​Guard outcomes

​Guards fail closed

​App and chain compatibility

​Protocol catalog

​Skills and Apps

​Related documentation

Transaction pipeline

Architecture

Transaction safety

Multi-chain support

How skills work

Skill bundle anatomy

Discovery and activation

Base tools and skill-owned tools

Instructions and execution procedures

The guard system

Guard outcomes

Guards fail closed

App and chain compatibility

Protocol catalog

Skills and Apps

Related documentation