Skip to main content

Account Abstraction

Account Abstraction RC

Account Abstraction is currently a release candidate and, therefore, only available on Testnet and 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
  • Gas sponsorship under custom on-chain policy (an abstract account paying for someone else's transaction)
  • Any custom cryptographic scheme not natively supported by IOTA
Sponsorship with abstract accounts

An abstract account can also act as a gas sponsor: it pays for another account's transaction while its own authenticator function enforces whatever sponsorship policy you choose (whitelists and gas allowances, per-tx signed approvals, …). See the sponsor authenticator design principle for the patterns, the whitelist sponsorship how-to for a worked example, and the sender-identity-binding security guide for the threat model.

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.