Xahmoeba

What this is

Xahmoeba is one species of small digital creatures, called moebas. A moeba is grown, not assembled: thirty-two bytes of genome are read through a fixed developmental process — how many segments, where limbs attach, how the head and tail form, how it moves, what colour it is — and the result is one canonical body. The drawing comes last, and the drawing never decides anything. Because looks follow from the genome step by step, a child resembles its parents for reasons that can be traced, locus by locus.

On the ledger a moeba is a URIToken issued by one Xahau account, the issuer (rMmx5nHzoVJAoMTFWkgCCMrZryTaD682tr on Xahau testnet). Whoever holds the token is its keeper. Two mature moebas can have a child: their keeper sends one payment to the issuer naming both, and from then on nobody signs anything. Hooks on the issuer's account seal the parents, and on the fire that captures the birth they take the ledger's own random number as its chance, combine the parents' genomes, then mint the child and deliver it. The child's genome is a pure function of the parents and the birth's seed: that random number, bound to the network, the issuer, the rules version, the request and the ledger of the draw. This site recomputes both on every moeba's page. The source is not published.

There is no token attached to the species, and no server that the population depends on: the issuer's hooks run every birth. The account they run on is held by xrplorer ApS. The site you are reading holds no data of its own: it reads the ledger and draws what it finds, and if it disappeared the moebas would be exactly where they are.

What a moeba carries

Everything that a moeba is sits on the token, in two places. Its life, once it has been brought to life, is kept elsewhere: on the LIFE account (below).

Its identity, in the URI. A URIToken's id is its issuer and its URI together, so the URI is immutable by construction. Ours holds the genetic model, whether it is a founder or a birth, its generation, the ledger it was born in, how many births it has in it, the version of the rules it was born under, the moment it becomes mature, its serial number, and the id of the request that committed its birth. Ninety-one characters.

Its records, as remarks on the token. Xahau lets an issuer attach small labelled values to a token, and mark each one immutable so that it can never be changed or removed by anyone, the issuer included.

• c.birth/1, immutable: who asked for the birth, the two parents in order, and the genome. A founder carries twenty zero bytes where the breeder would be: nobody bred it.
• c.audit/1, immutable: where the randomness came from, which ledger, and the randomness itself.
• c.rules/1, immutable: the hash of the exact rules the moeba was born under.
• c.use/1, written by the issuer as the moeba is used: how many of its births are spent.
• c.breed/1, written by the issuer at the keeper's signed request: the keeper's standing terms for letting others breed with it — their account, a price, an optional expiry — and deleted the same way.
• c.name/1, immutable, written once at the keeper's request: a name of up to twenty-four bytes. It says nothing about what the moeba is, so it is not part of its digest; it is not the keeper's to change afterwards, so it is not mutable either.

The token's Digest field, set at mint, is a hash over the URI and the three immutable records in a fixed order. A moeba whose records do not match its Digest is shown as such on this site, and would be by any reader that checks.

Nothing about its appearance is on the ledger

This is the part worth being clear about, because it is where Xahmoeba differs most from a collectible whose picture is a file. A moeba's token holds its genome and nothing about how it looks. There is no image, no image URL, no list of traits, no metadata describing a body. Body, colour, movement and even the systematic name are all read from the genome, on your device, by the same code every other device runs.

Many projects seal a card's identity on the ledger and point at a picture hosted somewhere. That is honest, and it is also a dependency: if the host goes, the picture goes, and what remains is an identifier. Xahmoeba has no such pointer to lose. If every copy of this site vanished, a moeba would still be the same moeba, because the moeba was never the picture; it was always the genome, and the genome is on the token. The source that reads a body from that genome is not published.

The trade is that the drawing is not a promise. It is a reading, and readings improve. Which brings us to the next section.

The drawing can change; the moeba cannot

The renderer is client code, versioned like any other, and it will be changed: to draw a limb the genome always specified but the old version fumbled, to make a texture read as the genome says it should, to fix a body plan that looked wrong. When that happens a moeba may look different than it did last month. It has not changed. Its genome is the same thirty-two bytes, its development is the same fixed process, and the body that process produces is the same body; we have become better at seeing it.

