ERC-5489 NFT Hyperlink Extension
Final · NFTs & multi-token · created 2022-08-16
An extension standard that lets hyperlinks be attached to NFTs. The NFT owner delegates a link slot to a specific address, that address manages the link address (URI), and the owner can revoke the authority at any time.
Why it is needed
NFTs have the potential to become a major medium of Web3, but today ordinary users have no way to attach rich content such as text, video, and images to an NFT, and even if they did, there is no standardized way to display it. Many industries are waiting for the ability to attach such rich content, but if the ways to attach, edit, and display it vary, each wallet or app must implement them separately, which makes compatibility difficult. This standard uses hyperlinks as the medium and organizes how to attach, edit, and display links on an NFT into a single set of rules. It standardizes the process of attaching highly customized information to an NFT, including the owner delegating a link slot to another address and revoking that delegation.
What to implement
event SlotAuthorizationCreated(uint256 indexed tokenId, address indexed slotManagerAddr);: An event emitted when the slot of tokenId is authorized to the address slotManagerAddr.event SlotAuthorizationRevoked(uint256 indexed tokenId, address indexed slotManagerAddr);: Emitted when the authorization of the slotManagerAddr slot on the token tokenId is revoked. The relevant dapp can receive it and halt rewards or rights in progress.event SlotUriUpdated(uint256 indexed tokenId, address indexed slotManagerAddr, string uri);: Emitted when the URI set on the slotManagerAddr slot of the token tokenId is updated to uri.function authorizeSlotTo(uint256 tokenId, address slotManagerAddr) external;: Authorizes the hyperlink slot of tokenId to the address slotManagerAddr. A slot is an entry in a map keyed by address, and only that address can manage the slot. Emits a SlotAuthorizationCreated event.function revokeAuthorization(uint256 tokenId, address slotManagerAddr) external;: Revokes the authorization of the slot pointed to by slotManagerAddr on the token tokenId. Emits a SlotAuthorizationRevoked event.function revokeAllAuthorizations(uint256 tokenId) external;: Revokes all slot authorizations on the token tokenId. Emits a SlotAuthorizationRevoked event for each slot.function getSlotUri(uint256 tokenId, address slotManagerAddr) external view returns (string memory);: Returns the latest URI of the slot pointed to by tokenId and slotManagerAddr. It fails if tokenId is not a valid NFT, and the URI must point to a JSON file that follows the EIP5489 metadata JSON schema.
In depth
A slot is a map entry keyed by address
A slot is an entry in a map keyed by the slotManagerAddr address, and its value is a URI. Using an address as the slot key was chosen to have the flexibility to cover every use case, and using a URI as the value is likewise meant to serve a variety of use cases. The authorized address can be either an externally owned account (EOA) or a contract address. authorizeSlotTo, revokeAuthorization, revokeAllAuthorizations, and setSlotUri MAY be implemented as public or external, and getSlotUri MAY be implemented as pure or view.
Authorization check rules
authorizeSlotTo, revokeAuthorization, and revokeAllAuthorizations are authenticated if and only if the message sender is the owner of the token. By contrast, setSlotUri can be called only by an address authorized through authorizeSlotTo, so it manipulates only the slot that the caller's own address points to. In other words, the owner decides who uses which slot, and the authorized address can change only the contents of that slot.
Event emission requirements
A contract MUST emit SlotAuthorizationCreated when a slot is authorized to an address, SlotAuthorizationRevoked when an authorization is revoked, and SlotUriUpdated when a slot's URI changes. revokeAllAuthorizations emits SlotAuthorizationRevoked for each slot. The authorization revocation event can be used as a signal for the dapp to halt rewards or rights in progress.
Metadata JSON schema
The URI returned by getSlotUri MUST follow RFC 3986 and point to a JSON file that conforms to the "EIP5489 Metadata JSON schema". The schema is titled "AD Metadata" and has three properties. icon is the URI of an image/* resource representing the slot occupant; a width of 48 to 1080 pixels and an aspect ratio between 1.91:1 and 4:5 are recommended, and it is suggested as the thumbnail of the target resource. description is a short paragraph introducing the target resource. target is a URI pointing to the target resource; it is suggested to follow 30X status codes to support more redirection, and the MIME type and content depend on user settings.
Interface identifier
The supportInterface method MUST return true when called with 0x8f65987b. This standard is an extension that requires EIP-165 and EIP-721.
Compatibility with EIP-721
This standard adds a set of extension functions, so it can be fully compatible with EIP-721. The newly introduced functions also resemble the existing EIP-721 functions in many ways, which makes it easy for developers to adopt quickly. The reference implementation is provided as ERC5489.sol. The status of this proposal is finalized as Final.