What a plugin contains
A plugin is a small Rust crate compiled to a shared library. You declare it with one macro,dyn_aomi_app!, and one config file, aomi.toml. That is
the whole contract. You write the tools; the platform handles the hard
parts:
- Non-custodial wallets. Your users keep their own keys. Your plugin never holds them.
- Simulate first. Every transaction is simulated before anyone signs, so the agent shows the real outcome before it commits.
Example: Somm Finance
Somm Finance provides automated DeFi vaults that seek yield while managing risk. Agentic Somm helps you move idle USDC into Aave v3 on Base through a human-approved flow. Somm’s models, data, and risk framework already existed as five HTTP endpoints. The team wrapped those endpoints as tools and used the investment mandate as enforced configuration in the system prompt. They deployed the plugin as the Somm Liquidity Manager App.
The same App now serves the Somm frontend, Telegram, and Discord from one
deployment. It executes vault operations and charges an App-level fee through
Aomi. The runtime holds no keys. The agent builds and simulates each
transaction, then sends the proposal to the mandate holder’s wallet.
Runtime Features
Your plugin contains tools and a prompt. You configure the runtime features below instead of building them. Wallets and signing. Your users’ keys never touch Aomi. Every wallet has one kernel-enforced signing mode:denied, manual, client_auto, or auto.
The mode changes only through a
wallet-signed permit, and everything unknown fails closed. Delegated
auto-signing exists only for embedded wallets (Privy, Para) under a
revocable grant; self-custody wallets sign every request on the user’s own
device. The invariant your users can rely on: the agent can compose and
simulate any transaction, but can only ever propose it.
Account abstraction. EIP-7702 and EIP-4337 package compatible EVM calls
into one operation. Your plugin does not need to manage bundler plumbing. See
Account abstraction for the EVM flow.
Solana bundles. Solana uses an ordered instruction bundle inside one atomic
transaction. Aomi can assemble the transaction or preserve venue-supplied
bytes, then route signing and submission according to the wallet policy. See
Solana bundle for the complete lifecycle.
Multi-threading. A parent thread can delegate focused work to a durable
child. The child keeps a separate transcript, returns its result to the parent,
and cannot sign or submit staged transactions on its own.
Asynchronous tasks. A user intent can outlive the conversation. One-time
schedules, recurring intents, and condition triggers persist as durable tasks,
run with bounded retries, and resolve signing
authority from the wallet’s own policy at execution time. The scheduler does
not pre-grant signing authority.
Fees. Set flat tool prices in <app>.pricing.toml. User payments settle
in USDC through x402. Supported outcome fees settle with the signed
transaction. Review revenue and service charges in Operate > Usage.
Surfaces. One deployment serves the portal, the widget or headless
library in your frontend, and a hosted Telegram bot. Discord and Slack are
planned.
Related Concepts
Accounts and wallets
How wallets link to an account and why keys never move.
Permission model
Per-wallet modes, the permit ceremony, and the guard layer.
Transaction pipeline
Build → simulate → sign → broadcast, with account abstraction in the sign step.
Multi-threading
Parent and child threads with separate context and controlled authority.
Asynchronous tasks
Detached, scheduled, recurring, and condition-triggered runs.
Fees
Price App tools and review revenue, platform fees, and service charges.
Multi-chain specification
What EVM and SVM support each mean, chain by chain.