Good
The property holds. Additional considerations may still be listed, but they do not undermine it.
CROPS | ||
|---|---|---|
 Tornado CashPrivacy protocol | TVL$740.31 M2.00% | |
 Uniswap V3DEX | TVL$844.22 M | |
 SafeMultisig | — | |
 Uniswap V2DEX | TVL$762.79 M |
Every review is attested onchain. Revision 1 covers 4 reviewed projects, as of 28 Oct 2026.
Get your protocol reviewed
Check it against the criteria below before submitting.
Show CROPS ratings in your app
A keyless JSON API, and a badge for protocols we have reviewed.
What the ratings mean
The shape and color of each icon show how a project does on a property.
Medium
The property mostly holds, but something is missing. The tooltip and the project page say what.
Bad
The property does not hold in practice. A project with a bad rating is not listed above.
Not reviewed
We have not reviewed the property yet.
Fully transparent
Used for privacy only, when the protocol makes no privacy claims and everything it does is public.
The four properties
What we look for in each property. This is guidance, not a checklist: the rating is our judgment and can weigh things that are not listed here.
Censorship resistance
Can anyone use the protocol and withdraw their funds without permission?
What we look for
- Anyone can use it and exit it: no allowlist, no KYC, and no operator whose approval is needed.
- The core contracts cannot be upgraded or paused, or any change waits at least 30 days, so users can exit first.
- Passes the walkaway test: users can still withdraw if the team, the frontend and every relayer disappear.
- Any remaining admin power is documented and limited: it applies to all users equally and cannot affect payments or withdrawals.
What lowers the rating
- Transactions are only included probabilistically, with no guaranteed way to force one in.
- A single relayer, or relayers that users cannot bypass by relaying their own transactions.
- A pause or a transaction filter that can be applied without notice, in the contracts, the RPC or the node.
Open source
Can anyone inspect the code, build it, and run it independently?
What we look for
- A license granting the right to run, modify and fork, as listed on the OSI register of approved licenses. Code under a delayed license counts only once that license has converted.
- Every component needed to use the protocol is published, such as the contracts, the interface and, for rollups, the node and prover.
- Deployed bytecode is verified against the published source. Where there is a ZK verifier or a program hash, anyone can regenerate it from source.
- It can be built and run locally, so it can actually be forked.
What lowers the rating
- A source-available license that restricts commercial or competing use.
- A closed-source component that users depend on, such as the prover, indexer or interface.
- Unverified contracts, or a program hash that no one outside the team can reproduce.
Privacy
How much privacy do users actually have?
What we look for
- Privacy is unconditional: no provider, list or approval decides who gets it.
- Outside observers cannot link transactions, thanks to ZK proofs, encrypted state or stealth addresses.
- No backdoor: no privileged viewing key and no way for an admin to deanonymize users, now or retroactively.
- Private by default, not an optional mode.
- The size of the anonymity set is published, together with what remains public.
What lowers the rating
- Metadata visible to a third party, such as a provider, an oracle or a sequencer, or an anonymity set too small to protect users.
- Compliance checks or address screening anywhere in the stack, even if not currently enforced.
- Privacy that depends on a relayer staying available, or that users can be excluded from.
- Privacy that relies on trusted hardware, such as a TEE.
Security
Can users lose their funds?
Security is a complex property. We evaluate if the projects follow best practices. This is not an audit or an endorsement of a protocol's security, and never a guarantee that funds are safe.
What we look for
- Contracts holding user funds cannot be upgraded, or upgrades wait at least 30 days, so users can exit first.
- Where the system posts state to L1, that state is validated by proofs, not by an external oracle or a committee.
- No dependency on permissioned actors that can mint, move or misprice user funds, such as a price oracle or a bridge run by a fixed set of operators.
- An ossification score of at least 80, which takes about a year without a critical change.
- Protection against a single failure, such as a second proof system or circuit breakers, or a clear statement of the maximum possible loss.
What lowers the rating
- A single proof system with known vulnerabilities, or no limit on what a prover bug could cost.
- A multisig that can upgrade contracts or replace state roots without delay.
- An ossification score below 80 limits Security to medium. Below 50, which means a critical change within roughly the last five weeks, Security is bad and the project is not listed.