ERC-7656: Generalized Contract-Linked Services

Define a factory for generic services linked to any contract type including ERC-4337 accounts and NFTs

Abstract

This proposal defines a factory capable of deploying generic services linked to specific contracts, such as ERC-4337 accounts or ERC-721 tokens (NFTs). These linked services extend the functionalities of the target contract, operating under the ownership of the contract’s or NFT’s owner without requiring modifications to the original contract’s code. As a secondary effect, this proposal helps fighting the proliferation of ERCs that require changes to the basic standards.

Motivation

Existing standards like ERC-6551 successfully bind smart accounts to NFTs, allowing registries to deploy accounts owned by specific token IDs. However, these standards have two key limitations:

1. They often require deployed contracts to implement specific interfaces for handling assets and executing transactions, effectively mandating that the deployed contract must function as an account.
2. They are restricted to NFTs, while many other contract types (particularly ERC-4337 accounts) could benefit from similar linking mechanisms to extend their functionalities.

This ERC proposes a more versatile factory specification that enables the deployment of proxies pointing to any contract that enhances the associated contract’s capabilities, whether it’s an NFT or an account contract.

Key Benefits

• Universal Linkability: Enables services to be linked to any compatible contract type, not just NFTs, creating a unified approach to contract extension.

• Non-Invasive Enhancement: Services can add functionality to existing smart accounts without modifying the underlying contract, maintaining compatibility with infrastructure like wallets and indexers.

• Backward Compatibility: Maintains compatibility with existing token-bound account standards (ERC-6551) while extending functionality to new use cases.

• Flexible Implementation: The mode parameter enables different linkage types (with or without token IDs) while ensuring consistent deterministic addressing.

• Reduced Standard Proliferation: Decreases the need for new specialized ERCs by providing an extension mechanism that can be applied to existing standards, simplifying the ecosystem.

Use Cases for ERC-4337 Smart Accounts

1. Social Recovery Services: Deploy a social recovery mechanism linked to an existing ERC-4337 wallet that can restore access if credentials are lost, without requiring the wallet to implement recovery functionality natively.

2. Customizable Permission Systems: Add granular permissions to an account (time-limited access, spending limits, multi-signature approvals) without rebuilding the account from scratch.

3. Account Abstraction Extensions: Implement advanced features like batch transactions, gas sponsorship, or session keys as linked services, allowing wallets to adopt these features selectively.

4. Identity and Reputation Services: Link verifiable credentials or reputation systems to accounts, enabling privacy-preserving identity verification.

Use Cases for NFTs

1. Enhanced Token Utility: Provide NFTs with financial capabilities like staking, lending, or revenue distribution.

2. Dynamic Metadata Services: Enable NFT metadata to evolve based on on-chain activities without changing the NFT itself.

3. Fractional Ownership: Implement fractional ownership mechanisms for high-value NFTs through linked contracts.

4. Conditional Access Control: Create time-locked or challenge-based access to NFT-gated content or services.

5. Real World Asset Management: Extend NFTs to represent and manage real-world assets (RWAs) by linking services that handle compliance, legal documentation, custody verification, transfer restrictions, and regulatory reporting without requiring specialized NFT standards for each asset class.

Specification

The keywords “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,” “RECOMMENDED,” “NOT RECOMMENDED,” “MAY,” and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

The IERC7656Factory interface is defined as follows:

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

/**
 * @title ERC7656
 * @dev ERC165 interface ID: 0x9e23230a
 * @notice Manages the creation of contract-linked services
 */
interface IERC7656Factory {
  event Created(
    address contractAddress,
    address indexed implementation,
    bytes32 salt,
    uint256 chainId,
    bytes12 mode,
    address indexed linkedContract,
    uint256 indexed linkedId
  );

  error CreationFailed();

