Core CatsFull On-Chain Pixel Cats

Transparency

Check the live contract surface and public artifacts.

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

This is not a promise of safety. It is a map of what can be inspected directly in the contract, explorer, and repository.

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.

Official CCAT Posture

What the released contract is meant to guarantee

These are the intended principles for the official `CCAT` contract. Compare them with the current live surface above and the linked public artifacts rather than trusting the website alone.

Intended on-chain guarantees

  • Minted cats should not change after mint: image, name, description, and attributes are meant to stay fixed.
  • The official release target is deploy-time immutability rather than a later admin lock.
  • The intended on-chain rule is `1000` total cats and `3` cats per wallet.
  • The intended official mint policy is permissionless rather than allowlist or signer gated.
  • The intended official contract posture is no retained owner/admin path after deploy.

Verification boundary

  • `Fully on-chain` is meant to describe the NFT object and mint rule, not the web UI itself.
  • The mint website, collection browser, and callback UX are convenience layers, not the NFT.
  • `3 per wallet` is the stated rule; Core Cats does not claim to enforce `3 per human` under the current architecture.
  • Public promises should stay limited to what the chain, source, and published evidence can actually prove.

How Minting Worked

How the approvals and delivery fit together

The public mint is complete, but the structure of the historical mint flow still matters for verification. It is summarized here as first approval, second approval, and finalize rather than only as QR labels.

First approval: bind one wallet

  • The first CorePass approval binds one wallet to the current mint session.
  • Depending on the live flow, this can appear as a login or wallet-binding confirmation in CorePass.
  • 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 published contract, historical mint transactions, and repository artifacts.

Quick verification checklist

  1. Check the current contract address on this page against the explorer and repository references.
  2. When reviewing historical mint transactions, confirm the first approval only binds one wallet and does not move tokens.
  3. For historical mint calls, confirm to matches the published contract and value is 0.
  4. Treat `approve`, `setApprovalForAll`, or unrelated token transfers as outside the published Core Cats mint flow.
  5. Inspect transaction results in Blockindex when checking historical mint or ownership activity.
  6. Compare explorer details, trust notes, 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.

What this page does not prove for you

  • This page combines the live contract surface with repository notes. The explorer entries and published artifacts remain the primary verification surface.
  • The top-level CoreCats contract file is not the whole review surface; imported dependency contracts also matter.
  • The active contract build path uses the Core-specific Ylem / Foxar / Spark toolchain, not a generic Ethereum-only path.
  • Historical rehearsal contracts, notes, and canary records remain public evidence, but they are not the canonical `CCAT` collection.
  • If explorer verification is missing or incomplete, rely on the published verify packet or equivalent reproducibility evidence before treating the deployment as fully inspectable.

References

Where to inspect more

Use these links to inspect the public project surface, the explorer entry points, and the repository references for renderer logic, data tables, manifests, and historical rehearsal evidence.