​
What is ERC404?

ERC404 is an open, mixed ERC-20 and ERC-721 implementation designed to provide native fractionalization while supporting seamless integration with existing protocols.

ERC404

The ERC404 Repository

​
How it Works

It’s important to understand the underlying philosophy of ERC404 and the tradeoffs made to ensure smooth integration with protocols that are typically unaware of ERC721 functionality. Each whole token is effectively tied to a typical ID, but is otherwise able to be traded or transferred fractionally. All ERC721 interface functions respect typical operation whereby users are able to transfer distinct token id’s without friction. As this native fractional balance is transferred, however, whole tokens leave the users account, drawn from a queue when ownership of whole tokens changes.

For example, when a user with a balance of 7.2 tokens transfers a fractional representation of 0.3, their most recently received token would be removed, and their balance would be 6.9.

This begs the question of where whole tokens go under these circumstances. This is one of the most significant generalizations from the initial iteration of ERC404, where a LIFO pool is maintained of available ID’s assuming the maximum ID is aligned with total supply.

For instance, when a new a collection is launched, new NFTs will be minted until the total number of NFTs is equal to the total supply (100 NFTs for a total supply of 100 * 10 ^ decimals). Once this point has been reached, if a token is removed from a users balance as result of a fractional transfer but the recipient does not experience a whole token balance change, this ID would then be added to this stack of pending ID’s. What this then offers is a persistent pool of static ID’s, allowing for more traditional collection design.

How ERC404 supports these mixed interfaces is another interesting topic. ERC404 takes the approach of isolating independent logic where possible, and introducing pathing to support simple, seamless integration on overlapping standards. Pathing could best be described as a lossy encoding scheme in which token amount data and ids occupy shared space under the assumption that negligible token transfers occupying id space do not or do not need to occur.

The following interface outlines a set of functions that rely on this pathing approach:

//SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

interface IERC404Pathing {
  function transferFrom(
    address from_,
    address to_,
    uint256 valueOrId_
  ) external returns (bool);
  function approve(
    address spender_,
    uint256 valueOrId_
  ) external returns (bool);
}

​
Current State

ERC404 is still in active experimentation, having grown rapidly from an initial implementation used to support the Pandora launch. As adoption has grown and new use-cases have been identified, we’ve rapidly moved towards building a more generalized implementation that can better suport novel protocols, existing integrations and creators alike.

As a result of these efforts, the latest implementation has introduced a number of improvements:

  • ERC-721 type token ids are now banked and reused in a FIFO queue instead of increasing forever as they are minted and burned. This allows for a predictable set of NFT token ids, as in a typical NFT collection.
  • Transfers of full ERC-20 type tokens now transfer ERC-721 type tokens held by the sender to the recipient. In other words, if you transfer 3 full tokens as an ERC-20 transfer, 3 of the ERC-721s in your wallet will transfer directly to the recipient rather than those ERC-721s being burned and new token ids minted to the recipient.
  • Predictable events emitted during transfers, approvals, and other operations that clearly indicate whether attributed to ERC-20 / ERC-721.
  • Dedicated functions for returning ERC-20 / ERC-721 balances and total supply.
  • Removal of fixed supply cap in core contract, allowing a fixed token supply cap to be added optionally if desired.
  • Simplification and centralization of transfer logic.
  • Easier to use dedicated minting function.
  • EIP-2612 support for permit approvals.
  • EIP-165 support.
  • Numerous logical optimizations and gas savings.

​
ERC404 Legacy

The legacy contract used for Pandora’s specific use-case has been deprecated but preserved, and will be archived in the near future.

ERC404 Legacy

The Legacy ERC404 Repository