Omnite: Multi-Chain NFT Token Solution

Author: Omnite Foundation

Compiled by: 0xMeta

This article introduces a new multi-chain solution aimed at revolutionizing the way users create, sell, and purchase non-fungible tokens (NFTs), fundamentally changing the current NFT industry. This is achieved by leveraging the revolutionary cross-chain technology—LayerZero and the Omnite protocol smart contracts.

Today's NFT creators are forced to choose a specific blockchain platform to issue their tokens, thereby limiting potential buyers, available markets, and native token payment methods. Omnite removes these restrictions by introducing multi-chain NFT token custody without relying on centralized custodians and the currently slow, expensive, and centralized token bridging mechanisms.

This article outlines the drawbacks of adopting a single blockchain from the perspectives of creators, investors, and markets, as well as how they can benefit from a multi-chain solution. The report also depicts how the platform reduces exorbitant gas fees and the difficulties in the NFT trading process while allowing a complete path for decentralized implementation procedures.

1: Introduction

Omnite is a smart contract-based protocol that allows NFT tokens to move between blockchains in a completely decentralized manner without the need for centralized custodians. It breaks down the boundaries that exist between blockchains, enabling NFTs to easily cross chains through the revolutionary trustless full-chain interoperability protocol LayerZero.

Operating on all network platforms supported by the LayerZero protocol, the first phase focuses on EVM-based blockchain networks such as ETH, POLYGON, AVAX, FANTOM, and BSC. The aim is to achieve network interoperability based on various ecosystems in future phases, becoming a development outcome of LayerZero.

The protocol supports tokens created using the Omnite Quick Start version (hereinafter referred to as "native tokens") as well as all other NFT tokens created under the ERC721 standard since the establishment of the blockchain network. The Omnite protocol addresses four major issues affecting the platforms or tools for transferring NFT tokens across the internet: centralization, complex token transfer processes, excessive transaction fees, and long wait times. The process of transferring tokens between networks is entirely based on smart contracts, and from the user's perspective, it does not require any additional steps, unlike transferring NFT tokens within the same network.

2: Protocol Design

At the core of Omnite is an NFT transfer protocol that allows NFT tokens to flow across chains while ensuring that at any given point in time within a given custody, there is only one token instance across all supported networks. The protocol is a decentralized smart contract custody distributed across all networks supported by our solution. Their functionalities and commands are independent.

Centralized custodians have been replaced by the revolutionary communication protocol—Layer Zero, which uses Layer Zero nodes to transfer encrypted data between networks in a decentralized manner.

Since the system uses multi-chain (and potentially different types of blockchains in the future), it needs to overcome different issues that do not exist in single-chain applications.

• Access Control Supports Multiple Wallet Types

One of the biggest challenges is proving that contracts from other chains can call our OmniteBridge, as smart contract bridges on Solana or TerraLuna chains handle different processing structures, which is not the case (or supported) on EVM-based chains. Therefore, a custom solution needs to be implemented to grant roles for different types of processing.

(b) Simultaneous Code Upgrades Across Multiple Chains (Hotswaps)

Figure 1: Multi-chain Transfer Flow of NFT Tokens Using the OMNITE Protocol

All modern EVM applications use the Proxy pattern to update smart contract code when new features or security fixes arise. OmniteHotSwaps introduces a revolutionary way to upgrade multiple instances of the same contract in a secure multi-chain manner at once. Swaps consist of three components: Blueprints represent various smart contract implementations (such as NFTs), UpgradeableBeacon tracks the latest possible implementation of a specific contract type (such as the latest implementation of ERC721), and BeaconProxy, a user-visible NFT contract, is responsible for delegating requests to the actual implementation. Our approach using the proxy pattern reduces the gas fees for deploying new ERC721 NFT custody by over 75% and allows Omnite users to easily receive new features implemented by the team and community in the future.

(c) DDOS and Bridge Block Protection

An intractable problem on-chain is gas estimation across different blockchain networks, as one blockchain network cannot access data from other networks. LayerZero requires payment for the specific amount of gas needed to process operations, so it can never ensure that the amount of gas provided by the front-end application is not malicious (or miscalculated) and is sufficient to execute transactions correctly on the target network. Omnite sets the minimum gas value acceptable for bridging and adopts a method where transactions do not recover in case of errors but instead generate error events. This is achieved through complex low-level requests during the bridging LayerZero callback entry phase.

(d) ERC20 Tokens

Omnite tokens are designed as multi-chain tokens. The tokens themselves also use LayerZero infrastructure to transfer value between different blockchains, allowing for decentralized multi-chain staking and attribution.

3: Protocol Composition

Omnite Bridges are at the core of multi-chain communication. They can directly access LayerZero endpoints and serve as a messaging layer between Omnite and LayerZero. They consist of a bridging sender and a bridging receiver. These contracts are responsible for encoding and decoding low-level requests, executing these requests across different networks, and receiving messages on the other end. They are designed to be trustless; for example, any sender can deploy multiple contracts to different networks in a single transaction.

Contract Factory is a contract that holds token blueprints. It is used to deploy new contract instances (e.g., different ERC721 implementations) through the proxy pattern using upgradeable contracts and beacon proxies. It supports version control of blueprints and deployment of contract types, which allows for gas savings: the layer zero bridge does not need to transfer the entire bytecode to bridge contracts; it only needs a blueprint name and constructor parameters to instantiate a proxy contract storage.

