Protocol Verification

Dateverse rules, contract facts, and read-model boundaries.

This page is a factual reference for verifying what Dateverse does before connecting a wallet or minting a calendar date.

Verified Contract

Genesis Range & Supply

  • First date 1950-01-01
  • Last date 2049-12-31
  • Calendar system Gregorian calendar
  • Total supply math 100 calendar years = 36,525 dates

Token ID Mapping

Each token ID is the canonical calendar date encoded as YYYYMMDD. The mapping is deterministic and does not depend on metadata servers.

  • Example date 1969-07-20
  • Token ID 19690720
  • Uniqueness rule one date, one token

Public Mint Pricing Curve

Public mint pricing is based on the number of public mints. Reserve mints do not advance the public pricing curve.

Public mint count Mint price
1-1,0000.005 ETH
1,001-5,0000.01 ETH
5,001-15,0000.02 ETH
15,001-30,0000.03 ETH
30,001-35,0640.05 ETH

Reserve Mints

Reserve mints are separate from public mints. They assign specific dates without incrementing the public mint counter used by the pricing curve.

  • Affects public price No
  • Can duplicate dates No

What Dateverse Is Not

  • Royalties No protocol royalty mechanism
  • Staking or rewards None
  • Tokenomics expansion No expanded supply
  • Social/content hosting Not part of the protocol

Decentralization & Verification

The smart contract on Base Mainnet is the absolute, final source of truth for Dateverse ownership, rules, and history. Ownership records are fully public and permanent, meaning anyone can verify, query, or build alternative indexing tools independently.

  • Final authority Base smart contract state and transaction log
  • Access protocol Direct EVM smart contract reads & JSON-RPC queries
  • Front-end independence Web applications consume static, verifiable public snapshots for speed, but all ownership resides on-chain
  • Client freedom No proprietary APIs; anyone can query the public blockchain ledger directly
Wallet connection is not required to browse the registry. It is only required for actions such as minting, transferring, or customizing a date. A Dateverse public mint should call the verified contract on Base for a specific tokenId; it should not request unrelated token approvals.