Glossary

Terms as Aomi uses them, A to Z. Each entry gives the plain meaning first, then the mechanics, then the page that owns the concept.

​

account abstraction (AA)

Smart-account execution lets a programmable account handle a batch of approvals and calls with one signature. Aomi supports EIP-7702 and EIP-4337 through its backend AA path, with fallback to direct EOA execution. See How execution works.

​

Aomi App

The deployed unit a builder ships. It combines your plugin tools and system prompt on the hosted runtime. Users select an App in the portal, CLI, and Developer Platform. See the Build overview.

​

aomi-core namespace

The platform’s own tool group, shipping runtime capabilities such as the scheduling tools schedule_cron, spawn_thread, and wake_on_condition. The default App includes it; a custom App opts in. See Asynchronous tasks.

​

batch

An EVM group of pending transactions treated as one unit. A batch can contain an approval and the swap that depends on it, with later steps seeing state created by earlier steps. Solana instead places ordered instructions inside one atomic transaction. See Transaction pipeline.

​

beneficiary

The wallet address that receives fees from a priced tool. Declare it in the [[beneficiaries]] section of an App’s pricing sidecar. Settlement occurs per beneficiary, so one receipt can clear fees across several Apps. See Fees.

​

canonical account

The account identity that owns threads, installed packages, settings, and wallet signing policies. Aomi links a person’s addresses across chains to this account instead of treating an address as the user. See Accounts and wallets.

​

condition trigger

A deferred intent that fires when observable state matches a rule: a read-tool probe plus a comparison such as “when the health factor drops below 1.1.” It is persisted by wake_on_condition and checked on a cadence. It can recur with re-arm hysteresis and can expire. See Asynchronous tasks.

​

confirm judge

An optional safety check before a risky condition trigger executes: a detached, read-only agent pass that must return an explicit yes. A no, a stall, or a crash fails closed without consuming a retry attempt. See Asynchronous tasks.

​

credit

Aomi’s unit of account for pricing and usage. One credit equals $0.01. Tool prices, platform usage, and the Usage page all count in credits. See Fees.

​

dead-letter

The state of an asynchronous task after three claimed runs fail to complete. Aomi retains it for inspection and does not offer it for another run. See Asynchronous tasks.

​

delegated grant

A revocable authorization that lets an embedded wallet provider such as Privy or Para sign without a prompt for each transaction. The auto signing mode requires an active grant. An expired or revoked grant makes the next signing request fail. See Configure approvals.

​

Developer Platform

build.aomi.dev, the web control plane for Aomi Apps: create, deploy, activate, and operate from the browser, plus secrets, provider keys, bot integrations, usage, logs, and metrics. It drives the same backend lifecycle as the aomi-build CLI. See Developer Platform.

​

drain vector

A calldata field that can redirect funds. Examples include recipient on Uniswap, onBehalfOf on Aave, mintRecipient on CCTP, and _to on OP Stack bridges. Protocol guards block a staged transaction when the field does not match the signer. See the transaction safety guide.

​

EIP-4337

The account-abstraction standard that routes operations through a bundler instead of a plain transaction, letting a smart account batch and sponsor calls. One of the two rails in Aomi’s AA lane. See How execution works.

​

EIP-712

The standard for signing typed, structured data instead of raw bytes, so a wallet can display exactly what is being authorized. Aomi uses EIP-712 signatures for the permits that change a wallet’s signing mode, and relays typed-data requests (a CoW order, a token permit) through the same queue as transactions. See Configure approvals.

​

EIP-7702

The standard that lets an existing externally-owned account temporarily act as a smart account, gaining batching without migrating to a new address. The other rail in Aomi’s AA lane, alongside EIP-4337. See How execution works.

​

fork

A temporary copy of live chain state used to simulate transactions before signing. It reports balance changes, gas, and revert reasons without spending gas or changing the live chain. See How execution works.

​

guards

The layer that decides what may be staged at all, before any signature is in play: App guard tables (allowlists of contracts, selectors, and spenders), protocol guards (drain-vector checks), per-call value caps, and read-only threads. Anything a guard cannot decode fails closed. See Transaction safety.

​

harness

Aomi’s core machine: the system that turns plain-language instructions into verified onchain execution through the build → simulate → sign → broadcast pipeline. Plugins extend the harness with your own tools and prompt. See the Build overview.

​

headless library

The @aomi-labs/react npm package: runtime logic, state management, hooks, and an API client with zero UI opinions, for building a fully custom frontend on Aomi. See Headless library.

​

hooks

The React hooks exported by the headless library, including useAomiRuntime, useWalletHandler, and useNotificationHandler. Each hook exposes part of the runtime state and must run beneath AomiRuntimeProvider. See the Hooks reference.

​

LLM interface

