Threat Model
This page summarizes the main risks Senticore designs around. It is a product-level view for investors, integrators, and security reviewers.
Primary assets
| Asset | Why it matters |
|---|---|
| User collateral | Held by vault contracts and must remain withdrawable |
| Account state | Drives balances, positions, and withdrawals |
| Sequencer logs | Needed for replay, audit, and recovery |
| Publisher keys | Authorize state commitments |
| Admin keys | Control operational surfaces and emergency actions |
Threats and mitigations
| Threat | Mitigation |
|---|---|
| Invalid withdrawal root | Publisher quorum, checkpoint validation, Merkle proofs |
| Sequencer crash | Durable logs, replay support, and recovery procedures |
| Read-model drift | Separation between canonical state and read projections |
| Admin-key misuse | Role separation, operational controls, audit logs |
| Publisher key compromise | Quorum threshold and emergency governance procedures |
| API abuse | Rate limits, authentication, idempotency, replay protection |
| User signing mistakes | Wallet prompts, typed messages, explicit error states |
Non-goals for v1
- Fully decentralized sequencing.
- Permissionless force-inclusion for every order path.
- Governance UI for all protocol decisions.
- A mobile-native application.
Incident expectations
Operators should be able to:
- Detect drift, checkpoint lag, and abnormal balances.
- Halt affected markets or operational planes.
- Preserve logs and replay material.
- Restore service from verified state.
- Publish a user-facing incident report.
See Status for public readiness signals and the planned operational status-page rollout.