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 wait for a ledger that has not closed yet, take its hash as the birth's chance, combine the parents' genomes, mint the child and deliver it. The child's genome is a pure function of the parents and the birth's seed: that hash, mixed with the network, the issuer, the rules version and the request itself. 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 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 living view: 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 commit first, reveal later: when a request is admitted, the hooks name a ledger a few ledgers ahead. That ledger's hash does not exist yet. When it closes, its hash — which depends on every transaction in it and the order the validators agreed on — is captured and mixed with the request 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. What this does not claim: that the hash is unbiased or beyond influence. Whoever can influence the final contents of that ledger may influence its hash; on Xahau that is a question about validators and transaction inclusion that has not been quantified. The protocol is not described here as fair or as a verifiable random function. It is described as commit-first with a public beacon, and the source is recorded on every moeba so that a better one can replace it in a later version of the rules without touching a single existing creature.

One more property of the design: once the named ledger closes, its hash is public and the child follows from it — anyone can compute it, before the hooks have even read the hash. This site recomputes that child from the record. So the line for refunds is that ledger closing, not the hooks capturing it. A birth a keeper breaks after the named ledger has closed — by burning a parent, their own or a partner's — is never refunded, whether or not the hooks have captured the hash yet: a refund then would be a free look at the outcome with the option to walk away from it and try again. A birth that breaks before that ledger closes is refunded when swept: the unspent budget, both prices, and the issuer's fee. So is a birth the clock never reached before its deadline, and one whose parent the issuer burned before its randomness was fixed — those are the issuer's failures, not the keeper's, and nobody should pay the fee for a birth that did not happen. 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 five hook positions, and nothing else runs the species. One admits or refuses a request when the payment arrives; one walks each birth through its stages; two do the genetics, recombination and mutation, in the same fixed arithmetic the site runs to check them; one refuses moving a moeba that a birth in progress still needs. Founders go through the same five: 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 randomness also combines the genomes and applies 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 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 before the draw is public. A birth that breaks before its named ledger closes refunds its unspent budget, both prices and the issuer's fee when swept, and so does one the clock never reached — the issuer earns its fee only on the wake-up that fixes the draw; one a keeper breaks after the named ledger has closed, or that breaks after the draw is fixed, refunds nothing, 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.

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 What if 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 four-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.
• Recompute the randomness. The record names the ledger whose hash was used. That ledger closed after the request was admitted, and its hash is public. Every moeba's page fetches that hash from the node and recomputes the entropy on your device, from the hash, the species, the rules version and the request that committed the birth, 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 hash 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 subscribes to the live ledger; 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.