Shipping a mint page you cannot redeploy at 3am

A mint page can be technically available and still be wrong: the wallet is on another network, the displayed price is stale, or the page points at a contract address that does not match the deployment. My pre-deploy check is about catching those mismatches before a transaction can take money.

The pre-deploy checklist: one address, checked chain, live price

I keep the contract address in exactly one place: the page’s configuration. The mint flow reads it from there; it does not duplicate the address in a component, a helper, and a deployment note. That makes address changes reviewable and prevents different parts of the page from quietly targeting different contracts.

Before every mint, I check the wallet’s chainId against the expected chain. A check on page load is not enough: the user can switch networks after loading the page. The check belongs immediately before sending the transaction.

I also read the mint price from the contract at runtime. I do not treat a price embedded in the page as authoritative. The page can display the chain value and pass that same value into the transaction, rather than trusting a cached label.

const address = config.contractAddress;

async function mint() {
  const { chainId } = await wallet.getNetwork();
  if (chainId !== expectedChainId) throw new Error("Wrong network");

  const price = await contract.mintPrice();
  await contract.mint({ value: price });
}

The checklist is simple: one configured address, a chain check at the point of action, and a price read from the contract.

What happens when the page and the contract disagree

The page is not allowed to resolve a disagreement by guessing. If the expected chain does not match the wallet, the mint stops before it sends a transaction. If the contract call fails, or the value needed for the mint cannot be read, the page stops there too.

That is the important guard: fail loudly, before taking the buyer’s money. A disabled button or a clear error is better than sending a transaction with a value the page assumed was correct. The contract remains the authority for whether a mint is valid; the page’s job is to make that boundary visible and avoid submitting a transaction when its own checks fail.

For a deploy, I verify the configured address and chain against the deployment, then exercise the mint path with those checks enabled. The test suite has about 473 tests, but that does not replace checking the actual page configuration and live contract reads for the release.

A rollback that needs no new deploy

A page can have a rollback switch without changing the contract. I keep a flag in the page that disables mint submission, then use a read-only contract call to decide whether the page should allow minting. Read-only calls do not send a transaction or take payment.

When the flag is off, the page does not expose a mint action. When it is on, the page still checks the chain and reads the current contract state and price before allowing a transaction. The flag is an operational brake, not a replacement for contract checks.

The useful rollback property is that the page can stop initiating transactions without waiting for a new contract deployment. That gives the operator a way to halt the interface while investigating a mismatch; it does not claim to reverse transactions already sent.

Takeaway

Before shipping a mint page, make the contract address singular, check the wallet’s chain immediately before every mint, read the price from the contract, and include a page-level switch that can stop new transactions. The collection page is at https://thunderous-sunflower-a910b4.netlify.app.