ERC-5269 — ERC Detection and Discovery

Back to Infrastructure & Patterns

ERC-5269: ERC Detection and Discovery

ERC-5269 generalises ERC-165 (single-bit interface detection) to richer ERC-by-ERC discovery: a contract returns boolean (or extended) information about every ERC it claims to support. Tools / wallets call supportsInterface for each ERC of interest; the contract returns true if it conforms.

Goes further than ERC-165 by:

• Returning extended status (full / partial / pending) instead of just boolean.
• Allowing extra context per ERC (deployment version, optional feature flags).
• Supporting discovery without prior knowledge of supported ERCs via a supportedERCs() enumeration.

Required Interface (delta from ERC-165)

interface IERC5269 {
    event OnSupportERC(address indexed caller, bytes32 indexed majorERCIdentifier,
                       bytes32 minorERCIdentifier, bytes extraData);

    function supportERC(address caller, bytes32 majorERCIdentifier,
                        bytes32 minorERCIdentifier, bytes calldata extraData)
        external view returns (bytes32);
}

The contract returns bytes32(0) for "not supported", or a status-encoded value (e.g. 0x01 = full, 0x02 = partial). The majorERCIdentifier is typically bytes32(uint256(ercNumber)); minorERCIdentifier lets contracts indicate sub-revisions.

Neo Equivalent: Native Manifest supportedstandards

Neo's contract manifest natively includes a supportedstandards field — an array of strings the contract claims to implement ("NEP-17", "NEP-11", "NEP-24", etc.). Tools query the manifest directly; no on-chain method call needed.

// Off-chain query: read the contract's manifest from ContractManagement.
const manifest = await neoRpc.getcontractstate(contractHash);
const supports = manifest.manifest.supportedstandards;  // ["NEP-17", "NEP-11"]
const supportsNep17 = supports.includes("NEP-17");

ERC-5269 (Ethereum)	Neo Equivalent	Notes
supportERC(caller, ercId, ...)	manifest.supportedstandards array	Read once from manifest
ERC ID = bytes32(uint256(ercNumber))	String like "NEP-17"	Symbolic instead of numeric
Extended status (full/partial)	Custom convention via additional manifest extras (or events)	Less standardised
Discovery via enumeration	Manifest array IS the enumeration	Native
ERC-165 fallback for older detection	Optional supportsInterface(...) method on contract	Backward compat

Why Neo Beats Both ERC-165 and ERC-5269

Both ERCs work around Ethereum's lack of contract metadata — contracts have to expose methods to advertise their interfaces. Neo bakes this into the manifest: every contract publishes its supported standards as part of the deployment package; tools query the manifest without any on-chain call.

For richer status (full/partial/pending), Neo contracts can add custom manifest extra fields — the manifest supports arbitrary JSON metadata.

Migration Notes

For Solidity contracts using ERC-5269:

1. The Neo port doesn't need the supportERC view method — set the manifest's supportedstandards correctly at deploy time.
2. For extended status (full vs partial vs pending), use the manifest's extra field with a JSON object like {"NEP-17": "full", "NEP-24": "partial"}.
3. Off-chain tools query manifests via ContractManagement.GetContract or RPC getcontractstate.

For backwards compatibility with ERC-165 / ERC-5269 expectations, implement supportsInterface(bytes4) and supportERC(...) views that read the same data they would on Ethereum — the manifest is the canonical source.

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

contract ERC5269 {
    mapping(bytes32 => bytes32) public supportedERCs;  // ercId → status

    event OnSupportERC(address indexed caller, bytes32 indexed majorERCIdentifier,
                       bytes32 minorERCIdentifier, bytes extraData);

    function supportERC(address /*caller*/, bytes32 majorId, bytes32 /*minorId*/,
                        bytes calldata /*extraData*/) external view returns (bytes32) {
        return supportedERCs[majorId];
    }
}

// On Neo, the canonical answer is in the contract's manifest, not in code.
// Manifest declaration (in C# attributes):

using Neo.SmartContract.Framework.Attributes;
using Neo.SmartContract.Framework.Native;

namespace R3E.Examples;

[SupportedStandards(NepStandard.Nep17, NepStandard.Nep24)]  // ← The manifest carries this
public class MyToken : Nep17Token
{
    public override string Symbol  => "MYT";
    public override byte   Decimals => 8;
    // No supportERC method needed — tools read the manifest directly.
}

Off-chain Query Pattern

async function getSupportedStandards(contractHash: string): Promise<string[]> {
    const result = await neoRpc.getcontractstate(contractHash);
    return result.manifest.supportedstandards || [];
}

const standards = await getSupportedStandards(MY_CONTRACT);
// → ["NEP-17", "NEP-24"]

For richer per-ERC status, declare a manifest.extra JSON field at deploy time:

[ManifestExtra("erc-5269-status", "{\"NEP-17\":\"full\",\"NEP-24\":\"partial\"}")]
public class RichManifest : SmartContract { /* ... */ }