[inf-1oop]

This PR carries two changes to the mainnet chain config:

1. Prysm v7 config keys — four keys the config never overrode, each of which breaks a v7 node.
2. The deposit contract switch — mainnet moves to a new deposit contract at block 10,229,958.

They are together because both touch networks/mainnet/config.yml and both land in the same operator upgrade.

⚠️ Part 2 changes the beacon node image. Part 1 on its own is backward compatible with Prysm v5.1.0; part 2 is not. See Compatibility below.

---

Part 1 — Prysm v7 config keys

Problem

networks/mainnet/config.yml declares PRESET_BASE: mainnet, so every key it does not define is inherited from Ethereum mainnet. Prysm v7 added three settings this config never overrides, and each inherited default breaks a Vana node in a different way — two of them silently.

Key	Inherited value	Failure
FULU_FORK_VERSION / GLOAS_FORK_VERSION	0x06000000 / 0x07000000	Node refuses to start: version 0x06000000 for fork fulu in config vana conflicts with existing config named=mainnet
SLOT_DURATION_MS	12000	Preferred over SECONDS_PER_SLOT for all slot timing → 12s/slot arithmetic on a 6s chain → FATAL invalid payload timestamp
BLOB_SCHEDULE	Ethereum BPO forks at epochs 412672 / 419072	Gossip allowlist truncated → every gossip topic refused

On BLOB_SCHEDULE specifically

A BPO entry only receives a distinct fork digest when its epoch is at or after FULU_FORK_EPOCH. Fulu is disabled here, so Ethereum's BPO entries instead reuse the preceding fork's digest — and since 412672/419072 fall between Bellatrix (epoch 2) and Capella/Deneb (503609), they carry Bellatrix's digest.

Prysm's allTopics() walks the fork schedule terminating on next.ForkDigest != last.ForkDigest, so the repeated digest halts the walk before Capella/Deneb. The allowlist ends up with 221 topics and no 78ba1733 (the live Deneb digest), so pubsub refuses everything with topic is not allowed by the subscription filter.

This one is the nastiest to diagnose: the node still starts and follows the chain by range sync, so it looks alive. It just participates in nothing — no gossip, and a sync distance that drifts instead of sitting at 0.

Verification

Tested on a live Vana mainnet node running Prysm v7.1.8:

• Before: FATAL at startup, then (after the fork keys) FATAL invalid payload timestamp, then (after SLOT_DURATION_MS) a running-but-gossip-dead node with sync distance drifting 2→17 and block arrival at 7–13s.
• After all three: sync distance 0 sustained, head advancing 2 slots / 12s (correct 6s cadence), 0 subscription-filter rejections, 0 payload-timestamp errors, 17 peers.

Consensus-safety checks:

• genesis_validators_root unchanged: 0x7a2ee1f3a4332b8a3229efd4cba0903049bc8b1e7cd1fe46052e320cf3f6d184
• Fork unchanged: current_version 0x20000093, head block version deneb
• Fulu/Gloas do not enter the fork schedule (far-future epochs are truncated), so the resulting schedule is still exactly Phase0 → Deneb and the Deneb digest is still 0x78ba1733
• MaxBlobsPerBlockAtEpoch() at the current epoch is 6 both before and after — the inherited BPO entries were superseded by Deneb, so emptying the schedule changes no blob limit

---

Part 2 — Deposit contract switch

Mainnet moves to a new deposit contract at block 10,229,958.

Current contract (from the switch block onward)	0xB98aafa6684aef18AEf518772F01F5aE0DA5eA4C
Retired contract (holds the history before it)	0x17BbE91c315Bf14f38F6D35052a827cadfFe184e
Switch block	10229958

Why this does not break the deposit trie

The new contract was deployed at block 10,099,568 already seeded with the retired contract's final state, so the merkle index continues across the boundary instead of restarting at 0. Read from both contracts on chain:

	Retired (at block 9,475,268)	New (today)
get_deposit_count()	32	32
get_deposit_root()	0x60dff8f6…172401	0x60dff8f6…172401

Below the switch block a node scans only the retired contract; at and above it, only the current one. A log batch that straddles the boundary is split into two queries, one per contract. A node syncing from genesis therefore reconstructs exactly the deposit history it always did, and no node resyncs.

