# The Chase — playable discovery and reward contract

Updated: 2026-09-06. A working Devnet game is implemented at `/chase`. It uses newly issued V3 records and temporary image adapters. Production assets, economics and difficulty remain open. [Asset and minting contract](ASSET-SYSTEM.md).

**Product direction:** this page describes implemented test code. The user has rejected generic puzzle gates as the product discovery mechanic. Discuss discovery separately for each asset; clues must correspond to meaningful asset facts. Watches' first-pass direction is no Discovery. No connected virtual world is planned. The [asset workshop](ASSET-SYSTEM.md) governs the next design pass; proposed games are not implementation decisions.

## What finding means

A find is completion of a trail's three validated locks. It establishes eligibility for that trail's assigned reward, not automatic ownership and not a reservation. The reward is disclosed before play. Price, rarity, hunt access and reward entitlement are separate fields.

| Reward/access | What a successful find grants | Current implementation |
|---|---|---|
| Free ownership claim | Eligibility to claim an available designated prize, regardless of its reference price | Playable; zero purchase charge; W VIBE sponsors the Devnet fee; claimant signs |
| Purchase offer | Permission to buy under specified price/discount and expiry terms | Policy category exists but is disabled; no offer, payment or free claim is issued |
| Reveal only | A scoped preview of the asset's captured Look | Playable; no ownership, wallet or payment; stays out of public feeds |
| Outside hunt inventory | No trail or claim entitlement | Excluded server-side; can support future purchase-only/spotlight assets |

Rarity does not automatically make something huntable or exclude it. Evolution is the primary rarity factor; the issuer separately chooses acquisition access. Exceptionally rare items may be purchase-only, or explicitly allocated as rare hunt prizes. Neither the final allocation nor its odds are selected. The pilot does not promise rare outcomes or financial value.

The active policy reads authenticated V3 mint terms through `lib/chase-policy.mjs`. Five unclaimed hidden prizes remain available across all three types; the refreshed counterpart of the previously claimed sample is already owned. One hidden Scene supports reveal-only play, two offer examples are disabled, and other inventory is excluded from these hunts. V3's program record commits access/reward/publication/difficulty and rejects unauthorized free claims. The original V2 catalog is archived; its immutable records and actual claim receipt remain intact.

For new production issuance, commit access, reward type, reveal rights and pricing policy with the canonical recipe. Authored terms must say whether an offer uses a fixed amount or a discount against a named price source, its evaluation time, expiry and minimum price, and whether discovery credit differs from ownership. Computed rarity/price never silently supplies missing reward rights. An incomplete paid policy fails closed. No real-money or discounted settlement ships in this iteration.

## Asset-selected games

The authored asset type selects its versioned game profile at minting. Visitors can choose a profile or request a surprise free-claim trail.

| Type / game | First lock | Second lock | Final lock |
|---|---|---|---|
| Artifact / Rebuild | Assemble three connected fragments | Match directional connectors | Predict the next Look |
| Entity / Resonate | Inspect the symbol/pulse signal | Reproduce its ordered rhythm | Predict the next Look |
| Scene / Pathfinder | Trace a four-move route through a blocked grid | Assemble connected fragments | Predict the next Look |

Difficulty is authored and validated as 1–3. It changes rhythm length and connector choices; it does not change rarity or reward. Route and fragment lengths are fixed in this starting version. Hints, undo and retries are available. The Scene reveal-only trail grants a captured Look without ownership.

The arrangement is derived from an authenticated asset identity and a session nonce. This changes the puzzle, not asset rarity. The Look index is captured from the deployed program's quote when play starts. A live evolution boundary does not change the answer halfway through. The asset continues its normal issuance-anchored schedule. Long-cadence assets can be played without waiting for a real Shift.

Hints and retries do not affect the reward or price. A trail lasts twenty minutes, a prototype setting. Progress is saved in the current browser. There is no daily streak, leaderboard, competition prize budget, real-world location requirement or claim of bot resistance. The three-lock design is a first mechanic for review, not the final game.

## Claim and reveal

Playing needs no wallet. On a completed free-claim trail, the visitor chooses **Claim free & reveal publicly**, connects Phantom and approves the exact claim. The server has co-signed only that designated reward for that wallet. It sponsors the Devnet network fee. Wallet connection by itself does not sign.

The first eligible transaction to confirm wins. There is no hold or reservation. A signed transaction still needs a successful confirmation before the UI says ownership was awarded. The Solana program records the first claimant/finder and owner; birth, traits and evolution remain unchanged. Sharing a solved guest trail is possible; this prototype does not prove a unique human solved it independently.

