01Overview
Claude is a collection of 21,000 unique inscriptions on Bitcoin (Ordinals), released alongside a native BRC-20 token $CLDE. Each inscription is a tiny child ordinal (about 300 bytes) that references a single shared recursive engine inscription; the engine is what actually renders every piece at view-time.
The economics have two sides: what holders earn directly, and what funds the project.
Direct holder yield
- $CLDE emissions - a continuous BRC-20 yield, snapshot every 7 days, multiplied by rarity × bond × lock factors. Automatic. The only direct sat-convertible yield a holder earns simply by holding.
- Soulmate pairing - every inscription has exactly one deterministic partner. Holding both halves at the snapshot earns 3× $CLDE on each. Burning $CLDE to permanently bond keeps the 3× even across sales.
- Future sister drops - new Claude collections airdrop free to current holders. Indirect future yield.
Project revenue, governed by holders
- Mint revenue - 10,000 sats per paid mint (every mint after a wallet's first free claim) flows to the treasury.
- 5% creator royalty - on every Claude trade through a cooperating marketplace (Magic Eden, Unisat, OKX, OrdinalsWallet, Gamma), 5% of the sale price flows to the same treasury address.
The treasury is a single Bitcoin address the team controls. Holders vote on every spend (token buybacks, sat airdrops, sister-drop funding, ops). Nothing is auto-distributed to holders. The wallet balance is on chain and verifiable; the spending policy is set by governance.
$CLDE has four sinks: burn to mutate the art, burn to bond a soulmate pair permanently, burn to vote on governance, burn to revive a provably-lost inscription. The token has real outflow pressure, not just emission.
02Art & rarity
Each piece is generated procedurally from five trait categories. The renderer is deterministic - given the same seed and the same token id, you'll always get the same composition.
| Category | Role | Variants |
|---|---|---|
| field | Background fill | 9 (warm-void, ash, ember-shade, smoke, cocoa, rust-haze, plum-shade, ivory-mist, cosmic) |
| ring | The C-shape color | 9 (coral, peach, terracotta, burnt, amber, rust, sandstone, ivory, phoenix) |
| pupil | Center glyph | 9 (dot, square, diamond, triangle, slit, cross, ring, spiral, void) |
| aura | Outer glow / particles | 9 (none, soft-glow, halo, sparks, particles, mist, burst, constellation, phoenix-aura) |
| trace | Ring texture | 9 (smooth, dotted, double, hatched, rough, gradient, etched, shimmer, fractured) |
Rarity tiers
Each piece earns a rarity score by summing the inverse-weight of each chosen trait
(sum(totalWeight / pickedWeight)). The whole collection is then sorted and
bucketed into five tiers by quantile:
| Tier | Name | Quantile | Count (21k) | Emission multiplier |
|---|---|---|---|---|
| 5 | Mythic | top 1% | 211 | 5.00× |
| 4 | Legendary | next 4% | 840 | 3.50× |
| 3 | Rare | next 10% | 2,101 | 2.25× |
| 2 | Uncommon | next 25% | 5,250 | 1.50× |
| 1 | Common | rest | 12,598 | 1.00× |
03Layer 1 - Creator royalty (5%)
Bitcoin has no protocol-level royalty enforcement. The closest practical thing is the
marketplace-honoured creator royalty that every major Ordinals marketplace
already supports. When a buyer purchases a Claude on Magic Eden, Unisat, OKX or
OrdinalsWallet, the marketplace's PSBT builder adds an output of
5% × sale_price to the treasury address.
The treasury is the same wallet that receives mint revenue (see §05). The two inflows compound: every paid mint adds 10,000 sats, every secondary trade on a cooperating marketplace adds 5% of the sale price.
The royalty is set per-collection in each marketplace's creator portal: name the collection, set the royalty percentage, point the payout at the treasury address. Magic Eden, Unisat, OKX, OrdinalsWallet and Gamma all support this natively. A buyer who routes around them (direct OTC swap) skips the royalty. We expect 80%+ of volume to flow through honouring marketplaces.
The treasury balance is just on-chain UTXOs at a public Bitcoin address. The engine
reads the live balance from mempool.space/api/address/<addr> at view
time. No indexer required.
04Layer 2 - $CLDE emissions
$CLDE is a standard BRC-20 token deployed at genesis with no premine. All supply enters circulation through the emissions described here.
Emissions snapshot every 7 days ("an epoch"). At each snapshot the indexer reads,
for every inscription, who currently owns it on-chain, then computes the emission for
that owner. The grant is published as a Merkle leaf; the epoch's root is committed to the
EmissionEpoch row.
The token enters circulation via standard BRC-20 mint inscriptions that the
indexer orchestrates; the indexer doesn't custody $CLDE - it just signs the inscriptions
that materialize the grants.
05Emission formula
Per inscription, per epoch:
// 8-decimal precision (1 $CLDE = 10^8 base units) emission = BASE × RARITY_MULT[tier] × BOND_MULT × LOCK_MULT // then floor to 8 decimals
| Variable | Value | Notes |
|---|---|---|
BASE | 1.0 $CLDE / epoch | floor emission |
RARITY_MULT[1..5] | 1.0, 1.5, 2.25, 3.5, 5.0 | per tier |
BOND_MULT | 3.0 if bonded; else 1.0 | both halves of soulmate pair owned by same wallet at snapshot, or a PERMANENT Bond exists between them |
LOCK_MULT | 1.0 → 3.0 (linear over 90d) | inscription held in LOCK_VAULT_BTC_ADDRESS |
Worst case (common, no bond, no lock): 1.0 $CLDE / epoch. Best case (mythic, bonded, fully-locked): 1.0 × 5.0 × 3.0 × 3.0 = 45.0 $CLDE / epoch. That's a 45× spread between the floor and the ceiling, all stackable.
06Soulmate pairing
At genesis, the indexer takes the integer set {1..21000} and produces a
deterministic permutation via Fisher-Yates, then pairs arr[2i] ↔ arr[2i+1].
This yields a perfect matching on 21,000 (10,500 pairs).
The permutation is seeded from a fork of the art-gen seed (seed XOR 0xDEFA017),
so it's stable even if the art renderer changes. The seed and the soulmate table are
published.
// build soulmate permutation arr = [1, 2, ..., 21000] fisher_yates(arr, seed=GENESIS_SEED XOR 0xDEFA017) for i in 0 .. 21000 step 2: soulmates[arr[i]] = arr[i+1] soulmates[arr[i+1]] = arr[i] // invariant: soulmates[soulmates[k]] == k for all k
The matching has three useful properties:
- Reciprocal - if N's soulmate is M, M's soulmate is N. No "one-way" pairs.
- Provable - anyone can reproduce the entire table from the seed.
- Stable - soulmate ids never change once genesis is inscribed.
A pair is considered bonded for an epoch if at the snapshot block, both halves resolve to the same Bitcoin address. Permanent bonds (via burn) override this and stay bonded regardless of ownership.
07Burn sinks
$CLDE has four sinks. Every sink permanently removes the burned amount from circulation - this is a real outflow, not a stake-and-unstake.
The burn protocol is the same for all four: the user inscribes an action
inscription (a small text inscription) with a payload like
op=mutate; id=BTC-1234; kind=AURA and simultaneously transfers the priced
$CLDE amount to the canonical burn address bc1q...dead. The indexer's
action-scanner matches the two and writes the state change.
08Mutate
Add a permanent overlay to an inscription. The recursive engine reads the mutations table at render time and applies the overlay every time the inscription is viewed.
| Kind | Cost ($CLDE) | Effect | Restriction |
|---|---|---|---|
| OVERLAY | 10,000 | Subtle pattern overlay on the ring | any tier |
| GLOW | 25,000 | Coloured outer glow halo | any tier |
| AURA | 100,000 | Animated particle aura | tier 4+ |
| CROWN | 200,000 | Head crown overlay | any tier |
| WINGS | 500,000 | Side wing overlay | tier 3+ |
Mutations stack. A mythic with all 5 mutations is a thing in itself.
09Bond
Burn 50,000 $CLDE to mark a soulmate pair as PERMANENT. Permanent bonds keep the 3× emission multiplier on both halves even if one half is later sold to a different wallet. The bond is keyed on token ids, not addresses.
A pair can only be permanently bonded once. Soft (same-wallet) bonds still apply automatically when both halves are co-held.
10Vote
Governance is plutocratic but cost-bearing: each $CLDE burned counts as one vote on an open proposal. Burn happens at vote-time, so every vote has real economic skin.
- Proposal authorship requires burning 100,000 $CLDE (anti-spam).
- Quorum for execution is 5% of circulating $CLDE.
- Optional quadratic voting mode caps the influence of any single wallet at
sqrt(burned). The author of the proposal selects voting mode at creation time.
Approved proposals authorize transactions from the treasury, so spending is genuinely community-controlled even though the wallet is held by a single party.
11Revive
If an inscription is sent to a verifiably-dead address (a P2WSH the indexer recognizes as
non-spendable, e.g. OP_RETURN outputs or known burn addresses), it's
eligible for revival. Burning 500,000 $CLDE inscribes a revived twin to the
revival applicant's address with all original traits + a permanent REVIVED
overlay so it's distinguishable.
Revival doesn't move the original inscription - it stays dead at the dead address. It mints a new sibling with the same id-tier-rank-soulmate.
12Recursive engine
The bulk of the rendering happens inside a single parent inscription - the engine. Each of the 21,000 child inscriptions is a tiny ~300-byte ordinal that references the parent and supplies its own token id; the engine takes the id, looks up the trait set + any on-chain mutations + any active permanent bond, and procedurally re-renders the piece in the viewer.
This means three useful things:
- Cheap inscription - 300 bytes vs ~50KB for embedded SVG.
- Live mutations - the engine re-reads state, so when you burn to mutate, your inscription visually changes the next time anyone views it. No reveals, no rugs, no re-inscriptions.
- Self-contained - the engine is on-chain. Even if every server we run goes dark, the inscriptions still render forever via ordinals.com / any ordinals explorer.
13Verifiability
Everything except the chain itself is open source and reproducible.
- Genesis seed is published in the parent inscription. Anyone can re-derive the 21k trait set and the soulmate table.
- Each epoch publishes a Merkle root over its emission grants. Holders can prove their grant with a Merkle proof.
- Treasury inflows are simply on-chain UTXOs; anyone can count them.
- Action inscriptions are public ordinals. The state transitions they imply (mutations, bonds, votes, revivals) are reproducible from any indexer running the same published rules.
If our indexer is buggy, anyone can fork it and re-run from the genesis seed + the chain. The on-chain state is the canonical source.
14Roadmap
- Genesis mint - 21,000 inscriptions, free first-per-wallet, then 10k sats each. Free / paid is enforced by the engine reading chain state at mint time.
- Marketplace listings - submit the collection to Magic Eden, Unisat, OKX, OrdinalsWallet and Gamma with 5% royalty + treasury payout configured in each creator portal. All free, all live within ~7 days of submission.
- $CLDE emissions go live - first epoch closes 7 days after genesis. Merkle roots published from epoch 1.
- Burn rails open - mutate / bond / vote / revive all live on day 1. The action scanner is hot from genesis.
- Sister drops - second and third Claude collections (smaller, themed) airdrop to current holders at month 6 and 12. Total cumulative supply across collections capped at 42,000.
- Cross-collection bonds (research) - extend soulmate to pair across sister collections. No commitment yet.
This whitepaper is a description of how the system is designed to work, not financial advice. Mint at your own risk. None of the participants are registered investment advisors. The team makes no representation that $CLDE will appreciate or hold any value, nor that the treasury will distribute to holders.