Skip to content

Coffer lifecycle and statuses

A Coffer’s status follows the validator behind it on the beacon chain. The app shows it as a pill, the same pill everywhere, and the coffer’s detail view turns it into a lifecycle screen that says what to do next. The table lists every status with the meaning the app gives it.

PillMeaning
Status UnknownValidator not yet found on the beacon chain
Deposit in QueueValidator deposit is waiting to be processed by the beacon chain
ActivatingValidator registered, waiting for activation eligibility
Activation QueueValidator eligible, waiting for activation epoch
Key/Address MismatchCoffer public key does not match beacon chain validator
Missing CredentialsValidator has not set execution withdrawal credentials (0x00)
Must ConvertValidator must convert from 0x01 to 0x02 compounding credentials
ActiveValidator is active and accepting bonds
ExitingValidator is in the beacon exit queue
SlashedValidator has been slashed and is pending exit
Slashed (Exited)Validator was slashed and has exited the beacon chain
ExitedValidator has voluntarily exited the beacon chain

Two notes on where the pill appears. In the coffers table the column shows a one word form. Status Unknown reads Unknown there, the three pending statuses all read Pending, and the detail view draws the finer line. And an owner who closes their Coffer to new bonds sees Closed in place of Active, closing is your own switch and does not outrank a real problem.

One more thing about the Browse list. It opens on the Active group, so a pending, exiting, slashed or exited Coffer shows only once its group is selected. It never lists a Coffer whose status is Status Unknown, Key/Address Mismatch or Missing Credentials. It does not list a Coffer whose mark is red either, the uncovered band, until the mark is green or amber again. A new Coffer is red until its validator is on the beacon chain, so Browse lists it only from then on. While the mark is red or grey, a visitor to your Coffer’s page sees no Buy Bond card. Browse also leaves out the connected wallet’s own Coffers, so the list is not where you look for your own. Your portfolio always shows it, whatever its status or its mark. A default does not hide a Coffer by itself, the Coffer reads by its lifecycle status, and the default shows on its Terms card.

What decides each status, which one wins when more than one fits, and the words the lists and the filters use are on Statuses across the layers.

The second rung of every screen is the withdrawal credentials, because a stake reaches only the Coffer its credentials name. Once they point to your Coffer the rung is done. It reads “Withdrawal credentials set”, with the line “The credentials for this validator key point to this Coffer.”

Waiting for your validator deposit covers Status Unknown and the three pending statuses. On Status Unknown the second rung is the open one, “Set your withdrawal credentials”, and it says exactly what to do, “Deposit 32 to 2048 ETH to your validator using 0x02 compounding credentials that point to this Coffer. Once the beacon chain picks it up, the Coffer goes live and you can issue bonds.” The credentials travel inside the deposit, so making the deposit is how you set them. Once the deposit is found with credentials that point to the Coffer, that rung and “Deposit landed” are done, and the open rung reads “Beacon chain picks it up, usually a few hours”. Bonds can already be bought while setup runs, and the table above them notes, “Validator setup isn’t finished. Bonds are backed only once the deposit lands.”

One step left to go live appears for a 0x01 validator. Its rung asks you to press the convert action, “The validator uses 0x01 credentials. Convert to 0x02 compounding credentials so the Coffer can track its balance and issue bonds.”

Ready for the first bond is the finished ladder, “Bonds appear here as soon as someone buys one.”

Validator setup problem covers two states, and both stop at the second rung. A key conflict, “This public key is already registered on the beacon chain with withdrawal credentials that don’t point to this Coffer. Setup can’t continue with this key.” And missing credentials, under the title “Validator hasn’t set its withdrawal credentials”, “The validator has 0x00 (BLS) withdrawal credentials. Set an execution withdrawal address pointing to this Coffer to continue. Until then this Coffer has no consensus backing at all and shouldn’t be used for issuing bonds.” The first has no fix on this Coffer, the second is the 0x00 path from Before you create a Coffer.

The missing credentials screen shows whatever the validator itself is doing. A deposit still in the queue, an activating validator, a slashed one and an exited one all read Missing Credentials while the credentials are 0x00, and the rungs after the second stay grey. A deposit in the queue that names another address reads Key/Address Mismatch.

Validator exiting, the validator is in the beacon exit queue, its bonds can no longer run to term, and the stake settles to the Coffer contract once the exit completes. Validator slashed, penalties are reducing the stake backing the Coffer, and the validator is on its way out. Validator exited, with or without a slashing, the stake has been withdrawn to the contract and bonds settle from there.

These three screens show only for a validator whose credentials point to the Coffer. With 0x00 credentials the Coffer reads Missing Credentials, because that stake does not reach it.