Referable NFTs Authorization

ERCs
1

Abstract

This ERC defines a standard interface for authorizing referral relationships between arbitrary ERC-5521 tokens. It allows the owner of a referred NFT to grant or revoke authorization for a specific referring NFT, either directly on-chain or by an off-chain signature. The ERC is intended for cross-contract referral use cases and for retrofitting referral authorization onto existing ERC-721 collections without modifying the token contracts themselves.

Motivation

Existing referral-capable NFT designs do not provide a general authorization layer for referral relationships across arbitrary ERC-5521 contracts. In particular, many existing ERC-721 collections cannot be modified to add native referral logic, and existing approaches do not standardize how the owner of a referred NFT may explicitly control which external NFTs are permitted to refer to it.

This ERC defines a minimal authorization interface for that purpose. It enables:

  • authorization between NFTs from arbitrary ERC-5521 contracts;

  • owner-controlled consent for referred NFTs;

  • gasless authorization through off-chain signatures;

  • deployment as a standalone registry or auxiliary module.

This ERC does not define the referral relationship itself. It defines only how authorization for such a relationship is granted, revoked, and queried.

Specification

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

Interface

This ERC standardizes an authorization interface for referral relationships between arbitrary ERC-5521 tokens. It does not itself create, store, or enforce a referral relationship.

For the purposes of this ERC:

  • a referred NFT is the NFT being referred to;

  • a referring NFT is the NFT that seeks to refer to the referred NFT.

A compliant implementation MUST expose the following interface:

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.4;
​
/// @title Referable NFTs with Authorization
interface IAuthorizedReferral is ERC165 {
    /// @notice Emitted when a referral authorization is updated
    event ReferralAuthorizationSet(
        address indexed referredContract,
        uint256 indexed referredTokenId,
        address indexed authorizedContract,
        uint256 authorizedTokenId,
        bool authorized
    );
​
    /// @notice Check if a referral is authorized
    /// @param referredContract The contract address of the referred NFT
    /// @param referredTokenId The token ID of the referred NFT
    /// @param authorizedContract The contract address of the referring NFT
    /// @param authorizedTokenId The token ID of the referring NFT
    function isReferralAuthorized(
        address referredContract,
        uint256 referredTokenId,
        address authorizedContract,
        uint256 authorizedTokenId
    ) external view returns (bool);
​
    /// @notice Set referral authorization directly on-chain
    /// @dev Only callable by the owner of the referred NFT
    function setReferralAuthorization(
        address referredContract,
        uint256 referredTokenId,
        address authorizedContract,
        uint256 authorizedTokenId,
        bool authorized
    ) external;
​
    /// @notice Set referral authorization using an EIP-191 off-chain signature
    /// @dev Anyone can call this method with a valid signature from the referred NFT's owner
    function setReferralAuthorization(
        address referredContract,
        uint256 referredTokenId,
        address authorizedContract,
        uint256 authorizedTokenId,
        bytes calldata signature,
        bool authorized
    ) external;
    
    function supportsReferenceRoyalties() external view returns (bool);
}

Authorization Semantics

If isReferralAuthorized(referredContract, referredTokenId, referringContract, referringTokenId) returns true, the current authorization state indicates that the referred NFT permits the specified referring NFT to establish or claim a referral relationship, subject to the logic of the consuming application or protocol.

This ERC does not mandate how a referral relationship is materialized, displayed, interpreted, or enforced. Applications that integrate this ERC MUST define how authorization state is consumed.

Direct Authorization

For direct authorization, the caller of setReferralAuthorization(...) MUST be either:

  • the current owner of the referred NFT; or

  • an address approved to manage that token under ERC-5521.

A successful call to setReferralAuthorization(...) MUST update the current authorization state for the specified (referred NFT, referring NFT) pair and MUST emit ReferralAuthorizationUpdated.

Signature-Based Authorization

A successful call to setReferralAuthorizationBySig(...) MUST satisfy all of the following conditions:

  • the recovered signer is the current owner of the referred NFT at execution time;

  • nonce matches the current nonce of the referred NFT;

  • the current block timestamp is less than or equal to deadline;

  • the signature is valid for the supplied authorization parameters.

