A census of node software versions across XPR Network's block producers, taken 2026-09-17. Posting it here because it bears directly on #26 (Spring/Savanna roadmap) and on whether the network can safely activate DISABLE_DEFERRED_TRXS_STAGE_1/2.
Short version: every producer in the active schedule is on Leap 5.0.x, so a feature activation is consensus-safe today. The exposure is on the client side — at least one widely used public RPC endpoint is still on Leap 3.1.2 and would halt at the activating block.
Date: 2026-09-17 · Method: eosio producers table → producer url → chains.json (keyed by XPR chain id) → bp.json → get_info on each published API endpoint. Chain id verified on every response.
Important caveat
These are the versions of each producer's public API node, not their block-producing node. A bp.json publishes API and p2p endpoints; the signing node sits behind a private relay and is never exposed. Operators normally run one build across their fleet, so this is strong evidence — but the only direct statement available about a producing node is that it is new enough for the chain to accept its blocks. Two producers (totalproton, eosusa) publish no discoverable bp.json/chains.json; their endpoints were reached by naming convention and are marked as such.
Summary
- 43 of 104 registered producers resolved to a version; the other 63 publish no reachable endpoint (50 have no
bp.json at any of 8 tried paths, 9 unreachable, 3 list no API node, 1 chains.json without the XPR chain id).
- All 21 producers in the active schedule are on Leap 5.x — 19 × v5.0.3,
xprnodeonebp v5.0.2, eosusa v5.0.0.
- Family split across all resolved: Leap 5.x 36, Spring 1.x 5, Leap 3.x 2.
- Spring 1.x is the successor to Leap 5.x, so those nodes are newer than the network standard, not behind it.
- One genuinely outdated XPR node:
proton.greymass.com (Leap v3.1.2), published by both teamgreymass and gmbpbackups2. It does not know the DISABLE_DEFERRED_TRXS_STAGE_* digests and would halt at the activating block. It is a widely used public API/SDK fallback, so this is a client-availability risk, not a consensus risk.
Active schedule (21)
| # |
Producer |
Node version |
Family |
Chain |
Endpoint |
Discovery |
| 1 |
protonnz |
v5.0.3 |
Leap 5.x |
XPR |
https://api.protonnz.com |
chains.json |
| 2 |
totalproton |
v5.0.3 |
Leap 5.x |
XPR |
https://api.totalproton.tech |
convention |
| 3 |
protonuk |
v5.0.3 |
Leap 5.x |
XPR |
https://proton.protonuk.io |
chains.json |
| 4 |
eosusa |
v5.0.0 |
Leap 5.x |
XPR |
https://proton.eosusa.io |
convention |
| 5 |
cafe |
v5.0.3 |
Leap 5.x |
XPR |
https://proton.eoscafeblock.com |
bp.json |
| 6 |
alvosec |
v5.0.3 |
Leap 5.x |
XPR |
https://proton-api.alvosec.com |
chains.json |
| 7 |
snipverse |
v5.0.3 |
Leap 5.x |
XPR |
https://api.snipverse.io |
chains.json |
| 8 |
blocksforge |
v5.0.3 |
Leap 5.x |
XPR |
https://api-xpr.blocksforge.com |
chains.json |
| 9 |
brotonbp |
v5.0.3 |
Leap 5.x |
XPR |
https://mainnet.brotonbp.com |
chains.json |
| 10 |
madblocks |
v5.0.3 |
Leap 5.x |
XPR |
https://api.madblocks.tech |
chains.json |
| 11 |
storexbp |
v5.0.3 |
Leap 5.x |
XPR |
https://bp-api.storex.io |
chains.json |
| 12 |
cryptolions |
v5.0.3 |
Leap 5.x |
XPR |
https://proton.cryptolions.io |
chains.json |
| 13 |
cerebroai |
v5.0.3 |
Leap 5.x |
XPR |
https://mainnet.cerebro.host |
chains.json |
| 14 |
catsvote |
v5.0.3 |
Leap 5.x |
XPR |
https://api.cats.vote |
chains.json |
| 15 |
bloxprod |
v5.0.3 |
Leap 5.x |
XPR |
https://xpr-mainnet-api.bloxprod.io |
chains.json |
| 16 |
protonmadrid |
v5.0.3 |
Leap 5.x |
XPR |
https://proton-api.eosiomadrid.io |
chains.json |
| 17 |
saltant |
v5.0.3 |
Leap 5.x |
XPR |
https://api-xprnetwork-main.saltant.io |
chains.json |
| 18 |
protonind |
v5.0.3 |
Leap 5.x |
XPR |
https://protonapi.blocksindia.com |
chains.json |
| 19 |
eosamsterdam |
v5.0.3 |
Leap 5.x |
XPR |
https://proton.eu.eosamsterdam.net |
chains.json |
| 20 |
xprnodeonebp |
v5.0.2 |
Leap 5.x |
XPR |
https://api-proton.nodeone.network:8344 |
chains.json |
| 21 |
chaininfra |
v5.0.3 |
Leap 5.x |
XPR |
https://api.chaininfra.net |
chains.json |
Standby / non-schedule producers with a reachable node
| # |
Producer |
Node version |
Family |
Chain |
Endpoint |
Note |
| 1 |
eosiodetroit |
v5.0.3 |
Leap 5.x |
XPR |
https://api.proton.detroitledger.tech |
|
| 2 |
eosrio |
v1.2.3-alpha1 |
Spring 1.x |
XPR |
https://proton.eosrio.io |
pre-release alpha on a public endpoint |
| 3 |
xprdata |
v5.0.3 |
Leap 5.x |
XPR |
https://mainnet-api.xprdata.org |
|
| 4 |
danemarkbp |
v5.0.3 |
Leap 5.x |
XPR |
https://api-xpr-main.danemarkbp.com |
|
| 5 |
luminaryvisn |
v5.0.3 |
Leap 5.x |
XPR |
https://api.luminaryvisn.com |
|
| 6 |
homebloksbp |
v5.0.3 |
Leap 5.x |
XPR |
https://api.homebloksbp.com |
|
| 7 |
xprcore |
v5.0.3 |
Leap 5.x |
XPR |
https://api-mainnet.xprcore.com |
|
| 8 |
rockeronebp |
v5.0.3 |
Leap 5.x |
XPR |
https://api.rockerone.io |
|
| 9 |
artwebin |
v5.0.3 |
Leap 5.x |
XPR |
https://mainnet-api.artwebin.com |
|
| 10 |
genereos |
v5.0.2 |
Leap 5.x |
XPR |
https://proton.genereos.io |
|
| 11 |
eosarabianet |
v5.0.3 |
Leap 5.x |
XPR |
https://api-proton.eosarabia.net |
|
| 12 |
ledgerwiseio |
v5.0.2 |
Leap 5.x |
XPR |
https://protonapi.ledgerwise.io |
|
| 13 |
cindronet |
v5.0.3 |
Leap 5.x |
XPR |
https://mainxpr.cindro.net |
|
| 14 |
energybp |
v5.0.3 |
Leap 5.x |
XPR |
https://api-energy.metalxpr.com |
|
| 15 |
bpadex |
v5.0.1 |
Leap 5.x |
XPR |
https://xpr.a-dex.xyz |
|
| 16 |
turtlebp |
v5.0.3 |
Leap 5.x |
XPR |
https://api-mainnet.turtlebp.online |
|
| 17 |
alohaeos |
v1.2.1 |
Spring 1.x |
other |
https://api.main.alohaeos.com |
endpoint serves a different chain (their XPR bp.json points at EOS/Vaulta) |
| 18 |
teamgreymass |
v3.1.2 |
Leap 3.x |
XPR |
https://proton.greymass.com |
outdated — would halt on DISABLE_DEFERRED activation |
| 19 |
pinknetwork |
v1.3.1 |
Spring 1.x |
XPR |
https://proton.api.atomicassets.io |
|
| 20 |
eosphere |
v1.2.2 |
Spring 1.x |
other |
https://vaulta-hyperion.eosphere.io |
endpoint serves a different chain (their XPR bp.json points at EOS/Vaulta) |
| 21 |
bountyblokbp |
v1.3.1 |
Spring 1.x |
XPR |
http://proton.api.atomicassets.io |
|
| 22 |
gmbpbackups2 |
v3.1.2 |
Leap 3.x |
XPR |
https://proton.greymass.com |
outdated — would halt on DISABLE_DEFERRED activation |
Notes for tooling
Eight producers' XPR bp.json files list endpoints for other chains (EOS/Vaulta, WAX). Any crawler that builds an XPR endpoint list from bp.json must validate chain_id from get_info, and should prefer chains.json keyed by the XPR chain id 384da888….
Why this matters for DISABLE_DEFERRED_TRXS
Deferred transactions have not executed on XPR since producers moved to Leap 5 (measurably, 1 November 2025 — pairing every unstakexpr with its following refundxpr shows auto-refunds dropping from ~95% to ~30% on that date). The consequence today is proton.contracts#10: eosio.system::unstakexpr schedules a refundxpr that never fires, and 376 accounts are currently holding 121,236,971 XPR of matured, unclaimed refunds (median wait 102 days, oldest 536 days).
What actually changes at activation — this is narrower than it is usually described. It is often said that activating these features makes send_deferred throw, breaking any contract that calls it. That is not what Leap 5.0.3 does: apply_context.cpp:427 and :633 show both send_deferred and cancel_deferred returning silently once the feature is active. Host functions are never removed, so no contract path starts failing.
The genuine breaking change is that transactions with delay_sec > 0 are rejected (transaction_context.cpp:253). So the question for XPR is simply: does anything on this chain use delayed transactions?
Measured answer: no. eosio::canceldelay has never been called on XPR mainnet, and none of 4,000 sampled updateauth calls set a waits entry. If anyone is aware of a wallet, dapp or internal tool that submits delayed transactions on XPR, this is the moment to say so — that is the one thing that would change the risk assessment.
Suggested sequencing:
- Deploy proton.contracts#10 first. Matured refunds need a working manual/keeper claim path before
STAGE_2 permanently clears generated_transaction.
- Give public API operators a window to upgrade. The failure mode for a node that doesn't know the feature digest is a halt at the activating block, which users will experience as "XPR is down" when it is actually a stale endpoint.
proton.greymass.com (v3.1.2) is the known case.
- Then activate
STAGE_1 — this stops new deferred transactions being accepted while leaving any already-queued ones in place — and only after that STAGE_2, which clears the generated_transaction table permanently. Leaving a gap between the two lets the existing queue be inspected and drained rather than discarded.
Worth noting for #26: on the Antelope/Spring path, SAVANNA declares a hard dependency on both deferred-disable stages plus BLS_PRIMITIVES2. If XPR's roadmap goes to PulseVM instead, that particular dependency may never be exercised — but the stuck refunds are a problem on the chain as it exists today, and 376 unresolved refund rows are not something you would want to carry across a VM migration either.
Request to BP operators
If your producer is in the "no reachable endpoint" group and you do run a public API node, publishing a chains.json (keyed by the XPR chain id) or a bp.json with nodes[].ssl_endpoint would make the network's topology auditable. And if you're reading this: what version is your signing node on? This census can only see public API nodes.
Happy to re-run this on a schedule and post updates if that's useful.
A census of node software versions across XPR Network's block producers, taken 2026-09-17. Posting it here because it bears directly on #26 (Spring/Savanna roadmap) and on whether the network can safely activate
DISABLE_DEFERRED_TRXS_STAGE_1/2.Short version: every producer in the active schedule is on Leap 5.0.x, so a feature activation is consensus-safe today. The exposure is on the client side — at least one widely used public RPC endpoint is still on Leap 3.1.2 and would halt at the activating block.
Date: 2026-09-17 · Method:
eosioproducerstable → producerurl→chains.json(keyed by XPR chain id) →bp.json→get_infoon each published API endpoint. Chain id verified on every response.Important caveat
These are the versions of each producer's public API node, not their block-producing node. A
bp.jsonpublishes API and p2p endpoints; the signing node sits behind a private relay and is never exposed. Operators normally run one build across their fleet, so this is strong evidence — but the only direct statement available about a producing node is that it is new enough for the chain to accept its blocks. Two producers (totalproton,eosusa) publish no discoverablebp.json/chains.json; their endpoints were reached by naming convention and are marked as such.Summary
bp.jsonat any of 8 tried paths, 9 unreachable, 3 list no API node, 1chains.jsonwithout the XPR chain id).xprnodeonebpv5.0.2,eosusav5.0.0.proton.greymass.com(Leap v3.1.2), published by bothteamgreymassandgmbpbackups2. It does not know theDISABLE_DEFERRED_TRXS_STAGE_*digests and would halt at the activating block. It is a widely used public API/SDK fallback, so this is a client-availability risk, not a consensus risk.Active schedule (21)
protonnzhttps://api.protonnz.comtotalprotonhttps://api.totalproton.techprotonukhttps://proton.protonuk.ioeosusahttps://proton.eosusa.iocafehttps://proton.eoscafeblock.comalvosechttps://proton-api.alvosec.comsnipversehttps://api.snipverse.ioblocksforgehttps://api-xpr.blocksforge.combrotonbphttps://mainnet.brotonbp.commadblockshttps://api.madblocks.techstorexbphttps://bp-api.storex.iocryptolionshttps://proton.cryptolions.iocerebroaihttps://mainnet.cerebro.hostcatsvotehttps://api.cats.votebloxprodhttps://xpr-mainnet-api.bloxprod.ioprotonmadridhttps://proton-api.eosiomadrid.iosaltanthttps://api-xprnetwork-main.saltant.ioprotonindhttps://protonapi.blocksindia.comeosamsterdamhttps://proton.eu.eosamsterdam.netxprnodeonebphttps://api-proton.nodeone.network:8344chaininfrahttps://api.chaininfra.netStandby / non-schedule producers with a reachable node
eosiodetroithttps://api.proton.detroitledger.techeosriohttps://proton.eosrio.ioxprdatahttps://mainnet-api.xprdata.orgdanemarkbphttps://api-xpr-main.danemarkbp.comluminaryvisnhttps://api.luminaryvisn.comhomebloksbphttps://api.homebloksbp.comxprcorehttps://api-mainnet.xprcore.comrockeronebphttps://api.rockerone.ioartwebinhttps://mainnet-api.artwebin.comgenereoshttps://proton.genereos.ioeosarabianethttps://api-proton.eosarabia.netledgerwiseiohttps://protonapi.ledgerwise.iocindronethttps://mainxpr.cindro.netenergybphttps://api-energy.metalxpr.combpadexhttps://xpr.a-dex.xyzturtlebphttps://api-mainnet.turtlebp.onlinealohaeoshttps://api.main.alohaeos.comteamgreymasshttps://proton.greymass.compinknetworkhttps://proton.api.atomicassets.ioeospherehttps://vaulta-hyperion.eosphere.iobountyblokbphttp://proton.api.atomicassets.iogmbpbackups2https://proton.greymass.comNotes for tooling
Eight producers' XPR
bp.jsonfiles list endpoints for other chains (EOS/Vaulta, WAX). Any crawler that builds an XPR endpoint list frombp.jsonmust validatechain_idfromget_info, and should preferchains.jsonkeyed by the XPR chain id384da888….Why this matters for
DISABLE_DEFERRED_TRXSDeferred transactions have not executed on XPR since producers moved to Leap 5 (measurably, 1 November 2025 — pairing every
unstakexprwith its followingrefundxprshows auto-refunds dropping from ~95% to ~30% on that date). The consequence today is proton.contracts#10:eosio.system::unstakexprschedules arefundxprthat never fires, and 376 accounts are currently holding 121,236,971 XPR of matured, unclaimed refunds (median wait 102 days, oldest 536 days).What actually changes at activation — this is narrower than it is usually described. It is often said that activating these features makes
send_deferredthrow, breaking any contract that calls it. That is not what Leap 5.0.3 does:apply_context.cpp:427and:633show bothsend_deferredandcancel_deferredreturning silently once the feature is active. Host functions are never removed, so no contract path starts failing.The genuine breaking change is that transactions with
delay_sec > 0are rejected (transaction_context.cpp:253). So the question for XPR is simply: does anything on this chain use delayed transactions?Measured answer: no.
eosio::canceldelayhas never been called on XPR mainnet, and none of 4,000 sampledupdateauthcalls set awaitsentry. If anyone is aware of a wallet, dapp or internal tool that submits delayed transactions on XPR, this is the moment to say so — that is the one thing that would change the risk assessment.Suggested sequencing:
STAGE_2permanently clearsgenerated_transaction.proton.greymass.com(v3.1.2) is the known case.STAGE_1— this stops new deferred transactions being accepted while leaving any already-queued ones in place — and only after thatSTAGE_2, which clears thegenerated_transactiontable permanently. Leaving a gap between the two lets the existing queue be inspected and drained rather than discarded.Worth noting for #26: on the Antelope/Spring path,
SAVANNAdeclares a hard dependency on both deferred-disable stages plusBLS_PRIMITIVES2. If XPR's roadmap goes to PulseVM instead, that particular dependency may never be exercised — but the stuck refunds are a problem on the chain as it exists today, and 376 unresolved refund rows are not something you would want to carry across a VM migration either.Request to BP operators
If your producer is in the "no reachable endpoint" group and you do run a public API node, publishing a
chains.json(keyed by the XPR chain id) or abp.jsonwithnodes[].ssl_endpointwould make the network's topology auditable. And if you're reading this: what version is your signing node on? This census can only see public API nodes.Happy to re-run this on a schedule and post updates if that's useful.