Skip to main content

Account Abstraction

Account Abstraction Beta

Account Abstraction is currently in beta and therefore only available on Devnet.
If you test it out, please share your feedback with us in the IOTA Builders Discord.

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.