Collection Registry keeps records of all native and non-native ERC721 tokens of Omnite. Each ERC721 deployed or bridged is stored in this registry. Each record saves the custodian's owner, address, and custody name. The CollectionRegistry provides the data needed to verify incoming and outgoing bridging requests.

Access Control List (ACL) specifies which contracts are granted access to other contracts and what operations are allowed on a given contract. It is based on OpenZeppelin's AccessControl library but has been extended to support processing structures for non-EVM networks.

System Context tracks smart contracts within the Omnite system, allowing contracts to subscribe to processing changes using callbacks. For example, it records address changes using callbacks. For instance, when a new version of the ContractFactory registry is set, the system context notifies all relevant parties.

Native Tokens are contracts deployed directly from Omnite custody creators. Custodians can easily mint them on the platform and then connect them. On a specific network, each token's smart contract has a minting range that limits minting to specific IDs. Native tokens are deployed as upgradeable contracts.

Non-native Tokens are contracts deployed outside the Omnite platform, such as Invisible Friends, Bored Apes, etc. They must implement the ERC721 Metadata interface. To bridge these tokens between networks, they first need to be wrapped. It is not possible to mint them through Omnite.

4: Protocol Fees and Benefits

The Omnite project, due to its multi-platform nature, is equipped with a payment mechanism using many local currencies. Depending on the network from which users request services (creating custody, minting tokens, or sending tokens to another network), payments will be made in the original network currency. Fees are accumulated on wallet contracts deployed across all supported networks. These contracts act as a treasury for fund accumulation, which can be exchanged for other tokens through the Stargate platform. The fees collected are both the project's profit and the cost of transfers and exchanges conducted through the Stargate platform. When the threshold is crossed, the fees will be exchanged for OMNITE tokens. This operation can be initiated by any entity. The purchased OMTs will enter the main benefit contract: OmniteStaking. This contract uses OMT tokens as custody tokens and reward tokens. By staking tokens on the contract, users can double the number of tokens they hold. Tokens are paid linearly to each benefit participant according to the ratio specified by the contract. The reward release rate is defined as a percentage of the number of tokens over a period: for example, 10% of the monthly reward liquidity pool.

5: Case Study: Bridging Non-native NFTs

In this section, we will briefly describe the details of how to implement the basic features of the Omnite platform that will bridge existing custody and send users' tokens to the target blockchain. Most existing custodians today rely on a set of Openzeppelin libraries and contracts that follow the ERC721Metadata standard. This interface exposes basic fields and functions such as name, symbol, and tokenURI. They need to manage custody within the Omnite ecosystem correctly. When a user holds a specific token from a custody that has not yet been brought to the Omnite platform, it first needs to be wrapped by Omnite's ERC721 wrapper, which follows the interface used by the platform in the form of a bridge (ITokenBridgeable).

All bridgeable tokens on the Omnite platform must implement this interface, so wrapping the source contract is crucial. This step is executed alongside multi-chain deployment. The steps include:

1. Deploying the wrapper on the source network
2. Deploying Omnite's ERC721 contract on the target network

Both operations are executed in a single transaction. The requester needs to provide the original contract address, the chain ID identifying a specific network in the LayerZero ecosystem, and the gasAmount for each deployment (the gas amount is calculated in a separate request). The requested function is payable, as the gas cost on the target network is deducted from the value sent by the user. The remainder is sent back to the user. To deploy the contract on the target network, Omnite's bridge will encode the deployment message into a Data structure, which includes the deployment operation type, the type of contract to be deployed, and the custody ID, which is generated by encoding the block timestamp and the requester's address. Next, it sends the message to the bridge contract on the target blockchain. The message passes through LayerZero endpoints and is forwarded to the receiving Omnite bridge. The bridge unpacks the data and forwards the deployment request to the ContractFactory. The ContractFactory stores all the data required for deployment and contract versions. Omnite utilizes beacon proxies: each new ERC721 is actually a set of contracts that follow this pattern. They all share a blueprint (via the beacon), which can be upgraded if necessary. After deploying a BeaconProxy with UpgradableBeacon and constructor parameters (for initializing a new custody with ERC721 fields), the new custody is registered in the CollectionRegistry, which is responsible for storing all custodians deployed or wrapped by Omnite smart contracts.

Once the deployment is complete, tokens can now be bridged. After an approval transaction is needed for the wrapper to transfer the user's assets, the bridging begins. This transaction includes:

1. Locking the token on the source network—when the asset is bridged back, it can be unlocked. This is a much safer solution than destroying tokens, as the asset will always remain in a locked state. Tokens are locked on their smart contracts and can be released when bridging back to the token.

2. Requesting the bridge to generate tokens on the target network. The move request is packed using the CallData operation type and packedData bytes. It includes the minting function selector, a token ID for minting, and the token URI for this ID. There are also gas amount values and message values, similar to the deployment transaction. Upon receiving the message on the target network, the bridge unpacks the data and executes the mint function on the target ERC721. The address of the token is retrieved from the CollectionRegistry. At the end of the process, there is an unlocked token on the source chain and a newly minted token on the target network. If the user decides to return their token, the asset will be locked again, and the original asset will be unlocked. The process can be executed indefinitely. If a specific target network holds locked assets, there is no need to create a new one.

6: Market Compatibility

Omnite smart contracts are designed to be fully compatible with leading NFT markets. By adhering to metadata standards, every custody created on the Omnite platform has a metadata URI and ownership management. After bridging the token to the target network, the user remains the owner of the NFT and can manage it freely.
It can be listed on platforms like Opensea, Rarible, etc. After selling the token, the new owner can bridge it back through the Omnite platform.