Reference
Implementation status
Every mechanism in these docs, mapped to live V1, points era, or planned V2, with links to the design docs.
These docs describe one mechanism design at three stages of construction, and the pages badge each piece honestly. This table is the single place all of it lines up: what runs in production code today, what runs with points as the stake asset until the token and vault exist, and what is specified but not built. When a page mixes eras, it says so; when this table and a page disagree, the table is stale and should be fixed.
| Mechanism | Status | Where specified |
|---|---|---|
| Second-score auction (scoring + clearing) | Live V1 | router/src/auction.ts |
| Sessions: cache-aware sticky routing, locked tariffs | Live V1 | router/src/sessions.ts, designs/omnious.md section 13 |
| x402 settlement on HyperEVM (EIP-3009 exact, Permit2 upto) | Live V1 | router/src/settle/evm.ts |
| Epoch payouts, refunds, on-chain anchoring | Live V1 | router/src/payouts.ts |
| Canary probes (model-substitution detection) | Live V1 | router/scripts/canary.ts |
| Sampled audits against a reference deployment | ○ Planned V2 | designs/omnious.md section 6.1 |
| Points-staked integrity challenges | ◆ Points era | router/src/challengeEconomics.ts, router/src/integrity.ts |
| USDC provider bonds and the on-chain vault | ○ Planned V2 | designs/omnious.md sections 6.3 and 7.5 |
| Automated challenge adjudication | ○ Planned | resolution is operator-driven today (admin resolve route) |
| Permissionless provider onboarding | ○ Planned V2 | designs/omnious.md section 12.9 |
| Payment channels | ○ Planned | designs/omnious.md sections 7.4 and 12.9 |
| Solana settlement rail | ○ Documented | designs/omnious.md section 7.3; enabled on demand signal |
| hyper, the first-party provider | ○ Design | designs/hyper.md |
how to read the erasLive V1 means shipped, tested code on the production path. Points era means the mechanism is live today with S1 points as the stake asset; the same rows re-denominate when the token lands, so nothing about the game changes except the denomination. Planned V2 means specified in the design docs and not yet built; nothing planned is load-bearing for anything live.
The forward-looking items are expanded in the roadmap. The V1 trust posture while they land: allowlisted seed providers, canaries, signed receipts, and on-chain anchors, described in Why verification matters.
where this lives in code
- designs/omnious.md the design doc these statuses map to
- router/src the shipped V1 code