Wallet context and transaction intent are not atomically revalidated #7

Wallet state is cached and can remain stale:

When account or chain reads fail, syncWallet() retains the previous values.
The network-switch path similarly preserves stale state after an RPC failure.
onRenew() checks cached readiness and captures the current account/name/method, but it does not freshly verify the chain and active account immediately before submission.
Form controls remain editable while a transaction is being prepared or shown in the wallet.

There is also no strict runtime validation of several RPC responses. Account strings and transaction hashes are largely trusted through TypeScript casts, and the chain ID is parsed permissively.

Problem scenarios
Network changes during preparation

For an ENS renewal, the application performs an asynchronous price read before submitting. The selected chain can change between:

mainnet readiness check
↓
price read
↓
wallet transaction request

The fixed contract address and value could then be submitted on a different chain. Whether it reverts, calls unrelated code, or simply transfers native currency depends on what exists at that address on the selected chain.

Account changes

The application can prepare an intent for account A, while the wallet changes to account B. Depending on wallet behavior, this may be rejected or may produce confusing confirmation behavior.

Form changes during the wallet prompt

The transaction uses the name and years captured at the beginning of onRenew(), while the visible form can subsequently display different values. The page and wallet prompt may therefore refer to different user intent.

Out-of-order wallet synchronization

Multiple asynchronous accountsChanged and chainChanged handlers can finish out of order. Without a generation counter or serialized state transition, an older RPC response can overwrite newer wallet state.