Threat Model

A threat model is a written, explicit answer to a question that's easy to skip and expensive to skip: what is this system actually trying to defend against, and, just as important, what is it explicitly not trying to defend against? Without one, "this system is secure" is close to a meaningless claim, because nobody has agreed what would count as a failure. Secure against whom, capable of what? A system with no stated threat model can't really be evaluated at all, every security claim about it is unfalsifiable by construction.

A useful threat model states the adversary's assumed capabilities precisely (can they read all network traffic? modify it? control some fraction of participants? forge signatures?), and then, for each stated capability, names what specifically prevents that capability from causing harm. It's a discipline, not a document format: the value is in forcing the exercise of thinking adversarially before something breaks, rather than explaining after the fact why it did.

Who formalized the practice

STRIDE, developed at Microsoft by Loren Kohnfelder and Praerit Garg in 1999, is the classic structured methodology still widely taught today: a mnemonic covering six categories of threat (Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, Elevation of privilege) meant to be walked through systematically for any given system component, rather than relying on whatever threats happen to occur to a reviewer. Solidus did not invent this or any comparable methodology.

Solidus's own threat model, and its honest gap

Solidus has a real, written threat model: docs/protocol.md §13.1 states the adversary capabilities the protocol is designed against, up to 33% of the validator committee (stated as "7 of 21"), full observation of network traffic, Sybil attacks via multiple identities, and attempts to correlate user activity across verification requests, followed in §13.2 by a mitigations table mapping each named threat (Sybil attack, stake-grinding, double-signing, credential forgery, privacy leakage, eclipse attack, replay attack, key compromise) to a specific countermeasure. This is a genuine specification artifact, not marketing copy dressed up as one.

But read the headline number carefully against what's actually running, because the gap matters: "33%, 7 of 21" describes the target 21-validator active committee design (see Committee Election). A scale that has never actually been deployed. The live public testnet runs exactly four validators (see Validator). Standard Byzantine fault tolerance requires f < n/3 faulty participants for safety; at n = 4, that arithmetic tolerates exactly one faulty or offline validator, not seven. A document whose headline percentage is accurate for its target design can still describe a materially weaker real-world margin today, and that's exactly the kind of gap this Lexicon exists to name rather than let a confident-sounding number paper over.

Check it yourself

docs/protocol.md §13 is Solidus's own specification document; this Lexicon has no confirmation it's published on a public page, so no public URL is claimed for it here, said plainly rather than inventing one. What you can check independently: rpc.solidus.network is a live, public endpoint confirming today's four-validator committee (see Validator), and the public solidusnetwork/protocol repository's consensus crate shows the VRF election mechanism exists in source but has never run at the 21-validator scale the threat model's headline assumption describes (see Committee Election).