Holograph

Holograph uses deterministic ERC-20 addresses while state and finality remain chain-specific

Holograph deploys ERC-20 tokens at matching addresses across supported EVM chains through deterministic contract creation. That shared address simplifies identification, yet each chain has its own transaction history, balances, and finality rules. Completion therefore comes from receipts and destination state, not the address alone.

Updated

In short: Matching addresses simplify token identity, while receipts, destination execution, and live contract settings determine whether each stage is complete.

Deployment paths and the records they create

The design separates initial creation from expansion to another chain. On Base, the launch path connects Doppler Airlock with HolographFactory. The factory passes the token configuration into deterministic deployment machinery. A successful transaction places contract code at the calculated address and creates a chain-local record. Repeating compatible deployment inputs elsewhere can reproduce the address, but it does not copy balances or transaction history.

Creation on Base

The creation record should identify the chain, initiating account, factory call, transaction hash, receipt status, and deployed address. Contract code must exist at that address after confirmation. Token metadata, supply controls, ownership, and other initialized settings also need to match the signed configuration. A predicted address without deployed code remains an expectation rather than a completed launch.

Expansion to another chain

Expansion depends on compatible deterministic inputs and deployed protocol components on the destination chain. The deployer, salt, and creation bytecode all contribute to a CREATE2 address. Changing one of them can produce a different result. The documented architecture assigns token creation to Base, fee processing and staking to Ethereum, and additional deployment support to Unichain. The supported set remains a live deployment property.

The factory, deployer, and token contract work at different layers

HolographFactory receives an authorized creation request and coordinates token initialization. HolographDeployer performs the deterministic contract creation, while HolographERC20 supplies the fungible-token implementation. FeeRouter and StakingRewards handle separate parts of protocol fee collection and HLG reward accounting. This separation keeps a deployment result distinct from later fee or staking state.

No single receipt proves every layer. A successful factory transaction establishes deployment on its chain. A router event or balance change describes fee accounting at that stage. A staking balance describes a position in the rewards contract. Each record answers a different question, even when the contracts belong to the same protocol.

What proves that a deployment succeeded?

A successful receipt and contract code at the expected address prove that the deployment executed on the selected chain. Retrieve the receipt from the intended chain, then check the sender, target, status, and relevant logs. The calculated address can then be compared with the address that actually contains code. A wallet notification alone does not establish those facts.

Initialization also matters. Read the token name, symbol, supply-related state, ownership, and any relevant fee configuration from the deployed contract. Where a proxy is involved, inspect its implementation and administrative settings as separate state. Confirmation of the outer transaction does not correct an unintended initialization value.

Matching addresses are an identity aid, not shared storage

Holograph uses CREATE2-based deployment to keep an ERC-20 contract address consistent across supported chains. The calculation relies on fixed deployment inputs, so address equality is reproducible rather than accidental. It gives applications a stable identifier when the required protocol components and inputs match.

Every chain still maintains its own storage. Balances, allowances, total supply, administrative settings, and transaction history can differ until an authorized action changes them. The same address therefore does not prove synchronized state, identical runtime configuration, or completed cross-chain work. Contract code and relevant storage must be checked on each chain involved.

State changes across the fee route

Fee settlement is a separate lifecycle from token deployment and from any holder-facing transfer feature. The architecture routes collected fees across chains with LayerZero V2, then processes them for configurable burning and HLG staking rewards.

Originating record

The originating chain first records the fee balance and the transaction that begins routing it. That record can show that a local action succeeded, including any emitted event and router balance change. It does not establish that the destination contract received or processed the value.

Message delivery

LayerZero V2 carries the cross-chain message under the route’s configured security settings. Its Decentralized Verifier Networks participate in verification, while destination execution remains another state change. A successful source send proves dispatch. Delivery and execution require their own observable records.

Destination accounting

On Ethereum, destination processing can apply the configured split between burning and rewards. StakingRewards accounts for the reward side and supports automatic compounding in the described design. Completion requires the destination transaction and resulting contract state. A source event alone cannot prove that rewards were credited.

A transaction-state checklist

A reliable completion decision follows the records in their actual order and stops at the first missing state.

  1. Record the chain ID, initiating address, expected contract, required authorization, and live configuration before signing.
  2. Submit the intended call once, then preserve its transaction hash instead of relying on a temporary interface message.
  3. Confirm that the receipt succeeded and that the expected code, event, balance, or configuration change now exists.
  4. For cross-chain work, check the destination transaction and state independently after the source action becomes final.
  5. Retry only after identifying a revert, replacement, dropped transaction, or supported recovery path that permits another submission.

A live gas quote, route configuration, reward split, or pause setting overrides a stored assumption. Durable rules explain the lifecycle, while on-chain parameters determine whether the next action is presently available.

Reconciliation starts with the missing stage

Conflicting displays usually refer to different chains, block heights, or lifecycle stages. Reconciliation should compare the same transaction and contract state before treating the difference as a failure.

Pending or reverted

