This specification introduces a new interface that extends ERC-721 and ERC-1155 to enable the discovery and use of onchain and offchain redeemables for NFTs. Onchain getters and events facilitate discovery of redeemable campaigns and their requirements. New onchain mints use an interface that gives context to the minting contract of what was redeemed. For redeeming physical products and goods (offchain redeemables) a redemptionHash and signer can tie onchain redemptions with offchain order identifiers that contain chosen product and shipping information.
Creators frequently use NFTs to create redeemable entitlements for digital and physical goods. However, without a standard interface, it is challenging for users and apps to discover and interact with these NFTs in a predictable and standard way. This standard aims to encompass enabling broad functionality for:
redemptionHash)The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
The token MUST have the following interface and MUST return true for ERC-165 supportsInterface for 0x1ac61e13, the 4 byte interfaceId of the below.
When creating a new campaign, createCampaign MUST be used and MUST return the newly created campaignId along with the CampaignUpdated event. The campaignId MUST be a counter incremented with each new campaign. The first campaign MUST have an id of 1.
Updates to campaigns MAY use updateCampaign and MUST emit the CampaignUpdated event. If an address other than the manager tries to update the campaign, it MUST revert with NotManager(). If the manager wishes to make the campaign immutable, the manager MAY be set to the null address.
If tokens are set in the params offer, the tokens MUST implement the IRedemptionMintable interface in order to support minting new items. The implementation SHOULD be however the token mechanics are desired. The implementing token MUST return true for ERC-165 supportsInterface for the interfaceId of IRedemptionMintable, 0x81fe13c2.
When mintRedemption is called, it is RECOMMENDED to replace the token identifiers in the consideration items and trait redemptions with the items actually being redeemed.
Any token may be specified in the campaign requirement consideration. This will ensure the token is transferred to the recipient. If the token is meant to be burned, the recipient SHOULD be 0x000000000000000000000000000000000000dEaD. If the token can internally handle burning its own tokens and reducing totalSupply, the token MAY burn the token instead of transferring to the recipient 0x000000000000000000000000000000000000dEaD.
Including trait redemptions is optional, but if the token would like to enable trait redemptions the token MUST include ERC-7496 Dynamic Traits.
A signer MAY be specified to provide a signature to process the redemption. If the signer is not the null address, the signature MUST recover to the signer address via EIP-712 or ERC-1271.
The EIP-712 struct for signing MUST be as follows: SignedRedeem(address owner,uint256[] considerationTokenIds,uint256[] traitRedemptionTokenIds,uint256 campaignId,uint256 requirementsIndex, bytes32 redemptionHash, uint256 salt)"
The redeem function MUST use the consideration, offer, and traitRedemptions specified by the requirements determined by the campaignId and requirementsIndex:
considerationtraitRedemptions according to ERC-7496 Dynamic TraitsmintRedemption() on every offer itemThe Redemption event MUST be emitted for every valid redemption that occurs.
The extraData layout MUST conform to the below:
| bytes | value | description / notes |
|---|---|---|
| 0-32 | campaignId | |
| 32-64 | requirementsIndex | index of the campaign requirements met |
| 64-96 | redemptionHash | hash of offchain order ids |
| 96-* | uint256[] traitRedemptionTokenIds | token ids for trait redemptions, MUST be in same order of campaign TraitRedemption[] |
| *-(+32) | salt | if signer != address(0) |
| *-(+*) | signature | if signer != address(0). can be for EIP-712 or ERC-1271 |
The requirementsIndex MUST be the index in the requirements array that satisfies the redemption. This helps reduce gas to find the requirement met.
The traitRedemptionTokenIds specifies the token IDs required for the trait redemptions in the requirements array. The order MUST be the same order of the token addresses expected in the array of TraitRedemption structs in the campaign requirement used.
If the campaign signer is the null address the salt and signature MUST be omitted.
The redemptionHash is designated for offchain redemptions to reference offchain order identifiers to track the redemption to.
The function MUST check that the campaign is active (using the same boundary check as Seaport, startTime <= block.timestamp < endTime). If it is not active, it MUST revert with NotActive().
The token MUST respect the TraitRedemption substandards as follows:
| substandard ID | description | substandard value |
|---|---|---|
| 1 | set value to traitValue | prior required value. if blank, cannot be the traitValue already |
| 2 | increment trait by traitValue | max value |
| 3 | decrement trait by traitValue | min value |
| 4 | check value is traitValue | n/a |
The token MUST check that the maxCampaignRedemptions is not exceeded. If the redemption does exceed maxCampaignRedemptions, it MUST revert with MaxCampaignRedemptionsReached(uint256 total, uint256 max)
The metadata URI MUST conform to the below JSON schema:
Future EIPs MAY inherit this one and add to the above metadata to add more features and functionality.
This standard MAY be applied to ERC-1155 but the redemptions would apply to all token amounts for specific token identifiers. If the ERC-1155 contract only has tokens with amount of 1, then this specification MAY be used as written.
The "offer" and "consideration" structs from Seaport were used to create a similar language for redeemable campaigns. The "offer" is what is being offered, e.g. a new onchain token, and the "consideration" is what must be satisfied to complete the redemption. The "consideration" field has a "recipient", who the token should be transferred to. For trait updates that do not require moving of a token, traitRedemptionTokenIds is specified instead.
The "salt" and "signature" fields are provided primarily for offchain redemptions where a provider would want to sign approval for a redemption before it is conducted onchain, to prevent the need for irregular state changes. For example, if a user lives outside a region supported by the shipping of an offchain redeemable, during the offchain order creation process the signature would not be provided for the onchain redemption when seeing that the user's shipping country is unsupported. This prevents the user from redeeming the NFT, then later finding out the shipping isn't supported after their NFT is already burned or trait is mutated.
ERC-7496 Dynamic Traits is used for trait redemptions to support onchain enforcement of trait values for secondary market orders.
As a new EIP, no backwards compatibility issues are present.
Authors have included Foundry tests covering functionality of the specification in the assets folder.
Authors have included reference implementations of the specification in the assets folder.
If trait redemptions are desired, tokens implementing this EIP must properly implement ERC-7496 Dynamic Traits.
For tokens to be minted as part of the params offer, the mintRedemption function contained as part of IRedemptionMintable MUST be permissioned and ONLY allowed to be called by specified addresses.
Copyright and related rights waived via CC0.