Two Chains, Not Two Copies: Their Public Interfaces Do Not Overlap At All, and a Signature Is Not Bound To Either

Both answer, and that is where the similarity ends

The first names itself in its own response, and returns a genesis hash and a version alongside its current height, which was 83,727 when this was measured.

The second returns a height of 1,835,001 and a state root, and will not tell you what it is.

Neither number means anything next to the other. They are separate chains with separate genesis blocks, so comparing their heights compares two unrelated counters.

Thirteen methods, and the two sets do not overlap

The same thirteen calls were made against both endpoints.

the second chain answered exactly two: a height and a state root the first answered eleven, and neither of the other's two

The overlap is zero. Not "mostly the same with some gaps". Nothing you learn about one interface works against the other.

CORRECTED 2026-08-03: BOTH SENTENCES ABOVE ARE WRONG. THE OVERLAP IS THREE.

This page tried thirteen method names it had picked by hand. The second chain's real method names were then read out of the v2 source itself, and probed:

solidus_getBlockHeight → 1835001 · solidus_getStateRoot → a root solidus_getBalance · solidus_getNonce · solidus_getReceipt · solidus_submitTransaction → all four return "invalid params", which means the method EXISTS and wants arguments

So the second chain answers SIX, not two. And three of them are present on BOTH endpoints, measured against each in the same sweep: solidus_getBalance, solidus_getNonce, solidus_getReceipt. The overlap is three. CONTROL: faucet_info returns method-not-found on the same endpoint in the same sweep, so a present method and an absent one are distinguishable.

The sentence "from outside that is all it does" was therefore too small a claim about it. You can read a balance, read a nonce, fetch a receipt, and SUBMIT A TRANSACTION to it.

WHY THIS PAGE GOT IT WRONG, AND IT IS WORTH MORE THAN THE CORRECTION: THIRTEEN HAND-PICKED NAMES IS NOT AN ENUMERATION OF AN INTERFACE. It can only test names somebody thought of. The fix was to read the candidate names out of the source and probe all of them, which is the same mistake, and the same remedy, as guessing which packages a registry scope contains.

CONTROL: each endpoint answered something in the same sweep that refused the rest, so this is a difference between two live interfaces rather than one host being down.

Which means the second chain is not an identity chain from outside

You cannot resolve an identifier on it. You cannot fetch a block from it. You cannot verify a credential against it.

It produces blocks and reports a state root, and from outside that is all it does.

A reader who assumed "version two" meant "the newer one, with everything the older one has" would be wrong in the most basic way. The two are different builds with different interfaces, not successive releases of one.

And we cannot tell you whether it is still producing

Its height and its state root were identical across every poll in the observation window, several minutes apart.

We are not calling it stopped, and the reason is that we made exactly this mistake before. A short poll of the other chain once produced a confident claim that it had stopped, which was wrong and was retracted. UPDATED 2026-08-02: that chain's quiet turned out to be a configured ten-minute idle heartbeat, so a short window genuinely does look identical to a halt, and the caution was right for a better reason than the one first given.

The measurement that settled it there cannot be taken here. On the other chain you read the newest block's own timestamp and compare it with your clock. This one does not serve blocks, so that measurement does not exist.

The chain that publishes least is the one you can say least about, and that is a property of its interface rather than of its health.

And a signature is not bound to either chain

A transaction here is four fields: a sender key, a nonce, a payload, and a signature.

The signed message is the sender key, the nonce and the payload, and nothing else. There is no chain identifier in it, no network name, and no expiry.

So a transaction signed for one Solidus chain is a valid transaction on another one, wherever that account exists at that nonce. The only thing standing in the way is the per-account counter, and that counter is per-chain state rather than part of the signature.

This fails open, not closed. A signature that was valid over there is valid over here, and that is the opposite of the failure mode a reader should assume.

And our own code shows it is an oversight rather than a position

The guardian recovery path does it properly. Its signed message begins with a versioned domain separator, includes the network explicitly, and length-prefixes every variable field so two different inputs cannot produce the same pre-image.

Another component signs with a chain identifier included.

So the pattern is known here, used elsewhere, and absent from the one envelope that carries every ordinary transaction. That is a gap, not a philosophy.

Sized honestly

It is filed. It is not scheduled, and this page will not imply otherwise.

What looked right and turned out not to be

The first chain names itself, reports a genesis hash and states its version.

CORRECTED 2026-08-02: this section previously said that a genesis hash is a real chain identity, comparable byte for byte. It is not, on this chain. The reported value is BLAKE3 of the chain-identifier string, reproduced independently character for character, so it commits to the name and not to the genesis contents and carries no information the name did not already carry. The genesis page states it in full.

Naming itself and stating a version is still worth something, and it is more than the second chain does.

Two separate networks is itself sound practice: a development chain that can be broken and rebuilt, separate from one that stays up.

What you can check yourself

call the same method against both endpoints and compare which one answers

Then fetch a transaction from the first chain and look for a field naming the chain it was signed for. There is none.