Proof-of-Identity: Gating Validator Eligibility on Verified Human Identity
Proof-of-Identity is not a way of reaching consensus: it's a proposed rule about who is allowed to participate in one. Nothing in the running code currently checks that a validator operator holds a verified-human credential distinct from any other validator's. The name describes an intended design, not current, enforced behavior: that concession is not a footnote here, it's the starting fact.
What Proof-of-Identity is, and isn't
Ordinary stake-weighted validator sets, the model nearly every non-proof-of-work chain uses, including Solidus's own, resist Sybil attacks purely through capital: running ten validators costs roughly ten times the stake of running one. That works, but it means a well-capitalized actor can still accumulate outsized influence by splitting money across addresses, not identities. Proof-of-Identity proposes a second, independent admission gate alongside stake: each validator slot should also be backed by a unique, verified human credential, so accumulating influence requires acquiring both capital and distinct verified identities.
It is not a replacement for how blocks actually get agreed on. Block production and finality on Solidus run on ordinary HotStuff BFT consensus, leader rotation, voting, quorum certificates. Proof-of-Identity is a gate on the guest list for that consensus, not a new way of running it. An earlier internal framing used "Proof of Identity" as if it named the whole consensus algorithm; that framing was wrong, and this page does not repeat it.
What it composes
Underneath the eligibility question, three existing pieces do the actual work, and none of them are original to Solidus:
- HotStuff BFT handles agreement once a validator set exists, proposing blocks, collecting votes, committing on quorum. Proof-of-Identity has no opinion about any of this; it only speaks to who gets a seat at the table before HotStuff starts voting.
- Committee Election, using a verifiable random function (VRF), selects which subset of eligible validators actively participates in a given round. This is where Proof-of-Identity's eligibility check would sit as a pre-filter: the pool a VRF draws from would be validators who have both posted stake and hold a verified-human credential, rather than stake alone.
- Slashing punishes bad behavior economically once a validator is seated. Proof-of-Identity doesn't change slashing; it changes who can be slashed in the first place.
Stake would remain a real, necessary gate: a validator still has to bond capital and can still be penalized for misbehaving. Proof-of-Identity proposes adding identity as a second, independent gate next to it, not instead of it. Both would need to hold for a design in which "buy ten identities" is a materially harder problem than "buy ten times the stake." Concretely, this means the eligibility check would happen once, at admission time, before a candidate is even in the pool the committee-election VRF draws from, rather than as an ongoing per-block check. A validator that loses its credential (a revoked or expired identity-verification credential, say) would need to be re-admitted, not merely re-elected; that's a distinction the current specification draws but the running code has no occasion to exercise, since nothing enforces the credential requirement yet.
For a reader evaluating this against the field: proof-of-work chains resist Sybil attacks through computational cost, and ordinary proof-of-stake chains (see Validator) resist it through capital cost. Neither asks who a participant is, only what they've spent. Proof-of-Identity is an attempt at a third axis, cost measured in distinct verified identities rather than compute or capital, layered on top of, not instead of, the capital cost that stake already imposes.
What's actually new here, precisely
Solidus did not coin this term. A public code search returns seventy-seven repositories using the hyphenated phrase in this field, the oldest from 2016, roughly a decade before this project. Binding a verified person to network participation is prior art too, from Proof of Humanity, BrightID, Idena and Worldcoin. The specific, narrow thing Solidus proposes is: validator admission gated on a verified-human credential distinct from any other validator's, so that one operator cannot cheaply run many validators by splitting capital across addresses. That's it, not a new agreement protocol, not a new cryptographic primitive, just a proposed second admission gate layered on an unmodified BFT engine.
Related prior art exists and deserves naming rather than silence. Proof of Humanity uses video submission and social vouching to build a registry of unique humans, primarily for a universal-basic-income-style token distribution. Worldcoin uses iris biometrics to issue a unique proof-of-personhood credential, primarily for Sybil-resistant airdrops and access control. Both attempt to bind personhood to network participation, but for different purposes than this page describes. Solidus's proposed use is narrower than either: it targets validator admission specifically, using an identity-verification credential rather than a new biometric enrollment step, and it says nothing about general network participation, token distribution, or access control beyond the validator set.
The committee number, stated at full precision
Solidus's protocol specification (protocol.md §7) describes a 21-of-up-to-100 VRF-selected validator committee as the target design once eligible validators exist in sufficient numbers. These are two different numbers describing two different things: one is a specification, the other is what currently produces blocks. This page repeats both, together, every time committee size comes up, because this is the single page on the whole node surface most likely to let a design number stand in for a running one if the discipline slips.
That repetition matters again here: Proof-of-Identity's eligibility rule, if and when it's enforced, would apply to the pool the 21-of-100 committee draws from, not to the 4-node dev committee running today, which admits nodes on stake alone with no identity check of any kind.
Why this is described as identity-verification, not a compliance product
Solidus's own internal product documentation describes the underlying mechanism plainly, as "a KYC-verified human DID bound to each validator." That's an accurate internal description, and this page is describing the identical mechanism, just in the vocabulary appropriate to what it actually is at this altitude: a consensus-design property, not a compliance product. "Identity-verified validator eligibility" and "Proof-of-Identity consensus" are the terms used here because the reader of a protocol-design page is asking a different question than the reader of a compliance vendor's page: the former wants to know what changes about who can seat a validator; the latter wants to know whether a specific regulatory checkbox gets satisfied. Those are related questions, but not the same one. Where the underlying credential comes from, how it's verified, and what regulatory frameworks it might eventually satisfy is a verify.solidus.network question, not a consensus-architecture one, that's where the acronym and the vendor-style comparisons belong.
To be concrete about where this stands for a reader evaluating whether Solidus already solves a validator-compliance problem: it doesn't, not yet. The reference flow, a verified-human credential bound to a validator, checked against a regulated custodian's identity records, is not demoable today. It's a thesis written into the protocol specification and the validator guide, not a flow anyone outside the founding team's own nodes has run. For an operator already running validator infrastructure elsewhere and watching regulatory pressure toward validator-level identity checks build (MiCA- and CARF-style reporting regimes are the relevant shape), the honest read of this page is: this is a design that would, if built and enforced, address that pressure. It is not something to point to as already addressing it.
The trust boundary this doesn't resolve
Even fully specified and someday enforced, Proof-of-Identity has a limit worth stating rather than papering over: an identity credential is only as trustworthy as whoever issued it. If a single issuer verifies "this is a distinct human," the system's Sybil resistance is only as strong as that issuer's own controls: a compromised or careless issuer could still mint credentials for the same person twice, or for no one at all. That's not a flaw specific to this design; every identity-binding Sybil-resistance scheme, including Proof of Humanity's and Worldcoin's, inherits the same dependency on whoever does the verifying. It's a real, open question for this design specifically, and it's treated at length on Page 7, which closes the loop this page opens: identity-gated networks are only as sound as the identity layer underneath them.
What can be checked, and what can't
No runnable command exists for this page, and that's said plainly rather than implied around. The mechanism is not demoable: there is no external validator who has gone through a Proof-of-Identity-gated admission flow, because that flow does not run anywhere yet outside internal testing. What can be checked instead:
protocol.md§7 states the 21-of-up-to-100 committee spec, in the publicsolidusnetwork/protocolrepository. That's a specification document, not a report on running state.architecture-system.mddescribes what's actually running: a 4-node dev committee, stake-gated, no identity check.
For background on what a validator is before any of the eligibility question, see What Is a Validator. For the running-vs-roadmap ledger across the whole protocol, see Shipped vs. Roadmap. For the deeper treatment of the identity-issuer trust question this page leaves open, see Identity-Gated Networks.