Becoming a challenger
The approved-challenger registry, wallet-signed filings, stake quotes, and reading your ledger.
Challenging is permissioned in the points era: filings are accepted only from wallets in the approved-challenger registry. The permission gate is about evidence quality while the adjudication tooling matures, not about protecting providers; the roadmap ends at a permissionless fraud-proof path.
Getting approved
The registry is seeded by the operator (modelIntegritySeedChallengersin the router config), and wallets can be added or retired through the admin surface. You can check any wallet's standing at GET /v1/model-integrity/challengers/:wallet. If you want in, the practical route today is demonstrating evidence work: drift analyses, fingerprint mismatches, reproducible substitution cases.
The filing loop
- Find a suspect receipt. Integrity receipts, drift signals from the verification pipeline, and your own paid probing are all fair game. What you are looking for is a specific fill whose output does not match the claimed model.
- Quote your stake.
GET /v1/model-integrity/challenges/quotereturns the stake for that receipt before you commit: max(25 bps, 1x its charge). The server also checks it against your available balance (settled minus locked). - Sign and file. Sign the
ModelChallengeEIP-712 payload (domainOmnious Model Integrity) with your challenger wallet andPOST /v1/model-integrity/challenges. Your stake locks. - Resolution. An operator records the verdict. Upheld pays you half the slash; rejected burns your stake; ambiguous returns it. The mechanics are on The three verdicts.
Reading your ledger
GET /v1/pointssurfaces your challenge ledger alongside your volume points: open, won, and lost counts, locked stake, earned bounties, forfeited stakes, and net. Every number is derived from the challenge rows themselves, so your ledger and the market's books cannot disagree.
- router/src/integrity.ts the registry and EIP-712 verification
- router/src/points.ts challengeLedger: your derived balances