Search…
Technical Specification

Abstract

A non-fungible token (NFT) interoperability protocol would enable NFTs to move freely between blockchains, resulting in a unified NFT ecosystem. At present, NFTs are fractured across multiple blockchains, impeding the innovation that comes with multi-chain composability. To achieve this, we propose a solution to create, authenticate, and track smart contract obligations across heterogeneous blockchains.

Introduction

Currently, NFTs remain on the blockchain to which they were originally minted. This is because bridging NFTs to different blockchains is difficult, as there is no way to definitively know if the bridged NFT is the original, if the bridge is trustworthy, or if there is more than one copy of the NFT across multiple networks. Additionally, transferring underlying NFT data across blockchains (in a universal format) is not currently possible. While bridging may exist for fungible tokens, using conventional bridging processes for NFTs results in a loss of non-fungible data.

Protocol Overview

Holograph is a smart contract protocol that enables non-fungible (& fungible) tokens to beam across Ethereum Virtual Machine (EVM) compatible blockchains, while maintaining a consistent smart contract address, token ID, and underlying NFT data. In one particular embodiment, an exact bit-to-bit version of an NFT is passed onto an EVM blockchain and combined with a specific set of rules and restrictions, enabling the NFT to “beam” freely among blockchains, while still maintaining its non-fungible attributes.
Holograph Protocol Stack
This is achieved by our patented process called “Holographing” (U.S. Provisional Application No. 63/317,343 Systems and Methods for Managing Network-Agnostic Smart Contracts), which was inspired from the process of “holography,” which is a technique in physics that “enables a wavefront to be recorded and later re-constructed.”
Holograph facilitates the use of a single, unique smart contract address and token ID across all blockchains, making them the definitive identifying characteristics of the token, while guaranteeing secure, non-fungible asset transfers between blockchains. By using a strictly enforced process, initial seeds are populated across blockchains, allowing for all subsequent smart contracts to be derived from them. With this approach, smart contract addresses are ensured to remain consistent no matter where they exist. The seeds allow for Holograph to synchronize and support all existing EVM blockchains, in addition to all future EVM blockchains.
Furthermore, Holograph expands this concept by utilizing “Holographers,” which operate in an isolated layer and enforce the universal standards of all non-fungible (& fungible) token types. This creates a virtual machine-like environment inside of a blockchain, empowering developers to create and innovate freely, without compromising data integrity or universal token standards.
Holograph Bridge Flow

Protocol Mechanics

A deployment object is created that includes certain preliminary configurations. This object is hashed and signed by the deploying wallet, and the configuration parameters are passed along to a Factory smart contract on the initially deployed blockchain. The Factory smart contract uses the configuration and original signer as the salt in the CREATE2 function. The signed configuration ensures that a deployment cannot be modified or changed, without altering the deployment contract address. This allows for the deployment of an identical smart contract on any other EVM blockchain by any wallet or contract.
More specifically, using the CREATE2 function allows for the deployment of a smart contract to the same address on all EVM compatible blockchains, as long as the initial configuration remains unaltered. These deployed smart contracts are used for the purpose of creating one (or more) non-fungible asset(s) on Chain A, and making it possible to move said asset(s) to Chain B (or any other EVM compatible blockchain) by either locking or burning the asset(s) on Chain A, and then minting the same asset(s) on Chain B (with same contract address and token ID), or unlocking the asset(s) on Chain B (if already created).
In the following example, we will unpack the deployment of smart contracts for creating and tracking an NFT. Initially, the original deployment blockchain is identified. For example, a numeric value can be assigned to each of the chains, e.g., Ethereum : 1, BSC : 2, Avalanche : 3, Polygon : 4, etc. (in some instances these may be hashed). Next, the Holograph Protocol and Token Standard Enforcer smart contract addresses are determined (in some instances these may be hashed). Then, the Custom smart contract bytecode is identified. Once all the information is available, a Holographer smart contract can be deployed with the previously identified values provided in the initial configurations.
Deployment of the bridgeable contract starts by hashing all the necessary configuration parameters and converting them into a salt variable. The salt is checked against the Registry smart contract to ensure that it has not already been deployed on the current blockchain. The Custom smart contract bytecode is deployed with a user defined salt. The CREATE2 function is then called with the salt, Factory smart contract address, and Holographer bytecode to deploy a Holographable smart contract. Before finalizing the deployment process, all configuration parameters are passed on to the newly deployed Holographer smart contract, including Custom smart contract address, which configures the Token Standard Enforcer, Holographer, and Custom smart contract itself.
Thus, a smart contract deployed via this process is guaranteed to have the exact same underlying source code and configurations, ensuring that an exact Holographable version of the smart contract can be made on all EVM compatible blockchains.

Main Components

Holograph Protocol consists of 10 main components. These components are the building blocks with which the entire tech stack operates.
Main Components

Core

HolographGenesis
Genesis will be deployed on all blockchains that run and support Holograph Protocol. All main components will be deployed via Genesis. Future blockchains will have a Genesis deployment as well.
HolographFactory
Factory enables developers to submit a signed version of the following elements to deploy a “Holographed” smart contract on the blockchain:
  • primary deployment chain
  • token type (ERC-20, ERC-721, etc.)
  • event subscriptions
  • custom smart contract bytecode
  • custom initialization code
Any additional blockchains that developers want to support can have the same signed data submitted to Factory, allowing for the creation of an identical “Holographed” contract.
The primary job of Factory is to:
  • allow propagation of exact data across all blockchains
  • ensure a proper standard is selected and used
  • ensure all deployments succeed and work as expected
  • ensure that security is enforced and impenetrable
