ERC-7656 — Generalized Contract-Linked Services

Back to Account & Authentication

ERC-7656: Generalized Contract-Linked Services

ERC-7656 generalises ERC-6551 (Token Bound Accounts) to any contract — not just NFTs. The registry computes a deterministic service contract address for any (implementation, chainId, linkedContract, linkedTokenId, salt, modeOrServiceId) tuple and deploys the service on first use. Services typically expose linkedContract(), linkedTokenId(), and linkedOwner() to identify what they're bound to, plus arbitrary service-specific methods.

This unlocks "every contract gets its own collection of plug-in services" — a multisig that has a vault, a DAO that has its own messaging endpoint, a token that has its own oracle, all looked up deterministically.

Required Interface

interface IERC7656Registry {
    event Created(
        address service,
        address indexed implementation,
        bytes32 salt,
        uint256 chainId,
        bytes12 modeOrServiceId,        // mode bit + 11-byte service-id
        address indexed linkedContract,
        uint256 indexed linkedTokenId
    );

    function create(
        address implementation,
        bytes32 salt,
        uint256 chainId,
        bytes12 modeOrServiceId,
        address linkedContract,
        uint256 linkedTokenId
    ) external returns (address service);

    function compute(
        address implementation,
        bytes32 salt,
        uint256 chainId,
        bytes12 modeOrServiceId,
        address linkedContract,
        uint256 linkedTokenId
    ) external view returns (address service);
}

interface IERC7656Service {
    function linkedData() external view returns (
        uint256 chainId,
        bytes12 modeOrServiceId,
        address linkedContract,
        uint256 linkedTokenId
    );
    function owner() external view returns (address);
}

Mode bit

The high bit of modeOrServiceId distinguishes:

• Mode 0 — linkedTokenId refers to an NFT id (the service is bound to a specific NFT, ERC-6551 style).
• Mode 1 — linkedTokenId is unused; the service is bound to the contract as a whole (the generalisation over ERC-6551).

The remaining 11 bytes are a free-form serviceId — multiple service instances per (linkedContract, linkedTokenId) are addressable by varying the serviceId.

Neo Equivalent: Registry With (Linked, ServiceId) Mapping

The same pattern works on Neo as for ERC-6551 — a registry contract that deploys per-tuple service contracts on first use, with the (linkedContract, linkedTokenId, serviceId) triple in storage.

ERC-7656 (Ethereum)	Neo Equivalent	Notes
IERC7656Registry.create(...)	Registry.CreateService(linkedContract, tokenId, serviceId, impl, salt)	Same shape; deterministic post-deploy
IERC7656Registry.compute(...)	Off-chain compute via Helper.GetContractHash from sender + nonce + salt	Predict-before-deploy
mode 0 (NFT-bound)	tokenId != null — service stores NFT contract + tokenId	Same as ERC-6551 mirror
mode 1 (contract-bound)	tokenId == null — service stores only the linked contract hash	Generalisation lets multisigs / DAOs / tokens have services
serviceId (11-byte tag)	serviceId (any ByteString) — namespaced storage prefix in the service	Extra dimension for multiple service instances per linked contract
IERC7656Service.linkedData()	Service.LinkedData() — returns the tuple stored at deploy time	Direct equivalent
IERC7656Service.owner()	Resolves to linkedContract.OwnerOf(tokenId) (mode 0) or linkedContract.GetOwner() (mode 1)	Owner resolution depends on the linked contract's interface

Relationship to ERC-6551

ERC-7656 is strictly more general than ERC-6551:

• ERC-6551 → mode 0 only, with linkedContract constrained to an ERC-721.
• ERC-7656 → mode 0 (NFT-bound) or mode 1 (contract-bound), serviceId selector for multiple services per binding.

If you've already adopted the ERC-6551 mirror's Pattern A, the ERC-7656 implementation is the same registry with two additional dimensions: mode and serviceId.

Why Now

ERC-7656 reached Final in late 2025 after a year of revision. The underlying need — "let any contract host a discoverable, deterministic collection of services" — has been recognised by every smart-account project (ZeroDev, Safe modules, Argent guardians) but each shipped its own ad-hoc registry. The standard converges those.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract ERC7656Registry {
    error AlreadyCreated();
    error CreationFailed();

    event Created(
        address service,
        address indexed implementation,
        bytes32 salt,
        uint256 chainId,
        bytes12 modeOrServiceId,
        address indexed linkedContract,
        uint256 indexed linkedTokenId
    );

    function create(
        address implementation,
        bytes32 salt,
        uint256 chainId,
        bytes12 modeOrServiceId,
        address linkedContract,
        uint256 linkedTokenId
    ) external returns (address service) {
        bytes memory creationCode = _proxyCreationCode(
            implementation, chainId, modeOrServiceId,
            linkedContract, linkedTokenId
        );
        bytes32 finalSalt = keccak256(abi.encodePacked(
            salt, chainId, modeOrServiceId, linkedContract, linkedTokenId
        ));
        assembly {
            service := create2(0, add(creationCode, 0x20), mload(creationCode), finalSalt)
        }
        if (service == address(0)) revert CreationFailed();

        emit Created(service, implementation, salt, chainId, modeOrServiceId,
                     linkedContract, linkedTokenId);
    }

    function compute(/* same args */) external view returns (address) { /* CREATE2 address compute */ }

    function _proxyCreationCode(/* args */) internal pure returns (bytes memory) { /* ERC-1167 with footer */ }
}