A compliant implementation MUST consume or increment the nonce associated with the referred NFT whenever a signature-based authorization is successfully processed.

A successful call to setReferralAuthorizationBySig(...) MUST update the current authorization state for the specified (referred NFT, referring NFT) pair and MUST emit ReferralAuthorizationUpdated.

Signature Message

Off-chain authorization signatures MUST be produced by the current owner of referredContract:referredTokenId over the following fields:

  • referredContract

  • referredTokenId

  • referringContract

  • referringTokenId

  • authorized

  • nonce

  • deadline

  • chainId

  • verifyingContract

One EIP-191-compatible message construction is:

keccak256(  
    abi.encodePacked(  
        "\x19Ethereum Signed Message:\n32",  
        keccak256(  
            abi.encode(  
                referredContract,  
                referredTokenId,  
                referringContract,  
                referringTokenId,  
                authorized,  
                nonce,  
                deadline,  
                chainId,  
                verifyingContract  
            )  
        )  
    )  
);

  • nonce prevents replay and MUST be unique per referred NFT;

  • deadline limits the validity period of the signature;

  • chainId prevents cross-chain replay;

  • verifyingContract binds the signature to a specific implementing contract.

Ownership Change Semantics

Authorization under this ERC represents consent from the current owner of the referred NFT.

If ownership of the referred NFT changes before a signature-based authorization is submitted, the signature MUST be treated as invalid.

Implementations MUST define whether previously stored on-chain authorizations persist across transfer. For interoperability, this ERC RECOMMENDS that a transfer of the referred NFT invalidate prior authorizations associated with that token, unless the new owner explicitly re-authorizes them.

Rationale

This ERC is intentionally limited to authorization. It does not define a canonical data model for referral relationships. This keeps the interface small and allows the ERC to be used across arbitrary ERC-5521 contracts, including existing collections that were not designed with referral functionality in mind.

A separate authorization interface is useful because it:

  • allows owner-side consent for referred NFTs;

  • supports cross-contract referral use cases;

  • can be deployed as a standalone registry or auxiliary module.

Separate entry points are defined for direct authorization and signature-based authorization. This makes the interface easier to implement, audit, and integrate than an overloaded method design.

Both referredContract and referringContract are explicit parameters so that authorization can be expressed across arbitrary ERC-5521 contracts.

This ERC specifies an EIP-191-compatible signature format for simplicity and broad compatibility. Implementations MAY additionally support EIP-712-compatible signing, but they MUST clearly document the canonical digest used for interoperability.

Backward Compatibility

This ERC does not require any modification to existing ERC-721 token contracts. It may be implemented as a standalone registry, middleware contract, or auxiliary module.

This ERC does not replace ERC-5521. Instead, it standardizes an external authorization layer that may be used by systems implementing referral-capable NFTs, including legacy ERC-721 collections that cannot be modified. Such systems MAY consult this ERC before accepting or materializing a referral claim.

Reference Implementation

A reference implementation may maintain authorization state as a mapping keyed by:

  • referred contract address;

  • referred token ID;

  • referring contract address;

  • referring token ID.

A reference implementation may maintain one nonce per referred NFT for signature-based authorization.

Security Considerations

  • Signature replay protection MUST be enforced through a nonce scoped to each referred NFT.

  • Signature-based authorization MUST verify that the recovered signer is the current owner of the referred NFT at execution time.

  • Expired signatures MUST be rejected.

  • If ownership of the referred NFT changes before a signed authorization is submitted, the signature MUST be treated as invalid.

  • Because any address may relay a valid signature, applications MUST assume that signature submission may be front-run.

  • Authorization updates and revocations may race in the mempool. Applications that depend on authorization state SHOULD rely on final on-chain state rather than off-chain intent alone.

  • If multiple registries implementing this ERC exist, applications MUST define which registry they trust, because authorization state may differ across registries.

  • Implementations SHOULD consider storage-growth risks arising from unbounded authorization records.

  • Implementations SHOULD use safe signature recovery procedures and reject malformed or ambiguous signatures.

Copyright

Copyright and related rights waived via CC0.