Holograph first-use checks confirm an ERC-20 deployment before configuration changes

Capture the intended deployment before signing

Before the first-use transaction leaves the wallet, preserve the intended chain, initiating account, factory address, deployment parameters, and predicted token address displayed by the launch path. If you calculate the address independently, also record the HolographDeployer address used for CREATE2. Retain the unsigned request or calldata when the software makes it available. Record public inputs only. A private key, recovery phrase, or raw signing secret never belongs in a deployment record.

This snapshot separates an intentional value from a default inserted by an interface, script, or environment file. It also fixes the version context for later comparisons. A predicted address belongs in the snapshot, although prediction alone does not establish that a contract was created. Readiness means the request is internally consistent, the signer is on the intended chain, and the account can cover the estimated execution cost.

Limit the first action to deployment

In the current architecture, Doppler Airlock supplies the authorized launch path into HolographFactory, and deterministic creation runs through HolographDeployer. End the first action after recording the deployment result. Do not combine a separate administrative update with the deployment unless the launch transaction explicitly includes that call.

A dry run or simulation can reveal a likely revert without creating an on-chain record. Broadcasting is a distinct action that produces a transaction hash and, after inclusion, a receipt. If the launch path bundles initialization with deployment, treat those initialized values as part of the original result. They should not be recorded as later configuration merely because an interface displays them on another screen.

Did the first transaction create the expected contract?

The first transaction created code at the expected address only when its receipt succeeded, the address returned or emitted by the deployment matched the precomputed address, and a read on the intended chain returned nonempty runtime bytecode there. Check the transaction hash against the same chain that the wallet used.

The normal path ends when the receipt reports success and a read at that address returns nonempty runtime code. A failed receipt ends the attempt before deployment. A successful receipt paired with an unexpected address or missing code is an unresolved result, even if the interface displays a completion message. The recovery boundary remains before configuration while the transaction input, logs, and chain selection are examined.

If no contract exists at the expected address, identify the failed condition before retrying. An incorrect chain or signer means the submitted transaction does not match the preserved request. A different CREATE2 deployer address, salt, or initialization code changes the predicted-address calculation. Repeating the request without finding that difference may reproduce the same failure or create a contract at another address.

Read the address as evidence, not as the whole result

Holograph uses CREATE2-based deployment to place compatible ERC-20 contracts at the same address across supported chains. CREATE2 derives an address from the deploying contract address, a salt, and the hash of the initialization code. The expected address is therefore a reproducible identity check when those inputs remain compatible. It is not a substitute for reading the chain where the transaction was submitted.

An address calculation can succeed before any bytecode occupies that address. Conversely, code found at the address proves that a contract exists, but it does not by itself establish the intended token state or authorization. Match four records: the prepared address, the transaction result, the address reported by deployment, and the address queried for code. Configuration should wait when any pair differs.

Compare the initial ERC-20 state with the signed request

Once code exists, read the ERC-20 values that the launch request was meant to establish. These may include the token name, symbol, decimals, total supply, and balances assigned during initialization, depending on the contract configuration. Compare raw on-chain values rather than a wallet label or cached interface view, since display software can retain stale metadata.

Any ownership, administrator, or role value exposed by the deployed contract also belongs in this comparison. The initiating account is not automatically the controller after every factory-based launch. An authorized launch path may assign control according to its initialization data. A mismatch at this stage is part of the original deployment investigation; changing the value immediately would erase the clean distinction between the initial result and a later correction.

Resolve authorization before preparing the second call

A configuration function matters only if the deployed contract exposes it and the intended caller has the required authority. Read the relevant owner, administrator, or role state when such controls exist. Also confirm that the proposed setting is mutable. Some deployment values can be fixed at initialization even when a nearby interface presents other editable fields.

Simulate the proposed call from the actual sending address against current state before asking for a signature. A successful simulation can identify a viable call path, but it does not create a receipt or reserve the observed state. An authorization failure, paused operation, invalid parameter, or missing function should return the process to diagnosis. It should not trigger a different configuration transaction chosen only because the first one reverted.

Stop at the earliest inconsistent record

Reconciliation starts with the first point where evidence diverges. A pending transaction has no final receipt yet. A failed receipt means that the deployment did not complete. A successful receipt with the wrong reported address redirects attention to the request inputs, while expected code paired with unexpected token state redirects attention to initialization and the contract being queried.

This order prevents a later transaction from masking the original fault. If code already occupies the calculated CREATE2 address, a fresh creation attempt cannot simply replace it. Determine whether that code came from the intended transaction and whether its readable state matches the request. If the transaction landed on another chain, its success there does not establish completion on the intended chain.

Put the reversible stop point before configuration

The first-use state is easiest to reason about while no follow-up call has changed it. At that point, declining to sign another transaction leaves the deployment unchanged and preserves a clean comparison target. The deployment itself may be irreversible once confirmed, but the operational decision to continue remains reversible until a new state-changing call is authorized.

View full-size image

A proposed correction deserves its own request record, simulation, and expected outcome. That separation makes the next receipt attributable to one intended change. It also prevents an interface retry from being mistaken for a configuration update. If no authorized function can correct the initial deployment, stop rather than record a different contract or address as the original result.

Refresh time-sensitive evidence before continuing

Transaction inclusion and practical finality are different states, and their timing depends on the selected chain. Use the confirmation policy appropriate to that chain and the risk of the next action rather than inventing a universal waiting period. If time passes between deployment and configuration, fetch a fresh receipt, code result, and relevant state at a recent block.

An RPC endpoint can lag, return cached data, or point to an unintended network. Bind every read to a chain identifier and retain the observed block reference. When two endpoints disagree, postpone the second transaction until the discrepancy is resolved. A current read is especially important when roles, pause state, or other mutable controls could have changed since the original receipt was captured.

Confirm deployment and configuration readiness

Proceed only when a current on-chain record and the preserved deployment request support every condition below.

• The wallet and receipt identify the intended chain and initiating account.
• The receipt reports success, and its block meets the chosen confirmation policy.
• The reported contract address matches the predicted address and contains runtime code.
• The exposed ERC-20 values agree with the initialization request.
• A simulation of the exact proposed function succeeds from the intended caller against the current state.

One unresolved item is a stop condition, not a minor exception. Keep the failed check beside its chain, block reference, and transaction hash, then investigate that boundary. Do not replace a missing fact with an interface status label or an address copied from another network.

Preserve the first-use record for later reconciliation

A durable record should retain the chain identifier, transaction hash, receipt status, block reference, predicted address, deployed address, public request inputs, and the initial read results. Capturing the runtime bytecode or its hash adds another comparison point. Keep secrets outside this record, and avoid storing wallet credentials beside public deployment artifacts.

Later configuration receipts can then be compared with a known starting state. If a future read differs, the transaction history shows whether an authorized call produced the change or whether the query used another chain or address. This preserved baseline is more reliable than reconstructing the original deployment from an interface after several updates have already altered the contract state.