[ ETERNAL BEINGS / CONTRACT CALL GUIDE ]● HUMAN-READABLE FUNCTION MAP
00 / Overview

## The interface is a contract-call guide with buttons

The official instance does three things: it reads public chain state, calculates the next valid player step, and prepares the exact write transaction for the wallet to review.

### Reads

Read calls do not cost gas and do not require signing. They show epoch, phase, ownership, token metadata, and gameplay state.

### Writes

Write calls change contract state. They require wallet confirmation and gas. Mint, Claim, Transfer, Hunt, Devour, and Fusion are writes.

### Irreversible actions

Devour permanently locks external NFTs. Fusion burns the sacrifice Being. Transfers move NFTs. These actions must be checked slowly.

READ STATE→CHECK CONDITIONS→PREPARE CALL→WALLET CONFIRMATION→VERIFY RECEIPT
01 / Read State

## Before any button is enabled, the page reads the contract

Read function | Purpose | Used for
--- | --- | ---
`currentEpoch()`, `epochStart(epoch)` | Find the current epoch and the epoch start block. | Commit / Reveal / Claim timing.
`EPOCH_BLOCKS()`, `COMMIT_BLOCKS()`, `MINTS_PER_EPOCH()`, `MAX_BEINGS()` | Read production constants from the deployed contract. | Countdown, release cap, and fairness display.
`releasedMintCap(epoch)`, `revealedCount(epoch)`, `epochClaimLimit(epoch)`, `epochClaimedCount(epoch)` | Show how many slots are released, revealed, selectable, and claimed. | Live epoch status and draw history.
`commitments(epoch,wallet)`, `revealed(epoch,wallet)`, `claimedEpoch(epoch,wallet)`, `hasMintedBeing(wallet)` | Check a wallet's Mint path state. | Enable the correct Mint button.
`balanceOf(wallet)`, `ownerOf(tokenId)`, `getBeing(tokenId)`, `tokenURI(tokenId)` | Find owned Beings and render their current on-chain state. | Player dashboard, selected Being card, and transfer panel.
`hunts(tokenId)`, `cooldownUntil(tokenId)` | Check whether a Being is hunting or cooling down. | Hunt, Devour, Fusion, and Transfer safety checks.

02 / Mint

## Fair Mint uses Commit → Reveal → Claim

COMMIT Hide the Secret during the entry window

The official page asks the connected wallet for a free deterministic signature scoped to the network, Game, wallet, and epoch. It hashes that signature into the Secret, calculates the Commitment, and asks the wallet to call:

commitMint(bytes32 commitment)

The Secret is not sent during Commit. The Commitment is bound to the exact caller and epoch.

### Steps

1. Read `currentEpoch()` and the block-based phase.
2. Confirm the wallet has not already Minted.
3. Sign the scoped off-chain message.
4. Derive and locally cache the Secret.
5. Submit `commitMint(commitment)`.

REVEAL Prove the entry before the epoch closes

During Reveal, the same wallet reconstructs or loads the exact Secret and sends it to the contract:

revealMint(uint256 epoch, bytes32 secret)

The page recomputes the Commitment and refuses to submit if it differs from the on-chain value.

### Steps

1. Check `commitments(epoch,wallet)` exists.
2. Check `revealed(epoch,wallet)` is false.
3. Reconstruct and verify the exact Secret.
4. Submit `revealMint(epoch, secret)`.
5. Wait until the epoch is complete.

CLAIM Claim if the draw selected the wallet

After an epoch closes, an eligible revealer can ask the contract to check selection and mint the Being:

claimMint(uint256 epoch)

If the epoch was oversubscribed and the wallet was not selected, no Being is minted for that epoch.

### Steps

1. Check the completed epoch.
2. Read `revealed(epoch,wallet)`.
3. Read `claimedEpoch(epoch,wallet)`.
4. Simulate and submit `claimMint(epoch)`.
5. Verify `BeingMinted` and `Transfer` events.

Calling the contract outside the official page is a different Secret-management path. Direct callers must preserve their own random Secret and use the same address for Commit, Reveal, and Claim. Open the complete visual Direct Contract Mint guide →
03 / Player NFT View

## After Claim, the page displays owned Beings

The dashboard lists every Being owned by the connected wallet, then lets the player select one to inspect. The page verifies ownership through `ownerOf(tokenId)` before showing actions.

Function | What it shows
--- | ---
`balanceOf(wallet)` | How many Beings the wallet owns.
`ownerOf(tokenId)` | Current owner of a specific Being.
`getBeing(tokenId)` | Stage, power, skill, mass, complexity, scars, devours, fusions, premium devours, mark luck, and genome state.
`tokenURI(tokenId)` | On-chain metadata and image projection for the selected Being.
`hunts(tokenId)` | Whether the Being is currently locked in a Hunt.

04 / Transfer

## Send a selected Being to another wallet

NFT TRANSFER Moves ownership of the selected Being

The transfer box prepares the ERC-721 transfer call:

safeTransferFrom(address from, address to, uint256 tokenId)

The website checks that the connected wallet owns the selected Being before preparing the transaction.

### Steps

1. Select a Being from the owned list.
2. Enter the recipient address.
3. Check `ownerOf(tokenId)` equals the connected wallet.
4. Check the Being is not in an active Hunt.
5. Confirm the transfer in the wallet.
6. Refresh ownership after receipt.