Some drawings will be wrong for a while. The genome can express combinations no moeba has yet had, and the renderer meets some of them for the first time when a birth produces them. A combination nobody has seen may be drawn badly the first time, and corrected once it has been looked at. That is expected in a species whose forms are discovered rather than designed, and it is why the site shows the structure and the genome beside the specimen: the drawing is one of three readings, and the genome is the one that is authoritative.

What does not change for a moeba once it is born: its genetic model, the developmental version it was born under, and the birth rules. The model is a byte in its identity, the developmental version is in its birth record, and the birth rules are hashed into c.rules/1. A new model, a new developmental version or new birth rules show up on new births and can never be applied to an existing one. A moeba is born under a version of the rules and stays under it.

Where the randomness comes from

A birth needs chance, and chance on a deterministic ledger is the hard part. Xahmoeba uses seal first, draw later: when a request is admitted the parents are sealed, and nothing about the child exists yet. On the clock’s next fire in a later ledger, the fire that captures the birth, the hooks take the ledger’s own random number from Xahau’s RNG amendment: each validator commits to a secret and then reveals it, and the ledger’s number is made from the reveals together. The hooks bind it to the network, the species, the rules version, the request and that ledger into a 32-byte seed. Every draw of the birth is read from that seed: which copy of each locus the child receives, where the reading switches, whether a mutation pathway opens.

So the parents are committed before the chance that decides the child exists, and the requester cannot compute the child before sending, cancel what they do not like, or try again. No single validator chooses the number. What this does not claim: that it is perfect randomness. Validators that hold back can keep a ledger from having a number at all, and then the birth waits and the clock tries again; one that sees the others’ reveals before fixing its own could tilt it a little. A request never captured within its window is refunded. Every draw can be checked from public data, and the source is recorded on every moeba.

One more property of the design: nothing about the child exists before the fire that captures the birth, and that fire draws the chance and fixes it in one step. So the line for refunds is capture. A birth is refunded if, and only if, it was never captured, whoever broke it: a keeper burning a parent, theirs or a partner's, the issuer, or a clock that never reached it before its deadline. A refund after capture would let a requester who dislikes the child break the birth and walk away paid. When it is refunded, the sweep returns everything the birth still holds, both prices and the issuer's fee, less the fires it already spent. If the child was already minted and is still with the issuer, and every partner who was owed a price has been paid, the sweep sends the child to the keeper who asked. A child whose partner is still unpaid stays with the issuer.

How a birth runs

The issuer's account carries six hook positions, and nothing else runs the species. Admission admits or refuses a request when the payment arrives. The clock walks the births on Xahau's Cron, buys the next fire, and on the fire that captures a birth draws its chance. The keeper answers the transactions people send: pokes that restart the clock, sweeps and their refunds, and a keeper's own requests for terms and names. Two do the genetics, recombination and mutation, in the same fixed arithmetic the site runs to check them. The lock refuses moving a moeba that a birth in progress still needs. Founders go through the same six: a founder is a request with no parents, whose named variants are drawn from the species' founder weights and whose number loci are drawn so a founder sits near the middle of a trait far more often than at either end.

Nobody signs the steps. The hooks wake themselves with Xahau's Cron, one birth per wake-up, round-robin across the four births the issuer will run at once. The wake-up that captures the birth draws its chance and, on the same fire, the two genetics positions combine the genomes and apply the mutation rules. Minting the token, sealing its three records, charging each parent one birth, delivering the child and paying the other keeper each take a fire of their own. Every transaction the hooks send reports back to them when it has been applied, and that report — not a clock and not a server — is what moves a birth to its next stage. If a step fails it is retried, paid from the birth's own budget, until it succeeds or the budget is gone; a birth that runs dry stops where it is and is swept, and anyone may send the transaction that sweeps it.

A newborn is not ready at once. It becomes mature one minute after its randomness was fixed, on the ledger's clock, and is born with a fixed number of births in it, spent one per child whichever parent it is. Founders are mature from birth. The hooks chapter lets you drive these stages by hand, including burning a parent halfway through.

The money