A pending transaction has no successful receipt yet and may later confirm, be replaced, or disappear from a node’s pending view. A reverted receipt means the intended contract changes did not persist, although the sender still spent gas. An interface timeout does not distinguish those conditions, so the transaction hash remains the useful starting record.

Source complete and destination absent

Cross-chain processing is asynchronous. A confirmed source action can precede verification or execution at the destination. Match the source event or message identifier with the destination record before resubmitting anything. Repeating an originating action is not a general recovery method and may create a second valid instruction where the contracts permit one.

Matching address and different balances

Different balances at the same address are expected when the chains have not received identical state changes. Confirm the chain ID, contract code, account, and balance independently. Then check the documented source and destination effects for the operation in use. An older burn-and-remint bridge flow should not be assumed for the newer fee-routing architecture.

Finality belongs to each chain

Finality must be judged separately for every transaction in a multi-chain path. A successful EVM receipt proves inclusion and execution in a particular block. It does not make every later reorganization impossible, nor does it confirm work on another chain. Confirmation policy depends on the chain and the application accepting the result.

A cross-chain route adds distinct checkpoints: source inclusion, source finality, message verification, destination execution, and destination finality. Their timing can change with network conditions and security configuration. A fixed completion time would hide those inputs. The durable test is whether each required state has appeared and reached the confirmation level used by the relevant application.

Finality belongs to each chain: A cross-chain route adds distinct checkpoints: source inclusion, source finality, message verification, destination execution, and destination finality. Their timing can change with network conditions and security configuration.; A fixed completion time would hide those inputs. The durable test is whether each required state has appeared and reached the confirmation level used by the relevant application.

View full-size image

Costs come from live transaction requirements

Deployment consumes gas on the chain where contract creation occurs. Cross-chain messaging can add verification and destination execution costs under the active LayerZero V2 configuration. These transaction costs are separate from protocol fees that FeeRouter later collects and distributes. A protocol fee balance does not describe the sender’s complete transaction cost.

Gas price, execution requirements, message size, and security configuration can change a quote. Read the estimate immediately before submission and retain enough native gas asset for the chosen chain. HLG reward accounting does not replace the native gas requirement. No static token or fiat amount can describe every deployment or message.

Exit and reversibility have different boundaries

Before broadcast, declining a signature leaves no on-chain state. A reverted transaction also leaves the intended state change unapplied, although its gas cost remains. Once a deployment succeeds, the interface cannot undo that transaction or erase its historical record. Administrative functions may pause, recover, or upgrade particular components only where the deployed contracts authorize those actions.

A dispatched cross-chain message should not be treated as wallet-cancellable. Recovery, retry, or pause behavior depends on the contracts and live route configuration. Staking exits have the same evidence requirement: read the deployed contract’s withdrawal conditions rather than inferring instant access from automatic compounding. An unavailable function, active pause, or unmet contract condition can change the exit path.

Version context changes what an old Holograph workflow means

Earlier Holograph V2 architecture covered omnichain ERC-20 and ERC-721 assets. Its bridge model burned an asset on the source chain, carried a message, and reminted the corresponding amount or token on the destination chain at the same contract address. That repository is no longer the maintained protocol codebase.

The newer architecture centers ERC-20 creation through Doppler, deterministic deployments, LayerZero V2 fee routing, and HLG staking. An older NFT or asset-bridge tutorial therefore does not establish that its workflow applies to a newer deployment. The answer changes when the contract version changes: identify the chain and deployed contracts, then match their callable functions and events before declaring completion or choosing an exit.

Quick answers about Holograph

Is HLG the same asset as every ERC-20 created through Holograph?

No. HLG is the protocol token used in the staking and reward design, while tokens created through Holograph have their own contracts, metadata, supply settings, and balances. A matching deployment address across chains does not turn a created token into HLG or combine their accounting.

Can a Holograph token exist without a holder-facing bridge?

Yes. Deterministic deployment and holder-facing bridging are separate capabilities. A token can be deployed at matching addresses without exposing a route that moves holder balances between chains. Transfer availability requires the applicable contracts, supported route, authorization model, messaging configuration, and destination execution path.

Does the newer Holograph design create NFTs?

The newer architecture describes ERC-20 creation as its principal token path. ERC-721 deployment and burn-message-remint bridging appear in the earlier V2 and SDK design. Those older materials do not confirm that the same NFT workflow is available through a newer deployment, so version and contract support must match.

Are HLG staking rewards fixed in advance?

No. The described system routes protocol fees through a configurable split between burning and HLG staking rewards. Available fees, the active split, contract state, and a participant’s position affect accounting. Automatic compounding describes how credited rewards are handled; it does not promise a fixed amount or rate.

How are tokens recovered after a transfer on the wrong chain?

There is no universal recovery action. If the recipient controls the same account on that chain, the tokens may remain accessible there. Transfers to contracts or unsupported destinations depend on the recipient contract’s code and authorized recovery functions. A matching Holograph contract address does not move the balance back automatically.