TLDR: A staking protocol should not accept a validator signature alone. It should accept a signature plus a proof that the validator key is non-exportable and lives on a physical machine. This anchors the protocol in the physical world.
In proof-of-stake, a validator key is usually just a private key. This is too weak. A plain private key can be copied silently, duplicated across data centers, rented, or sold, while the protocol sees no difference. If we want staking to correspond to real participation, we need provably hardware validator keys, in the same spirit as provably hardware crypto wallets.
Definition
A provably hardware validator key is a validator key that satisfies three properties:
- The key is generated inside secure hardware.
- The key is cryptographically non-exportable.
- The network can verify, through attestation, that this exact public key is bound to this exact hardware-backed execution environment.
With those three properties, a validator signature no longer means “someone had the key at some point”. It means “someone had access to this physical machine at signing time”.
Why It Matters
A protocol with provably hardware validator keys has a new property: participation requires physical custody.
This is important because today’s proof-of-stake is too virtual. One operator can clone software environments at will. One institutional custodian can centralize thousands of validators behind a standard key-management stack. The protocol cannot distinguish exclusive possession from perfect copyability.
Hardware-bound validator keys change this.
- A validator cannot be spun up from a copied seed phrase.
- A validator key cannot be duplicated silently for backup or resale.
- A validator identity becomes tied to a real machine.
- Slashing becomes stronger evidence of machine-level control.
This is a way to anchor the protocol in the physical world.
Protocol Sketch
The enrollment of a validator would contain more than a public key.
- The validator generates its key inside a TEE, HSM, TPM-backed module, or secure element.
- The hardware produces an attestation statement binding:
- the validator public key
- the code hash of the validator client
- the hardware identity or manufacturer certificate chain
- The chain verifies this attestation at registration time.
- At every epoch, or at random challenges, the validator proves liveness by signing from the same hardware-bound key.
This idea is related to Justin Drake’s 2022 post Liquid solo validating, which also proposes trusted hardware for validator keys. My angle here is different: I am not primarily interested in liquid staking or slashing protection, but in forcing validator participation to be attached to physical hardware.
An even stronger variant is periodic re-attestation. This prevents one-time enrollment followed by migration to a plain software key (which should be imposible anyway with a sound proof of non exportability).
What This Changes
The economic meaning of staking changes.
Today, capital is the scarce resource and machines are cheap wrappers around keys. With provably hardware validator keys, machines become part of the scarce resource too. This creates friction against unlimited logical replication. It does not eliminate centralization, but it changes its shape.
Why? Because a large operator would need large amounts of physical hardware to control large amounts of stake. Worst case, this becomes one machine with hundreds of USB ports and hundreds of attached secure devices. Fine. Even then, the protocol has forced the operator to acquire, power, connect, inventory, replace, and physically secure real objects. This is already a better anchor than infinitely copyable software keys.
In other words, the worst case is that centralization and sybil scale now requires boxes, ports, cables, and inventory management.
Limits
This idea does not magically solve staking.
- It does not prevent rich actors from buying many devices.
- It does not prevent hosting providers from running warehouses of attested validators.
- It does not remove trust in silicon vendors.
- It does not remove side-channel risks or firmware bugs.
But it does remove one bad property of current staking systems: the complete absence of any physical constraint on validator identity.
Final Word
A staking protocol should not only ask “who has stake?” It should also ask “what physical machine is actually participating?”
Provably hardware validator keys provide one possible answer. They do not make proof-of-stake perfect. They make it less ghostly.
Thanks to Javier Ron for sparking that with a BLS question (mind the L)