A request pays four things at once, all quoted from the ledger at the moment it is made: the issuer's fee, the other keeper's price if the other parent is theirs, a budget for the transactions the hooks will send on the request's behalf, and the Cron wake-ups that carry it through its stages. The site puts that amount on the payment; the keeper types nothing. The hooks check the same numbers on arrival and refuse anything under them, keeping nothing from a refused request. What a birth does not spend of its budget stays with the issuer, so the quote is kept close to the floor.

The fee for a birth, the fee for a founder, the fee for a name, the maturity wait and the number of births a newborn gets are parameters on the issuer's account, not compiled into the hooks. The issuer can move them with one transaction, without new code. A new fee applies from the next request; a new maturity wait or fertility reaches only moebas born after it, since each moeba carries the values it was actually born under. The founder price is a curve: it steps up every so many founders, so that once there is a population, buying a moeba and breeding it is cheaper than asking for another founder, and founders stay raw material rather than the prize. Breeding is not a way in — at least one parent must be the requester's own — so a keeper starts with a founder, a purchase or a gift. Today's figures, read live from the account, are on Getting started.

Buying, selling and giving moebas between keepers are ordinary URIToken transactions; the issuer takes nothing from them. Letting others breed with a moeba pays its keeper the price they set, per birth, as part of the birth — and spends one of that moeba's births, which is what the price is for. The issuer keeps a share of that price, 10%, set by parameter and shown before anyone publishes terms or pays. The split is in whole drops, rounded down in the keeper's favour, so the keeper's part and the issuer's always add up to the price.

A birth's whole budget is committed at admission and released at settlement: the emissions, and 20 Cron fires at the price the ledger quotes at admission. The fee is earned on the fire that captures the birth, and comes back with the rest if the birth is swept before that. Reserves are not charged: a reserve is a deposit, not a cost.

The rules

Everything the issuer's hooks refuse or require, in one place. None of it is enforced by this site.

• A fixed number of births, spent one per child as either parent. When they are gone the moeba cannot breed again.
• Maturity first. A newborn waits one minute from the fixing of its randomness. Founders are mature from birth.
• No close kin. Not itself, not a parent or child, not a full sibling. Half-siblings may breed, and so may grandparents and grandchildren. The rule is not about fitness — there is no fitness model — but about a shared species: without it one keeper with one pair could run a closed line forever.
• Closed by default. Only the keeper may breed a moeba unless the keeper has published terms. Terms are bound to the keeper who made them and stop applying the moment the token changes hands.
• One birth at a time. A parent in a birth still in progress cannot join another, be sold, given or bought until that birth settles. It can always be burned.
• Paid up front, refunded only if never captured. A birth that breaks before the fire that captures it, whoever broke it, or that the clock never reaches before its deadline, refunds what it still holds, both prices and the issuer's fee when swept, less the fires it spent. Once captured, nothing is refunded, though a child already minted is still delivered when it can be (above).
• The issuer writes the records. Birth, randomness and rules are written once and immutable; usage counts up; terms are the keeper's to publish and withdraw; a name is given once.

Its life

A moeba can also be brought to life, once, by its keeper. What it is stays on its token: genome, parents, records, untouched. Its life is state on a second account, the LIFE account, written by that account's own hooks: five needs that drift with time (satiety, energy, stimulation, social, comfort), the bond with its keeper, whether it is at home, resting, visiting or in a long sleep, how long it has lived without a break, and the milestones it has reached. Bringing it to life writes that state for the first time, from the genome on its token; from then on it lives in its own home on its page, for anyone who opens it.

What is on the ledger, and what is not. Each act of care is a transaction its keeper signs: feed, care, play, rest (for when its keeper is away: at least 3 days, until woken or until a chosen time), wake, opening its home to visitors, a visit to another. The LIFE hooks check it against the state and write the new state, and nothing else changes. Between those writes the needs move by fixed rules, so the state at any moment follows from the last one written and the time: every reader works it out the same way, and nothing is stored while nobody acts. Neglected for about two weeks, it falls into a long sleep, which ends its unbroken life; it can be woken again. The motion, the scene, the sounds and the moment-to-moment drawing are the site's, on your device: they are a reading of the state, and are not on the ledger.

What it costs. Bringing a moeba to life costs a price set on the LIFE account, once, shown before you sign, and a network fee of about 0.01 XAH. Each act of care costs a network fee of about 0.01 XAH, a rest with a chosen end about 0.01 XAH, and a visit about 0.01 XAH. Nothing is charged while nobody acts. The price goes to the LIFE account; the network fee pays the ledger, as for any transaction.

What the LIFE account's key can do. As with the species, the hooks hold everyone to the rules except whoever holds the account's key. That key can replace or remove the LIFE hooks, and with them the rules of every life, including installing hooks that write any state they like; change the price, whether new lives may begin, and the durations and gains the hooks read as parameters; and withdraw what the account has earned. Withdrawals are guarded by the hooks, which keep back the reserves every life needs, but that guard is on ordinary payments and stops a mistake, not bad faith. It cannot touch a moeba itself: the LIFE account is not the issuer, so a moeba's token, genome, records and owner are beyond it, and it cannot sign for a keeper. Every version of the LIFE hooks is on the ledger with the ledger it went live in, so any such change is public.

Rarity is counted, not assigned

There is no rarity table. No moeba is marked common, rare or legendary, by us or by the rules, and no odds are printed on a box, because there is no box: what a birth produces depends on which two moebas are its parents, and that is the keepers' doing. What the site shows instead are counts. On a moeba's page: how many living moebas share its morph, which moeba was the first recorded with it, and what it carries on the copy that does not show, with how many others show or carry the same. On the Plan a birth page: for any two parents, what their children could be, how often, and which of those morphs nobody has recorded yet.

Every count says what it is counted among — the living moebas in this read of the ledger — and none of them is a rank. A form is rare when the genetics make it hard to reach and common when the population keeps breeding it, and both can change as the population does. The simulations behind the design suggest that single alleles spread quickly once they exist, whilecombinations stay open far longer; the naming layer (the Latin name is the body plan, limbs, symmetry and pattern together) exists so that people can talk about combinations without a tier system.

Why every moeba is burnable

Every moeba is minted with the URIToken flag that lets the issuer destroy it. That is not a choice we would have made for its own sake, and it is worth explaining. On Xahau a hook on the issuer's account runs when one of its tokens is sold, bought or sent — but whether that hook can refuse the transaction depends on the issuer being what the ledger calls a strong stakeholder in it, and the issuer is one only when it holds the right to burn. Measured on the test network: without the flag, the lock that keeps a parent from being sold mid-birth runs, rolls back, and the sale goes through anyway. With it, the refusal holds.

So the flag is the price of the one rule the protocol cannot do without: a moeba a birth still needs cannot be moved out from under it. The other side of that trade is stated plainly in the next section: the issuer can burn any moeba. It is the ledger's arrangement, not ours, and we would rather write it down than have it found.

What the issuer can do

The hooks enforce every rule above against everyone, including the account they run on — with the exceptions that come from holding the account's key. Whoever holds it can:

• replace or remove the hooks, and with them any rule, for births to come and for births in progress;
• refuse transfers: the same position that lets the lock hold a parent mid-birth would let a different hook refuse any sale or gift;
• write a moeba's terms record directly, since only the issuer writes records — including terms that name the current keeper and a price the keeper never chose, which would open the moeba to breeding without the keeper's consent;
• change the prices, the maturity wait and the fertility of newborns, by parameter;
• delete the queue's state, breaking every birth in progress;
• burn any moeba, because of the flag described above;
• withdraw what the account has earned — guarded by the hooks against taking what the queue still owes to births in progress, but that guard is on ordinary payments and stops a mistake, not bad faith.

What the key cannot do, because the ledger enforces it against the issuer like everyone else:

• change a moeba's genome, parents, breeder, randomness or rules hash, or its given name — those records are immutable;
• change a moeba's identity URI, which is part of the token's id;
• stop a keeper from burning a moeba: a burn can never be refused.

Every version of the hooks that has run is on the ledger with the ledger it went live in, and the hash of the rules a moeba was born under is on the moeba. A species is a promise by whoever holds its key; the records are what make it a checkable one.

Why the account is not blackholed