The runtime component that connects agent threads to models. Your plugin declares which model an App uses, and the runtime handles model selection and scheduling. See the architecture overview on the Introduction.

​

MCP

Model Context Protocol is a standard for connecting an AI client to external tools. Aomi hosts an MCP server at chat.aomi.dev/api/mcp. Clients can search tools, read chain state, and stage transactions inside your account. Signing always completes on a wallet surface. See MCP.

​

namespace

A named group of related tools inside an App. Pipeline discovery lists the current catalog through the /v1/pipeline directory tree. aomi-core is Aomi’s namespace. See MCP.

​

non-custodial

Aomi does not hold private keys or funds. The agent composes and simulates transactions. Only the user’s wallet or a provider with a revocable delegated grant can sign. See Accounts and wallets.

​

outcome fee

A percentage of the value moved by a supported transaction. Aomi adds the fee to the signed smart-account transaction and pays it in the asset being moved. Declare the fee with an [[outcome]] rule in the App pricing file. See Fees.

​

permit

A wallet-signed authorization that changes a wallet’s signing mode. EVM uses an EIP-712 message, while Solana uses a canonical Ed25519 message. Permits are replay-protected and expire within five minutes. See Configure approvals.

​

plugin

The thing a builder writes: a small Rust crate compiled to a shared library, declared with the dyn_aomi_app! macro and an aomi.toml config, wrapping your external APIs as tools with a system prompt. The runtime loads plugins dynamically, with no restart; deployed, a plugin becomes an App. See the Build overview.

​

preamble

The system prompt that defines an App’s role, constraints, and tool usage. A plugin treats it as configuration rather than a suggestion. See the Build overview.

​

Project

A GitHub repository connected to the Developer Platform. One Project can ship several Apps, and every deploy-lifecycle action on it works from both the web console and the aomi-build CLI. See Developer Platform.

​

read-only thread

A thread carrying a credential that denies signing outright. Any thread it spawns inherits the restriction, so a read-only context can never mint itself an escalation. See Transaction safety.

​

recurring intent

A deferred instruction stored as durable state instead of a sleeping process. It includes the instruction, target App, a snapshot of user state, and a recurrence rule. Each occurrence starts a fresh thread and checks wallet policy for signing authority. See Asynchronous tasks.

​

runtime

The hosted environment your App runs in: it loads plugins dynamically, manages per-user agent threads, schedules tools and models, simulates every staged transaction, enforces signing policy, and serves every surface from one deployment. You configure it; you don’t build it. See the Build overview.

​

signing mode

The per-wallet policy checked on every commit. Its value is denied, manual, client_auto, or auto. The mode determines whether signing is allowed and changes only through a wallet-signed permit. See Permission model.

​

simulation

Executing a proposed transaction without changing the live chain. EVM uses a stateful fork and requires a passing result before signing. Solana provides explicit LiteSVM or cluster simulation that an App should run before commit. See Transaction pipeline.

​

Solana bundle

An ordered instruction set compiled into one legacy or v0 Solana transaction. Every instruction succeeds together or the transaction fails without committing any of them. This is different from a Jito bundle of several independent transactions. See Solana bundle.

​

skill

A markdown instruction file that teaches an AI coding assistant how to use Aomi. aomi-transact covers trading through the CLI, and aomi-build covers scaffolding App crates. See Skills.

​

staged transaction

A transaction the agent has composed and queued for approval but not signed. Staging tools collect pending transactions, and a commit submits the batch for wallet approval. The CLI lists them as tx-N in aomi tx list. See How execution works.

​

staging

Aomi’s pre-production environment, reachable at chat-staging.aomi.dev. It is a separate account graph: a sign-in or wallet link on production does not carry over. See MCP.

​

statement

The record behind the Usage page. It summarizes gross revenue, platform fees, service charges, and net earnings for your Apps. See Fees.

​

stateless dispatch

The runtime’s front layer, which routes each incoming message to the right per-user agent thread without holding conversation state itself. It is why one deployment scales across users and surfaces. See the architecture overview on the Introduction.

​

thread

One durable agent workspace that belongs to an account. It contains message history, user state, and staged transactions. A parent can create a child with its own transcript and narrower authority. See Multi-threading.

​

Tool Scheduler

The runtime component that dispatches calls to plugin tools, chain gateways, and data drivers. It returns the results to the agent thread. See the architecture overview on the Introduction.

​

widget

The drop-in AomiWidget React component, with chat, authentication, and wallet review composed for your host application. Install @aomi-labs/widget-lib and select a deployed App and wallet provider. See Widget installation.

​

x402

The HTTP payment protocol Aomi uses to collect tool fees. Aomi returns 402 Payment Required with the exact amount and recipient. The user authorizes the USDC payment, and a facilitator settles it onchain. See x402 payments.