Transparency

Check the live contract surface and public artifacts.

Use this page to verify what is live right now, how the mint flow is structured, and where to inspect the public artifacts yourself.

This is not a promise of safety. It is a map of what you can inspect for yourself before and after minting.

Current Live Surface

What is live right now

Start here if you want to confirm the current network, launch stage, and contract address before looking at the mint flow itself.

Published contract surface

Network: Mainnet
Launch state: Canary
Site surface: Public teaser
Contract status: Mainnet canary contract configured
Contract: cb3022bb9ee4752d778f4c63b47559e77b4ca06a122a
Contract verification status: Check the explorer contract page and the published repository artifacts together.

How This Mint Works

How the approvals and delivery fit together

This page should still make sense on its own, so the mint flow is described here as first approval, second approval, and finalize rather than only as QR labels.

First approval: bind one wallet

The first CorePass approval is a wallet-binding signature for the current mint session.
It proves control of one wallet for that session.
It is not a token transfer.
No mint transaction is sent yet at this stage.

Second approval: send the mint call

The second CorePass approval is the mint contract call.
The to address should match the published CoreCats contract.
The value field should be 0.
Gas is still required even when no native token amount is sent to the contract.

Finalize: random assignment and revealed delivery

Mint delivery is not complete at commit. After the mint call, a separate finalize step completes the random assignment and delivers the NFT.

The published randomness path uses commit, a future block, and on-chain finalize rather than a one-step reveal.
This design can be replay-checked from public chain data without adding a separate VRF or oracle dependency.
This is why mint completion can take longer than a single block even on a fast chain.
When finalize completes, the cat arrives already revealed for that mint rather than waiting for a later collection-wide reveal.

How To Verify

How to verify it yourself

If you want the practical checks rather than the architecture, start with the checklist and then use the listed surfaces to inspect the details.

Quick verification checklist

Check the current contract address on this page before minting.
In CorePass, confirm the first approval is a signature and the second approval is a contract call.
For the mint call, confirm to matches the published contract and value is 0.
After submission, inspect the transaction result in Blockindex.
Compare explorer details and repository artifacts when you want deeper assurance.

Where each check lives

Inside CorePass: approval type, destination address, value field, and the long 0x... calldata.
Inside Blockindex: contract page, submitted transaction fields, execution result, and verified source / ABI if available.
Inside GitHub: contract logic, randomness documentation, trust-surface notes, and release runbooks.
About the long 0x field: it is encoded calldata. It is not meant to be human-readable directly, but it can still be compared against the published ABI and explorer transaction details.

References

Where to inspect more

If you want to go deeper than the quick checks above, use these public links and repository documents.