Sortis has not been audited. It is deployed on Sepolia only, against a mock yield source, and nothing here should be treated as production infrastructure.
Known limits
- A shard holds 32 stakes. The 33rd depositor is rejected by RegisterFull rather than silently pushing the draw past what it can settle.
- Multi-shard routing is not built. The contracts support many shards; the deployment scripts and the frontend address one. The thesis depends on this and the deployment does not demonstrate it.
- Weight is evaluated at whole hours. A stake held for less than an hour carries no weight, which is what stops a late deposit sniping a draw and also means very short holds earn nothing. The unit is a constant, not a law.
- The epoch wrap queue is deployed but the frontend commits directly, which is the more legible path for a judge and the less private one. The queue is the private path, and the docs say which is which rather than quietly using the weaker one.
- One leaf wins per draw. Several winners would need either several walks, each at full cost, or a different selection rule.
- Settling a draw is not behind a button, because drawLot needs a KMS decryption proof for the published total, which is an off-chain fetch slow enough that a button would appear to hang. Opening a draw is permissionless; settling runs from a script, and on mainnet would run behind a keeper.
Where the frontend is weakest
Reads depend on a public RPC and degrade under rate limiting. Every read retries, and when one exhausts its retries the interface names that state rather than rendering an empty register or an unauthorised account. A failed read and an empty shard must never look the same, and making them look the same was the most misleading bug in this build.
The change that would raise the ceiling
About 728,000 HCU of depth is spent per level of the descent, and most of it is turning a node's intercept and slope into a weight while the walk waits. That is the price of a weight line that never goes stale, and it is paid on the critical path.
Materialising the weights once at openDraw would move it off. Each node's evaluation is independent of every other node's, so a snapshot pass bills against the 20,000,000 global budget rather than the 5,000,000 depth one.
It would not make a shard much larger, because global cost roughly doubles per level and takes over around the same place. What it would do is convert a hard ceiling into a soft one, since global work is checkpointable across transactions and depth is not. That is the named path forward, and it is not in this build.