The assembly { create2(...) } faults under neo-solc. Replace with the Neo registry pattern (see C# tab); the public registry interface (Create(...) / Compute(...)) keeps the same shape so dApps can port without API churn.

using System;
using System.ComponentModel;
using System.Numerics;
using Neo;
using Neo.SmartContract.Framework;
using Neo.SmartContract.Framework.Attributes;
using Neo.SmartContract.Framework.Native;
using Neo.SmartContract.Framework.Services;

namespace R3E.Examples;

[DisplayName("ServiceRegistry")]
[ContractPermission("*", "deploy")]
public class ServiceRegistry : SmartContract
{
    private const byte Prefix_Service = 0x01;

    [DisplayName("ServiceCreated")]
    public static event Action<UInt160, UInt160, ByteString, ByteString, UInt160> OnServiceCreated;

    /// Mode 0 — bind a service to a specific NFT (linkedContract, tokenId).
    /// Mode 1 — bind a service to a contract (tokenId = null).
    public static UInt160 CreateService(
        UInt160 linkedContract, ByteString tokenId,
        ByteString serviceId, ByteString salt)
    {
        var key = ServiceKey(linkedContract, tokenId, serviceId);
        var existing = (UInt160)Storage.Get(Storage.CurrentContext, key);
        if (existing is not null) return existing;  // idempotent

        var (nef, manifest) = BuildServiceFor(linkedContract, tokenId, serviceId);
        var deployed = (Contract)ContractManagement.Deploy(nef, manifest);
        Storage.Put(Storage.CurrentContext, key, deployed.Hash);
        OnServiceCreated(linkedContract,
            tokenId is null ? UInt160.Zero : (UInt160)tokenId, // mode-flag pseudo
            serviceId, salt, deployed.Hash);
        return deployed.Hash;
    }

    public static UInt160 GetService(UInt160 linkedContract, ByteString tokenId, ByteString serviceId)
        => (UInt160)Storage.Get(Storage.CurrentContext, ServiceKey(linkedContract, tokenId, serviceId));

    private static byte[] ServiceKey(UInt160 linked, ByteString tokenId, ByteString serviceId)
        => new byte[] { Prefix_Service }
              .Concat(linked)
              .Concat(tokenId is null ? (ByteString)new byte[] { 0xff } : tokenId)
              .Concat(serviceId);

    private static (NefFile, ContractManifest) BuildServiceFor(
        UInt160 linked, ByteString tokenId, ByteString serviceId)
    {
        // The service NEF bakes in `linked`, `tokenId`, and `serviceId` as
        // constants in three reserved slots. Manifest name is suffixed with
        // serviceId for address uniqueness across services on the same linked
        // contract. Vendoring elided.
        throw new Exception("vendoring elided for example brevity");
    }
}

[DisplayName("LinkedService")]
[ContractPermission("*", "*")]
public class LinkedService : SmartContract
{
    private static readonly UInt160 LINKED_CONTRACT =
        (UInt160)"0x0000000000000000000000000000000000000000";
    private static readonly ByteString LINKED_TOKEN_ID = "";  // empty in mode 1
    private static readonly ByteString SERVICE_ID = "";

    public static (UInt160, ByteString, ByteString) LinkedData()
        => (LINKED_CONTRACT, LINKED_TOKEN_ID, SERVICE_ID);

    public static UInt160 Owner()
    {
        if (LINKED_TOKEN_ID.Length > 0)
        {
            // Mode 0: NFT-bound — owner is the NFT holder.
            return (UInt160)Contract.Call(LINKED_CONTRACT, "ownerOf", CallFlags.ReadOnly, LINKED_TOKEN_ID);
        }
        else
        {
            // Mode 1: contract-bound — owner is the contract's own owner method.
            // Convention only; the linked contract must expose `getOwner` or similar.
            return (UInt160)Contract.Call(LINKED_CONTRACT, "getOwner", CallFlags.ReadOnly);
        }
    }

    // Service-specific methods follow. Authorization defers to Owner() above.
}

Mode 1 Use Cases

Where ERC-6551 is "every NFT gets a wallet", ERC-7656 mode 1 unlocks:

• Multisig modules — every Safe-style multisig deterministically gets a vault, a guardian list, an oracle, addressed by (safe, serviceId).
• DAO endpoints — every governance contract gets a treasury, a forum, a delegation registry — same deterministic-address property.
• Token services — an ERC-20 / NEP-17 token can host its own oracle, fee router, or governance, all under the registry pattern.

For all of these, the registry-with-mapping approach in the C# tab works unchanged; only the BuildServiceFor helper changes per service kind.