Before you buy

A bond is only as good as the validator behind it, and the protocol checks none of what follows. The contract verifies the issue size capacity when you buy, nothing else. The contracts README says it without decoration, “The condition is an off-chain evaluation tool, not an on-chain rule. No contract function reads the consensus balance, so the condition is never checked by code.”

The Review Bond modal will not let you buy until you tick three statements, and it links here under the third. Each section below is one box, the sentence word for word, then what it means and how to verify it. The marketplace asks for the same things in its own words, which On the marketplace sets out at the end.

The validator and its balance

“I have verified that this validator’s withdrawal credentials point to this Coffer, and that its balance on both layers covers this bond’s maturity value together with every bond already outstanding.”

Two checks, and the protocol makes neither.

The credentials. Withdrawals authenticate against the address inside the validator’s withdrawal credentials, so credentials that point anywhere but this Coffer make the stake unreachable and the bonds unbacked. Open the validator through the Public key link on the terms card, which leads to a beacon explorer, and read the credentials there. The type is 0x02 and the address is the Coffer’s, the one in the title of the page you came from. A validator still on 0x00 has committed to nothing yet, and anyone can create a Coffer against any public key, so a mismatch is not a corner case. The app reads the credentials too. A Coffer whose validator is on 0x00, or whose credentials name another address, shows the pill Missing Credentials or Key/Address Mismatch, and Browse never lists it.

The balance. What stands behind a bond is the validator’s whole backing, the ETH in the Coffer contract on the execution layer plus the stake on the beacon chain. It must cover this bond’s maturity value together with every bond the Coffer still owes. The terms card shows the parts. Validator Balance is the beacon balance, Contract Balance is the contract balance, Issue Size is what the Coffer can still issue, and the bar under them reads Issue Size against Backing in the coverage colour. Validator Balance shows a dash when the validator’s credentials do not point to the Coffer, because the app counts that stake only for the Coffer the credentials name. That colour is the check in one glance. Promised is the remaining issue size plus everything owed, and buying moves your maturity value from the first into the second. A green or yellow bar before you buy therefore already covers your bond, every bond outstanding and everything the validator could still sell. Red means the Coffer promises more than it holds. The app does not list a red Coffer in Browse and shows no buy card on one. It shows none on a grey one either, where the band is unknown.

To redo it yourself, take four figures. The contract balance is on the Coffer’s page on a block explorer. The validator’s balance is on its beacon explorer page. The remaining capacity is Issue Size on the terms card. What is still owed is the Value column of the Coffer’s bond table. Count the beacon balance only if the credentials are 0x01 or 0x02 at the Coffer’s address. Contract plus beacon must be at least Issue Size plus the sum of that column. The figures the app shows are a recent reading and not the live chain, which is why the box says verified rather than seen.

The terms and the buffer

“I accept this bond’s terms, the maturity value I will receive, the maturity date and the fee, all fixed at purchase, and I judge the validator’s buffer adequate for this bond’s duration.”

The estimate card in the modal shows the figures you accept. The headline is the maturity value, principal plus interest less the protocol fee, and it is a net figure, there is nothing further to subtract. The fee is taken from the interest at the rate on the card and stays at that rate for this bond however the schedule moves later. The unlock date is the maturity. Once the purchase lands these three are written into the bond and no one can change them, a validator’s later changes to the Coffer’s terms apply to future bonds only. How a bond works has the formulas and Fees the schedule.

The buffer is different. It is not a promise but the validator’s own estimate, the share of the beacon balance held back from the issue size against penalties, and the protocol neither enforces it nor checks that it is sensible. You do. The whitepaper’s sizing rule, “Choosing the buffer R therefore depends on the bond’s duration, since the holder expects enough reserve on the consensus layer to keep a bond backed even if the validator goes offline for a long period.” A long bond needs a wider buffer than a short one, and a validator that is one of several under common control needs a wider one still, since one cause can slash them together. The buffer you see on one Coffer says nothing about the operator’s other validators. The terms card shows it as Issue Size Buffer.

What can go wrong

“I understand that only the validator’s balance backs this bond, that penalties beyond the buffer, or a network-wide event that no buffer prevents, can leave it partly or fully uncovered, and that a defaulted Coffer pays first come first served from what it holds.”

Your principal does not stay in the contract. It goes to the validator’s wallet the moment you buy, net of the fee, and from then on the bond rests on the validator’s balance, which rewards and penalties move every day while the issue size does not follow. Penalties inside the buffer leave every bond covered. Penalties beyond it, a validator offline for months or slashed on its own, leave the bond partly or fully uncovered. Two events are beyond any buffer, an inactivity leak, when the chain stops finalising, and a large-scale correlated slashing. Both need a failure the size of the whole network, they stay rare, and a long bond carries them longer. Risks walks through each mechanism.

When a matured bond is not paid, anyone can declare a default, every bond becomes redeemable at once, and anyone can ask the network to exit the validator so the stake is swept into the contract. Claims are then paid first come first served from whatever the contract holds. Whoever claims first is paid in full while the money lasts, and whoever claims last may be paid in part or not at all. When a validator defaults has the steps.

On the marketplace

A bond bought from another holder is the same claim on the same coffer, so everything above applies unchanged. The Review Bond modal on a listed bond’s buy card asks for it in the trade’s own words. The maturity value it names is the bond’s remaining value rather than a fresh bond’s, what you pay now is the ask plus the marketplace fee rather than a principal, and no protocol fee is charged, because that one was paid when the bond was minted. Its third box is word for word the third box above. Buy or accept walks the whole purchase.

Making an offer asks once instead of every time. The Review Approval modal opens on the WETH approval, the one transaction standing behind every offer that wallet will ever sign, so its boxes are written as a commitment to run these checks before each offer and as an acknowledgement of what the allowance lets the marketplace draw. After that the offer button carries the line “Offering confirms the checks you accepted when approving WETH” with a link back here, on a fresh offer and on a revision alike. Make an offer walks the steps.