Weird ERC721 Tokens

This repository contains examples, in Solidity, of ERC721 (NFTs) tokens with behavior that may be surprising or unexpected.

The behavior mentioned in this repo is based, as much as possible, on real-world tokens and implementations. However, some theoretical corner cases are also mentioned where no concrete examples have been identified (to the author's knowledge).

The goal of this repository is to serve as a valuable resource for developers and auditors, similar to how it's predecessor weird-erc20 has been.

While the ERC721 specification is well-defined, over the years, certain non-standard behaviors have appeared. These often arise from combining ERC721 tokens with other standards in novel or unintended ways.

If you are developing an ERC721 token, consider this repository a guide to potential pitfalls and behaviors to approach with caution. If you are building a protocol that interacts with ERC721 tokens, you are strongly advised to account for these cases or, at the very least, define which scenarios your product intends to support.

ERC721 resources:

• Official ERC721 documentation: https://eips.ethereum.org/EIPS/eip-721
• RareSkills ERC721 guide: https://www.rareskills.io/post/erc721

ERC721 Tokens

1️⃣ Simultaneous ERC721 and ERC1155 Standards

Some NFT collections are both ERC721 and ERC1155 at the same time. Protocols that automate transfers by attempting to detect if an asset is an ERC721 or ERC1155 may result in an incorrect number of assets being transferred.

examples:

• Sandbox Game Asset — an example integration issue
• F1® Delta Time — old Animoca collection

2️⃣ Wrapped ERC721 and Old NFT Collections

Before the ERC721 standard was fully established, many NFT collections were created without adhering to a standardized framework. As demand grew for trading these legacy collections within the current ERC721 ecosystem, wrapper solutions emerged. Holders would deposit the original non-compliant NFT and receive an ERC721 wrapper NFT which can be redeemed for the original NFT.

examples:

• CryptoPunks — the wrapped versions can be traded here Wrapped CryptoPunks
• CryptoKitty — some collections, such as CryptoKitty, were wrapped to ERC20 tokens
• CryptoFighter — collections like CryptoFighters, which are still in circulation but are not fully ERC721 compliant and are not wrapped, create issues for any integrating protocol

More information on old NFTs can be found by joining the NFT Relics community

3️⃣ Multiple NFT Collections On the Same ERC721 Contract

An NFT collection is usually tied to a single instances of an ERC721 contract. There are cases, however, where multiple collections are on the same ERC721 contract.

Of special importance for users is that, giving approval for one collection via ERC721::setApprovalForAll will actually give allowance over all NFTs of the underlying ERC721 contract.

examples:

• both the CyberKongz (Babies) and OG CyberKongz are on the same contract.
• @punk6529's NextGen contract, which is specifically designed for multiple collections on the same contract. It currently has only one collection mapped. Adding another collection may break ERC compatibility. For example, the ERC721Enumerable compatibility will be broken (due to totalSupply returning an incorrect value) by adding another collection

4️⃣ Large or Custom ERC721 Token IDs

The ERC721 standard specifically does not limit how mining and burning is to be done:

Creation of NFTs (“minting”) and destruction of NFTs (“burning”) is not included in the specification. Your contract may implement these by other means.

The only constraint is that that the ID of a collection NFT must be representable as a number that fis in a unit256 variable.

While the majority of tokens opt for incremental minting, or start the mining process from 0/1 and up until the number of NFTs, there are collections that create custom schemas for the tokenId.

examples:

• having information within the token ID. The Sandbox Game Asset collection encodes asset creator, NFT type and other data in the token ID. Example Token ID of a Wooden Chair: 93539746106169265185984122850742147987924040810729814653747710597909864011777
• Wrapped Number Board collection with the max uint256 value as token ID: 115792089237316195423570985008687907853269984665640564039457584007913129639935

5️⃣ Multiplying or Breeding ERC721s

Depending on the project behind the ERC721 contract, other ERC721 contracts may be airdropped (or "breed") to the same holding address. The airdrop paradigm has slowly changed over time to a claim airdrop logic (implemented pull versus push pattern) instead, thus this type of behavior is not that common, but it may lead to issues if an airdrop is expected.

Holder contracts of NFTs that might receive airdrops for holding them, are encouraged to implement their ERC721TokenReceiver interface in such a way to allow arbitrary NFTs to be received (if protocol logic allows it).

6️⃣ Fractionalized ERC721

Fractionalized NFTs is when ownership of an ERC721 is split into several other components, usually ERC20 tokens.

Initial implementations would have the ERC721 deposited into a smart contract to hold, then mint a corresponding amount of ERC20 tokens. Under certain conditions, usually holding all the tokens, the ERC721 was retrieved.

Fractionalizing ERC721 can lead to scenarios where the underlying NFT changes ownership in debatable circumstances, although it does not introduce integration issues after the ERC721 was made whole.

example: Ape CryptoPunk #2386 (worth millions at that time) was acquired with only 10 ETH by gaming the fractionalization mechanism

7️⃣ Mixed ERC20 and ERC721 Implementation

Some contract merge features of fungible (ERC20) and non-fungible (ERC721) tokens to create what was coined as semi-fungible tokens. Users could own fractions of an NFT by holding the underlying ERC20 base tokens.

The first semi-fungible variation to gain significant popularity was named ERC404 (the name is not an ERC/EIP standard). ERC404-tokens combines both ERC20 and ERC721 standards into one contract but is not fully compatible with either standard.

Supporting these types of ERC721 tokens requires special and dedicated attention, the readme on the ERC404 repository needs to be rigorously inspected while making a protocol.

examples: Pandora, DeFrogs, Palette

8️⃣ ERC721 bound to ERC20

Extending on the idea of pairing ERC20 with ERC721, a new standard appeared, namely ERC-7631: Dual Nature Token Pair which, quoting the documentation represents a way of having:

A fungible ERC-20 token contract and non-fungible ERC-721 token contract can be interlinked, allowing actions performed on one contract to be reflected on the other.

The most popular implementation of ERC-7631 is the DN404 project. DN404 uses two separate contracts, one for each token type, interlinked and each fully compatible with their respective standard.

Protocols that integrate with ERC7631 type tokens must pay attention to subtleties, such as determining which ERC721 token is moved or minted when the underlying ERC20 tokens are transferred.

DN404 - Vulnerabilities Reported And Resolved is article written by the author of this document, ABA (shameless marketing), which details issues and corner-cases that can appear when integrating the DN404 implementation of ERC-7631.

examples: Asterix Labs, Velocity Pass 2.0 by Oracle Red Bull Racing, Sheboshis

9️⃣ Self Destructing or Self Burning ERC721

There are some ERC721 collections that will burn tokens automatically due to predefined triggers.

Integrating protocols need to account for token IDs randomly disappearing (being burned).

examples:

• the Two Degrees collection will burn its only token ID when global warming reaches 2 degrees above average.
• another example is the Complex Death collection, where there is a 30% chance of burning your NFT on each transfer.

1️⃣0️⃣ Upgradable ERC721

There are ERC721 collections that can be upgradable.

While not fitting the weird classification, it is important to note that protocols interacting with upgradable ERC721 tokens may need to update their code in response to it changing.

Example, if a legitimate collection was compromised and the attacker would revert all transfers, any protocol using the ERC721 as collateral, for example, would have issues.

examples: DeGods, Mocaverse, Sproto Gremlins, Neo Tokyo Citizens

1️⃣1️⃣ Pausable ERC721

Some ERC721 collections can be paused by a privileged role, usually the owner. In case of a contract ownership compromise, any integrating protocol may have issues with blocked or trapped NFTs.

examples: Pudgy Rods, PudgyPresent

1️⃣2️⃣ ERC721 With Blacklists

There are ERC721 collections that can block addresses from transferring tokens (to and from). This is done at contract level and often employ a registry for managing the blocked addresses.

The same type of issues as when transfers are paused can appear, by blacklisting say, marketplaces, some collections become untradable.

Registry-based blacklists targeting marketplaces were popular at one point when the trend was to not allow NFTs to be traded if creator royalties are not enforced.

Projects like ClosedSea and operator-filter-registry gained popularity and were integrated in several known and important collections.

examples (with registry-based blacklists): Azuki Elementals, Sproto Gremlins, goblintown

1️⃣3️⃣ ERC721 That Mint During Contract Creation

The ERC721 standard includes an exception regarding the Transfer event:

This event emits when NFTs are created (from == 0) and destroyed (to == 0). Exception: during contract creation, any number of NFTs may be created and assigned without emitting Transfer.

The Transfer event is essential for off-chain systems to determine and track token ownership. ERC721 contracts that mint in the constructor without emitting the Transfer event, although technically ERC721 compliant, may break off-chain token trackers.

It’s important to note that the phrase during contract creation is somewhat ambiguous and could also be interpreted to include the initialize function call in upgradable contract patterns.

To ensure compatibility with off-chain systems, ERC721 developers are strongly encouraged to emit Transfer events whenever associating a token ID with an address.

1️⃣4️⃣ ERC721 With Permit

ERC-4494: Permit for ERC-721 NFTs was a proposed standard aimed at bringing ERC20-permit (EIP-2612) functionality to ERC721 tokens. This standard allowed users to sign an ERC721 approve transaction off-chain, generating a signature that could then be submitted to the permit function by anyone.

However, the standard is now stagnant and is not recommended for use. It can cause issues with protocols that assume ERC721 to not have any alternative approval mechanism.

While few NFT collections have implemented this standard, it is still important for protocols interacting with ERC721 tokens to account for them. Most notably, the Uniswap V3 Position NFT adheres to this standard.

examples: Uniswap V3: Positions NFT, Wallkanda Curated Artists, Bleeps