ERC-7409 Public NFT emote repository (Public Non-Fungible Tokens Emote Repository)
Final · NFTs & multi-token · created 2023-07-26
A standard for a shared repository contract that lets anyone leave and revoke reactions to any NFT with Unicode emoji. Reaction records stay onchain, so everyone can query them at the same address.
Why it is needed
NFTs are widely used tokens on Ethereum, but there is no standardized way to show how much a particular token is loved right now. Existing reaction and like features are tied to specific services or handled offchain, so they can be manipulated and are hard to trust. Valuation also relies only on past sale prices, floor prices, and rarity data provided by marketplaces, with no metric to gauge preference in real time. The earlier ERC-6381 proposed the same feature, but it represented emoji as 4-byte (bytes4) values, which created a compatibility problem because it could not hold long emoji with variation flags or skin tones. This standard fixes that problem by accepting emoji as a string, and defines a shared repository reachable at the same address on every network.
In depth
String-based design that supersedes ERC-6381
This standard supersedes ERC-6381. ERC-6381 represented emoji as bytes4 on the assumption that every emoji is 4 bytes, but real emoji usually take up to 8 bytes, and personalized emoji with skin tones are much longer. So this standard accepts emoji as a string, making it compatible with emoji that will be added to the Unicode standard in the future. Apart from this fix, the functionality is identical to ERC-6381. Values not in Unicode can also be passed as a string, which allows custom emotes, but in that case they are displayed only in interfaces that know which image to draw.
A shared repository instead of an extension, and a fixed address
It was first designed as an extension attached to ERC-721 tokens, but a common-good repository can react to existing NFTs minted before the standard, so the repository approach was chosen. The repository contract uses a deterministic address calculation so that it is deployed at the same address on every network, and that address is 0x3110735F0b8e71455bAe1356a33e428843bCb9A1. The leading 0x3110735 is meant to resemble EMOTES. The ERC-165 identifier of this interface is 0x1b3327ab.
Behavior rules of emote and bulkEmote
emote takes collection, tokenId, emoji, and state, and either leaves a reaction (true) or revokes it (false). Trying to set the same state again does nothing, and the Emoted event MUST be emitted only when the state actually changes. bulkEmote handles multiple entries at once. If the collections, tokenIds, emojis, and states arrays differ in length, it MUST revert. Both single and bulk operations are provided so that users can choose the cheaper one depending on network gas costs and the number of tokens. A user can have only one active reaction with the same emoji on a given token.
Presigned message format and DOMAIN_SEPARATOR
The signed message for submission on behalf is built as keccak256(abi.encode(DOMAIN_SEPARATOR, collection, tokenId, emoji, state, deadline)). DOMAIN_SEPARATOR is generated as keccak256(abi.encode("ERC-7409: Public Non-Fungible Token Emote Repository", "1", block.chainid, address(this))), so the value differs when the chain ID differs. This prevents a signature made on one chain from being replayed on a repository on another chain. A delegate scheme was also considered, but it added too much complexity, so verifying the user's own consent through an ECDSA signature was chosen.
Why there is no chain ID parameter
There was a proposal to take a chain ID along with each reaction so that one could react to tokens on other chains, but it was not adopted. A rarely used parameter would raise transaction costs, and marketplaces and wallets would have to query every chain where the repository is deployed to aggregate reactions. Because the repository does not verify that the token being reacted to actually exists, in theory one can react to a token that does not exist yet or at all. If a collection creator wants, they can direct users to record reactions on other chains using the same collection address, and the chance of a different collection existing at the same address is considered very low.
Directions for use: interaction, feedback-driven evolution, valuation
The source presents three areas of use. First, the interaction of accumulating reactions can itself raise a token's uniqueness or value. Second, because reactions are recorded onchain, they can be counted without manipulation concerns, and a token can be designed to evolve once its reaction count passes a threshold, encouraging interaction with the collection. Third, it adds real-time preference as a reference metric to valuation that relied on past sale prices, floor prices, and rarity. This standard is finalized in Final status and is fully compatible with ERC-721 and existing ERC-721 infrastructure and tooling.
Things to watch out for
- Does not handle user assets: This proposal does not handle user assets in any form, so assets must not be put at risk when interacting with the emote repository.
- Defense against signature reuse (replay) attacks: ECDSA signatures submitted by a proxy carry a replay risk, but the DOMAIN_SEPARATOR included in the signed message is unique to each chain and repository contract, so the signature is invalid on other chains and the repository must revert the operation.
- Reuse of a pre-signed message before its deadline: A signed message can be resubmitted any number of times before its deadline. Only one instance of the same emoji reaction can be active, so this cannot be abused to inflate reaction counts. However, a service that relies on reaction removal may see the reaction set again with a still-valid signature. It is recommended to set the deadline so that the signature expires within a short period.
- Beware of unaudited contracts: Take care when dealing with contracts that have not been audited.