For the same eth_chainId request, the official mainnet addresses did not have the response delivered back, but the testnet returned normally. This result cannot be replaced with the claim that the mainnet is already down. What it exposes is another layer of issue.@Dusk has the entry written into the documentation; that only proves the address was declared, not that this machine has established a trusted connection with it. The fact that the documentation exists and the client can reach it is still only the beginning—there are certificates, the network, and chain identity in between.
I narrowed the variables very tightly. The client, the POST content, and the 15-second timeout are exactly the same; only the RPC endpoint was changed. At 2026-08-24 00:08, the testnet returned 0x2e9, and then provided block 0x11bc06. On the mainnet, under strict certificate validation it stops at TLS; the HTTP status is 000, the validation result is 20, and the chain ID at the application layer was never obtained.
The most useful part of this comparison is not whether the testnet passes a health judgment. A strict TLS failure could be caused by the certificate chain, or it might only occur along my current network route. The scope of what it can prove is very clear: at least in this client environment, the documentation address has not passed the availability acceptance test. Writing a single connection failure as a full-network outage is more careless than ignoring the failure itself.
Before, I would configure wallets once I saw the RPC. Now the order has to change. A trusted connection is the door; the chain ID is the room number. Only the continuous advancement of blocks shows that someone is inside. If any one step is missing, you shouldn’t try with real funds for troubleshooting. This time, the testnet could still proceed through all three checks; the mainnet only reached the first door and stopped. The difference is not speed—it’s whether you can enter the next verification step.
To say that the EVM entry for $DUSK is truly usable, you need evidence that all three conditions are met: the certificate is trusted, the chain ID matches the expected value, and the block height continues to change. Since the three proofs aren’t all gathered, I will only mark it as “to be investigated,” not as usable—and definitely not as “mainnet failure.” The most cost-saving actions for ordinary users are also very specific: before transferring, do these three checks; if any one doesn’t yield a result, stop.
Give the address to the documentation; only real testing grants the pass.#dusk
I narrowed the variables very tightly. The client, the POST content, and the 15-second timeout are exactly the same; only the RPC endpoint was changed. At 2026-08-24 00:08, the testnet returned 0x2e9, and then provided block 0x11bc06. On the mainnet, under strict certificate validation it stops at TLS; the HTTP status is 000, the validation result is 20, and the chain ID at the application layer was never obtained.
The most useful part of this comparison is not whether the testnet passes a health judgment. A strict TLS failure could be caused by the certificate chain, or it might only occur along my current network route. The scope of what it can prove is very clear: at least in this client environment, the documentation address has not passed the availability acceptance test. Writing a single connection failure as a full-network outage is more careless than ignoring the failure itself.
Before, I would configure wallets once I saw the RPC. Now the order has to change. A trusted connection is the door; the chain ID is the room number. Only the continuous advancement of blocks shows that someone is inside. If any one step is missing, you shouldn’t try with real funds for troubleshooting. This time, the testnet could still proceed through all three checks; the mainnet only reached the first door and stopped. The difference is not speed—it’s whether you can enter the next verification step.
To say that the EVM entry for $DUSK is truly usable, you need evidence that all three conditions are met: the certificate is trusted, the chain ID matches the expected value, and the block height continues to change. Since the three proofs aren’t all gathered, I will only mark it as “to be investigated,” not as usable—and definitely not as “mainnet failure.” The most cost-saving actions for ordinary users are also very specific: before transferring, do these three checks; if any one doesn’t yield a result, stop.
Give the address to the documentation; only real testing grants the pass.#dusk