ERC-8092: Associated Accounts

ERCs
1

A new standard for linking blockchain accounts across chains and platforms.

ERC-8092 introduces a standardized method for establishing verifiable associations between blockchain accounts. The specification enables two addresses to publicly declare, prove, and revoke their relationship through a cryptographically signed payload.

Add ERC: Associated Accounts by stevieraykatz · Pull Request #1377 · ethereum/ERCs · GitHub

What It Solves

Managing multiple blockchain addresses across different chains and platforms creates friction for users and applications alike. ERC-8092 provides the infrastructure for:

  • Sub-account relationships: Link multiple addresses under a primary identity

  • Delegation schemes: Authorize specific accounts to act on behalf of another

  • Reputation aggregation: Consolidate activity and credentials across addresses

  • Cross-chain identity: Connect accounts on different blockchain networks

How It Works

The specification defines two core data structures:

Associated Account Record (AAR) contains the association details: initiator and approver addresses, validity timestamps, and optional contextual data identified by an interface selector.

Signed Association Record (SAR) wraps the AAR with cryptographic signatures from both parties, key type identifiers, and revocation status.

Both parties sign the EIP-712 hash of the association, creating a trustless proof of their relationship. The standard supports multiple signature schemes including secp256k1, secp256r1, BLS12-381, Ed25519, WebAuthn/Passkeys, and smart contract signatures via ERC-1271 and ERC-6492.

Storage and Lifecycle

Associations can be stored onchain for transparency and composability, or offchain for scalability. Either party can revoke an association at any time. The specification includes comprehensive validation rules for timestamp validity, signature verification, and revocation status.

Interoperability

By leveraging ERC-7930 for address representation, ERC-8092 enables associations between accounts on different chains and with different cryptographic architectures. This cross-chain capability is essential for modern multi-chain identity systems.

5 Likes
2

More synchronous discussions happening in this Telegram chat: Telegram: Join Group Chat

A solidity implementation of the spec’s core structures, a functional library for interacting with AssociatedAccountRecords and SignedAssociationRecords as well as a simple implementation of an Associations Store can all be found in this repo: GitHub - stevieraykatz/AssociatedAccounts.

3

I really like the idea but a question about the implementation example. I’m wondering if defining the supported signing schemes is the most scalable way to enable associations between keys of different chains and algos.

Have you considered instead defining an interface and letting the members of the association specify a contract to use as the verifier that meets that interface

interface AssociationVerifier {

function validateAssociatedAccount(AssociatedAccounts.SignedAssociationRecord memory sar)
        public
        view
        returns (bool);

}

// Returns data on the validation mechanism such as which ZK implementation
// or curve type.
function validationMetadata() public pure returns (string);

That way the struct then becomes

// Note: The new verifierContract slots in perfectly to the existing fields without requiring
// an additional storage slot.
struct AssociatedAccountRecord {
        /// @dev The ERC-7930 binary representation of the initiating account's address.
        bytes initiator;
        /// @dev The ERC-7930 binary representation of the approving account's address.
        bytes approver;
        /// @dev The timestamp from which the association is valid.
        uint40 validAt;
        /// @dev The timestamp when the association expires.
        uint40 validUntil;
        /// @dev Optional 4-byte selector for interfacing with the `data` field.
        bytes4 interfaceId;
        /// Should be verified as following supportsInterface() on creation
        address verifierContract;
        /// @dev Optional additional data.
        bytes data;
    }

As the EVM begins to support more alternative signature validation mechanisms this may be the most efficient and agnostic way to future proof the validation mechanism.