When a user selects the wrong network, the product should stop it as early as possible—not wait until after they finish signing and then report an error.
DuskEVM has a clear network identity: the testnet’s Chain ID is 745, and other environments have different IDs. For developers, this is just a configuration setting; for ordinary users, it’s a high-frequency source of mistakes. In the span of a single second, they might be on another EVM chain, and then in the Dusk app they click Submit—while the wallet pop-up looks almost identical.
A good product will compare the Chain ID immediately after reading the wallet, make the page non-interactive, and clearly tell the user which network they need to switch to. It shouldn’t let the user fill out the form, approve Tokens, and sign a whole series of messages first—then finally use an “RPC Error” to say “Wrong network.” The earlier the error is cut off, the lower the cost.
More detailed tests include: the user rejects the network switch, the wallet doesn’t recognize the network, the account changes during switching, and the page caches the previous account’s balance. The app must respond to the wallet’s Network and Account changes, promptly clear old quotes and old eligibility. Otherwise, the page may look like it’s still going—while the business context has already changed to a different person.
The Dusk Connect for @Dusk will find compatible wallets and sense state changes. For $DUSK and #dusk , what the application layer needs to do is turn these signals into safe interactions. I judge whether a Web3 product is mature largely by how it handles users not following the standard script.
DuskEVM has a clear network identity: the testnet’s Chain ID is 745, and other environments have different IDs. For developers, this is just a configuration setting; for ordinary users, it’s a high-frequency source of mistakes. In the span of a single second, they might be on another EVM chain, and then in the Dusk app they click Submit—while the wallet pop-up looks almost identical.
A good product will compare the Chain ID immediately after reading the wallet, make the page non-interactive, and clearly tell the user which network they need to switch to. It shouldn’t let the user fill out the form, approve Tokens, and sign a whole series of messages first—then finally use an “RPC Error” to say “Wrong network.” The earlier the error is cut off, the lower the cost.
More detailed tests include: the user rejects the network switch, the wallet doesn’t recognize the network, the account changes during switching, and the page caches the previous account’s balance. The app must respond to the wallet’s Network and Account changes, promptly clear old quotes and old eligibility. Otherwise, the page may look like it’s still going—while the business context has already changed to a different person.
The Dusk Connect for @Dusk will find compatible wallets and sense state changes. For $DUSK and #dusk , what the application layer needs to do is turn these signals into safe interactions. I judge whether a Web3 product is mature largely by how it handles users not following the standard script.