Skip to main content

Account Abstraction

Summary​

Account Abstraction in IOTA replaces fixed cryptographic signature verification with a programmable Move function. An abstract account is a Move object whose ObjectID is its address; its authenticator function is registered on-chain via AuthenticatorFunctionRefV1 and called by the protocol on every incoming AA transaction. The AA transaction sender provides a MoveAuthenticator instead of a traditional signature, supplying the arguments the authenticator function needs. The authenticator function receives the account, those arguments, an AuthContext describing the AA transaction, and a TxContext, and it either returns (authenticated) or aborts (rejected).

Account Abstraction Summary

What Is Account Abstraction?​

Traditional IOTA accounts, known as Externally Owned Accounts (EOAs), are controlled by a single cryptographic key pair. Every transaction sent from an EOA must be signed with the corresponding private key; the protocol verifies the signature before allowing the transaction to proceed. This model is simple but rigid: authentication is always reduced to possession of a private key.

Account Abstraction (AA) replaces this fixed rule with programmable logic.

Instead of forcing the authentication of an account to the checking of a cryptographic signature, the protocol calls a Move function you define. That function decides whether the transaction is authorized. If the function executes successfully, the transaction proceeds; if the function aborts, the transaction is rejected.

For the full technical specification, including component details, protocol design, requirements, and test cases, see IIP-0009.

Why Account Abstraction?​

AA accounts offer two main properties that EOAs cannot provide:

  • Stable address — the account address is an ObjectID, not derived from a key pair. The address never changes, even when keys are rotated or the authentication scheme is replaced entirely.
  • Programmable authentication — any Move function (following the authenticator function requirements) can serve as the authenticator.

Together, these enable use cases like:

  • Key rotation and recovery without address change
  • Dynamic multisig with on-chain member management
  • DAO governance and treasury access control
  • Function-call keys that restrict which Move functions an account can call
  • Spending limits and time locks
  • Any custom cryptographic scheme not natively supported by IOTA

The Authentication Lifecycle​

The following diagrams illustrate how the components interact from package publication through transaction execution:

For the full technical specification, including component details, protocol design, requirements, and test cases, see IIP-0009.