Sui programmable transaction blocks (PTBs) are transactions made of a list of commands, where later commands can use the results of earlier ones and the whole list succeeds or fails together. The Sui documentation caps a PTB at 1,024 commands. A programmable transaction, in general terms, is a transaction that carries its own sequence of logic instead of a single call, so a developer can compose existing contracts without deploying a new one.
​

Think of a PTB as a shopping list the cashier runs in one pass: split a coin, call a swap, send the output to a recipient. If any line fails, nothing on the list happens. Ethereum and other EVM chains did not ship that shape natively. EVM developers reach for three substitutes instead: wallet-level call batching (EIP-5792), delegated code on a regular account (EIP-7702), and transaction runtimes that compile a program and run it inside one transaction. This article explains how PTBs work, how each EVM option compares, and when a developer still needs to deploy a smart contract.
​

Programmable transactions are transactions that contain an ordered set of operations instead of one function call. Each step can consume the output of a prior step, and the network executes the set atomically, so every step lands or none do. Sui PTBs are the native example; EVM chains approximate the pattern through wallet batching, account delegation, or in-transaction programs.
​

The distinction matters because a standard Ethereum transaction calls exactly one entry point. If a user wants to approve a token and then swap it, that has traditionally meant two transactions, two signatures, and a window between them where prices move. The EIP-7702 specification names this directly: an ERC-20 approval followed by spending that approval is "a common workflow in DEXes that requires two transactions today."
​

Programmable transactions collapse those steps. On Sui, the composition lives in the transaction format itself. On Solana, a transaction holds one or more instructions that execute together, and if any instruction fails, all state changes revert, though Solana caps the serialized transaction at 1,232 bytes, which limits how much logic fits. On EVM chains, the answer depends on which of the three substitutes a team adopts.
​

For background on the contract model these transactions compose, see What Is a Smart Contract? and What Is Sui?.
​

A Sui PTB is a vector of commands plus a set of inputs. Commands include MoveCall, SplitCoins, MergeCoins, TransferObjects, MakeMoveVec, Publish, and Upgrade. Each command can reference inputs or the result of an earlier command, and the block executes as one unit, so a failure in any command reverts the entire transaction.
​

The Sui PTB reference lists seven command types, exposed in the TypeScript SDK as builder methods such as tx.splitCoins, tx.moveCall, and tx.transferObjects. A typical flow splits an amount off a coin, passes that new coin into a Move function call, then transfers the returned object to an address. All three steps travel in one signed transaction.
​

Three properties define the model:

What PTBs do not do is branch. A PTB is a fixed list. It cannot read a pool price mid-block and choose a different path based on what it finds; any decision logic has to live inside a Move function the block calls. That limit is where the EVM comparison gets interesting, because one class of EVM tooling adds branching.
​

The EVM has no single native PTB equivalent. Developers use EIP-5792 wallet batching for simple multi-call flows, EIP-7702 delegation to give an ordinary account batch-execution code, or a transaction runtime that compiles a program and runs it atomically inside one transaction. Only the runtime approach adds in-transaction branching on live state.
​

EIP-5792 defines JSON-RPC methods that let an app ask a wallet to process a batch of onchain write calls. When the app sets atomicRequired to true, the wallet must execute all calls atomically, meaning either every call succeeds or no material effects appear onchain. It is the closest analogue to a PTB's list-of-commands shape, but atomicity depends on what the wallet supports, and calls cannot pass return values to each other.
​

EIP-7702 adds a transaction type that lets an externally owned account set a delegation to contract code. The spec lists batching as a core motivation and notes that advanced batching can involve dependencies, where the output of the first operation feeds the second. The delegated code is still a contract someone wrote and deployed. Eco's explainer on EIP-7702 covers the account mechanics.
​

The third option ships a compiled program with the transaction. Eco's Sauce SDK, launched October 28 2026, compiles SauceScript, a subset of TypeScript, into bytecode that runs once onchain against live state, reads from many contracts, compares results, loops, and passes one call's output into the next. It commits as a whole or reverts as a whole, and no contract is deployed per workflow.
​

A smart contract is code deployed at an address that persists and can be called many times. A programmable transaction is logic that lives in one transaction and runs once. Contracts hold state and enforce rules for everyone; programmable transactions compose existing contracts for one user's specific outcome, without a deployment, audit cycle, or upgrade path.
​

The table below compares the options on the dimensions developers ask about most.
​

