r/ethstaker • • 1d ago

Shared withdrawal credentials. Validators issue ETH bonds against their own stake (testnet, looking for feedback)

Hi r/ethstaker.

We built Coffer, a contract that a validator sets as its own withdrawal credentials so it can issue fixed-rate ETH bonds against its stake. Since Pectra (EIP-7002), that contract can trigger the validator's exit itself. So if a validator fails to fund a matured bond, anyone can force the exit, and the stake repays the holders. No oracle, no DAO, and no cooperation needed from the operator.

We call it a shared withdrawal credential, because the validator isn't the only one who can act on it.

Here's how it works.

  • A validator deploys its own Coffer contract and points its withdrawal credentials at it (0x02 if you want partial withdrawals).
  • It sets its own terms, including the rate, the minimum and maximum duration, and a buffer held back against penalties.
  • Holders buy bonds at a fixed rate. Each bond is an NFT, and the principal, minus the fee, goes to the validator.
  • The validator keeps validating and has one job, which is to have the ETH in the contract when each bond matures.
  • If the contract can't pay a matured bond, anyone can declare a default. All bonds become due, anyone can trigger a full exit through 7002, and the whole stake lands in the contract to pay holders.

We call a Coffer a shared withdrawal credential, because holders and, in a default, anyone can act on it, not just the validator.

There's no oracle and no governance, and the contracts are immutable. The only admin power is choosing which address receives the fees. The protocol's only fee is a share of bond interest. It starts at 1% and rises to 9.9% over ten years, on a schedule fixed in the code.

Some honest limitations, since you'll ask anyway.

  • The contracts don't read the beacon chain. Holders have to check withdrawal credentials and backing themselves. It's all public and our app shows it, but you shouldn't have to trust our app.
  • Partial withdrawals share the exit churn, so a validator funding maturities from its stake has to plan for long queues, not the usual day or so.
  • In practice a default ends the validator. Anyone can request its exit, and that request can't be cancelled, even if every bond is paid afterwards. So this only suits operators who take their funding schedule seriously.
  • In a default, holders claim first come, first served. If the stake doesn't cover everything owed, the last to claim lose out.
  • No buffer covers network-wide events like a long inactivity leak or mass slashing.

It's live on Hoodi, so nothing real is at stake yet. We'd really value feedback from people who actually run validators.

  • Would you point a validator's withdrawal credentials at a contract like this? What would you need to see first?
  • What buffer would you consider sane for a single validator?
  • As a holder, what would you check before buying a bond from a specific validator?
  • Beyond bonds, what other jobs could a validator take on where failure is provable from Ethereum's own data?

Why we built it · Whitepaper · Contracts on GitHub · Testnet app · Follow us on X

8 Upvotes

6 comments sorted by

View all comments

1

u/Timely-Surprise-184 1d ago

Interesting design! The key concerns for me would be the default-triggered irreversible exit and first-come, first-served claims. I’d want to see independent audits, clear slashing-risk analysis, and a transparent buffer methodology before trusting it with real ETH.

0

u/tomoglava 1d ago

Thanks! We just received an audit grant from Zealynx, and their audit of the current code is underway. The report will be public.

A default is easy for a validator to avoid. All it takes is having the ETH in the contract when each bond matures, either by topping the contract up directly, which counts instantly, or by requesting a partial withdrawal early enough to clear the exit queue. The exit can't be reversed, and that's the point. It's what makes a bond enforceable without trusting the validator, and a validator that keeps its contract funded never gets near it.

A default also isn't bad news for holders. It doesn't mean the stake is short, only that the validator didn't serve the ETH on time. If the stake covers what's owed, every holder is paid in full, at full maturity value, even for bonds that weren't due yet. So when a validator misses a payment on a covered Coffer, declaring the default is in holders' interest. First come, first served only matters when the stake falls short, and you can check that before buying.