Assets, issuance, evolution and decoding

Updated: 2026-09-06. The current implementation is a starting point; actual assets are the next discussion.

Confirmed foundation

Evolution is the main rarity factor. The V3 baseline also has a smaller authored behavior factor. W VIBE authors the inputs; deterministic minting validates them and the program derives rarity and initial test price. The exact formula, field ownership, encoding, sample distribution and limits are in Minting. Asset choices may change this program, the minting factors, decoding adapters and games.

W VIBE-only issuance is enforced in the program. Owners cannot change birth traits or schedules after issuance. Both owned and unclaimed assets continue shifting. The initial active batch has been refreshed through new V3 issuance, with predecessor commitments; old immutable records retain their original meaning.

A future complexity factor should measure meaningful structure or supported behavior for the selected asset. Encryption size, padding, randomness or inefficient computation are not rarity measures. The current authored core profile is provisional and is not represented as measured complexity.

Asset workshop: first-pass discussions

Discuss each asset briefly, record its appeal and unresolved choices, then revisit the set before specifying or implementing changes. Current brainstorming is not authorization to implement proposed assets, schemas, games or program changes.

Product boundaries

The audience wants recognizable ownership worth flexing. Wealthy creators may buy premium collections; less wealthy participants need worthwhile assets to discover. Acquisition is decided per asset: discovery is not compulsory for every category.

No connected virtual world or real-world geographic mirror is being designed. A mansion can stand alone without coordinates. A neighborhood or fictional city may group assets without implying world navigation. Collections can contain unrelated assets; their premium price comes from the disclosed rare contents, not a world label. The first-pass purchase direction is clear contents and fixed prices, not unexplained random mystery boxes. Collection naming remains open.

An ownable asset containing other assets is a separate concept from a commercial bundle. Parent/child ownership, membership and transfer rules are unresolved and are not implemented by the current flat Stash catalog. Do not assume every asset has a location or parent.

Artwork is outside the current asset-category direction, although visual quality remains essential. Cats are a specific category, not a general creatures category. Cars and watches must use original, unbranded designs; authorized sponsored assets are a possible future route.

Watches — first pass complete

Acquisition: working direction is no Discovery for watches. Likely premium purchase/collection assets; purchase structure and prices are not settled. This is provisional and can be revisited after the first round across categories.
Appeal: original design, precision, visible working mechanisms, interactivity and meaningful evolution. The code can define much of the asset, with artwork supporting its presentation.
Mechanism: component relationships and actual behavior may supply meaningful secondary rarity factors. Evolution remains primary. No specific component model, formula or degree of simulation is selected.
Evolution: one-second changes are an interesting possibility, not an approved cadence. Ordinary operation versus true evolution, what changes, and how much is rendered/calculated in code remain open. The current program supports minute/hour/day/month/year only.
Presentation: cases and opening a case are interesting options. A display-case collection and the watch's own enclosure need separate consideration. Neither a case interface nor a case-based hunt is selected.
Discovery: do not develop the suggested hidden-desk hunt or mechanism-reconstruction puzzle. A collection of cases with asset-derived clues was raised, but does not establish a viable watch hunt. Do not substitute random case opening for discovery.
Sponsorship: original watches first; future authorized brand-sponsored editions are an option. Do not use existing watch brands as the identity of unsponsored assets.
Next pass: decide the actual product behavior, presentation, evolution, meaningful rarity factors and acquisition model together; only then derive mint fields, decoder/render behavior and program requirements.

Cats — first pass complete

Selected first-pass concept: animated cartoon cats. The cat is progressively revealed, then its animation begins. Progressive reveal is essential to this direction; the detailed design will be revisited.
Appeal: evaluate what someone would want to own and flex, and what someone would want to search for. Start with the cat concept and visual character before selecting breeds or traits. Realistic cat pictures/photos are excluded.
Development: progressive reveal does not imply the cat getting older. Drawing in lines or adding color were examples, not selected reveal methods.
Deferred: exact cartoon style, reveal stages and timing, animation behavior, sound, interactivity, breed/traits, rarity factors and technical implementation. Discovery and acquisition are undecided and outside this first-pass decision.
Next: move to original, unbranded cars; return to detailed cat design in a later pass. This records a concept, not implemented cat assets or authorization to change minting, rendering, programs or games.

Other categories awaiting their first pass

Next: original unbranded cars. Fictional real estate follows among the remaining candidates (buildings, mansions, streets and farms need further refinement). Each category needs its own discussion of appeal and behavior.

Additional candidates to evaluate, not approved categories: jewelry, sneakers, fashion, motorcycles, boats/yachts, musical instruments and arcade machines. Evaluate why the digital version would be coveted, what changes, what interaction adds, and whether/how that particular asset is discoverable.

