Learn

A program is a hash

A program is one set of market economics — the fees, how they change, how they are split — identified by the hash of its canonical form and by nothing else. It has no owner, no permissions and no state, because it is a hash.

That has a consequence worth stating plainly: two people who independently launch identical economics have not launched two programs. They have launched two markets running the same program, and the first hash observed owns the identity. The interesting fact about a program is therefore how many people chose it, which is what the list on the front page is ordered by.

Two hashes, answering two questions

configHash covers the economics and nothing else. Two markets with the same configHash charge the same fees and split them the same way, whatever chain they are on and whichever engine runs them. It is deliberately chain- and engine-independent.

implementationHash is the stronger claim. It binds those economics to a chain, an engine address and an engine version, so it answers “are these rules the rules that will execute here” rather than merely “which rules”. The same economics deployed against a different engine produce a different commitment.

Rules are derived, never written

The canonical configuration is the authoritative form of a market. The review card, the encoder, the commitment hash and the contracts all read it and nothing else — so if two descriptions of a market could disagree, one of them is not reading it.

Every sentence in a market's rules on this site is produced by the engine from that configuration. This interface chooses where a sentence sits and never what it says. There is no model, no per-program template and no hand-written copy anywhere in the rule text, which is what makes it disclosure rather than marketing.

Verification is a recomputation

A market page does not take the registry's word for anything. It takes the canonical bytes, recomputes both hashes, and compares them with what the chain recorded. There are three outcomes and the third is the point:

• Verified — the bytes recompute to both hashes the chain recorded.
• Mismatch — they recompute to something else. Loud, and rare enough to be alarming.
• Unverified — the check could not run. This is not a failure and is never coloured like one: an app that reported an unchecked market as verified would assert something nobody established, and one that reported it as mismatched would accuse a market that is very likely fine.

Generations

The engine version is a field inside the canonical encoding, so it is inside the identity too. The same economics written for two engine generations are two different programs with two different hashes, and a market stays on the generation it launched under for ever.

A market whose generation this build does not carry an encoding for reads as unverified rather than as wrong. Recomputing it under another generation's encoding would produce a hash that cannot match, which would be an accusation made by software that is merely out of date.

Names, and what they are not

Most programs have no name, and none is generated for them — an unnamed program shows its hash, because the hash is what it is. A name is attached by a claim, and the right to make one belongs to the address that launched the earliest market running those economics.

A name is a label and never the identity. A program can be renamed; the old name then stops resolving, for ever, and is not forwarded and not reissued to anybody else. A program's permanent address is its configuration hash.

Lineage is claimed, never inferred

Nothing on chain records that one configuration was derived from another. Where this site shows a fork or a revision, a creator stated it when they built the market. Where it shows nothing, that means nobody said — not that there were no ancestors — which is why a program with no recorded lineage has no lineage section at all rather than an empty one.