Yoalto separates where a payment executes from who agrees on it. One validator set finalizes every partition under HotStuff; each account lives on exactly one partition and its payments execute only there. Nothing on the payment path needs a cross‑partition lock.
A validator is the whole bottom two layers: a pod cluster over one FoundationDB cluster, not a single machine. Adding capacity means adding pods.
Every account's home partition is derived by hashing its identity — MurmurHash3-32 over the claim hash, mapped into [1, 255]. Any client computes it before sending; no sequencer assigns it, and it never moves.
On the sender's home partition: debit the balance, advance the account's nonce, and emit a commitment. It finalizes there, without waiting on the recipient's partition or taking a lock anywhere else.
On the recipient's home partition: verify the SEND against a Merkle proof and the signed quorum certificate that finalized it, then credit. The two halves are independent transactions — this is the pattern Nano proved in production.
HotStuff finalizes each partition's blocks under a 2‑chain commit rule with a 2n/3+1 threshold. Leaders are drawn per (partition, view) by deterministic stake‑weighted election, so no single node proposes for all 256 partitions at once.
Yoalto signs consensus with BLS and user transactions with Ed25519. Neither is post‑quantum, and this page will not pretend otherwise. What the design does provide is a migration that costs one transaction rather than a chain‑wide event: an account's external address is a claim hash fixed when the account opens, held separately from the key that signs for it. Rotating to a different scheme changes the key, not the address, so nobody's sends or receives break.
| Property | Single-chain L1 | Rollup stack | Yoalto |
|---|---|---|---|
| Execution parallelism | 1 lane | 1 lane per rollup | 255 payment partitions |
| Payment model | Global state | Bridged, async | SEND / RECEIVE, per partition |
| Cross-partition atomicity | Atomic | Bridged | None — by design |
| Validator scaling | Vertical | Vertical | Horizontal — pods over FoundationDB |
| Validator-set propagation | Global | Per rollup | Signed EpochCerts, 48 bytes |
| Added trust assumption | — | Bridge + prover | None |
These are architectural properties, not benchmark results. No throughput comparison appears here because Yoalto has not published one.