Become a validator

The September 14 release schedules funded validator admission and the exit/withdrawal lifecycle at epoch 2884 (2026-09-14 22:35:19 UTC). Admission was observed active on both public archivals. Protocol activation does not complete production qualification.

Release evidence and remaining requirements

1. Weak-subjectivity checkpoint: artifacts published; signer assurance remains separate. The epoch-1536 envelope has three verified signatures under a 2-of-3 signer set. Its verification record explicitly says external roles are declarations, not independent identity attestations. It also records an all-zero validator-set-root placeholder. The operator confirms that the ceremony took place on September 4, 2026. That date is an operator statement; the published cryptographic record does not independently attest the specified Phase-A custody arrangement or the external signer’s identity. Initial sync refuses this checkpoint at epoch 3552 (2026-09-22 08:43:19 UTC).
2. Coordinated release: epoch 2884 published. The retained fleet audit recorded 64 upgraded, qualified validators at 2026-09-14 22:59:46 UTC. This audit is after the activation time and must not be presented as proof that all nodes were upgraded before the epoch. A flag day requires all validating nodes to run the agreed consensus rules before activation.
3. Exit/withdrawal lifecycle: enabled in this release; complete mainnet qualification pending. A controlled funded deposit → activation → exit → withdrawal → payout-spend cycle has not yet been qualified on mainnet. An ordinary exit included at epoch E matures at E + 32 + 2048, subject to consensus conditions and possible slashing extensions. Do not treat a successful deposit as proof of a tested withdrawal. Review the remaining qualification before committing funds.
4. Public P2P bootstrap: tested for the pinned release. A keyless observer started with empty data and the public checkpoint reached the live head on September 14 at 23:11:43 UTC through the public bootnodes. This verifies that bootstrap path; it is not a production transport audit or proof of independently operated observers.

Exchange observers do not need validator admission

An observer uses no validator key, no bond, and has no validator slashing exposure. Follow Run a node and stop after observer synchronization. Do not generate a validator identity or submit a deposit for exchange integration. Authenticate the checkpoint and signer identities through independent trusted channels and meet the deposit-crediting requirements before crediting. Admission activation does not satisfy those requirements.

Dated observer, Phase-A and admission status.

The protocol

Everything in this section is consensus fact from the merged implementation — the spec is docs/specs/BLOCH-FUNDED-VALIDATOR-ADMISSION.md in the public repository.

FundedDeposit — wire tag 0x0B

• Consumes 1–128 existing, strictly-ordered, distinct UTXOs owned by one funding key; creates the validator record, an activation-queue entry, and one change UTXO.
• Input values come from committed state — no RPC parameter or genesis-offset allowance can manufacture a bond.
• The legacy Deposit (0x02) and Delegate (0x04) tags remain refused.

Two role-separated PQ authorizations

One unsigned intent, two signatures over it, from two roles that may live on different machines and different keys:

• FUNDING — the owner of the coins authorizes: the UTXOs, the stake, the validator identity, the withdrawal route, the change/refund script, and the fee budget.
• POSSESSION — the operator proves control of the validator key and accepts the terms, including the RANDAO commitment and the commission.

Both signatures use the suite-1 envelope b1 0c 01 00 = ML-DSA-65 and Falcon-1024, each signature verifying both algorithms. Funding and validator keys may differ; there is no custodial coordinator.

The intent binds the SHA3-256 of the canonical genesis manifest plus an inclusive expiry epoch — anti-replay across networks and across time.

Bond bounds

Conservation

The transaction balances exactly, by consensus rule:

sum(inputs)    = B + C + Fmax + T
change created = C + Fmax − Factual
charged        = Factual + T

where B is the bond, C the signed minimum change, Fmax the signed maximum base fee, Factual the base fee actually charged at inclusion, and T the tip. The refund always goes to the signed change script, never to a validator reward. Inclusion above the signed maximum base-fee rate is refused.

Activation queue

• Ordered by (deposit epoch, pubkey hash).
• Delay of ≥ 8 epochs before activation; at most 4 admissions per epoch.
• Registration queues — it does not grant consensus weight.

Signing roots

