Threat Model
This document describes the adversaries Shinobi Cash considers, the attacks they can mount, and how the protocol mitigates them.
Adversaries
Malicious ASP (Association Set Provider)
What they control: Approval/rejection of deposits into the compliant set.
| Can Do | Cannot Do |
|---|---|
| Censor deposits (refuse to approve) | Steal deposited funds |
| Delay approval indefinitely | Deanonymize past withdrawals |
| Reject legitimate deposits | Access user secrets or nullifiers |
- Rejected deposits can be recovered via "ragequit" (reveals depositor, but funds are safe)
- ASP decisions are on-chain and publicly auditable
- Future: multiple competing ASPs possible
Malicious Solver
What they control: Filling cross-chain intents.
| Can Do | Cannot Do |
|---|---|
| Delay or refuse to fill intents | Steal escrowed funds |
| Front-run other solvers | Redirect funds to wrong recipient |
| Go offline | Forge proofs or bypass ZK validation |
- Solvers are permissionless — anyone can run one
- Economic incentives (solver fees) drive correct behavior
- Expired intents trigger refund commitments — funds return to pool
- No single solver can block the system
Malicious Indexer
What they control: Serving deposit/withdrawal data to the UI.
| Can Do | Cannot Do |
|---|---|
| Withhold data (notes don't appear in UI) | Forge deposits or proofs |
| Serve stale data | Steal funds |
| Degrade UX | Prevent on-chain withdrawals |
- Indexer is a read-only UX layer — not trusted for correctness
- Users can generate proofs from on-chain data directly
- Multiple indexers can exist (not a single point of failure)
Malicious UI
What they control: The web interface users interact with.
| Can Do | Cannot Do |
|---|---|
| Phish users | Access funds without user signature |
| Display incorrect data | Forge ZK proofs |
| Trick users into signing malicious txs | Bypass wallet confirmation |
- UI is explicitly untrusted
- All sensitive operations require wallet signatures
- Users can self-host or use CLI tools
- Proofs are generated client-side, never sent to servers
Malicious User (Attacker)
What they try: Double-spend, forge proofs, deanonymize others.
| Attack | Mitigation |
|---|---|
| Double-spend same deposit | Nullifiers prevent reuse; once revealed, marked spent |
| Forge withdrawal proof | Groth16 SNARK verification on-chain |
| Deanonymize other users | ZK proofs reveal nothing about which deposit was spent |
| Front-run withdrawals | Context binding in proofs prevents replay |
Attack Scenarios
Scenario 1: Solver Collusion
Attack: All solvers collude to refuse filling withdrawal intents.
Impact: Withdrawals delayed until intent expiry.
Outcome: Escrowed funds return to pool as refund commitments. User can withdraw refund normally. No fund loss.
Scenario 2: ASP Censorship
Attack: ASP refuses to approve any deposits.
Impact: New deposits cannot join the compliant set.
Outcome: Users can ragequit (recover funds with privacy loss). Protocol can add alternative ASPs.
Scenario 3: Indexer Downtime
Attack: Indexer goes offline or serves empty responses.
Impact: UI cannot display notes; users cannot easily discover their deposits.
Outcome: No fund loss. Users can query on-chain events directly or wait for indexer recovery.
Scenario 4: Proof Replay
Attack: Attacker captures a valid proof and tries to replay it.
Impact: None.
Outcome: Context binding (hash of withdrawal data + scope) makes proofs non-replayable. Same proof cannot be used for different withdrawal.
What Shinobi Cash Does NOT Protect Against
- Compromised wallet — If your private key is stolen, attacker can sign withdrawals
- User error — Withdrawing to wrong address, losing recovery phrase
- Contract bugs — Smart contracts are not yet audited; bugs could cause fund loss
- Regulatory action — Protocol cannot prevent legal enforcement against users
- Timing correlation — Depositing and immediately withdrawing same amount reduces privacy
Security Assumptions Summary
| Component | Trusted For | Not Trusted For |
|---|---|---|
| ZK Proofs | Correctness (math) | — |
| Smart Contracts | Correctness (code) | — (unaudited) |
| ASPs | — | Availability, fairness |
| Solvers | — | Availability, honesty |
| Indexer | — | Correctness, availability |
| UI | — | Anything |
| Bundlers (ERC-4337) | Tx relay | Privacy (public mempool) |
Related Pages
- Trust Assumptions — Bullet-point summary
- Compliance — How ASPs work
- Cross-Chain Architecture — Solver and intent system