Explanations > Security model
Security model
Explain Quovra's trust assumptions and controls.
Security model
Quovra protects the settlement path. It does not claim to remove every data-source assumption.
Trust assumptions
| Component | Assumption |
|---|---|
| Solana | Executes the deployed program correctly |
| SPL Token | Enforces token balances and transfers |
| TxODDS TxLINE | Signs honest score proofs |
| txoracle | Validates TxLINE proof payloads correctly |
| Quovra keeper | Only submits proofs; cannot choose winners without valid proof |
| Faucet | Server-only mint authority is protected |
Controls
- Market terms are stored before settlement.
- Deposit closes at
close_ts. - Settlement validates fixture id and stat key.
- Quovra only accepts known txoracle program IDs.
- Return data must originate from txoracle.
- Payout requires resolved market and winning position.
- Claims are idempotent per position.
Threat model
| Threat | Mitigation |
|---|---|
| Wrong fixture proof | FixtureMismatch |
| Wrong stat proof | StatMismatch |
| Fake oracle program | InvalidOracleProgram |
| Replayed claim | AlreadyClaimed |
| Losing claim | NotAWinner |
| In-play deposit | MarketClosed |
| Faucet abuse | 30s wallet cooldown; add IP limits in production |
| Secret leakage | Keep secrets server-only and out of source control |
OWASP considerations
- Validate request body for faucet calls.
- Avoid leaking server secret names in user-facing errors.
- Rate-limit public endpoints.
- Log failed faucet and keeper operations without logging secrets.
- Use secure hosting secret stores.
Related pages
Search keywords
security, threat model, OWASP, TxLINE, Solana, proof verification
Last updated: [YYYY-MM-DD]