Frame transactions, verification and fees decided by the account itself

Strawmap Hegotá (2027) · frame transactions

This is a new transaction type (0x06) that splits a transaction into several frames (contract calls) and lets the account code decide signature verification, fee payment and execution. It builds account abstraction into the protocol as a native feature.

Why it is needed

Today an Ethereum account verifies the sender with only one method, the elliptic curve signature (ECDSA). Because an account is tied to a single private key, the key cannot be replaced, and there is no path to migrate to a signature scheme that is safe against quantum computers. To bundle several operations into one or to have another account pay the fee on its behalf, smart account code and an external intermediary (relayer) must be set up separately, which complicates the structure and raises the risk accordingly. A frame transaction splits a transaction into up to 64 frames and executes each frame as a contract call. The account code decides which signatures to accept, who pays the fee and what to execute. As a result the protocol natively supports key rotation, migration to quantum-resistant signatures, batched calls and alternative fee payment. It is a proposal that realizes the original vision of account abstraction, in which an account becomes an address that holds code. The core developer call has raised this EIP to headliner status for the Hegotá fork. However, the spec is still being refined and is at the stage of being validated on devnets together with other execution layer candidates, so detailed design may keep changing.

How it works

  1. The protocol checks signatures first The transaction carries the sender address and a list of signatures separately. The secp256k1 and P256 signatures in use today are verified directly by the protocol, and if even one is wrong, the entire transaction is invalid. Signatures of the ARBITRARY type are read by the account code, which verifies them itself.
  2. The verification frame approves The verification (VERIFY) frame runs as a read-only call that cannot change state, and the account code judges whether this transaction may be executed and whether the fee may be paid, and approves it. If it reverts or halts here, the transaction is invalid.
  3. After approval, the execution frames run A frame running in the sender capacity (SENDER) can be executed only after approval is complete. A transaction can contain up to 64 frames, and an atomic batch flag processes several frames as one bundle.

Related EIPs

← Roadmap