The current Artifact, Entity and Scene image adapters remain technical fixtures. They are not the selected product taxonomy or approved discovery design.

Implemented test boundary — not the accepted game design

The V3 record is 216 bytes and binds type, behavior core, cadence, initial phase, derived rank/price, birth Clock, recipe digest, access, reward, publication and difficulty. The canonical authenticated recipe additionally binds the selected game profile and renderer. The immutable evolution inputs produce the current state; the application authenticates the recipe and renders the permitted Look.

Temporary type	Game	Distinctive mechanic
Artifact	Rebuild	Assemble connected fragments and choose a directional connector
Entity	Resonate	Inspect signals and reproduce an ordered rhythm
Scene	Pathfinder	Navigate a blocked grid and assemble a connected path

The user rejected these generic challenge gates as the product discovery mechanic. They remain implemented test code; future clues must describe meaningful facts about the asset being discovered. All end by predicting a captured Look's next Shift. Game difficulty affects the puzzle, not rarity. Designated free rewards, reveal-only finds, disabled purchase offers and excluded assets have independent acquisition terms. The program prevents offers/reveals from becoming free claims. See Discovery.

The initial reference price is computed; market floors, discount economics and production supply commitments are not selected. The active sample's cadence counts make frequent shifts scarce in this batch, without claiming a perpetual enforced supply limit.

Implemented scheduled evolution

The program uses its Clock and original issuance time to calculate the current index and phase. The test has minute, hour, day, calendar-month and calendar-year schedules. Month/year boundaries use UTC and preserve the original date anchor. Claims and transfers do not restart evolution; hidden and unclaimed items keep progressing.

For read-only display, the server calls the program quote using Solana simulation without broadcasting a transaction. No owner signature or periodic write is needed to calculate a scheduled state. The old freely incremented counter is rejected for new-format records; it remains a legacy lab test only.

The returned phase selects a type-specific authored pattern. Our application authenticates its recipe, checks the program result, and renders the current and previous appearance. Ordinary motion is decorative. If a visitor misses many periods, the service calculates the current index directly and returns the immediately previous one.

Production choices still needed: the actual visible transformation, whether evolution cycles or permanently develops, number and significance of stages, exact schedules, optional owner/game influence, and whether any future transition needs a persistent action receipt. The four-phase image cycles are explicit test rules.

Price semantics

Value	Current meaning
Initial issue price	Fixed at issuance from origin traits; zero is a reference basis, not claim permission
Current platform test price	Program-calculated phase price; an issuance basis if unclaimed and a reference if owned
Seller asking price	Separate application test listing, valid only while its recorded seller owns the asset
Recorded sale	Verified payment and ownership transfer in the same test transaction
Market floor / valuation	Not implemented and not inferred from any of the values above

Each origin core fixes a test price profile at issuance. Profiles can rise, fall or stay flat; free origins remain free. There is no guaranteed appreciation, real demand or executable consumer offer. The actual price formulas, ownership-dependent economics and any minimum listing rule remain product decisions. A seller ask is never silently changed to match the evolving platform reference.

Visibility, collections and discovery

Ownership, reveal permission and featured selection are separate facts. The API excludes hidden item names, identities, artwork, traits, prices and events, including direct-item lookups and sealed-container exports. Public container counts/ownership and revealed member drill-down follow the same model. A collection's members keep independent schedules and individual ownership records; collective rights and purchase/reveal mechanics remain open.

Solana is public: account existence, ownership and now program-enforced rule parameters can be inspected on-chain. Encryption conceals the seed. Associated data authenticates the server-held recipe; it does not encrypt that recipe. The full recipe is kept out of consumer responses, while its on-chain fields remain public. Application hiding does not make public-chain parameters confidential. Production secrecy requirements must be evaluated before discovery. Protected hunt inventory also needs isolated authority/access controls; the public disposable lab is not that service.

The current claim instruction provides issuer-plus-claimant authorization. The Chase validates three locks server-side before co-signing designated free rewards; it does not prove discovery fairness on-chain. A bulk purchaser's finder credit and reveal rights still require a decision.

Current test scope

One hundred new Devnet records, three image adapters, five cadences, four birth tiers, owned/unclaimed states, eight varied Stashes, actual controlled transactions and dynamic scheduled Moments. Homepage price/rank/schedule sorting and pagination operate on the complete permitted inventory. The previous/current Look and program prices are shared by The Flex, Moves, Moments and exports.

Read HOMEPAGE-V1.md for exact routes/API/timing, STATUS.md for evidence and BOOTSTRAP.md for reset recovery. Actual assets and their effect on minting, games and production economics are the next design decisions; the technical implementation does not settle them.

Sources for runtime behavior: Solana Clock sysvar and read-only transaction simulation.