One Validator, One Bank
We mined Ethereum when it was proof-of-work. We’ve run validators since it moved to proof-of-stake. And through all of it, one question kept coming back. Why does a staker need governance or an oracle to use liquidity that’s just sitting there?
A validator is transparent by design. Anyone can check its balance and where its withdrawals go. Every attestation and block proposal it makes or misses, every reward and penalty, and any slashing is on public record, epoch by epoch, from the day it activates.
The ETH behind a validator does exactly one job and earns exactly what the network pays. Every time stakers tried to put that capital to work, the answer was to add someone in the middle. Liquid staking typically needs an oracle to tell the execution layer what happened on the beacon chain, plus a DAO that can change the rules. Lending against staked ETH needs price feeds and governance parameters. Each layer is useful. Each one also adds a party you have to trust.
Why it couldn’t be built before
Section titled “Why it couldn’t be built before”For years, the honest answer to our question was that the protocol left no other way. A validator has long been able to point its withdrawal credentials at a smart contract. But that contract could only receive ETH, never request it, since only the validator’s own signing key could start an exit. So any promise backed by stake was really a promise from the operator (“trust me, I’ll pay”), or it meant handing pre-signed exit messages to a third party, which is just another party to trust.
Pectra changed that with two EIPs.
EIP-7002 lets the withdrawal-credential contract trigger withdrawals itself, from partial amounts up to a full exit, straight from the execution layer. For the first time, a contract can claim a validator’s stake without the operator’s cooperation.
EIP-7251 made it practical. Compounding (0x02) credentials let the contract withdraw exactly what it needs while the validator keeps running, and let a single validator hold up to 2048 ETH, with rewards accumulating in the same balance that backs its obligations.
Although letting a contract read the stake directly would be a nice feature to have, what we needed was for the stake to answer to the contract. Now it does.
One validator, one bank
Section titled “One validator, one bank”This is the idea we’ve carried for years, and Pectra finally made it possible. Not a bank with branches and a licence, of course, but a bank in the mechanical sense. Beyond being a yield machine, why shouldn’t a validator also be a balance sheet that takes on obligations, manages its risk, and earns for doing it well? Our vision is to show that those who do more with their stake can earn more yield.
Why bonds came first
Section titled “Why bonds came first”Borrowing for a fixed term at a fixed rate is the most basic thing a bank does, so that’s where we started. On one side are ETH holders whose ETH sits idle and who would take a fixed return for a fixed period. On the other are validators whose ETH is locked and who need liquidity without exiting.
Coffer connects them.
- A validator deploys its own Coffer contract and points its withdrawal credentials at it.
- It sets its own terms, including the interest rate, the minimum and maximum duration, and a buffer held back against penalties.
- A holder buys a bond and receives it as an NFT. The rate is fixed at purchase, whatever the network does afterwards, and the principal goes to the validator.
- The validator keeps the contract funded so each bond is paid at maturity, and keeps validating the whole time.
- If a matured bond isn’t paid, anyone can declare a default. Every bond becomes due immediately at full value, anyone can trigger the validator’s full exit through EIP-7002, and the entire stake lands in the contract to pay holders.
A validator that puts the raised ETH to work above the bond rate, for example by staking it, earns more than its stake alone would. It’s the most direct way to do more with a stake.
Responsibilities are split cleanly. The holder chooses a validator whose backing covers the bond for its whole life. Everything needed for that choice is public on the consensus and execution layers. Our app lays it out, but nobody has to take our word for it. The validator’s job is to have the ETH in the contract when a bond matures. A default isn’t a verdict on backing. It means the validator didn’t do its job, and the consequence follows automatically.
No oracle. No governance. The contracts are immutable. The one protocol fee follows a schedule written into the code. It starts lowest for the earliest bonds, and nobody can change it. The whitepaper and README cover the risks in detail, including the network-wide events no buffer can absorb.
Bonds are the first job, not the last
Section titled “Bonds are the first job, not the last”We built bonds, the simplest and most obvious job. We hope ideas for more validator jobs will emerge over time. Some will reward caution, and others will pay more for taking more risk. Like bonds, each one should depend on the Ethereum protocol and nothing else, giving validators a new way to earn without putting intermediaries back in the middle.
Try Coffer on Hoodi at coffer.bond, read the whitepaper at https://docs.coffer.bond/whitepaper/ and check the contracts at github.com/blockroad-doo.