A Penalty Is Only a Deterrent Against the Thing It Can Detect
Any penalty applied on our network today is an internal accounting adjustment with no market value, which is the limit to hold while reading the rest.
The mechanism, and the claim built on it
Operators post a bond. Misbehave and the bond is reduced. The argument is that honesty becomes the profitable choice, so the network is secured by economics rather than by trust.
That argument is sound and it is narrower than it sounds, because a penalty only deters behaviour the system can observe and prove.
Everything else is unpriced.
What is actually detectable
Signing two conflicting things for the same slot. Cryptographically undeniable: two signatures over incompatible statements, both valid, both from the same key. Nobody can argue about it, which is why it is the canonical slashable offence everywhere.
Being absent. Extended downtime is observable by everyone, so it can be penalised without a dispute.
That is close to the whole list, and both are protocol misbehaviour: an operator breaking the rules of the consensus game in a way the game itself records.
What is not detectable, and therefore not deterred
Observing what passes through. An operator who reads data, copies it and never acts on it has left no trace inside the protocol. No stake is reduced for a thing nobody can prove.
Censoring selectively. Declining to include particular transactions while behaving normally otherwise is very hard to distinguish from ordinary variation.
Coordinating quietly. Operators who appear independent and are not have broken an assumption rather than a rule, and assumptions are not slashable.
So economic security is strong against the failures a protocol can see and weak against the ones it cannot. That is not a criticism of the design; it is what the design is for. It becomes a problem only when the claim gets stated as though it covered everything.
Why we built it before it can bite
Because retrofitting penalties under a live validator set is worse than starting with them. The rules an operator joins under are the rules they accepted, and changing them later is a governance problem rather than an engineering one.
That is a bet on a later requirement, not a present benefit, and a buyer should price it as the former. Independent operators would make it real; the mechanism existing does not.
What to ask any network claiming economic security
"What is actually slashable, named individually?" The list is usually shorter than the pitch. If it is only equivocation and downtime, say so, because that is the honest answer almost everywhere.
"What is a slashed unit worth today?" If the token has never been distributed, the answer is nothing, and the security argument is a design document.
"How many independent operators?" Not validators. Operators. Penalties between processes run by one team deter nothing.
"What does slashing not cover?" A project that can answer this has thought about its threat model. One that treats the question as hostile has not.
Where this leaves a decision
If you need a network whose security rests on real economic consequence today, ours does not qualify, and the honest reason is that there is nothing at stake yet in the sense the word requires.
If you are evaluating the design rather than the deployment, the mechanism is implemented against the failures a protocol can prove, its blind spots are named above rather than left for you to find, and the deployment gap is a fact to weigh rather than a detail.