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:
- The Neo port doesn't need the
supportERCview method — set the manifest'ssupportedstandardscorrectly at deploy time. - For extended status (full vs partial vs pending), use the manifest's
extrafield with a JSON object like{"NEP-17": "full", "NEP-24": "partial"}. - Off-chain tools query manifests via
ContractManagement.GetContractor RPCgetcontractstate.
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.