After claiming, the configured prize and public wallet address can appear on The Flex. A Chase Moment additionally requires a confirmed transaction containing the correct claim instruction and game memo, with the expected issuer/claimant signatures. Controlled fixture claims are labelled separately. Transferring later does not erase first-claim publication. History lookup covers the most recent twenty record transactions; unavailable/older receipts omit the Moment and flag incomplete history rather than inventing an event.

The reveal-only path shows its captured appearance only to the holder of the completed trail. It does not make the record public, set an owner, or enable a claim. A preview can of course be shared by someone who sees it; this is not DRM.

My Stash remains a balance/connection panel, not a full owned-inventory dashboard. These are custom program records, not standard NFTs displayed automatically in a wallet's collectible tab. Mobile claiming currently requires Phantom's in-app browser. Progress stays in the browser where it was created; switching from Safari starts another trail. The implementation uses the injected Phantom provider’s transaction signing, with server-controlled Devnet submission; [Phantom transaction documentation](https://docs.phantom.com/solana/sending-a-transaction) describes this provider flow. An actual Phantom approval/signature interaction has not been browser-tested here.

## API and trust boundary

`POST /api/vibe/chase` accepts JSON (maximum 8 KiB), checks same-origin browser requests and sends `Cache-Control: no-store`.

| Action | Result |
|---|---|
| `start` | Verify Devnet and candidate availability; authenticate a record; capture its program-evaluated Look; return the first puzzle and opaque ticket |
| `resume` | Revalidate the ticket, generation, record identity/birth and decoding; return that saved step |
| `answer` | Validate the exact step answer on the server; wrong answers retain the step; correct answers issue the next ticket |
| `prepare` | Require all locks and a free-claim policy; verify unclaimed state; bind to the claimant wallet; return an issuer-co-signed transaction and protected receipt |
| `submit` | Match the exact authorized message and issuer signature; verify required Ed25519 signatures; broadcast only that transaction to verified Devnet |
| `status` | Resolve the existing signature and original claimant; distinguish pending, confirmed, failed, expired and unavailable |

Tickets are AES-GCM sealed using a domain-separated HKDF key derived from the server decoder secret. They bind policy/version, generation, target, recipe digest, birth time, nonce, captured Look, step and expiry. Private identities and answer fields are omitted from incomplete game responses. Client progress alone cannot award a claim.

Claim receipts bind message hash, wallet, expected signature and last-valid block height. The browser saves the receipt before asking the wallet to sign, and saves signed bytes before submission. A retry resends the same transaction. Status receipts last seven days independently of the shorter play window; on-chain blockhash validity still governs submission. The program's existing issuer-plus-claimant instruction enforces one first claim. Program v0.3.0 was recompiled to enforce mint authority and immutable reward inputs. Puzzle validation remains application logic; no on-chain puzzle verifier or reservation is implied.

The public disposable lab only parses legacy 156-byte records; it cannot route these 216-byte hunt records through its legacy claim/transfer helper. Production secret recipe storage, authority governance, abuse resistance and paid settlement require a separate design before launch.

## Storage, failures and recovery

No D1, distributed snapshot cache or authoritative database progress was added. Sealed tickets carry progress; Solana owns availability and ownership. Browser storage is a convenience, not a reservation system. Source-held policy changes require a new version and invalidate old game tickets.

A transient verification error retains progress. A missing record returns recovery-required, not a claim that all Devnet reset. A changed generation, digest or birth invalidates the old trail; it never silently substitutes a different prize. Administrative recovery remains explicit. Restoring fixtures does not restore arbitrary player claims. Already-prepared receipts retain their specific transaction identity so an uncertain submission can be checked before another is prepared.

## Verification and remaining decisions

[Status](STATUS.md) lists current evidence. A real wallet-signed claim through the published site was confirmed for an original sample, with owner/finder and a public Moment verified. That record remains intact; its V3 counterpart keeps the same owner. The V3 suite separately authenticates all reissued records and simulates signed free/offer/reveal claims and outsider mint rejection. The hosted game check covers Rebuild, Resonate, Pathfinder and reveal-only play using actual RPC and public clues. It also verifies issuer-only preparation and refusal of an unsigned claim, without broadcasting extra claims.

Phantom's approval UI has not been automated. Use published HTTP/API verification; the user explicitly ruled out the internal preview browser. The next task is brainstorming actual assets and types, which may refine these mechanics, minting factors and renderers. Production reward allocation, discounts, reservation rules, Stash rights, wallet onboarding and abuse controls remain open. Buying a mystery Stash bypasses individual hunts conceptually; current hunt prizes remain outside Stash memberships.