This depends on a patch to Prysm (vana-com/prysm#1), released as v7.1.8-vega.1, which adds the two config keys and the split scan.

Compatibility

This is the part that is not backward compatible. The beacon node moves to Vana's build of Prysm, ghcr.io/vana-com/prysm-beacon-chain:v7.1.8-vega.1, pinned by a new BEACON_IMAGE variable. Upstream Prysm cannot run against this config: it does not know the two new keys, and it refuses to start at all once DEPOSIT_CONTRACT_ADDRESS no longer matches the address recorded in its own database.

Only the beacon node is forked. The validator and prysmctl stay on upstream Prysm, moving from v5.1.0 to v7.1.8 — the release the Vana build is based on — so the two components no longer sit four minor versions apart. The switch is beacon-node work; the upstream validator reads this config file fine. Both v5.1.0 and v7.1.8 were run against it and report the two new keys as unknown fields in the same non-fatal message they already emit for FULU_FORK_VERSION and BLOB_SCHEDULE, with every recognised field still applied — UnmarshalStrict populates what it recognises before collecting the strict errors, and the loader logs and continues.

For part 1 alone, the earlier claim still holds: Prysm v5.1.0 logs the new keys as unknown fields and continues normally.

Operator impact

Upgrading is an image change:

docker compose pull beacon validator
docker compose up -d beacon validator

• The beacon service passes --clear-deposit-contract. A node's database records the deposit contract address it last ran with and refuses to start when the configured one differs (database contract is 0x17bbe91c... but tried to run with 0xb98aafa6...). The flag clears that record and the migration marker, then writes the address again from the config on the same start. All other data is kept — this is not a resync. It is on by default so operators don't have to edit docker-compose.yml; the cost is that the marker is cleared on every start, so the check that refuses a changed switch block does not fire. The comment in the file says to drop it once the fleet is past the switch.
• A node that has already scanned past the switch block rewinds its deposit log scan once, logging Rewinding deposit log scan.
• DEPOSIT_CONTRACT_ADDRESS in .env moves to the new contract — it is where submit-deposits sends deposits, and the retired contract no longer accepts them.
• PRYSM_VERSION crosses two major versions for the validator, so operators should back up the validator database (slashing protection) first.

Verification

Rehearsed end to end on a 4-stack shadowfork devnet, all 8 phases, zero failures:

• The seeded contract is a byte-identical continuation — count, root, and all 32 branch slots matched the retired contract.
• A rolling upgrade v5.1.0 → patched, one stack at a time, while the other three kept producing. No keys moved, no node retired; 31 of 34 slots produced across the cutover, finality never stalled, and the deposit-log scan came back clean on all 4 stacks.
• The boundary-split query fired as designed on a batch straddling the switch block.
• The chain then walked Deneb → Electra → Fulu with incorrect merkle index: 0 and Could not process deposit log: 0, confirming the switch does not disturb the later EIP-6110 transition.

Against the published image with the config in this PR: it starts and reaches genesis loading, and each validation guard was confirmed to fire by deliberately breaking it (switch block 0, deployment block above the switch, retired equal to current, retired as the zero address). Every image tag the compose file now references was confirmed to exist.

Open question: the pre-switch window

The switch block is roughly 9 days out, but the new contract is already live and accepting deposits — its only gate is a pubkey allowlist (DepositContract: publicKey not allowed), not a block height.

That leaves a ~130,000-block window in which a deposit from an allowlisted key would land below the switch block, where no node scans the new contract. The result would be an index gap and nodes halting deposit processing. The devnet rehearsal avoided this by setting the switch block to the new contract's deployment block, which leaves no window.

Two ways to close it, for reviewers to decide:

1. Set DEPOSIT_CONTRACT_SWITCH_BLOCK: 10099568 (the deployment block) — strictly safe, since the contract could not emit before it existed.
2. Keep 10229958 and hold the allowlist empty until then, as an operational guarantee.

Separately worth noting: the retired contract now reverts on get_deposit_count() and get_deposit_root() — it answered 32 at block 9,475,268 and reverts by block 10,000,000. Since the config still points at it today, that is the likely source of any Unable to process past deposit contract logs errors currently seen on mainnet. The switch resolves it, and the Vana build additionally makes an unreadable deposit count non-fatal.

---

Not included: networks/moksha/config.yml

Moksha is missing all four v7 keys too and will hit the same class of problem. I have deliberately left it out because I could not test it, and it is not a copy-paste of this change:

• Its fork-version numbering differs (ELECTRA_FORK_VERSION: 0x60000038, not the 0x2000009x series), so Fulu/Gloas versions need a deliberate choice.
• All its forks are at epoch 0, so the inherited BPO entries land after Deneb rather than before it — the topic-walk truncation may not bite the same way.

Moksha also has no deposit contract switch of its own.

Worth a follow-up from someone who can run a Moksha node.

🤖 Generated with Claude Code

[github-actions]

🎉 This PR is included in version 2.4.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