Composability Through Different Lenses: PTBs and EIP-7702

As decentralized apps become more complex, users are often required to complete multiple transactions onchain in a specific sequence. Actions like approving token spends before making swaps can result in multiple transactions for a single overall action. Along with user friction, this type of transaction processing is computationally inefficient. To address this, both Sui and Ethereum provide solutions that aim to improve composability at the transaction level: Sui’s Programmable Transaction Blocks (PTBs) and Ethereum’s EIP-7702.
These mechanisms give developers the ability to bundle multiple actions into a single, atomic transaction, streamlining execution and improving the user experience. While they share similar goals, they differ significantly in their design and underlying architecture.
EIP-7702: Smart contract behavior for EOAs
Introduced in Ethereum’s recent Pectra upgrade, EIP-7702 allows an externally owned account (EOA) to temporarily act like a smart contract account for the duration of a single transaction. Smart contract accounts are programmable accounts that can hold assets and execute complex logic, such as batching multiple actions or enabling others to pay gas fees on your behalf. Previously, users needed to create and move assets to a separate smart contract wallet to access features like gas sponsorship or multi-action execution. EIP-7702 was implemented to remove that barrier by enabling these capabilities directly from a standard Ethereum wallet.
It’s a creative solution that gives developers more flexibility, allowing them to simulate composable transaction flows using Ethereum’s existing architecture. However, the approach still operates within the boundaries of Ethereum’s account-based and sequential execution model. Thus, EIP-7702 introduces additional considerations for developers and wallet providers, such as handling new transaction types, maintaining compatibility, and integrating with existing EIP-4337 infrastructure.
Full functionality depends on supporting infrastructure like bundlers and paymasters defined in EIP-4337. While these additions enable greater flexibility, they also introduce trade-offs in tooling requirements, developer overhead, and consistency across wallets and applications. EIP-7702 also raises design challenges around tx.origin and backward compatibility, which could affect how some existing apps function.
EIP-7702 shows how far Ethereum can stretch to improve composability, but it still operates within the constraints of its foundational architecture rather than redefining them.
PTBs: Native composability at the protocol layer
In contrast, Sui’s Programmable Transaction Blocks (PTBs) are designed with composability as a first-class principle, enabling seamless coordination across onchain actions. PTBs allow developers to bundle up to 1,024 actions—including object transfers, contract calls, merges, and splits—into a single, atomic transaction.
Each action within a PTB is treated as an independent command. If actions don’t conflict, Sui can execute them in parallel, unlocking significant throughput gains and ensuring low-latency finality even under high load. For developers, this means:
- Clean, declarative composition of multi-step interactions
- Fewer trust assumptions and fewer workarounds
- No need to depend on external relayers or layered abstraction frameworks
PTBs also offer increased safety through Sui’s object-centric model. Transaction logic is explicitly tied to object ownership, which removes ambiguity and reduces the surface area for common bugs or exploit patterns. Actions are executed deterministically, and the system enforces strict rules on object usage and mutation.
This architecture allows developers to build rich, multi-step apps that feel seamless to users, without sacrificing performance, transparency, or control.
Design philosophy and ecosystem impact
EIP-7702 is a useful enhancement to Ethereum’s existing account abstraction framework. It reflects Ethereum’s philosophy of gradual evolution: improving developer flexibility while maintaining compatibility with a mature network. However, this layered approach comes at a cost: greater complexity, fragmented tooling, and the need for workarounds to achieve functionality that newer systems provide by default.
Sui’s PTBs reflect a different mindset. Instead of extending a legacy model, PTBs are built into the protocol itself. The result is a more coherent developer experience: composability, security, and parallelism all handled natively. There’s no need for bundlers or patchwork abstraction layers—just clear, structured logic with predictable behavior.
This difference in design philosophy has practical consequences. For developers, PTBs lower the barrier to building efficient, expressive applications. For users, they enable smoother interactions with fewer approvals and fewer steps. And for the broader ecosystem, they unlock the kinds of high-frequency, high-complexity strategies, across DeFi, gaming, and identity, that are difficult to execute reliably on older systems.
Evolution versus clean slate design
EIP-7702 and PTBs both aim to improve how users and developers interact with smart contracts by enabling composable, programmable transaction flows. EIP-7702 highlights Ethereum’s ability to evolve, but it also highlights the constraints of working within an architecture not originally designed for this level of flexibility.
As application complexity continues to grow, the ability to compose logic cleanly and execute it efficiently may prove just as important as throughput. In that future, PTBs offer a model that’s not just technically robust, but purpose-built for what’s next.
PTBs, on the other hand, showcase what’s possible when composability is part of the core system design. By making multi-action transactions simple, safe, and scalable, Sui shows how to optimize onchain coordination.