You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we calculate the hash in eth_sendTransaction with the assumption that our expected nonce will match that during the time of transaction execution. However, there exist race conditions where this assumption is invalid.
The outcome is that users end up in a UI error state without knowing that the transaction has actually succeeeded.
Suggested Solution
I believe a good short term path to prevent UX friction during eth_sendTransaction calls may be simply to revert during nonce mismatches on-chain. E.g. the client can send its predicted nonce in the Cadence wrapper transcation and this TX can panic.
This provides more predictable guarantees regarding the error state and helps assure users that their funds are safe. It does seem however that COAs could benefit from more resilient nonce-management mechanisms like their EOA counterparts (e.g. see TX pooling mechanisms that exist for EOAs on the EVM GW onflow/flow-evm-gateway#699).
Existing COA wallets (Flow Wallet) currently do not perform such pooling & nonce-management guarantees are will as such be more prone to error conditions.
The text was updated successfully, but these errors were encountered:
Problem
Currently, we calculate the hash in eth_sendTransaction with the assumption that our expected nonce will match that during the time of transaction execution. However, there exist race conditions where this assumption is invalid.
The outcome is that users end up in a UI error state without knowing that the transaction has actually succeeeded.
Suggested Solution
I believe a good short term path to prevent UX friction during
eth_sendTransaction
calls may be simply to revert during nonce mismatches on-chain. E.g. the client can send its predicted nonce in the Cadence wrapper transcation and this TX can panic.This provides more predictable guarantees regarding the error state and helps assure users that their funds are safe. It does seem however that COAs could benefit from more resilient nonce-management mechanisms like their EOA counterparts (e.g. see TX pooling mechanisms that exist for EOAs on the EVM GW onflow/flow-evm-gateway#699).
Existing COA wallets (Flow Wallet) currently do not perform such pooling & nonce-management guarantees are will as such be more prone to error conditions.
The text was updated successfully, but these errors were encountered: