Holograph bridging in Protocol V2 moved Holographed tokens from authorization to destination confirmation

Source state, transfer path, and destination evidence

The transfer workflow connected two separate blockchain histories through a message and an executable destination request. It began with an eligible Holographed contract on the source chain. The submitted request identified the destination, the token contract, the transfer payload, and the resources intended for cross-chain delivery.

Protocol V2 then validated the contract against its registry and invoked the token standard’s bridge-out logic. That call produced the payload used by HolographOperator. The messaging module carried the packaged request toward the destination, where the operator system created a job for destination execution.

Each stage left different evidence. The source receipt recorded bridge-out. A messaging record showed that the payload entered the cross-chain path. The destination transaction recorded bridge-in, while the token contract exposed the resulting balance or ownership state. Only a successful destination transaction and the resulting token state established arrival.

Authorization sets the transfer boundary

Authorization defined what the source transaction could change and where the resulting request was directed. A wallet signature approved a particular transaction on a particular chain. Any token approval required by the implementation remained a separate permission. It did not send the asset or authorize an unspecified destination.

Before signing, the material inputs were the values encoded in the request:

• the source chain and Holographed contract;
• the selected destination chain;
• the token amount or NFT identifier;
• the intended destination recipient; and
• the native value and gas inputs for message delivery.

A mismatch in any field changed the request rather than merely changing its display. The sender therefore had to verify every field before bridge-out. Once the source transaction succeeded, editing a local interface or revoking a later approval could not rewrite that confirmed transaction.

Bridge-out commits the source-side change

Bridge-out was the source-chain commitment point in the V2 transfer model. HolographBridge checked whether the submitted contract qualified as Holographed, called its bridge-out function, validated the returned selector, and passed the resulting payload to HolographOperator. A failed call reverted instead of producing a valid outbound request.

Token standards preserve different state

The standard-specific contract determined what changed at the source. The shared bridge path did not make fungible balances and NFT ownership interchangeable.

Fungible balances

Protocol V2 described token movement as a source-chain burn followed by a destination-chain remint at the same contract address. The amount in the confirmed source event and payload therefore mattered to reconciliation. A wallet balance alone could hide the transaction that caused the change.

NFT identity

For an NFT, the relevant record combined the Holographed collection contract, token identifier, source ownership change, and destination ownership result. V2 documentation required the Holographed contract to exist across the participating chains so that the contract address and token identity could remain consistent.

The message links two chain-local histories

A cross-chain message carried the authorized transfer data between independently finalized networks. It was not the token itself, and delivery did not merge the chains’ storage. The archived bridge-out path passed its payload from HolographOperator to a configured LayerZero module for cross-chain delivery.

On the destination side, the messaging module handed the request to HolographOperator. The operator contract encoded a job and emitted an availability event. That event showed that destination work could proceed, but it did not show that bridge-in had executed successfully.

This distinction matters during a delay. A source transaction can succeed while the message, operator job, or destination transaction remains unfinished. Searching only the source account will not reveal which later stage is missing.

Destination execution creates the receiving state

Destination completion required an operator to execute the available job and the destination bridge to accept the inbound payload. The resulting transaction needed a successful receipt. The Holographed token contract then had to expose the balance or ownership state described by that payload.

An emitted job and a submitted destination transaction were intermediate records. A reverted destination call did not create a completed transfer, while a pending call had not yet established durable receiving state. The destination chain’s own finality conditions applied after execution.

The strongest completion evidence combined the destination transaction hash, successful receipt status, expected contract, intended recipient, and resulting token state. A block explorer label or interface notification could help locate those records, but neither replaced them.

Can the source receipt prove that the transfer finished?

No. A successful source receipt proved that bridge-out executed on the originating chain. It could not prove that the message arrived, that an operator executed the destination job, or that the receiving contract recorded the expected state.

Source proof

The source record established the initiating account, Holographed contract, destination selection, payload-related events, and transaction status. It also fixed the source-side state change. These details identified the request that later records needed to match.

View full-size image

Destination proof

The destination record established execution on the intended chain. Its receipt and logs identified the contract and recipient, while a state read confirmed the balance or ownership result. Matching the destination data back to the outbound request prevented an unrelated transaction from being mistaken for completion.

A bounded recovery path starts with the missing record

Recovery began by locating the first stage without valid evidence. This method separated an ordinary delivery delay from a failed or inconsistent destination execution.

Fees and timing remain live route conditions

The total cost depended on source execution, cross-chain messaging, and destination execution requirements. V2 requests included gas-related inputs, but the archived documentation did not establish one permanent fee or completion time for every route. Network demand and route configuration could change those values.

A quote therefore belonged to the exact request being prepared. It did not become a durable protocol constant. Timing followed the same rule: source confirmation, message delivery, operator execution, and destination finality each contributed a separate interval.

Version context limits operational conclusions

The burn-message-remint sequence described a specific Holograph architecture rather than an eternal interface contract. The Holograph Protocol V2 repository was archived in August 2025 and directs readers to the newer protocol monorepo.

The newer architecture documents deterministic ERC-20 deployment and LayerZero V2 cross-chain fee collection. Those features do not, by themselves, prove that every legacy V2 token route, operator path, contract address, or application screen remains available.

Old transaction records still retain their historical meaning. A V2 bridge-out receipt can identify what happened on its source chain, and a corresponding destination receipt can establish whether that transfer completed. Legacy instructions become unsafe when they are treated as evidence of present availability without checking the deployed contracts involved.

For a new request, first confirm a currently supported route, compatible contracts on both chains, and an executable destination path. If any condition remains unconfirmed, stop before authorization instead of relying on the archived workflow.