How Agents Interact With Smart Contracts

Every contract interaction is either a read or a write, and the gap between them is the whole game.

Reads call view or pure functions — balanceOf, getReserves, the state of a governance proposal. They execute against a node's local copy of the chain, cost no gas, need no private key, and change nothing. An agent can read as often as it wants. The only real risks are *stale* or *wrong* data: a lagging indexer, a reorged block, or a manipulated price feed.

Writes send a signed transaction that mutates state — a swap on a DEX, a transfer, a vote, a deployment. They cost gas, require the agent's wallet to sign, and are irreversible once mined. This is where spend limits, permission scoping, and human-approval steps earn their keep. A useful rule for onchain agents: reads can run autonomously; writes above a threshold should pass a guardrail first.

To touch a contract, an agent needs two things.

• ▸The ABI (Application Binary Interface) — a JSON schema listing the contract's functions, their inputs, and outputs. It's how the agent knows swapExactTokensForTokens exists and what arguments it takes. Without the right ABI, a call is just undecodable bytes.
• ▸An RPC endpoint — the connection to a node that relays reads and broadcasts transactions. Providers like Alchemy or a self-hosted node expose the standard JSON-RPC API: eth_call for reads, eth_sendRawTransaction for writes, eth_estimateGas for sizing.

The flow: the agent takes a function name plus arguments, ABI-encodes them into calldata, and sends that to the RPC. For a read it uses eth_call and decodes the result; for a write it builds a full transaction object, signs it, and broadcasts. Libraries such as viem handle the encode/decode automatically from the ABI — readContract({ address, abi, functionName }) is the entire read path.

The single most important habit for a write-capable agent is simulation — running the transaction against current chain state without broadcasting it, to see exactly what it would do.

A basic simulation is just eth_call against the same calldata you'd submit: it executes in the node's EVM and returns the result or the revert reason, for free. Richer tooling like Tenderly Simulations predicts the full state changes, token deltas, and emitted events before anything is signed.

For an agent this is non-negotiable, because the model's reasoning can be confidently wrong. Simulation answers questions a write should never skip: *Will this revert? How many tokens come back? Is the price within tolerance?* Catching a bad outcome in simulation costs nothing; catching it on-chain costs the trade. The same logic underpins risk limits on a trading agent — simulate, check against policy, then sign.

Even a correct call meets the messy reality of a live chain. The recurring failure modes:

• ▸Gas estimation and spikes. eth_estimateGas gives a baseline, but estimates can be wrong for state-dependent calls, and fees move before inclusion. Underpriced transactions stall; over-tight gas limits revert mid-execution.
• ▸Nonce management. Transactions are ordered by nonce. An agent firing several writes in quick succession can collide nonces, stranding later ones until the gap is filled.
• ▸Slippage and MEV. Between simulation and inclusion, the price can move or a searcher can sandwich the trade. Without slippage bounds, a swap can execute at a far worse rate than simulated.
• ▸Reverts and partial state. A transaction can revert after spending gas, returning nothing but a fee bill.
• ▸Approval risk. An unlimited token allowance that's never revoked leaves funds exposed if that contract is later compromised. Scope approvals to the amount needed.

None of these are exotic. They're the standard tax of writing to a public chain, and an agent that ignores them will eventually pay it.

Few teams hand-roll ABI encoding and nonce logic. Agent skill libraries wrap the contract layer into typed actions the model can call as tools.

• ▸[GOAT SDK](/resources/goat-sdk) exposes onchain actions across EVM chains and Solana as agent tools, bundling wallet signing with protocol integrations so the model calls swap or transfer instead of building calldata (repo).
• ▸[Solana Agent Kit](/resources/solana-agent-kit) does the same for Solana, wrapping dozens of program interactions behind agent-callable functions (repo).
• ▸Read-heavy agents often add an MCP server or indexer that serves chain state in one interface, so the model queries data without managing raw RPC.

These abstractions are conveniences, not magic. The agent still signs real transactions against real contracts, and the ABI, simulation, and gas concerns above don't disappear — the SDK just stops you re-implementing them. Whether a given library is open and active, rather than self-reported, is the kind of thing the Sato Score tracks.