The practical split: contracts are for rules that must persist and apply to many users, such as a lending market or a token. Programmable transactions are for one-off compositions of those rules, such as "swap on whichever of two pools quotes better, then deposit the output." A team shipping new routing logic every week pays a deployment and review cost each time with contracts; with a transaction program, the logic changes without a new address.
​

Not always. If the logic only composes existing contracts, a Sui PTB, a Solana multi-instruction transaction, an EIP-5792 batch, or a transaction program can run it without a deployment. A new contract is still required when the logic must hold state between transactions, custody funds for other users, or be callable by third parties.
​

A decision path helps here. Read it top to bottom and stop at the first match:

The middle branch is where most "should we deploy?" debates land. Routing, rebalancing, and settlement checks rarely need persistent state. They need a decision made against live numbers and a hard floor that reverts the transaction if the numbers are wrong. The Sauce launch post describes this as the tradeoff between static contract logic and offchain infrastructure that adds latency between quote and execution.
​

Yes, with limits. Sui's TypeScript SDK builds PTBs in TypeScript, though the called logic is still Move. On EVM chains and Solana, SauceScript is a TypeScript subset compiled to bytecode that executes inside the transaction. Persistent contracts on Ethereum are still written in Solidity or Vyper.
​

The Sui case is a builder pattern: TypeScript assembles the command list, and Move code onchain does the work. Developers who want branching still write Move.
​

The SauceScript case moves the logic itself into TypeScript syntax. The Sauce product page shows a payment program as a main function that requires the Pot (the account the program runs from) to hold enough USDC, then transfers it, compiled with npx sauce compile pay.sauce.ts --chain base. The same page shows a recipe that compares two Uniswap V3 fee-tier quotes, picks the better pool, swaps, and supplies the output to Aave V3, all in one transaction that reverts if any require fails.
​

Two caveats from Eco's own documentation keep this honest. SauceScript is a subset, so not every TypeScript construct compiles. And the Sauce security notes state that a program enforces the conditions written into it and no others: a wrong recipient or an amount in the wrong unit still compiles and runs as written.
​

Programmable transactions do not replace contracts for persistent logic, and each implementation has hard limits. Each one limits branching, size, or atomicity in a different way, and in-transaction rollback does not undo approvals or cross-chain legs made outside that transaction. The limits below come from each protocol's own docs.

For a Sui developer, PTBs are the default way to compose Move calls. For an EVM or Solana developer looking for the same thing, the choice depends on whether the logic must branch at execution time. Simple sequences fit wallet batching; decisions against live prices fit a transaction runtime; persistent shared rules still need a contract.
​

Eco uses the runtime pattern in production: the launch post says Sauce powers swap routing behind the Eco Routes API, where programs compare markets, split orders, and enforce minimum received amounts without a new contract per workflow. Teams building agents that move stablecoins can read AI Agent Spend Controls for how in-transaction limits fit a wider control stack.
​

These are short answers to the questions developers and operators ask most often about Sui programmable transaction blocks and their EVM equivalents. Each answer stands on its own and points to the primary documentation used in this article, retrieved in November 2026, for readers who need the full detail.
​

No. A PTB is a single transaction that calls existing Move functions in sequence. A smart contract (a Move package on Sui) is deployed code that persists at an address. PTBs compose packages; they do not replace them.
​

Up to 1,024, per the Sui PTB documentation.
​

Not natively. EIP-5792 batches wallet calls, EIP-7702 lets an account run delegated batching code, and transaction runtimes such as SauceScript run a compiled program inside one transaction.
​

Neither is inherently safer. A transaction program avoids a persistent attack surface but enforces only the checks it contains. Contracts persist and can be audited once, but every logic change means a new deployment.
​

Native PTBs and Solana transactions are chain-specific. SauceScript compiles one source to EVM and SVM bytecode, per Sauce; see Solang and other ways to target EVM and Solana from one codebase.
​

Facts in this article come from primary documentation retrieved on November 9 2026: the Sui PTB reference, Solana transaction docs, EIP-5792, EIP-7702, and Eco's Sauce product page, launch post, and security considerations. No performance numbers were measured for this article.
​

Related reading: What Is a Smart Contract?, What Is Sui?, What Is EIP-7702?, Smart Wallet UX Patterns, Solana vs Ethereum, Transaction Simulation Tools Compared, Claude Code vs Cursor vs Codex for Onchain Development, AI Agent Spend Controls.
​