Skip to main content

Introduction

Introduction​

This documentation outlines the wide range of potential use cases for the Nexera Standard, establishing it as the Ethereum standard for projects that require mutability, extensibility, adaptability, and interoperability.

In this reference implementation, we demonstrate an example of adaptability, allowing an asset to conform to multiple standards, thereby expanding the range of benefits and dApps that can interact with it.

Since the release of ERC-1155 (the multi-token standard), it has been widely adopted by blockchain games due to the limitations of previous standards such as ERC20 and ERC721, which were not well-suited for certain in-game assets. ERC-1155 also reduces gas costs when transferring, minting, or burning multiple assets simultaneously.

However, as new standards have been introduced to address specific issues, the blockchain ecosystem has become fragmented, resulting in reduced interoperability between tokens. For instance, tokens based on ERC-1155 are unable to interact with ERC20-based dApps like Uniswap, which creates challenges when integrating DeFi solutions.

With ERC-7208, tokens can be dynamically adapted to multiple standards. For example, an RC-1155 token can be used as an RC-20 token simply by changing the associated DataManager. This flexibility enables tokens to integrate with existing DeFi applications without modifying the underlying asset.

This reference implementation demonstrates how a single asset can expose both an ERC-1155 interface and an ERC-20 interface. This showcases the adaptability of the Nexera Standard, allowing assets to leverage multiple token standards and interact with a wider range of decentralized applications.

Why We Chose This Scenario​

Our motivation for showing this example stems from a common challenge in blockchain development: balancing specialized token functionalities with the need for interoperability across multiple decentralized applications (dApps). Traditionally, when developers issue an ERC1155 collection, they gain the efficiency of batch transfers and multi-asset handling, but they also lose out on DeFi functionalities that are typically built for ERC20 tokens.

We specifically chose to illustrate an ERC1155 collection that behaves like an ERC20 to showcase how the Nexera Standard overcomes this challenge. By adapting ERC1155 tokens to function as ERC20 tokens, developers can create a more dynamic asset ecosystem. This enables users to leverage their tokens in both gaming applications (using ERC1155 standards) and DeFi ecosystems (utilizing ERC20 standards), unlocking liquidity options like token trading, liquidity pools, and more.

This implementation serves to show how assets can adapt to changing requirements, allowing for more robust and interoperable applications. The design decisions made here were intended to demonstrate how flexibility in token management enables better integration across a fragmented blockchain landscape.

High Level Architecture​

The core of the Nexera Standard's architecture is the separation of logic and storage.

introduction diagram

Fig 1. Simplified architecture of the Reference Implementation.

When a user calls transfer() on the ERC-20 Data Manager or transferFrom() on the ERC-1155 Data Manager, the process varies based on the asset type. The ERC-20 Data Manager handles a single-token transfer, performing checks like sufficient balance, while the ERC-1155 Data Manager processes more complex operations involving multiple token IDs and quantities. Both Data Managers then delegate the operation to the shared Data Object responsible for storing the relevant data. Throughout this process, the Data Index ensures access control, validating permissions for each operation, including multiple checks for each token ID in ERC-1155 transfers. Upon completion, the Data Object updates balances or retrieves data as necessary for the token standards involved, whether for a single token or multiple token IDs.

Asset data is stored in dedicated contracts called Data Objects, with minimal asset logic embedded within them. Data Managers are used to expose the desired interface, ensuring the asset adheres to a specific standard. Access control is managed by an intermediary system that bridges data storage and access management while defining the rules for data compatibility.

Key Concepts​

To better understand how this is achieved, let’s revisit some of the core components involved in this reference implementation:

  • ERC1155WithERC20Fraction DataManager: This contract handles the logic of the ERC1155 collection with ERC20 fractions, exposing the ERC1155 interface for interaction with traditional multi-token standards.
  • ERC20Fraction DataManager: This contract exposes the ERC20 interface, allowing the same ERC1155 tokens to be used within DeFi platforms that require ERC20 functionality.
  • ERC20Fraction DataManager Factory: A factory contract used to deploy new ERC20 DataManagers as needed, allowing the ERC1155 collection to issue new ERC20-compliant assets dynamically.
  • FungibleFractions DataObject: This object manages data related to both ERC1155 and ERC20 tokens, such as supplies, ownership, and token IDs. It ensures smooth data handling between different token types.