Why doesn't JsonRpcSigner.sendTransaction call populateTransaction when Signer.sendTransaction does?

[markdalgleish]

In order to avoid deep linking issues with WalletConnect on iOS, I'm trying to remove as much async logic as possible from click handlers that send a transaction.

In theory it seems like I should be able to call signer.populateTransaction(tx) ahead of time, but I can see that this goes through a different code path to the regular signer.sendTransaction(tx) flow in JsonRpcSigner.

JsonRpcSigner.sendTransaction seems to have its own manual subset of async population logic — only adding a gasLimit and resolving the to field — and completely ignores the populateTransaction method. This is in contrast to the abstract Signer.sendTransaction which calls populateTransaction first. I'm wondering why JsonRpcSigner.sendTransaction doesn't make use of populateTransaction and implements its own logic instead?

If there's a good reason for this difference, it would be nice to have access to the same transaction population logic used within JsonRpcSigner.sendTransaction via some other API so that it can be called up-front before attempting to send a transaction. I want to be able to guarantee that all async work has already been done before the click handler fires without having to re-implement the logic myself.

[markdalgleish]

I should add that one notable difference in behaviour is that populateTransaction populates the from field before estimating gas which can cause Alchemy to throw an error if the account doesn't have enough eth to cover the transaction. When using sendTransaction without the from field specified, the same gas estimation succeeds and the transaction request is allowed to go through to my wallet.

[ricmoo]

Estimating gas requires the fee data be 0 if the sending account has insufficient funds for the intrinsic gas cost of the transaction.

[ricmoo]

The reason is that a node performs much of its own internal logic when sending a transaction; e.g. Geth has access to cached internal values for its own account state trie values such as its nonce, and the fee data (gasPrice in legacy transaction and the max*FeePerGas for EIP-1559) is available synchronously within the node’s sendTransaction and has its own configuration for the fee.

Nodes such as MetaMask will usually ignore fee data and including a nonce can cause a node to hiccup, as it’s UI may wish to reassign the nonce based on a rejection and if multiple transactions are submitted, it will serialize the minces (while populating it would cause them to become replacement transactions).

It would be nice if it could use populateTransaction, but node clients do so much extra above and beyond that the application either doesn’t have control over, is ignored or can cause complications…

Does that make sense?

[markdalgleish]

Yep, that makes sense. Thanks for the detailed answer.

In that case, would it be possible for us to get access to JsonRpcSigner's async transaction preparation logic somehow? We want to make sure this has been run before the click handler fires so that deep linking on iOS isn't intercepted.

[ricmoo]

I don’t know that this change can be included in v5, but it would probably make sense to add in v6.

Re-reading your question, I think you could wrap Signer and in sendUncheckedTransaction, you could estimate gas with your custom logic; if there is a gasLimit specified, it won’t do gas estimation.