  function create(
    address implementation,
    bytes32 salt,
    uint256 chainId,
    bytes12 mode,
    address linkedContract,
    uint256 linkedId
  ) external returns (address);

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

Linking Modes

The mode parameter serves as a selector for how the linked contract should be interpreted and utilized. Currently, ERC-7656 defines two standard modes:

bytes12 constant NO_LINKED_ID = 0x000000000000000000000001;
bytes12 constant LINKED_ID = 0x000000000000000000000000;

• LINKED_ID Mode (0x000000000000000000000000): Used when linking a service to an NFT or any contract that requires a token/entity ID. This mode ensures compatibility with ERC-6551, allowing seamless integration with existing token-bound account systems.

• NO_LINKED_ID Mode (0x000000000000000000000001): Used when linking a service to a contract that doesn’t require an ID parameter, such as an ERC-4337 account. In this case, the linkedId parameter is still present in the interface for consistency but SHOULD be set to zero if not used to store alternative data relevant to the service.

The mode parameter (being bytes12) allows for future extensions beyond these initial modes, enabling more complex linkage patterns as ecosystem needs evolve.

Deployment Requirements

Any ERC7656Factory implementation MUST support the IERC7656Factory interface ID (0x9e23230a).

Each linked service MUST be deployed as an ERC-1167 minimal proxy, appending immutable constant data to the bytecode. The deployed bytecode structure is:

ERC-1167 Header               (10 bytes)
<implementation (address)>    (20 bytes)
ERC-1167 Footer               (15 bytes)
<salt (bytes32)>              (32 bytes)
<chainId (uint256)>           (32 bytes)
<mode (bytes12)>              (12 bytes)
<linkedContract (address)>    (20 bytes)
<linkedId (uint256)>          (32 bytes)

Linked services SHOULD implement the IERC7656Service interface:

// Interface ID: 0x7e110a1d
interface IERC7656Service {
  function linkedData() external view
    returns (uint256 chainId, bytes12 mode, address linkedContract, uint256 linkedId);
}

Implementation Patterns

When implementing a linked service, developers SHOULD consider the following patterns:

1. Ownership Verification: Services SHOULD include mechanisms to verify that operations are authorized by the current owner of the linked contract or token.

2. Mode-Specific Logic: Services SHOULD implement conditional logic based on the mode parameter to handle both NFT-linked and account-linked scenarios appropriately.

3. Cross-Chain Awareness: Services SHOULD check that operations are being performed on the chain specified in the chainId parameter to prevent cross-chain replay attacks.

Rationale

The design of ERC-7656 is guided by several key principles that address limitations in current contract extension methods:

Why a Unified Factory?

Rather than creating separate standards for NFT extensions and account extensions, ERC-7656 employs a unified factory approach. This design choice stems from recognizing the fundamental similarity between linking services to tokens and linking services to accounts - both involve extending functionality while maintaining a clear ownership relationship.

Mode Parameter Design

The mode parameter uses 12 bytes instead of a simple boolean flag because the 12-byte format reserves space for future linking modes beyond the initial two (NFT linking and account linking). For example, if a service is associated to an ERC-1155 token but requires that the balance of the user is more than 1000 tokens, the mode could be 0x000000000000000000003e802, where the least significant byte, 0x02 is the primary mode and the rest is the minimum required balance. Similarly, someone can think of a service associated to ERC-20 tokens that requires a specific balance where the required balance can be put in the linkedId field, and the mode specified accordingly.

Deterministic Addressing

ERC-7656 follows the deterministic addressing pattern established by ERC-6551, appending immutable data to the contract bytecode rather than storing it in contract storage. This ensures that:

1. Linked services have predictable addresses that can be computed off-chain
2. The factory remains stateless, reducing gas costs
3. Linked services can be deployed on-demand or even referenced before deployment

Compatibility with ERC-6551

The LINKED_ID mode (0x000000000000000000000000) maintains byte-for-byte compatibility with ERC-6551 token bound accounts. This intentional design ensures that applications built for ERC-6551 can work seamlessly with ERC-7656 services in this mode without requiring any modifications.

Generic Linking Mechanism

Unlike standards that enforce specific interfaces or behaviors on linked contracts, ERC-7656 remains agnostic about the implementation details of linked services. This deliberate design choice allows developers maximum flexibility to create specialized services while maintaining a consistent deployment and ownership model.

Backwards Compatibility

ERC-7656 maintains compatibility with ERC-6551 when used with the LINKED_ID mode (0x000000000000000000000000). This ensures that existing applications and infrastructure supporting token-bound accounts can continue operating without modification.

For contracts using the NO_LINKED_ID mode (0x000000000000000000000001), specialized interfaces may be required, but the core factory mechanism remains consistent.

Reference Implementation

See ERC7656Factory.sol for an example implementation of IERC7656Factory. For convenience, the reference implementation will be deployed at erc7656.eth on primary mainnets and selected testnets.

An example of implementation of IERC7656Service:

contract LinkedService is IERC7656Service, EIP5313 {

  function linkedData(address service) public view returns (uint256, bytes12, address, uint256) {
    bytes memory encodedData = new bytes(0x60);
    // solhint-disable-next-line no-inline-assembly
    assembly {
    // Copy 0x60 bytes from end of context
      extcodecopy(service, add(encodedData, 0x20), 0x4d, 0x60)
    }

    uint256 chainId;
    bytes32 linkedContract;
    uint256 linkedId;

    // solhint-disable-next-line no-inline-assembly
    assembly {
      chainId := mload(add(encodedData, 0x20))
      linkedContract := mload(add(encodedData, 0x40))
      linkedId := mload(add(encodedData, 0x60))
    }

    bytes12 mode = bytes12(linkedContract);

    address extractedAddress = address(uint160(uint256(linkedContract)));
    return (chainId, mode, extractedAddress, linkedId);
  }

  function owner() public view virtual override returns (address) {
    (uint256 chainId, , address tokenContract_, uint256 tokenId_) = linkedData();
    if (chainId != block.chainid) return address(0);
    return IERC721(tokenContract_).ownerOf(tokenId_);
  }
}

Security Considerations

Ownership Cycles

Smart wallets linked to NFTs that are then held by the same wallet can create ownership cycles, potentially rendering assets inaccessible. Implementers SHOULD include safeguards to prevent or detect such cycles.

Fraud Prevention

A malicious seller could alter or revoke service permissions just before finalizing a sale. Lock mechanisms preventing last-minute changes MAY be implemented, especially for NFT marketplaces integrating with ERC-7656 services.

Malicious Implementations

The registry cannot enforce legitimate ownership when linking services. Users SHOULD review or audit implementations before deployment. Front-end applications integrating ERC-7656 SHOULD display warnings when interacting with unverified implementations.

Upgradeability Risks

Linked services that are upgradable pose risks of unexpected changes or asset exfiltration. Secure upgrade mechanisms with timelock controls or multi-signature governance SHOULD be implemented when upgradeability is required.

Reentrancy & Cross-Contract Attacks

Linked services interacting with assets or external protocols may be vulnerable to reentrancy exploits. Implementers SHOULD follow security best practices such as the checks-effects-interactions pattern and consider reentrancy guards.

Mode-Specific Vulnerabilities

Services operating in different modes (LINKED_ID vs NO_LINKED_ID) may have different security requirements. Implementations SHOULD validate that operations are appropriate for the service’s configured mode.

User Education & Phishing Risks

Even with secure contracts, users may fall victim to fraudulent services masquerading as legitimate ones. Clear UI warnings, verification tools, and educational resources SHOULD be provided by applications integrating ERC-7656.

Copyright

Licensed under CC0.

Citation

Please cite this document as:

Francesco Sullo (@sullof), "ERC-7656: Generalized Contract-Linked Services [DRAFT]," Ethereum Improvement Proposals, no. 7656, March 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7656.