Yoalto has no user documentation yet — no tutorials, no API reference, no guides. What it has is the set of design documents the protocol was built from, which are more detailed than a manual would be and considerably less friendly. They are listed here so you can see what the thinking actually is.
How 256 partitions coordinate validator sets and epochs without a runtime synchronous dependency on chain 0. Certificate format, when it is and is not needed, and the per-partition sync protocol.
How validator-set transitions are triggered, signed, distributed and verified. The mechanics behind the architectural role that the sync design establishes.
The architecture of the transaction layer: the account model, how the three action categories stack, what is built, and the order the rest should land in.
Action-by-action status for coin, tokens, NFTs, attestations, trading and the marketplace, plus the cross-cutting deferrals. The source for the status tags across this site.
Where the HotStuff implementation stands — what is complete, what is next, and the verification suites that back the claim.
The behavioural contract a wallet must implement to interact with Yoalto correctly. What a wallet must do, rather than the wire format.
An audit of a fresh-sync hazard in which a lagging validator could apply a receive before the send that funded it, and the fix.
An internal adversarial pass over roughly 41k lines and 104 packages. Twelve findings, all fixed. It does not conclude that the codebase is clean.
Until there is a reference, the interfaces themselves are the documentation. The JSON-RPC method set and the CLI are both small enough to read end to end, and both are listed on the developers page with their real signatures.
A whitepaper exists in the repository, but it describes Flink — the block‑lattice design Yoalto grew out of, with different architecture and different numbers. Publishing it here would misrepresent what Yoalto is, so it is deliberately not linked. The design documents above are the accurate account.