Where the randomness comes from
The one input to a birth that did not exist when the parents were chosen. The order is the point: the breeding decision comes first, the chance comes after, and neither side gets to look at the child and try again.
Ask for a birth and watch the dice roll
Below, the ledger closing as it happens, read from a public node: every few seconds a new one, with a hash nobody had before it closed. Ask for a birth and see which ledger would become the source, then try to guess a hash before it closes. Nothing is sent; if the node cannot be reached, a model on your device stands in and says so.
Commit first, reveal after
When a request is admitted the parents are reserved and a target is written down: a ledger four ahead. That ledger has not closed, so its hash does not exist yet — not for the keeper, not for the operator, not for a validator. When it closes, its hash is what it is, and the child follows from it. The requester therefore cannot know the child before committing to the parents, and cannot decline the child afterwards. That is the property the protocol is built around.
It is worth saying precisely what this is and is not. A ledger hash is deterministic: it is computed from everything in that ledger and the ledger before. It is not a dedicated, audited randomness beacon, and this site does not call it perfect or impossible to influence. What it gives is order — the breeding decision precedes the entropy that determines the offspring — plus a public record this site recomputes the child from. Xahau has a proposed amendment for consensus-derived commit-and-reveal entropy; if it is activated, births could take their seed from it with a stronger, documented provenance. That is a possible future, not something the protocol does today.
Why the request cannot bring its own
A request that supplies its own randomness, target ledger or serial is refused. If a requester could choose any of them they could try many and keep the one they liked, which would make births an auction for the best genome rather than a draw. The hook checks for those parameters by name and rolls back if any is present.
Why it is mixed, not used raw
The ledger hash is mixed with the network id, the issuer account, the rules version, this request’s own id and the target ledger before it becomes the seed. Two births admitted in the same ledger therefore get different seeds, and the same hash cannot be replayed under a different rules version.
The capture window
A node keeps recent ledger hashes readable for a while, not forever. The hook has 240 ledgers, roughly a quarter of an hour, to capture the target’s hash. If the clock stops and the window passes, the source is gone and the birth is terminal: it is marked broken, and anyone can sweep it. A swept birth whose randomness was never fixed gets its unspent budget, both prices and the issuer’s fee back. The fee is earned on the fire that fixes the randomness, and not before.
Once the randomness is fixed the child is determined and could not have been anything else. From that point nothing is refunded: by then anyone could compute the child from a public hash, and a refund would be a free option to reject a child one did not like. Delivery may take as long as it takes, and a broken delivery is retried. If the child was minted and is still with the issuer when the birth is swept, 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.
What is recorded
Each moeba carries a record naming the source, the ledger the hash came from, and the seed itself. Its page on this site shows all three and replays the birth from them. The ledger hash is public on any explorer.