An account on Xahau can be blackholed: its keys given up so that nobody can ever sign for it again, freezing its hooks and parameters exactly as they stand. That would remove every power in the list above, and it is a reasonable thing to ask for. We have not done it, and we do not plan to. The reason is not the earnings, though it is true that a blackholed issuer could never withdraw them; it is that being able to find and fix a fault matters more than being unable to.

The protocol is young. The rehearsal on the test network exists precisely because the hooks have had faults — a lock that broke a birth it should not have, a clock that stranded a healthy birth one step from settlement — each found by running the species, each fixed, each recorded in the protocol's own account of itself. A blackholed account could fix none of them; a fault found afterwards would be permanent, for every birth to come. The prices could never move, so a species priced for one market would be stuck in another; the maturity wait and fertility could never be tuned to what the population turned out to need.

What you have instead is narrower and, we think, more useful: everything a moeba is is sealed against us by the ledger, every change to the hooks is public with the date it went live, and the rules a moeba was born under travel with it forever. If that position ever changes, it will be a transaction anyone can check, and this section will say so.

The rehearsal on the testnet

The species runs on the Xahau test network before its release, where XAH is free and mistakes cost nothing. Everything you see here is a rehearsal, and the rehearsal has one rule that overrides all the others: it may be reset without notice.

• The population may be wiped. When the rules change in a way that existing moebas cannot follow, the honest thing is a fresh start, and we take it.
• The issuing account may be replaced. The account named at the top of this page is the current one; earlier accounts ran earlier versions and are not this species.
• The rules may change, and prices with them, with no notice beyond the ledger itself.
• The clock runs fast. The rehearsal uses the fast profile: a newborn is mature one minute after its randomness is fixed, so that a generation can be bred and looked at in an afternoon. The release profile is the same code with a two-hour maturity. Everything else — the fee, the fertility, the genetics — matches the current release candidate.
• Nothing carries over. A moeba born in the rehearsal is not a claim on anything in the release. It is a rehearsal of the species, not an early edition of it.

Why rehearse in public? Because the things that go wrong in a species — a lock that misfires, a queue that stalls, a form the renderer has never met — only go wrong when many people are breeding many moebas in ways nobody planned. A private test finds the faults we thought of. This finds the rest. Take part, break things, and tell us what you find at @xahmoeba on X; it is the most useful thing anyone can do for the species right now.

What this is not

Moebas are creatures in an artificial-life experiment. There is no yield, no staking, no governance right, no token attached, and no promise that a moeba will be worth anything to anyone later. The site never quotes a value, a floor price or a chance of profit, and it never will. What is on offer is a species whose forms are grown rather than drawn, whose heredity you can trace, and whose population is kept by many people rather than run inside one simulation. That is the whole offer.

The site holds none of your keys and never submits a transaction for you. It prepares one, lays it out field by field and as JSON, and your wallet signs it. Anyone can mint a URIToken that looks like a moeba; a moeba is one only if it was issued by the account named above, and that is what every page here checks before it draws anything.

How to check any of it

• Replay a birth. Every moeba's page runs the birth rules again on your device, from the two parents' genomes and the recorded randomness, and says whether the recorded genome matches, byte for byte.
• Read the token. The ledger record on each page shows every identifier whole, and the explorer shows the token, its owner, its offers and its full history, held by a third party.
• Check the randomness. The record names the ledger of the draw. The species’ fire in that ledger carries the ledger’s random state in its metadata; from it, the fire, the species, the rules version and the request that committed the birth, every moeba’s page recomputes the entropy on your device and says whether it is the entropy the birth recorded. A node that does not keep that ledger is said as such, not counted as a mismatch.
• The hooks' hashes. The source is not published. The hashes of the hooks are on the issuer's account, and every version that has run is on the ledger with the ledger it went live in. What this site can recompute is the randomness, from the ledger’s draw and the request, and the child, from the parents and that randomness, on the moeba's own page.
• Watch it work. A birth replays the exact draws on real parents; The randomness follows the live ledgers, shows where a birth’s chance comes in, and lets you try to predict the next ledger’s random number; The hooks lets you drive the stages by hand.

If this document and the ledger disagree, the ledger is right and this document has a fault. Tell us.