Layer A — Epoch 1 Drop (ERC-721 / 721A)

• Purpose: Mint only the Epoch 1 supply (1,000) with the current tiers.
• Include only what we need now:
  • maxEpochSupply = 1_000 (not 10,000)
  • Minting controls: Pausable, Ownable, role-based MINTER_ROLE
  • Optional ERC-2981 royalties (e.g., 5%)
  • Metadata flag (redeemed boolean) for the coaching utility (or point the flag to the registry—see Layer B)
  • BaseURI per pack/tier
• Do not add rentals (4907), token-bound accounts (6551), or bundle logic (1155) here.
• Why: keeps gas low, audit surface tiny, and avoids painting us into a corner.

Layer B — Budhihal Registry (thin, composable)

• Purpose: The source of truth across all epochs and standards.

• Stores:

  • Global maxSupply = 10,000 (sum across all future drops)

  • Mint accounting per contract (contract → count)

  • Redemption status for any token (contractAddress, tokenId → redeemed/when/where)

    (so even 1155/4907/6551 assets can mark a coaching hour as used)

  • Redemption window (2035–2050) and guards

• Exposes:

  markRedeemed(address tokenContract, uint256 tokenId),

  isRedeemed(tokenContract, tokenId),

  globalSupplyUsed(), remaining()

• Access control: only approved epoch contracts (and the Foundation) can mark redemption.

• Upgrade pattern: if you want flexibility, make the Registry UUPS-upgradeable; keep drop contracts non-upgradeable.

With this split, the epoch drop contracts stay dumb and safe; the Registry is the only piece you may ever need to evolve.

Why not a single 10,000-cap contract?

You could deploy one ERC-721 with maxSupply = 10_000 and mint by tranches per epoch. But:

• You’ll struggle to add ERC-1155 bundles, 4907 rentals, or 6551 diaries inside the same token standard cleanly.
• Your first audit scope balloons today for features you may never ship.
• Composability suffers: non-721 packs can’t live in that one contract anyway.

Net: a Registry + multiple epoch/pack contracts is cleaner, safer, and more future-proof.