The most common question we get about Sudo's escrow system is: who are the validators?
The answer is intentional and short: even we don't know who any specific dispute panel is, and we built the system so that we cannot find out. This post explains why anonymous-by-default isn't a privacy nicety — it's the only design that holds up under adversarial pressure.
What a validator does on Sudo
When two people open an escrow, the contract holds the funds. If they agree, Release sends the funds out. If they disagree, Dispute triggers the validator panel: 5 wallets staked into the validator set, drawn at random by an on-chain VRF, who commit-reveal their decision and settle the dispute on-chain.
The validator never sees the parties' identities — only the dispute card and the evidence each side chose to publish. The validator stakes SUDO before voting. If their vote is a clear outlier on a panel where there is consensus, they get slashed (small slash) or removed from the set (large slash, only triggered by patterns over time).
Each validator earns a small fee per dispute they resolve. Run an honest panel, earn the fee. Run a corrupt panel, lose your stake.
Three failure modes if validators are public
We started out, in 2023, planning to ship a public validator scoreboard. Names, addresses, dispute records, all of it. We changed our mind after working through three scenarios that became impossible to defend.
1. Targeted bribery
If a validator's wallet is known and reachable, a determined disputant can DM them: "Vote my way on dispute #4821, I'll send 5 ETH." Even if the validator refuses, the cost of refusing — the friction of receiving and dismissing these messages — degrades the network. And of course, some validators will not refuse.
If the validator is anonymous and only addressable through the disputed escrow itself, the bribery path is broken. The disputant doesn't know who's on the panel until the panel reveals — at which point the vote is already cast on-chain. There's nobody to bribe.
2. Targeted retaliation
A validator who has settled hundreds of disputes will, statistically, have decided against a few users who feel cheated. Some of those users will go further than the dispute itself. We have seen this pattern in every adjudication system that publishes the names of the adjudicators: the people who lose start filing complaints, harassing accounts, sometimes worse.
The on-chain primitive that lets us run a global, neutral arbitration network depends on validators not being personally vulnerable. We won't ship a system where a wrong-but-popular decision becomes a personal safety issue.
3. Selective evidence
If you knew that vitalik.sudo was on your dispute panel, you would phrase your evidence very differently than if you knew meganova.sudo was on it. That's adversarial UX. The dispute is meant to be decided on the evidence both sides chose to publish, not on a mental model of what a specific known panelist might find persuasive. Anonymity makes the evidence the only signal.
How "hidden by default" actually works
The validator set is public. The total stake is public. Every dispute outcome is public. What's hidden is the mapping between specific disputes and specific validator wallets at the time of the vote.
Concretely:
- VRF panel selection. When Dispute is tapped, the contract draws 5 wallets from the validator set using an on-chain VRF seed. The seed is committed minutes in advance and revealed at dispute time. Even a validator monitoring the chain doesn't know in advance which dispute they'll land on.
- Anonymous transit. The dispute card is delivered to each selected validator through a relayer mix. Each validator only sees that they were selected for this dispute; they don't see who else is on the panel until the reveal.
- Commit-reveal voting. Each validator publishes a commit (a hash of their vote + a salt). After all five commits land, each reveals. The vote is settled by majority. The commit-reveal step means the first vote can't anchor the others.
- Stake-blind incentives. Validators are paid per dispute, not per outcome. They can't tell which party is "richer" from the dispute card — the funds in escrow are visible but the rest of the parties' wallets are not surfaced.
- No post-hoc deanonymisation. After the dispute is settled, the wallet addresses involved are visible on-chain to anyone who reads the contract event — but those addresses don't trivially link to .sudo handles, and nothing in the protocol surfaces "here are the people who voted in your dispute" to the disputants.
The whole pipeline is designed so a validator's wallet stays addressable for staking and payouts but not addressable as a person who can be contacted, bribed or harassed.
What it costs us
Hiding validators costs us a marketing surface. We can't show "audited by these 87 well-known wallets". Some users would prefer that visibility because it feels safer. The validator network looks more like infrastructure and less like a face.
That's an acceptable trade. We optimised for the worst case, not the best.
What you can verify even though validators are hidden
This isn't security through obscurity. The validator set composition is public; the stake is public; the VRF seed and the dispute outcome are public; the commit-reveal hashes are public.
You can re-derive every dispute outcome from public chain data and confirm:
- Every dispute panel was selected fairly from the eligible validator set
- Each panelist had their stake at risk
- The reveal hashes match the commits
- Slashes were triggered correctly when panel members voted clearly off-consensus
You just can't tell which validator made which decision. That's the only piece of information the protocol intentionally withholds — because surfacing it breaks the threat model the rest of the design depends on.
When validators are not hidden
Two cases:
Validators who opt in to public attestation. A validator can publish a signed statement linking their .sudo name to their validator wallet, then advertise it themselves. Some institutional validators do this — they care about brand more than personal safety. It's their call.
Slashing events. When a validator is slashed for clear bad behaviour, the slashing event is public on-chain. The wallet is named in the event log. We make no effort to obscure misbehaviour. The penalty is meant to be visible.
A note on regulation
We get asked occasionally whether anonymous validators create a compliance problem. The short answer: validators are neutral software operators, not parties to the dispute, and the protocol gives them no way to favour one side. They are closer to the people who run network nodes than to mediators.
We work with regulators in jurisdictions where Sudo operates. So far, every regulator we've talked to has accepted that anonymity at the validator layer is a feature of the cryptography, not a way to evade scrutiny. The dispute trail is fully auditable. Only the personal identities of the network operators are kept off the trail.
Bottom line
You don't need to know who decided your dispute to trust the result. You need to know:
- The selection was random and verifiable
- The voters had skin in the game
- The voters could not collude or be bought
- The outcome can be reproduced from public state
That's what hidden-by-default validators give you, and it's why we won't change the default no matter how often we get the question.
Read the complete validator operating policy. The operator guide and rewards math live on the validator landing page. And every line of the panel-selection contract is open source on GitHub.
— The Sudo Validator team