Transfer is a real asset move. If the recipient address is wrong, the website cannot recover the NFT.
05 / Hunt

## Hunt is a repeatable gameplay loop

ENTER HUNT Lock the Being into a Hunt state

Starts a Hunt for a selected Being:

enterHunt(uint256 tokenId)

The Being is held by the game during the Hunt and cannot be transferred or used in other incompatible actions until resolved.

### Before entering

1. Verify connected wallet owns the Being.
2. Check `hunts(tokenId)` is empty.
3. Check cooldown through `cooldownUntil(tokenId)`.
4. Confirm gas and call `enterHunt`.

RESOLVE HUNT Return the Being and settle rewards or scars

Finishes an active Hunt:

resolveHunt(uint256 tokenId)

Resolution may update ORE, Power, Skill, scars, cooldown, or other Being state according to the contract rules.

### Before resolving

1. Read `hunts(tokenId)`.
2. Confirm the Hunt has reached its minimum resolution block.
3. Estimate gas.
4. Submit `resolveHunt`.
5. Refresh `getBeing`, `tokenURI`, and ORE state.

06 / Devour NFT

## Devour permanently locks an external NFT

UNKNOWN ERC-721 DEVOUR Observation first, then exact NFT approval

For eligible ERC-721 collections outside the curated Top-100 list:

observeExternal(address nft, uint256 externalTokenId) devourExternal(uint256 beingId, address nft, uint256 externalTokenId)

The observation step records collection code and supply conditions before the final lock.

### Steps

1. Own the Being and the external NFT.
2. Call `observeExternal`.
3. Wait `UNKNOWN_HOLD_BLOCKS`.
4. Approve the exact NFT to the game contract.
5. Call `devourExternal`.
6. Verify the NFT is locked and the Being state updated.

TOP-100 DEVOUR Curated collection with tier proof

For collections in the curated Top-100 list:

verifyCollectionTier(address nft, uint8 tier, bytes32[] proof) devourTieredExternal(uint256 beingId, address nft, uint256 externalTokenId, uint8 tier, bytes32[] proof)

The tier proof decides the nutrition and complexity gain. The NFT is still permanently locked.

### Steps

1. Find the collection in Devour Tiers.
2. Obtain the tier and Merkle proof.
3. Verify the proof against the deployed root.
4. Approve the exact NFT.
5. Call `devourTieredExternal`.
6. Refresh the selected Being.

Devour has no withdrawal, rescue, or undo path. It should always show a final irreversible-action confirmation before signing.
07 / CryptoPunk Devour

## Native CryptoPunks use a separate path

CRYPTOPUNK DEVOUR Observation, transfer, then consume

Native CryptoPunks are not standard ERC-721 approvals, so the contract uses dedicated functions:

observeCryptoPunk(address punkContract, uint256 punkId, uint8 tier, bytes32[] proof) devourCryptoPunk(uint256 beingId, address punkContract, uint256 punkId)

The Punk must be transferred to the game contract after observation and before the observation expires.

### Steps

1. Own the Punk and the target Being.
2. Verify the Punk collection proof.
3. Call `observeCryptoPunk`.
4. Transfer the Punk to the game contract using the Punk contract.
5. Call `devourCryptoPunk`.
6. Verify permanent lock and Being evolution.

Do not use the ERC-721 approval flow for native CryptoPunks. Follow the Punk-specific flow exactly.
08 / Fusion

## Fusion burns one Being to strengthen another

FUSE BEING Parent survives, sacrifice burns

Fusion combines two owned Beings:

fuseBeing(uint256 parentId, uint256 sacrificeId)

The parent remains. The sacrifice is burned forever. The parent absorbs state and may mutate according to the contract rules.

### Steps

1. Own both parent and sacrifice Beings.
2. Check neither Being is hunting.
3. Check cooldown and eligibility.
4. Choose the parent carefully.
5. Confirm the permanent burn of the sacrifice.
6. Call `fuseBeing` and refresh the parent.

Fusion is irreversible because the sacrifice Being is burned. The page or agent must show the exact parent and sacrifice token IDs before signing.
09 / ORE

## ORE is the resource token emitted by gameplay

ORE state is read to show economy status and gameplay results. It is not custody by the website.

Function | Purpose
--- | ---
`ore()` | Find the ORE token contract associated with the game.
`totalEmitted()` | Show total ORE emitted by gameplay.
`emittedCap()` | Show the emission cap.
`availableEmission()` | Show remaining emission available under the cap.
`nutritionForTier(tier)` | Preview nutrition and complexity gain for curated Devour tiers.

10 / Safety Checklist

## What must be checked before signing

### Network

- Chain ID matches the official manifest.
- Contract address matches the official instance.
- Explorer source and bytecode are verified.

### Ownership

- Wallet owns the selected Being.
- Wallet owns any external NFT being devoured.
- Recipient address is correct before transfer.

### Irreversible effects

- Devour locks external NFT forever.
- Fusion burns sacrifice Being forever.
- Transfer moves the NFT to another wallet.

Never sign from a pasted private key in chat. Use an injected wallet, hardware wallet, multisig, or a local encrypted signer only when explicitly authorized. The official website never needs to know the private key.
OPEN TRANSPARENCY SECTION →