# Frames Are All You Need Account abstraction is a wildly diverse domain with many opinions forged over nearly a decade of research and development. We have honed in on the most capable and pure form and we have synthesized it into the frame transaction. In the desire for the perfect abstraction lies the root of contention. Several competing ideas have spawned to achieve similar goals. We will share a few thoughts for each. ## Alternatives to Frames ### EIP-8130: Account Abstraction by Account Configuration This is the "everything but the kitchen sink" proposal. It is comprehensive and well-thought-out. A few differences that are worth highlighting: 1. All configs and nonces are stored in system contracts. This allows validation of transactions with a subset of the state, but it deviates from traditional account management where the smart account uses its own storage. 2. The standard lays out accepted verifiers and some room for customization, however verifiers have no access to chain state beyond current nonce. This precludes trustless withdrawals from privacy protocols, among other use cases. 3. Payer is a hardcoded signature in the transaction object. This makes an entire class of trustless sponsorship impossible. None of these are fatal flaws of the proposal and each can likely be resolved. However, it brings a significant amount of complexity into the protocol. The frame transaction focuses explicitly on simplicity, because simplicity is safe. ### EIP-8175: Composable Transaction The composable transaction standard takes a simpler, but more constrained route of adding a new `capabilities` element to the transaction object which allows for a list of different capabilities to be *composed* together in the transaction. Composing these capabilities can achieve various user outcomes. Currently defined are the sender and payer capabilities, which essentially only allows transaction sponsoring and adds a framework for adding more signature algorithms over time. This proposal narrowly achieves some core goals of the frame transaction, but makes no progress on the long tail of use cases such as unifying smart accounts and allowing them to originate transactions, transaction assertions, trustless paymasters, and more. ## Good Abstractions are Powerful Ethereum was built on the idea of **permissionless innovation**. It's naive to imagine that we can foresee every way someone may use something. Competition drives new solutions. Yes, at times it may feel frustrating that the batteries weren't included, but also things have different power requirements. Making blanket solutions stifles creativity. This is why we believe **frames are all you need**. They give users choice in how they secure their account and how they interact with the chain. Usage will coalesce around the standards that use these primitives best; we don't need to force it upon the community.