A programmable transaction is a single transaction that carries its own logic: it reads onchain state, chooses which calls to make, and checks conditions, all at execution time and without deploying a new contract. A smart contract is a program deployed once to an address, which the Ethereum Foundation documentation describes as a collection of code and state that resides at a specific address on the blockchain (Ethereum Foundation: smart contracts). Both run onchain. They differ in when the logic is written down, who can change it, and what it costs to ship. This page defines the category, compares the two models, and explains when a contract is still the right tool.
​

Last reviewed: Nov 2026. Product details are quoted from each platform's documentation.
​

A programmable transaction bundles several onchain actions and the conditions they must meet into one transaction that executes atomically. If any condition fails, the whole transaction reverts and nothing moves. The logic travels with the transaction instead of living in a deployed contract, so each transaction can carry different logic.
​

Two production systems use the idea in different ways. Sui's programmable transaction blocks group up to 1,024 commands into one transaction, where later commands can use earlier commands' results, and execute them atomically (Sui documentation: PTBs). Eco's knowledge base compares that model with EVM options in Sui programmable transaction blocks and the EVM equivalent.
​

On EVM chains and Solana, Sauce, Eco's onchain harness for agents, takes a program-per-transaction approach. A Sauce program is written in SauceScript, a language based on a subset of TypeScript, and compiles to instructions for Sauce's engine; the docs state that a developer does not deploy a new contract for each program (Eco docs: Sauce introduction).
​

A smart contract is deployed once and then called many times. Its code and state live at a fixed address, anyone permitted by its logic can call it, and changing its behavior means deploying new code or using an upgrade pattern designed in advance. Deployment itself is a transaction that costs gas.
​

Ethereum's documentation notes that contracts are not controlled by a user once deployed, cannot be deleted by default, and that interactions with them are irreversible. It also notes that gas costs for deploying a contract are far higher than for a simple ETH transfer (Ethereum Foundation). For a team that needs a one-off sequence, such as swap then pay, writing, auditing and deploying a contract for that sequence is heavy.
​

The two models differ on five axes: whether a deploy step exists, the language used, how state is read, how logic changes over time, and what has to be audited. Programmable transactions favor one-off and agent-generated logic; contracts favor shared, persistent rules that many users call.
​

A Sauce program runs in four steps: compile for a chain, build the transaction, simulate it against chain state, then authorize and send. On EVM chains the transaction calls a Pot, the account that holds tokens and executes the program, and the Pot runs the compiled program through Sauce's engine in one transaction.
​

Eco's docs walk through a first program that pays USDC from the Pot after a require check that the Pot holds at least the amount, with the message "not enough USDC" (Eco docs). The compiler resolves names such as USDC to the token address for the chosen chain, and Uint256 arithmetic checks for overflow and underflow. The CLI builds and sends transactions on Ethereum, Base, Arc and Solana and on several testnets.
​

The docs define the terms used: the Program is the actions and checks in a .sauce.ts file, the Pot holds tokens and executes it, a Cook is a transaction that runs a program through a Pot, and the Kitchen creates Pots and sets the execution fee (Eco docs).
​

Programmable transactions fit tasks where an action depends on a balance, a price, or the result of an earlier action in the same transaction. Eco's documentation names three families: payments that distribute tokens or swap before paying, swaps that compare pools or enforce a minimum output, and lending actions that check the resulting position.
​

A program compares two pools, swaps on the better one, and requires that the output meets a floor. If the price moved between quote and execution, the transaction reverts instead of filling at a worse rate. The Sauce docs list "enforce a minimum output" and "try a second pool when the first attempt fails" as common swap patterns (Eco docs).
​

A treasury pays several recipients in one transaction and checks the balance first. Either every payment lands or none do, which keeps reconciliation simple. Eco's programmable stablecoin payments guide covers payment flows in more depth.
​

Programmable transactions suit AI agents because an agent can write a fresh program per task without a deploy step, and the conditions bound what the transaction can do. The Sauce MCP server gives coding agents tools to compile, simulate and build these transactions (Eco docs: Sauce for AI agents). See how to connect Claude to a crypto wallet for that setup.
​

A smart contract is still the right choice when logic must persist and be shared: a token, a lending market, a vault many depositors use, or any rule that third parties need to rely on without trusting whoever builds each transaction. Programmable transactions call those contracts; they do not replace them.
​

The test is who needs the rule. If only the sender cares that a swap meets a floor, the rule belongs in the sender's transaction. If every depositor needs the same withdrawal rule enforced, it belongs in a contract that all of them call. Most production systems use both: contracts for shared state, programmable transactions for the per-user sequence on top. Teams writing contracts with AI help should read AI smart contract security and EVMbench, and teams targeting several chains Solang and other multi-target options.
​

Programmable transactions have limits worth stating plainly: they run on one chain at a time, they only enforce what the sender wrote, and simulation results can go stale. They reduce the need for bespoke contracts; they do not remove the need for careful conditions.

These are the common questions about programmable transactions and how they relate to smart contracts.
​

No. It calls contracts and carries its own logic for one execution, without deploying a new contract (Eco docs).
​

Both bundle actions atomically. PTBs are native to Sui with a 1,024-command limit (Sui docs); Sauce programs run on EVM chains and Solana.
​

They skip deployment, which Ethereum documentation notes costs far more gas than a simple transfer (Ethereum Foundation). Execution still costs gas, and Sauce's Kitchen sets an execution fee.
​

Yes. Sauce's MCP server lets coding agents compile, simulate and build them (Eco docs).
​

Definitions and limits are quoted from platform documentation fetched on November 12, 2026. No transactions were sent for this page.