HolographRegistry
Registry is a central on-chain location where all Holograph data is stored. Registry keeps a record of all currently supported standards. New standards can be introduced and enabled as well. Any properly deployed Holographed contracts are also stored as reference. This allows for a definitive way to identify whether a smart contract is secure and properly Holographed. Verifying entities will be able to identify a Holographed contract to ensure the highest level of security and standards.
HolographBridge
Bridge is a universal smart contract that functions as the primary entry and exit point for any Holographed tokens to and from all supported blockchains. Bridge validates and ensures integrity and standard enforcement for every Bridge-In and Bridge-Out request. Additionally, Bridge implements a universal standard for sending tokens across blockchains by abstracting away complexities into sub-modules that remove the burden of management for developers. This allows for simple one-click/one-transaction native gas token payment-based interactions for all bridge requests.
HolographOperator
Operator's primary job is to know the messaging protocols that are utilized by the Holograph protocol for all cross-chain messages, and to ensure the authenticity and validity of all requests being submitted. Operator ensures that only valid bridge requests are sent/received and allowed to be executed inside of the protocol.
Holograph
Holograph is the primary entry-point for all users and developers. A single, universal address across all blockchains will enable developers an easy way to interact with the protocol’s features. Holograph keeps references for all current Registry, Factory, and Bridge implementations. Furthermore, it allows for single interface management of the underlying Holograph Protocol.
Holograph provides a reference to the name and ID of all supported blockchains. Additionally, it:
  • Enables custom smart contract logic that is chain-dependent
  • Frees developers from having to query and monitor the blockchain
Holograph Smart Contract Flow

Standards Enforcers

Holographer
Holographer exists at the core of all Holographed smart contracts, which is applied whenever a Holographed smart contract is deployed. Holographer pieces together all components and routes all inbound function calls to their proper smart contracts, ensuring security and the enforcement of specified standards. Holographer is isolated on its own private layer and is essentially hard-coded into the blockchain.
Enforcer
Enforcer enables and ensures complete standards, compliance, and operability for a given standard type. HolographERC20 and HolographERC721 are perfect examples of such Enforcers. Enforcers store and manage all data within themselves to ensure security, compliance, integrity, and enforcement of all protocols. Communication is established with custom contracts via specific event hooks. The storage/data layer is isolated privately and not directly accessible by custom contracts.
PA1D
PA1D is an on-chain royalties contract for non-fungible token types. It supports a universal module that understands and speaks all of the different royalty standards on the blockchain. PA1D is built to be extendable and can have new royalty standards implemented as they are created and agreed upon.
Interfaces
The Interfaces contract is used to store and share standardized data. It acts as an external library contract. This allows all the Holograph protocol smart contracts to reference a single instance of data and code.

External Components

Custom Contract
Custom contract is any type of smart contract that was developed outside of Holograph Protocol, and is used to create a Holographed contract. This empowers developers to build their projects however they want. The requirements for enabling a custom contract to be Holograph-able are minimal, and allow for even novice-level developers to implement. Any current and future fungible and non-fungible token type contracts can easily be made Holograph-able.

Protocol Scope

Holograph Enforcers have been limited to encourage developers to push the boundaries of what is possible. We support the enforcement of token standards, but will never prevent developers from maximizing their creativity.

Fungible Tokens

Minting
Developers should have the freedom to decide variables like token supply, distribution, and emissions.
Transfers
Custom contracts may initiate transfers for any wallet and for any amount. There may be scenarios (e.g., responding to legal actions, denylisting, DAO approved overrides, etc.) where a token contract may need to override a standard and initiate a transfer.
Bridging
When fungible tokens are bridged, they are burned on the source chain and minted on the destination chain. No matter the smart contract logic being used, the tokens leaving the source chain will be burned before allowing them to be minted on the destination chain.
Reverting or Blocking Transactions
Custom contracts should be able to revert or block enforced standard function calls via connected event hooks.

Non-Fungible Tokens

Minting
Custom contracts should be able to call the mint function as many times as it wants. Holograph Enforcers will never restrict or control this aspect of the standard.
A custom contract that is minting a token, will be able to assign any token ID within a 28 byte range. Mints originating on origin chain will have 4 empty bytes prepended to make a 32 byte token ID. All other non-origin chain mints will have a 4 byte chain ID prepended to make a 32 byte token ID.
Transfers
Custom contracts should be able to initiate a transfer for any wallet and for any token ID.
Bridging
NFTs are unique, meaning that there should never be more than one copy of it. Since all non-fungible properties of an NFT (address, ID, etc.) **can be Holographed to the destination chain, it is unnecessary to keep a version of it on the source chain. With this in mind, when an NFT is bridged, it is burned on the source chain and minted on the destination chain.
Burning
Custom contracts should be able to initiate a burn function for any wallet and for any token ID.
Reverting or Blocking Transactions
Custom contracts should be able to revert or block function calls via connected event hooks.
URIs
Enforcers do not store token URIs. It is up to developers to decide how to implement and pass token URIs to Enforcers. At the heart of every NFT is the token URI, which is a reference to a JSON payload. Token URIs can be implemented in a variety of ways (e.g., generative on-chain SVGs). Because of this, Enforcers pass on token URI requests to custom contracts, allowing them to decide and define what the URI will return.

Conclusion

Holograph Protocol provides NFT interoperability infrastructure for the web3 ecosystem. We have outlined the protocol’s technical specifications to enable NFTs to move between heterogeneous blockchains with complete data integrity. Our mission is to reduce asset fragmentation across blockchains, resulting in the unlocking of creativity, liquidity, and brand-new use cases.
Copy link
On this page
Abstract
Introduction
Protocol Overview
Protocol Mechanics
Main Components
Core
Standards Enforcers
External Components
Protocol Scope
Fungible Tokens
Non-Fungible Tokens
Conclusion