Sui's Programmable Transaction Blocks (PTBs) are a fundamental departure from single-intent transaction models, enabling a sequence of up to 1,024 operations to execute atomically. This design unlocks powerful native composability, allowing a single transaction to perform complex, multi-step actions like atomic arbitrage, flash loans, and batched marketplace settlements without a smart contract intermediary. For front-end and wallet teams, this shifts the security boundary: the transaction construction layer itself becomes a critical point of trust, as the final PTB presented to a user for signing may contain commands they did not intend to authorize.
Protocols
Programmable Transaction Block (PTB) Composability and Risk Analysis
A technical guide for front-end and wallet teams on the security and UX risks of PTB composability, covering atomic arbitrage, flash loans, command injection, and simulation strategies.
introduction
PROGRAMMABLE TRANSACTION BLOCK COMPOSABILITY
Introduction
Understanding the security and UX risks of atomic composability in Sui's Programmable Transaction Blocks.
The primary risk vector is 'sandwiching' within a PTB, where a malicious or compromised front-end injects commands before and after a user's intended actions. For example, a PTB constructed for a simple token swap could be silently prepended with commands to drain a related object and appended with commands to obfuscate the final state change. Because the entire block executes atomically and the user approves a single opaque transaction, traditional simulation that only shows the immediate function call is insufficient. Wallets must simulate the entire PTB and display the net state changes across all objects touched by the block to make the transaction's effect transparent and verifiable.
Operationally, this requires integration teams to implement PTB-level simulation that parses the full command graph, identifies all input and output objects, and presents a human-readable diff of the proposed state changes. This is a non-trivial engineering challenge, as a single PTB can touch dozens of objects with complex ownership and dynamic field relationships. Chainscore Labs can audit this critical simulation and display logic, ensuring that wallets and front-ends accurately detect injected commands and faithfully represent the final state transition to the user before signing.
PTB COMPOSABILITY & RISK
Quick Facts
Key facts about Programmable Transaction Block (PTB) composability, its operational impact, and the associated security risks for builders and integrators.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Transaction Model | Multiple Move calls and object operations are chained atomically in a single block, succeeding or failing together. | Wallet providers, dApp front-ends, exchanges, custodians. | Review simulation and signing UX to ensure users can inspect the full, final state change, not just a single function call. |
Atomic Composability | Enables atomic arbitrage, flash loans, and multi-protocol settlement within one block without deploying a separate contract. | DeFi protocols, MEV searchers, liquidity providers. | Audit smart contracts for cross-protocol re-entrancy and state-change assumptions that differ from single-call execution. |
Injection Risk | A malicious dApp or compromised front-end can inject commands between a user's intended actions within a single PTB. | Wallet users, front-end developers. | Implement PTB simulation and display the full sequence of commands and net state changes for user approval before signing. |
Simulation | Wallets must simulate the entire PTB to show a preview of all effects, including object mutations, balance changes, and gas costs. | Wallet development teams, security auditors. | Verify simulation logic against all PTB command types, including Move calls, object transfers, and gas coin operations. |
Sponsored Transactions | A gas sponsor can pay for a PTB, but the sponsor does not control the transaction's internal commands. | Gas station operators, app developers, users. | Ensure sponsor logic validates the PTB's commands against an allowlist to prevent paying for unauthorized actions. |
Display Logic | Parsing PTB results to display a human-readable summary of complex, multi-command state changes is non-trivial. | Wallet UI/UX teams, integrators. | Test display logic with PTBs that touch dozens of objects, including NFTs, dynamic fields, and Kiosk purchases. |
Sandwich Risk | A PTB is atomic and cannot be front-run internally, but the entire block can be sandwiched by preceding and following transactions. | MEV searchers, DeFi protocols, traders. | Design protocols with awareness that PTB atomicity protects internal commands but not the block's ordering position. |
technical-context
ATOMIC EXECUTION AND COMPOSITION RISK
The PTB Composability Model
How Sui's Programmable Transaction Blocks enable powerful multi-command composition while introducing novel security and UX challenges for builders.
Sui's Programmable Transaction Block (PTB) is a primitive that allows a single transaction to execute up to 1,024 distinct commands atomically. Unlike EVM chains where complex multi-step operations require separate transactions or smart contract entry points, a PTB can call multiple public functions, split and merge objects, and transfer assets across different Move modules in one all-or-nothing execution. This composability model is a fundamental shift for integration engineers: a wallet or front-end must now construct, simulate, and present a coherent view of a transaction that can touch dozens of unrelated objects and perform operations that would be separate transactions on other chains.
The atomicity of a PTB creates a new attack surface that front-end teams must model. A malicious dApp can inject commands between a user's intended actions—for example, inserting a token swap that manipulates a pool price immediately before the user's trade settles within the same block. This 'intra-PTB sandwich' is undetectable by conventional front-running monitors because it occurs within a single transaction's execution scope. Similarly, atomic arbitrage and flash loan patterns that require complex multi-hop execution on other chains are trivial to construct within a single PTB, making it critical for wallets to simulate the full command sequence and display the net state changes to the user before prompting for approval.
The operational burden falls on wallet and front-end teams to build robust PTB simulation and display logic. A secure integration must parse every command in the block, simulate the transaction against a recent checkpoint, and present a human-readable summary of all object mutations, coin balance changes, and authority transfers. Teams should implement allowlisting or blocklisting of known function signatures and flag any commands that interact with user-owned objects in unexpected ways. Chainscore Labs can audit PTB construction, simulation, and display pipelines to ensure that injected commands are detected and that the user's approval context accurately reflects the full, final state change.
PTB RISK EXPOSURE BY ROLE
Affected Actors
Wallet Integration Risk
Wallets are the primary defense layer against malicious PTB injection. The core risk is that a user approves a transaction block that contains hidden commands inserted between their intended actions.
Critical responsibilities:
- Simulate the full PTB and display the net state changes, not just the user's intended commands.
- Highlight asset outflows, object transfers, and approvals that differ from the dApp's stated intent.
- Implement human-readable decoding for all commands in the block, including Move calls and object transfers.
Action items:
- Audit PTB simulation logic to ensure it catches injected commands.
- Test against known sandwich and flash loan patterns within a single block.
- Provide clear warnings when a PTB touches objects outside the user's expected scope.
Chainscore can audit PTB simulation and display logic for wallet teams to prevent blind signing of malicious blocks.
implementation-impact
PTB THREAT MODEL
Attack Patterns and Mitigations
Programmable Transaction Blocks introduce unique atomic composability risks that front-end and wallet teams must actively mitigate. These attack patterns exploit the gap between user intent and the final transaction state.
01
Malicious Command Injection
A compromised or malicious dApp front-end can inject commands into a PTB between the user's intended actions. For example, a swap transaction could be preceded by a command that transfers an NFT to the attacker. Wallets must simulate the entire PTB and display a human-readable summary of all state changes, not just the final balance. The simulation must be performed against a trusted full node to avoid a compromised RPC node colluding with the front-end.
02
Atomic Arbitrage and Sandwiching
A PTB's atomic execution allows a single block to contain a flash loan, a market-moving swap, and a profitable arbitrage on another pool, all without upfront capital. While this is a feature for legitimate MEV, a malicious builder can sandwich a user's swap by inserting a command to manipulate the pool price immediately before the user's trade and a reversal command immediately after. Simulation must reveal this sequence to the user for explicit rejection.
03
Object Wrapping and Deletion Traps
A PTB can wrap a user's owned object into another object or delete it entirely if the Move module allows. A malicious command sequence could wrap a valuable NFT into a custom object the attacker controls, effectively stealing it without a standard transfer. Wallets must parse the full effects of the PTB and explicitly warn users when their owned objects are being wrapped, deleted, or transferred to a new owner, not just when a coin balance changes.
04
Sponsored Transaction Gas Drain
If a user signs a PTB that is sponsored by a gas station, a malicious builder can inflate the gas budget or insert commands that consume excessive computation. This can drain the sponsor's gas tank or cause the transaction to fail after the user has already committed to the action. Wallets should estimate and display the gas budget before signing and alert users if the budget is abnormally high relative to the intended operations.
05
Epoch-Change Replay and Expiry Risks
A PTB constructed with a specific epoch boundary may become invalid or replayable if the epoch changes before execution. An attacker could hold a signed PTB and submit it after an epoch transition, potentially exploiting stale object references. Wallets should enforce a transaction expiry window and ensure the PTB's gas object and all input objects are validated against the current epoch before simulation and signing.
PTB COMPOSABILITY THREAT MODEL
Risk Matrix
Operational risks introduced by atomic multi-command execution within a single Programmable Transaction Block, and the actions required by front-end, wallet, and protocol teams to protect users.
| Risk | Failure mode | Who is affected | Mitigation |
|---|---|---|---|
Malicious command injection | A compromised dApp or man-in-the-middle injects a command between a user's intended actions (e.g., a token swap and a transfer) to drain assets atomically. | Wallet users, dApp front-ends, wallet developers | Wallets must simulate the full PTB and display all side effects before prompting for signature. Front-ends should construct PTBs server-side and return them as opaque blobs. |
Atomic sandwich attack | An adversary observes a pending PTB in the mempool and constructs a competing PTB that front-runs the user's trade, executes it, and back-runs it within the same checkpoint. | Traders, DEX aggregators, DeFi protocols | Protocols should enforce slippage limits within PTB commands. Wallets should warn users when a PTB interacts with highly volatile pools. Aggregators should use private transaction submission where available. |
Hidden state change in composed PTB | A wallet displays only the top-level transaction effect but misses a critical state change (e.g., a Kiosk royalty payment or a dynamic field modification) triggered by a nested command. | Wallet users, NFT marketplaces, custody providers | Wallets must recursively parse and display all object mutations, including dynamic field changes and Kiosk events, in the transaction preview. Chainscore can audit PTB simulation and display logic. |
Gas coin exhaustion or griefing | A PTB that splits, merges, or transfers gas coins as part of its logic fails mid-execution due to insufficient gas, leaving the user with a partially mutated state and a consumed gas coin. | Wallet infrastructure, gas station operators, users | Wallets must simulate gas consumption for the entire PTB, including all coin operations, and ensure the gas budget covers worst-case execution. Gas stations should enforce strict budget limits. |
Sponsored transaction replay or misuse | A gas station signs a sponsored PTB that is replayed across multiple epochs or modified by the user to perform unintended actions, draining the sponsor's gas reserves. | Gas station operators, dApps offering sponsored transactions | Sponsored transactions must bind the PTB to a specific epoch and sender. Gas stations should verify the full PTB digest before co-signing and enforce rate limits. |
Epoch boundary atomicity failure | A PTB that depends on an object or validator set that changes at an epoch boundary fails or produces unexpected results if the transaction is executed across the boundary. | Exchanges, bridges, DeFi protocols relying on checkpoint proofs | Critical PTBs should check the current epoch and include an expiry condition. Bridges verifying checkpoint proofs must handle epoch transitions gracefully. |
Object version conflict | A PTB references an object version that is mutated by another transaction before the PTB executes, causing the entire block to abort. | High-frequency traders, DeFi protocols, wallet users | Wallets should surface object version dependencies in the simulation. dApps should construct PTBs that minimize shared-object contention and handle abort retries gracefully. |
WALLET AND FRONTEND SECURITY
PTB Simulation and Display Checklist
A checklist for front-end and wallet teams to validate that their PTB simulation and user display logic correctly detects injected commands and accurately represents the final state change before a user approves a transaction.
What to check: The front-end must construct the complete PTB—including any commands added by the dapp, wallet, or user—and run sui_dryRunTransactionBlock or an equivalent simulation against a trusted full node before displaying the result to the user.
Why it matters: A malicious dapp or a compromised dependency can inject commands (e.g., an asset transfer) between the user's intended actions. Simulation is the only pre-execution signal that reveals the full set of mutations.
Readiness signal: The wallet's transaction preview is populated exclusively from the dry-run result, not from the dapp's declared intent.
resource-links
OFFICIAL REFERENCES
Source Resources
Use these primary Sui resources to validate PTB semantics, simulation behavior, SDK construction patterns, and security assumptions before shipping wallet or front-end approval flows.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
PTB COMPOSABILITY AND RISK
Frequently Asked Questions
Common questions from front-end and wallet teams about the security, simulation, and user-display risks introduced by Programmable Transaction Block composability.
The core risk is command injection, where a malicious dapp or a man-in-the-middle front-end inserts unintended commands between the user's intended actions within a single PTB. Because a PTB executes atomically, a user who signs a block expecting a simple token swap could unknowingly authorize a flash loan, an asset transfer to an attacker's address, or a manipulation of a DeFi position. The wallet's simulation and final approval screen are the only lines of defense. A simulation that only shows the user's intended commands, rather than the full, final state delta of all commands, will fail to reveal the attack.
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.