Smart contract architecture

TABLETS is deployed behind a UUPS proxy. Normal reads and writes target the proxy. The current implementation contains the protocol logic, while the proxy preserves contract state and address continuity across authorized upgrades until upgrades are irreversibly frozen.

The contract interacts with these principal components:

• CLAY token: the ERC-20 token escrowed to back submissions;
• TABLETS proxy: the canonical address for normal protocol calls;
• TABLETS implementation: the verified logic contract used through the proxy;
• Tablet NFT: the ERC-721 representation minted by TABLETS for a finalized day;
• burn address: the configured destination for the winning CLAY; and
• upgrade authority: the account or Safe authorized to upgrade or freeze upgrades while that authority remains active.

Contract state model

Auction

Represents one Tokyo-calendar day. It tracks timing, the leading submission and finalization state.

Submission

Represents one author’s content and CLAY-backed bid for an auction. Each author may submit once per auction. The author may increase only their own submission.

Record

Represents the finalized outcome for an auction: either the winning submitted content or the configured empty-day content.

Tablet

The numbered ERC-721 token minted for the finalized Record. A winning Tablet is minted to the winning submission’s original author. An empty Tablet is minted to the account that finalizes the empty auction.

Canonical data

Contract state and confirmed contract events are canonical. Offchain services may index them for convenience, but they do not alter auction state, determine eligibility, finalize an auction or establish transaction success.

An IPFS content identifier can identify external bytes, but the TABLETS contract does not guarantee that those bytes remain pinned or available through a gateway.