The Codex

The game nobody starts

How The Summoning runs itself. Written by the builder. Every claim checkable on chain.

Contracts are forever. Games are not.

The best property Ethereum has is permanence. A contract deployed today will still execute, byte for byte, long after every server from this decade is landfill. Onchain games should inherit that: worlds that simply cannot be shut down.

They do not. Over 75% of the 2,817 web3 games launched between 2018 and 2023 are dead, by CoinGecko's count. The contracts are all still there, immortal and idle. What died was everything around them: the funding, the roadmap, and above all the humans the game needed to keep running, the admin key that starts the next round, the server that quietly became load-bearing. Permanence was the promise, and a human in the loop was the leak.

The Summoning is my attempt to actually collect on Ethereum's promise. Showing up is not my job. The game has no schedule, no start button, and no dev in the gameplay loop. It is live on mainnet right now, waiting, and it will keep working whether or not anyone shows up, including me.

The lifecycle: demand opens the game

Players mint $RITUAL on a bonding curve, then burn it in collective rituals to summon Old Ones. The interesting part is what happens when no ritual is active:

      idle (minting open, contract waiting)
        │
        ▼
 someone burns ≥ 1 $RITUAL ──► the SAME transaction
        │                      opens a 24h ritual
        ▼
 24h collective burn race toward the threshold
        │
        ▼
 permissionless resolveEpoch()  (anyone can call)
        │
        ├─ WIN:  threshold +150k, next Old One
        └─ LOSS: threshold ×0.75, same Old One
        │
        ▼
      back to idle … forever

There is no privileged opener. The first line of commitRitual() in the verified source:

function commitRitual(uint256 amount) external nonReentrant whenNotPaused {
    // Self-perpetuating auto-start: if no epoch has ever opened, or the
    // current one is already resolved, this sacrifice opens the next epoch
    // (threshold + Old One derived on-chain) before it is counted.
    if (currentEpochId == 0 || epochs[currentEpochId].resolved) {
        _openNextEpoch();
    }
    ...

The opening sacrifice is not a setup transaction. It counts as the first contribution of the epoch it creates. One person, one burn, and a 24 hour clock the whole world can watch is running.

Difficulty is on-chain policy

Nobody picks the next target either. The threshold for a successful summoning is computed by the contract from the previous outcome:

The asymmetry is deliberate. Wins ramp linearly, a fixed +150,000 each time, so a growing community faces a steadily rising wall rather than an exponential one. Losses decay geometrically to a floor of 25,000, so a summoning is always reachable. The two curves meet in the middle: the game finds the difficulty its community can actually sustain, with no one tuning it.

Failure is a mechanic, not an outage

If a ritual ends below threshold, the epoch fails honestly. Participants can still claim their glyphs, plus a failure memento (the Shattered Ritual). The threshold eases, the same Old One waits, and the next sacrifice starts the next attempt.

This is what lets the game idle gracefully. A small community can fail its way down from 75,000 to the 25,000 floor and then win, and every failed attempt along the way is a public, on-chain story beat rather than a dead project. Most games need momentum to survive. This one is built to wait.

Provable randomness, with a scar

Every 100 $RITUAL burned in an epoch earns one Eldritch Glyph, an ERC-1155 whose rarity tier is rolled by Chainlink VRF. One VRF request per claim returns up to 20 random words, one glyph each. Nobody, including me, can choose the outcome.

The 20 cap has a story. The original audit suggested 50. A testnet rehearsal ran the real callback and hit an out-of-gas inside Chainlink's 2.5M gas ceiling, a stuck batch and lost LINK. We measured, resized to 20 with a ~17% margin, and wrote the number down next to the scar it came from.

What the owner can still do

Verify-everything cuts both ways, so here is the honest scope. A 2-of-3 multisig owns the contracts. It can pause gameplay in an incident and it can withdraw the treasury, both visible on chain. What it cannot do is start a ritual on a schedule, pick a threshold, choose a glyph, or stop the resolution of an epoch already running. The loop needs no one, and resolution stays live even under pause.

A tiny keeper server usually calls resolveEpoch() at the bell, but the function is permissionless by design. If my server dies, anyone with gas money settles the round. The keeper key holds zero protocol authority.

Verify, don't trust

All five contracts are source-verified with full bytecode matches against the public repo. The security reviews are in the open too, including the internal audit that caught a loop-bricking bug in this exact mechanism before it shipped: github.com/clay-slpstrm/the-summoning (AUDIT.md, AUDIT-PHASE0.md; 246 tests, 10,000-run fuzzing, 100% branch coverage on the engine).

The Summoning is the first game built this way under The Veil Protocol. It will not be the last. The thesis of the whole studio fits in one line: things that live onchain should live forever, and games should be one of them. Make Ethereum Fun Again. No promises. Only rituals.