The hooks
Hooks are small programs attached to an account. When a transaction touches the account, the network runs them; they can refuse the transaction, keep state, and emit transactions of their own. Xahmoeba is six of them on one account.
A moeba on the ledger
On the ledger a moeba is a URIToken issued by one account, the species’ account. Its URI holds its identity — kind, generation, the ledger it was born in, when it matures; three sealed records hold its genome with its parents and who asked for it, the randomness used, and the hash of the rules. To make a new moeba, a keeper sends one payment naming two parents. From then on nobody signs anything: on its next fire in a later ledger the clock on the account takes the ledger’s own random number as the birth’s chance, combines the parents’ genomes, applies the mutation rules, and later fires mint the child and deliver it. The child’s genome is a pure function of the parents and the birth’s seed: that number, bound to the network, the species’ account, the rules version and the request itself. This site checks both on every moeba page. The source is not published.
Who does what
The same beats every birth goes through, from the keeper’s payment to the child coming home.
One request, nine stages
After admission nobody signs anything. The next wake-up captures the randomness, combines the genomes and mutates them, all on that one fire. Each later step takes a fire of its own, and the two parents are charged on two fires. The button walks the stages one at a time, including the three that share a fire, so each can be read. Watch what the issuer account holds change. Try burning a parent midway to see how a birth breaks.
Six positions, one account
A hook position may declare at most 65,535 instructions and 65,535 bytes of code, and the genetics does not fit beside the stage machine. So the work is split across positions, and one Cron fire wakes all of them at once. A fire is not free: it costs the sum of what the Cron-triggered positions declare, so every fire is paid for before it is booked. A position is charged its whole budget on every type of transaction it names, so the stage machine is two positions built from one source: the clock, which Cron alone runs, and the keeper, which answers keepers’ payments and the poke. Fires no longer pay for the code that answers requests, nor requests for the stage machine. Founders need no position of their own: a founder request goes through admission like a birth, and the clock draws its genome from the ledger’s random number instead of from two parents.
| Position | Runs on | Does |
|---|---|---|
breed-admit | Payment | Checks a request against every rule, reserves both parents, takes one of the four queue places (the issuer runs at most four births at once), prices the birth from the ledger’s current fees, and guards the account: an operator can withdraw only what the queue does not owe. A founder request (no parents) takes the same door. |
breed-finalize, the clock | Cron | Walks one birth forward on each fire. The fire that captures a birth checks that both parents still exist, takes the ledger’s own random number and binds it to the request; recombination and mutation run on that same fire, and mint, seal, each parent’s births, the partner’s price, delivery and releasing the queue place take a fire each. A ledger without a random number makes the birth wait for the next fire. Books the next fire, paid from the budget of the birth it will serve. For a founder, draws the genome from that random number. |
breed-recombine | Cron | Reads both parents’ genomes from their records and forms the two gametes. |
breed-mutate | Cron | Applies pathways and drift, continuing the same random stream, and fixes the child’s genome. |
breed-lock | Remit, sell offer, buy, burn | Refuses moving a moeba that a live birth still needs. A burn is never refused; the next fire finds the parent gone and breaks the birth instead. |
breed-keeper | a keeper’s Payment; a poke by Invoke | Answers the keepers: on a signed payment it publishes or withdraws breeding terms and gives a name once, then restarts a stopped clock, as a poke would. On an Invoke from anyone it sweeps a broken birth, refunds it where it is owed, or restarts a stopped clock. A sweep of a birth whose child was minted and is still here sends that child on, once every partner who was owed a price has been paid. It does not collect, so it never runs at the species’ expense on a transaction that only touches the account. |
What a payment can ask for
Every request except the poke is an ordinary XAH payment to the species’ account. What makes it a request is a handful of one-letter hook parameters on the transaction, read by the hooks and by nothing else: F says what is asked — a founder, a birth, terms opened or closed, a name — and the others name the moeba, the parents and a price. The site fills them in. The full table, with what each request pays, is in the protocol.
What is refused, in words
- A parent the issuer did not issue, or a token of the issuer that is not a moeba at all.
- A moeba breeding with itself, with its own parent in either direction, or with a full sibling. The two parents must be the same genetic model.
- A parent that is not mature against the ledger clock, or has no fertility left.
- A parent already reserved by another live birth.
- A parent the requester neither keeps nor has a permission for; a permission belonging to a previous keeper, expired, or malformed.
- A request in which the requester keeps neither parent. Terms open a moeba to other keepers, not to someone with no moeba at all.
- A request that supplies its own randomness, the ledger to draw in or serial.
- A request that underpays, partially pays, or is not in XAH — for a birth, a founder, terms or a name alike.
- A requester whose account refuses incoming Remits, or requires a destination tag or deposit authorisation: the child, or a refund, could not be delivered.
- A partner whose account requires a destination tag or deposit authorisation, when a price is owed.
- A parent of a genetic model this issuer does not run.
- A withdrawal by the operator that would touch money the queue owes.
- Moving a moeba a live birth still needs, except a burn, which breaks the birth instead.
- Terms published, changed or withdrawn, or a name given, by anyone but the moeba’s current keeper; a second name for a moeba that has one.
When a hook refuses, it says why in a short sentence that is recorded with the transaction. This site shows that sentence when one of your requests is refused.
The money
A request pays the protocol fee, the partner’s price and a budget for the work the birth will make, all quoted from the ledger at admission, and the hooks refuse anything under the quote. How the money moves, what comes back when a birth breaks, and what the species’ account keeps are in the whitepaper; today’s figures are onGetting started.
Three places, different jobs
Your device reads the records and draws the moebas. It can cache and explore, but it decides nothing.
Your wallet, whichever one holds your key, shows you a transaction and signs it. The key never leaves it.
Xahau validates transactions and runs the hooks. The Xahmoeba issuer is rMmx5nHzoVJAoMTFWkgCCMrZryTaD682tr on Xahau testnet; its hooks and their hashes are visible there.
What to remember
- Six hook positions on the species’ account run every birth. After the keeper’s one payment, nobody signs anything.
- Admission checks the request against every rule, reserves both parents and takes a place in the queue. Each later fire of the clock walks the birth one stage on: the draw and the genes, the mint, the records, each parent’s birth, the delivery and the payments.
- A moeba a live birth still needs cannot be sold, given or bought. A burn is never refused: it breaks the birth instead.