Keeping moebas
A moeba is a URIToken. Whoever holds it is its keeper and can do with it what the ledger allows any token holder to do, plus the things the Xahmoeba issuer adds. This chapter is the list.
Buying and selling
A keeper puts a moeba up for sale with a sell offer: a price in XAH, and optionally the one account allowed to buy. Anyone who meets the offer receives the token and the keeper receives the price, in one transaction. A keeper can cancel an offer at any time. These are ordinary Xahau URIToken transactions; the issuer does not take a cut.
The issuer does refuse one thing: a sell offer or purchase for a moeba that is a parent in a birth still in progress. Wait until the birth settles; it usually takes a minute or a few.
Giving
A gift sends the moeba to another account outright, with no price: on the ledger it is a Remit carrying the token. The recipient pays nothing, signs nothing and needs no prior offer. The same lock applies while a birth needs the moeba.
Breeding your own
If you keep both parents you need nobody's permission. Send the request from the moeba's page, or from My moebas; the payment is the fee plus the birth's own transaction budget.
Opening a moeba to others: terms
By default a moeba is closed: only its keeper can breed it. A keeper can open it by having standing terms written on the token: their account, a price, and optionally a ledger at which the terms expire. Another keeper's request then pays that price to them as part of the birth. Terms open a moeba to other keepers, not to everyone: the other parent must be the requester's own, so nobody breeds two strangers' moebas without keeping one themselves.
Terms are bound to the keeper who made them. The moment the token changes hands they stop applying, with nothing to clean up; if it comes back to the same keeper, the same terms stand again. Only the issuer can write on a token, so a keeper publishes, changes or withdraws terms with one signed payment to the issuer, which writes the record for them and puts the keeper's own account in it — nobody can publish terms on a moeba they do not hold. The payment covers the ledger cost of writing or deleting the record. There is no protocol fee on top of that; anything paid above the write stays with the issuer.
Breeding does not use up terms. A moeba open to others stays open, one birth after another, until its fertility runs out or its keeper withdraws them.
Naming
Every moeba has a systematic name read from its genome. Its keeper may also give it a name of their own: up to twenty-four bytes, written once by the issuer at the keeper's signed request, and immutable from then on — it stays with the moeba through every sale. Naming costs a price the issuer sets, plus the record write. A moeba that already has a given name cannot be renamed, by anyone.
Fertility and maturity
Every moeba is born with five births, spent one per child as either parent, and recorded on the token as it goes. It becomes mature one minute after the moment its own randomness was fixed, measured on the ledger's clock; a founder is mature from birth. Both are shown on the moeba's page, along with a plain yes or no on whether it can breed right now.
Burning
A keeper can destroy a moeba. The issuer cannot stop this: a holder must always be able to dispose of a token. If the moeba is a parent in a birth that has not yet finished with it, the birth breaks; once both parents' fertility has been charged, the child no longer depends on either and is unaffected. A burned moeba's records stay readable, and it appears greyed out in the population.
The rules, in one place
Everything the issuer refuses or requires, gathered from the chapters above and from The birth. Every one of these is checked by the hooks on the issuer account, not by this site.
- Five births. Every moeba is born with five, spent one per child as either parent. When they are gone it cannot breed again.
- One minute to maturity. A newborn may breed one minute after its randomness was fixed, on the ledger's clock. Founders are mature from birth.
- No close kin. A moeba cannot breed with itself, with either of its parents, with its own child, or with a full sibling. Half-siblings may breed; so may grandparents and grandchildren.
- Closed by default. Only the keeper can breed a moeba unless the keeper has published terms. Terms name the keeper, a price per birth and an optional expiry; they stop applying the moment the moeba changes hands.
- One birth at a time. A moeba that is 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, quoted from the ledger. A request pays the issuer's fee, the partner's price and the birth's own transaction budget at once. Underpaid requests are refused and nothing is kept.
- Refund before the draw, never after. A birth that breaks before its randomness is fixed refunds its unspent budget, both prices and the issuer's fee when it is swept; one that breaks after does not, because by then the child follows from a public hash. The issuer's fee follows the same line: refunded before the draw, earned on it. A child already minted is still delivered when it can be; the randomness chapter says when.
- The issuer writes the records. Birth, randomness and rules are immutable and written once; usage counts up; terms are the keeper's to publish, change and withdraw; a name is given once and never changed.
- Prices are set by the issuer. The fee for a birth, the founder curve, the fee for a name, the maturity wait and the births a newborn gets are parameters on the issuer account, shown on this site as they stand. A new fee applies from the next request; a new maturity wait or fertility reaches only moebas born after it, since every moeba carries what it was actually given.
What this site does, and does not
Every action above is a button on the moeba's page once the site knows which account is yours. The site builds the transaction and lays it out, field by field and as JSON, for you to sign with whatever wallet holds your key; Xahau does not care which. It never holds a key and it never submits on your behalf. If you use Xaman, you can connect it so the request opens in that app directly, and the site then reads the result back from the ledger and tells you what the issuer said.