intent_root      = SHA3-256("BLOCH:VALIDATOR:DEPOSIT:V1"    || fields 1–8)
funding_root     = SHA3-256("BLOCH:VALIDATOR:FUNDING:V1"    || intent_root)
possession_root  = SHA3-256("BLOCH:VALIDATOR:POSSESSION:V1" || intent_root)
txid             = SHA3-256(DS_TXID || intent_root)   // existing rule; witness-independent

Wire format (0x0B)

Prepare now

Prepare infrastructure and review the remaining qualification before committing funds. Observers need only the public node files and an authenticated checkpoint; validator keys and bonds are not required.

1. Hardware. Linux x86-64, 2+ vCPU, 8 GB RAM, 80 GB SSD — the same footprint as an observer node.
2. Build from the public source. Use the pinned release and checksum instructions in this portal's Run a node section — they are identical for a validator candidate.
3. Offline key ceremony. Generate the validator keystore offline; keep the sealed keystore, the RANDAO seed, and the withdrawal-authority backups secure and separate. The withdrawal script must name a PQ key the intended recipient actually controls — registration does not establish that control. keygen --index auto exists for rehearsal only (devnet-grade).
4. Run a following node now (observer posture), so your infrastructure is proven before your money is at stake. The public bootstrap test passed; independently authenticate the checkpoint and signers before trusting its history.

The step-by-step at activation

These commands describe validator registration, not observer setup. Use the pinned release, confirm active admission on your synchronized node, and review the outstanding production qualification before signing or broadcasting.

1. Query admission state

getvalidatoradmission — an unarmed build answers active:false, activation_epoch:null, plus the network domain, head epoch, stake bounds, queue limits, and next base fee. Fee and bound figures are quoted from the head; consensus rechecks them at inclusion.

2. Gather inputs and public material

listunspent for the funding authority; export the two suite-enveloped public keys as hex files, plus the RANDAO commitment from the offline ceremony. No private material enters the draft.

3. Prepare, inspect, and sign — each role on its own machine

bloch-pos validator-deposit prepare \
  --genesis genesis.bin \
  --funding-pubkey funding.pub.hex --validator-pubkey validator.pub.hex \
  --randao <commitment-hex32> --withdrawal <withdrawal-script-hex32> \
  --change <change-script-hex32> --stake 2500000000000 \
  --input <txid-hex32>:<vout>:<value-sat> \
  --max-base-fee <millisat-per-gas> --tip <millisat-per-gas> \
  --expiry <inclusive-epoch> --commission <basis-points> --out draft.hex

bloch-pos validator-deposit inspect --tx draft.hex
bloch-pos validator-deposit sign --tx draft.hex --role funding \
  --dir funding-keystore --out funded.hex
bloch-pos validator-deposit inspect --tx funded.hex
bloch-pos validator-deposit sign --tx funded.hex --role validator \
  --dir validator-keystore --out ready.hex

• The passphrase comes from the sealed-keystore sourcing, never a command-line argument.
• Inspect on each signing machine — network domain, inputs, validator hash, withdrawal script, commission, fee budget. Rebuilding any field invalidates both signatures.
• --stake 2500000000000 is 25,000 BLCH expressed in sat — the minimum bond.

4. After activation: broadcast

Submit ready.hex via sendrawtransaction. The offline CLI never broadcasts anything itself.

5. Track

• getvalidatorbykey <sha3-256 pubkey hash> — VALIDATOR_NOT_FOUND before inclusion is the ordinary pending state, not an error in your submission.
• gettxstatus to distinguish included / justified / finalized.

6. Run the candidate node

Run with the auto-index keystore (the 4294967295 sentinel) and the correct genesis manifest. The node follows and verifies while queued and needs no restart when it becomes eligible; duties resolve the key from the committed registry, so there is no index race.

Operating notes

• Never run one key twice. Doppelganger observation and the persistent slashing journal are on the signing path, bound to pubkey-hash + genesis digest (index-independent). The network permanently discards the fork-choice weight of an equivocating key — measured on this chain's own history, not a hypothetical.
• Rewards and commission follow the existing emission schedule; queue and stake figures are live-queryable, not promises.
• Rehearsal exists in-repo: scripts/rehearse-validator-admission.py copies the source, arms epoch 0 in the copy, runs the production paths end-to-end, and deletes the copy.