Security model

The question for every part is the same: if Ed25519 signatures can be forged tomorrow, what can an attacker do here?

Part	Authorised by	After Q-day	Status
Treasury withdrawals	LM-OTS signature	Safe, keeps working	Built
Q2 mint and redeem	Ed25519 wallet	Frozen by the canary	Built
Q2 backing	Basket program address, no key	Stocks stay in the vault	Built
Lifeboat registration	Ed25519 wallet	Frozen, records before the break stand	Built
Snapshots	Ed25519 admin	Frozen, roots before the break stand	Built
Lifeboat recovery claim	LM-OTS signature plus Merkle proof	Planned	Not built
Bonding curve and DAMM v2 pools	Meteora’s programs	Not covered, keep trading	Outside QuantArk
Meteora program upgrades	Meteora’s Ed25519 upgrade key	Not covered	Outside QuantArk
QuantArk program upgrades	Ed25519 upgrade key	Not covered	Open, before audit
Fee sweep into the treasury	Ed25519 fee claimer	Not covered	Manual
Your own wallet	Ed25519	Exposed, like every Solana wallet	Lifeboat is the answer

Design rules

Hash signatures bind every effect. A treasury signature commits to the vault, counter, next key, mint, destination and amount. The transaction fee payer cannot change any of them.
Freeze, do not guess. After the canary trips, anything Ed25519-signed is refused instead of trusted.
The latch is one-way. No admin can unfreeze QuantArk after Q-day.
Rounding favours the vault. Q2 backing cannot fall below 100% through rounding.
Only real token programs. Basket operations reject any token program other than SPL Token and Token-2022, and any vault not owned by the basket.

Area	Coverage
LM-OTS crate	RFC 8554 test vectors. Rust and TypeScript key generation produce identical keys
Program (LiteSVM)	Basket rounding, spoofed vault rejected, Lifeboat, admin-only snapshots, treasury withdraw with replay and tamper attempts, Q-day latch
End to end	Full launch, buy and snapshot flow on a local validator running Meteora’s mainnet DBC binary