An agent that drafts an email can be wrong twice a day and nobody notices. An agent with a wallet is a different object.
It signs, it broadcasts, and the moment a validator includes the transaction the thing it did is true for everyone, permanently.
No chargeback, no support queue, no undo — the recovery path on a public blockchain is a polite message to an address that owes you nothing.
So the engineering of AI agents for crypto does not sit in the prompt. It sits at the signer. An on-chain agent should never hold raw key material.
It produces an intended transaction and hands it to a signing service that holds the policy — which contracts it may call, which functions on them, which chains, which destination addresses, and how much value may leave per transaction and per day.
A limit written into a system prompt is a request. A limit enforced by the thing that owns the private key is a control.
That distinction carries more weight here than anywhere else, because on a chain almost everything the agent reads was written by someone who is not you.
A token name, a symbol, a metadata URI, a contract's return value, the body of a governance proposal: all of it arrives inside the model's context and competes with your instructions on equal terms.
What the agent reads is a security boundary before it is a retrieval quality problem.
Before anything is broadcast, the transaction is simulated against a fork of chain state at current head, and what comes back is a state diff — value moved, approvals granted, ownership changed, gas and slippage.
That diff is what a person approves, not the agent's account of what it means to do. A rejected simulation costs nothing. A signed mistake costs whatever was behind the key.
Then the part that catches teams who have only built off-chain: confirmed is not final.
A reorg can unwind an inclusion the agent has already treated as settled and acted on, and a blind retry against a stuck nonce is how one payment becomes two.
Reorg depth, nonce handling, replacement transactions and idempotent action design get decided per chain before the agent is allowed to sign anything, not after the first mismatch.
The signing discipline here comes from Anupam Shah's record in payments.
He ran payment infrastructure at $60M+ volume in MAS-regulated, SOC 2 / ISO 27001 environments, where a process holding signing rights with no human in the loop would have been a control failure long before anyone called it a feature.
Those controls transfer to a chain almost unchanged. What does not transfer is the safety net underneath them.
An agent that reads chain data, drafts a report or files a ticket is ordinary AI agent development; where the contracts, indexing or settlement path underneath it are themselves the problem, that is protocol engineering.
Scope
The agent never holds raw key material.
It proposes a transaction; a signing service holds the policy and decides — an allowlist of contracts and the functions on them, permitted chains and destination addresses, per-transaction and per-day value ceilings, and token approvals that are bounded and expiring rather than infinite.
Written this way, an agent that gets compromised is worth its allowance for the day, not the wallet behind it.
Every action runs against a fork of chain state at current head before broadcast, and the approval screen carries the resulting state diff — value moved, approvals granted, ownership changed, gas and slippage — rather than the agent's description of its intent.
A rejected simulation is a nothing event. Numbers the agent acts on, from balances to remaining limit, are returned by code it calls, never produced as tokens.
Reorg depth is chosen per chain and the agent's idea of settled state derives from it, so an inclusion that gets unwound does not leave the agent acting on history that no longer happened.
Nonce handling, replacement transactions and idempotent retries are designed in rather than discovered: on a public ledger a double-send is not a bug report, it is somebody else's money.
Token names, symbols, metadata URIs, contract return values, proposal text and any feed the agent reads are strings an attacker can author, arriving inside the model's context.
The mempool cuts the other way: a pending transaction is public before it lands, so an agent whose next move is legible to a counterparty is leaking strategy as well as spending permissions. Both belong in the threat model, not in the plumbing.
Stopping the process is not stopping the agent, because a broadcast transaction cannot be recalled.
The stop revokes at the signer, and it ships with a written procedure for the rest: pulling outstanding token approvals, clearing a stuck nonce, rotating a key you no longer trust.
You keep the policy file, the address book and the runbook, and nothing in the handover depends on a key we hold or a service we host.
An on-chain AI agent is a model wired to tools where at least one of those tools can sign a transaction, so its output is not text, it is a state change on a public blockchain.
That one fact reorders the engineering: key custody, spend ceilings, simulation before broadcast and finality handling matter more than which model you picked, because everything downstream of a signature is irreversible.
If nothing in your system holds a key, you are describing a general agent rather than a web3 AI agent.
AI agent development covers agents acting inside systems you control, such as your CRM, your queue or your ledger, where a wrong action can usually be reversed by someone with database access. This page covers agents acting on a chain, where it cannot.
The controls look superficially similar and the failure modes are not: reorgs, nonce collisions, an infinite token approval nobody revoked, a mempool that publishes intent before it executes, and no counterparty who can be asked to send it back.
No, and we take no custody of client funds.
Keys sit in your infrastructure, in an HSM, a cloud KMS or a threshold signer, with a multisig or a second approver on your side where the amounts justify it, and the agent gets the right to request a signature, never the key itself.
The policy deciding which requests get signed lives with the signer rather than in the agent's prompt, so withdrawing the agent's authority does not mean redeploying the agent.
Not after it signs. Once a transaction is broadcast and included, the remaining options are social and legal ones, which is why every control on this page sits before the signature rather than after it.
What can be stopped is the next one: the signer refuses, outstanding approvals are revoked, and the runbook covers the stuck-nonce and key-rotation cases. Planning to rely on a kill switch after the fact is planning on the wrong side of finality.
No. Formal audit is a separate discipline carrying its own liability, and a contract that needs one is referred to an independent auditor. A firm offering you the build and the audit on the same invoice is marking its own homework.
What an engagement covers is how your agent behaves against contracts nobody on your side controls. That means allowlisting them by address and by function, and reading decimals instead of assuming them.
It means capping token approvals rather than granting infinite ones, and treating an upgradeable proxy as something that can change its ABI without warning.
Chain scope and signing surface set the number long before hours do. Every additional chain is a second integration with its own finality behaviour and its own failure modes.
Every additional contract the agent may call is another policy entry and another simulation path that has to hold up under test. An agent that only reads chain data costs a fraction of one that can spend.
You do, outright. IP assignment is signed before repository access, by everyone who touches the code, and it covers AI-assisted output. Handover includes the runbook and the rollback path. Nothing depends on a licence we control.
Nobody before an NDA. Access is read-only until scope is signed, and you can revoke it at any time. The AI tools used on your code, and what each one retains, are listed on the governance page.
Retainers end on 30 days written notice from either side, with no minimum term. Milestone billing means you never pay ahead of delivered work.
Founder, Provingmark
Thirty minutes, no charge.
Related: AI consulting & implementation · AI workflow automation · LLM & RAG integration · Trading & execution infrastructure · DeFi protocol engineering · How we work