# W VIBE encrypted-record program

Version 0.3.0. Devnet only. Not audited for real-value use. Program address: `3tQdNmR9ArfHm2SELZR5iWHMFoytJComvzJ7UvKdRP7C`.

## Layout and authority

V1 uses 156 bytes, V2 212, V3 216. All share DLAB magic, version, claimed flag, issuer, owner, original finder, 44-byte authenticated ciphertext and legacy epoch. V2/V3 add type/core/cadence/phase, derived rank, policy/decoder versions, birth Clock timestamp, initial price and a 32-byte recipe digest. V3 adds access/reward/publication/difficulty at offsets 212–215. Type and the authenticated game version select the game profile.

V3 price policy is 2 and decoder version 3; V2 remains price policy 1/decoder 2. The V3 canonical recipe uses its own AES-GCM associated-data domain. Initialization requires the configured W VIBE issuer `3yh5HvdW6t6t1bR3THpFgQYKM7eqdGr4t5YTWbuh2w5J` on every format. The retained upgrade authority is unchanged.

## Instructions

| Opcode | Behavior |
|---|---|
| 0 | Initialize legacy V1, with platform issuer and record signatures |
| 1 | Claim an unclaimed record with issuer and claimant signatures; V3 requires a free reward and permitted access |
| 2 | Transfer with current owner's signature; retain original finder and birth rules |
| 3 | Increment legacy V1 counter; reject V2/V3 |
| 4 | Initialize V2 with its frozen birth formula |
| 5 | Read-only Clock quote for up to 20 V2/V3 records; each record uses its original formula |
| 7 | Initialize V3: 44-byte payload, four origin bytes, digest32 and four acquisition/difficulty bytes; derive birth terms |

V3 scores cadence `[90,68,45,23,0]` for minute/hour/day/month/year plus `core × 3`. Rank thresholds are 80/60/40. Initial test price uses tier base `[0,1000000,8000000,30000000] × (100 + core × 5)/100`. The existing four-state core profile governs scheduled prices. Full explanation: [Minting](../docs/MINTING.md).

Access is excluded/hunt/direct; reward is free/disabled offer/reveal/none; publication is hidden/after-claim/public; difficulty is 1–3. Invalid combinations are rejected. Paid/reveal/excluded records cannot use the free-claim instruction. Prices never grant claim rights. No paid settlement opcode or global issuance cap is implemented.

The program derives state from its Clock and immutable birth schedule; it does not need a periodic write. Month/year calculations preserve UTC anchors. Quote requests may use current Clock or a shared time at most 30 seconds old. The application authenticates the full recipe and performs type-specific rendering. Clue completion remains application authorization, not a claim that puzzles are bot-proof.

## Build, verification and compatibility

Use [Development](../docs/DEVELOPMENT.md) and the pinned Cargo lockfile/toolchain. The current artifact and source hashes are in `artifacts/manifest.json`; earlier artifacts retain technical provenance. Eight focused Rust tests cover issuer rejection, reward enforcement, legacy counter behavior, transfer authorization/finder preservation, rarity dominance, schedule boundaries and prices. Signed Devnet simulations verify deployed authorization without modifying accounts.

The active samples are newly issued V3 records with predecessor-address commitments; original V2 records are not mutated. Their birth formula, ciphertext and existing ownership remain valid. Reissuing a sample creates a new identity and birth clock; claims/transfers of an existing record do not.