Threat model

Implemented

Threat by threat: prevention, detection, blast radius, response, residual risk.

Threat by threat: prevention, detection, blast radius, response, residual risk. The full analysis lives in the repository's threat model document; this page carries its structure and its conclusions.

#1. Source-account threats

#Side-wallet farming — the most important one

A source builds a public track record on the observed address while trading the opposite way on a wallet nobody is watching. The vault mirrors the visible half.

Prevention is incomplete, and saying otherwise would be dishonest. Nothing in the protocol can prove an address is somebody's only address. What the design does instead: it never claims otherwise, sizes trades proportionally rather than absolutely, and keeps every constraint visible so a depositor is evaluating a bounded strategy rather than a person's honesty.

Residual risk: real, and permanent.

#Transfers masquerading as trades

A balance change from an incoming transfer is not a trade, but it looks like one to a balance-diff observer.

Mitigation: the sizing denominator counts only approved assets, and impact/liquidity checks bound what any single apparent movement can cause.

#Source account compromise

An attacker with the source key can move balances and the vault will mirror what it is permitted to mirror.

Blast radius: bounded by every cap — concentration, cash buffer, liquidity floor, impact ceiling, slippage floor. Not bounded to zero.

#Malicious or spam token transfers

An airdropped token cannot be bought (unapproved) and cannot move the denominator (excluded). Covered by a test.

#2. Token threats

Honeypots, fee-on-transfer, rebasing and blocklisting tokens all break pro-rata accounting. Prevention: an asset is eligible only after a recorded review with decimals cross-checked on chain. Reentrancy via token callbacks is handled by a reentrancy guard and checks-effects-interactions ordering.

#3. Execution threats

Threat	Mitigation
Sandwiching / public-mempool MEV	Slippage floor and price-impact ceiling measured against an independent oracle
Malicious execution adapter	Allowlist; exact approvals revoked in-transaction; residual asserted zero
Arbitrary calldata or recipient injection	Structurally impossible — the order struct has neither field
Duplicate keeper execution	Snapshot accepted only after success; a repeat sees `NoChange`
Keeper censorship or liveness failure	Permissionless calling; drift is visible, not hidden

#4. Accounting threats

Threat	Mitigation
Share inflation / donation attack	Virtual shares and assets, offset 10^6
First-withdrawer advantage	Epoch settlement treats everyone in an epoch identically
Flash-loan NAV manipulation around fee crystallisation	High-water mark plus conservative valuation
Rounding	Reserves round up; claims round down; never in the depositor's disfavour

#5. Oracle and infrastructure threats

Oracle staleness or failure → the adapter reverts, NAV is unavailable, deposits refuse, in-kind exit still works.

Chain reorganisations → an Orbit chain's unfinalised L2 blocks can be reorganised. The indexer marks shallow rows soft and every surface labels them unfinalised.

#Residual risks

The repository's threat model closes by naming eight residual risks that are real, rather than concluding everything is handled. The headline ones: side-wallet farming cannot be prevented; the base asset is upgradeable by bridge governance; keeper liveness is a genuine dependency; and the protocol is unaudited.

See Known limitations.