Dynamic Plasma spork label/compiled-ID mismatch keeps the current testnet on legacy Plasma semantics

[edgepillar]

Evidence date: 2026-09-20
Affected published generation: 2026-09-18 public testnet generation, chain identifier 73404, built from the published go-zenon dev source revision.

Summary

The current public testnet publication labels Dynamic Plasma as activated, but the identifiers assigned to the Dynamic Plasma and Libp2p records are reversed relative to the identifiers compiled into the published go-zenon binary.

As a result, the label shown in genesis and spork metadata does not match the consensus feature selected by the binary. Live momentum behavior confirms that Dynamic Plasma is not currently enforced: the chain remains on version-1 momentum semantics with zero Dynamic Plasma price fields.

This report intentionally omits raw identifiers. They can be compared directly in the linked public sources.

Verified observations

1. The published genesis contains:

   • dynamic-plasma: activated, enforcement height 10;
   • libp2p: not activated, configured enforcement height 20.

   Sources: published genesis, testnet builder constants.

2. The identifier assigned to the published dynamic-plasma record is the identifier compiled as Libp2pSpork.

3. The identifier assigned to the published libp2p record is the identifier compiled as DynamicPlasmaSpork.

   Source: compiled spork definitions.

4. The live spork RPC reproduces the same label/identifier/activation combination as the published genesis.

5. Momentums 9 through 14—including the configured enforcement boundary—are all version 1 and report:

   • nextFusionPrice = 0;
   • nextWorkPrice = 0.

6. The frontier observed on 2026-09-20, far beyond height 10, is still version 1 with both prices zero.

   Under the documented Dynamic Plasma behavior, post-activation momentums use version 2 and carry adaptive price fields whose minimum resource-price baseline is 1000.

   Sources: Dynamic Plasma specification, public RPC endpoint.

7. Spork enforcement is selected by exact identifier, activation state, and enforcement height—not by the human-readable name.

   Sources: spork activation lookup, feature-specific spork checks.

Why getVariables is not activation evidence

embedded.plasma.getVariables currently returns the Plasma configuration successfully. That result alone does not establish Dynamic Plasma activation.

The RPC method is publicly registered and reads the Plasma contract variables without first requiring the Dynamic Plasma spork to be active. Other Plasma calculations separately branch on the effective spork state. Therefore:

• RPC availability proves that the node exposes the method;
• returned defaults prove that configuration can be read;
• neither proves that version-2 consensus rules are being applied.

Sources: Plasma RPC implementation, RPC registration.

Operational impact

• Operator-facing metadata says Dynamic Plasma is active while the running binary interprets that record as the Libp2p spork.
• The compiled Dynamic Plasma identifier remains associated with an inactive on-chain record.
• Clients must not infer Dynamic Plasma activation from the label, chain identifier, configured enforcement height, or successful getVariables response.
• Clients that require Dynamic Plasma pricing should continue to fail closed while the frontier remains version 1.
• Live x402 Dynamic Plasma payments remain blocked. Offline, network-free compatibility work can continue independently.

Conservative remediation choices

Option A — Publish a corrected testnet generation

Correct the builder mapping, generate a new genesis, verify the generated records against the exact binary, and coordinate a clean node rollout.

This is the clearest long-term repair because labels, configured activation state, and compiled semantics become consistent.

Risks and costs:

• it resets the current testnet generation;
• balances, transactions, profiles, fixtures, and published chain bindings must be replaced;
• every node and dependent service must move to the new generation together.

Option B — Preserve this generation and activate the record whose identifier the binary recognizes as Dynamic Plasma

A governance activation of the currently inactive record could allow the existing binary to enforce Dynamic Plasma after the normal activation delay.

This should be considered only after confirming that all nodes run the same reviewed binary and after a coordinated dry run.

Risks:

• the human-readable labels remain reversed;
• dashboards and operational tooling can continue to report misleading feature names;
• both Dynamic Plasma and Libp2p activation state must be assessed by compiled identifier rather than label;
• this is operationally fragile and should not be treated as a permanent clean configuration.

Option C — Remap the identifiers in a replacement binary on the current chain

This is not recommended as a quick repair.

Because one reversed record is already active with an enforcement height in the past, a remapped binary could change effective Dynamic Plasma and Libp2p behavior immediately upon upgrade. A partial rollout could create incompatible node behavior. This option requires explicit consensus review and an atomic, coordinated upgrade plan.

Changing only the website or builder constants does not repair the current chain state; it only affects future publications.

Required post-remediation verification

The repair should not be declared complete until all of the following pass:

1. Every participating node reports the same reviewed go-zenon source revision.
2. The published genesis and live spork RPC associate the Dynamic Plasma label with the identifier compiled as DynamicPlasmaSpork.
3. The Libp2p record independently matches the identifier compiled as Libp2pSpork.
4. The Dynamic Plasma record is activated and its enforcement height has passed.
5. A post-enforcement sample of 12 consecutive momentums is version 2.
6. Every momentum in that sample reports non-zero fusion and work prices at or above the protocol minimum.
7. Nodes agree on the same frontier throughout the sample; no mixed-version or divergent behavior is observed.
8. Plasma quote behavior is independently recomputed from the same pricing momentum and current on-chain variables.
9. getVariables success is treated only as configuration evidence, not as an activation gate.
10. Dependent clients update and verify their exact genesis/profile binding before enabling live Dynamic Plasma behavior.

Until those checks pass, x402 should continue using its default-inactive compatibility path and must not initiate a live Dynamic Plasma payment.

Publication metadata

• Node plan
• Published genesis
• Public deployment statistics