Skip to main content

Protocol Specification

Overview​

Holograph is a smart contract protocol that enables fungible and non-fungible tokens to move across Ethereum Virtual Machine (EVM) compatible blockchains, while maintaining a persistent contract address, token ID, and underlying data. In one particular embodiment, an exact bit-to-bit version of a digital assets is passed onto an EVM blockchain and combined with a specific set of rules and restrictions, enabling the asset to move freely among blockchains while maintaining its token attributes.

This is achieved by a process called Holographing, 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 contract address and token ID across all blockchains, making them the definitive identifying characteristics of the token, while guaranteeing secure asset transfers between blockchains. By using a strictly enforced process, initial seeds are populated across blockchains, allowing for all subsequent contracts to be derived from them. With this approach, 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 types of digital assets. 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.

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 contract on the initially deployed blockchain. The Factory 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 contract on any other EVM blockchain by any wallet or contract.

More specifically, using the CREATE2 function allows for the deployment of a contract to the same address on all EVM compatible blockchains, as long as the initial configuration remains unaltered. These deployed contracts are used for the purpose of creating one (or more) 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, this specification will unpack the deployment of 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 and Enforcer contract addresses are determined (in some instances these may be hashed). Then, the Custom contract bytecode is identified. Once all the information is available, a Holographer 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 contract to ensure that it has not already been deployed on the current blockchain. The Custom contract bytecode is deployed with a user defined salt. The CREATE2 function is then called with the salt, Factory contract address, and Holographer bytecode to deploy a Holographable contract. Before finalizing the deployment process, all configuration parameters are passed on to the newly deployed Holographer contract, including Custom contract address, which configures the Enforcer, Holographer, and Custom contract itself.

Thus, a 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 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.

Core​

HolographGenesis​

Genesis will be deployed on all blockchains that run and support Holograph. 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 contract on the blockchain:

  • primary deployment chain
  • token type (ERC-20, ERC-721, etc.)
  • event subscriptions
  • custom 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 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 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 Holograph.

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 protocol.

Holograph provides a reference to the name and ID of all supported blockchains. Additionally, it:

  • enables custom contract logic that is chain-dependent
  • frees developers from having to query and monitor the blockchain

Standards Enforcers​

Holographer​

Holographer exists at the core of all Holographed contracts, which is applied whenever a Holographed contract is deployed. Holographer pieces together all components and routes all inbound function calls to their proper 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). 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.

Royalties​

Royaties 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. Royaties is built to be extendable and can have new royalty standards implemented as they are created and agreed upon.

Interfaces​

Interface is used to store and share standardized data. It acts as an external library contract. This allows all Holograph contracts to reference a single instance of data and code.

External Components​

Custom Contract​

Custom is any type of contract that was developed outside of Holograph, 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 Holographable are minimal, and allow for even novice-level developers to implement. Any current and future fungible and non-fungible token type contracts can be made Holographable.

Protocol Scope​

Enforcers have been limited to encourage developers to push the boundaries of what is possible. Holograph supports 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, deny listing, 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. Enforcers will never restrict or control this aspect of the standard.

A Custom contract that is minting on an originally configured network will be able to assign any token ID within a 28 byte range. The remaining 4 bytes are prepended with zeros to make a 32 byte token ID. All subsequent mints, no matter what the chain, will have the 28 byte token ID prepended with a 4 byte chain ID.

// final token ID
uint256 token;

// variables defined by Enforcer
uint32 originChain = 0xffffffff;
uint32 currentChain = 0xfffffffe;

// custom contract sets tokenId for minting
uint224 tokenId = 0x00000000000000000000000000000000000000000000000000000001;

// Enforcer compares chain data
if (currentChain() == originChain) {
  // minting on original chain, prepend with 0s
	token = abi.encodePacked(0x00000000, tokenId);
	// token == 0x0000000000000000000000000000000000000000000000000000000000000001
  // token == 1
} else {
  // minting on foreign chain, prepend with chain ID to prevent token ID conflicts
  token = abi.encodePacked(currentChain,tokenId);
	// token == 0xfffffffe00000000000000000000000000000000000000000000000000000001
	// token == 115792089183396302089269705419353877679230723318366275194376439045705909141505
}

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.