decision: a dApp-supplied gas limit is silently dropped, so the popup always re-estimates #207
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A
gasfield supplied by a dApp ineth_sendTransactionis discarded by ethers'copyRequest, so the popup always estimates the gas limit itself and the dApp's value never reaches the signed transaction.Consequence: a dApp that deliberately raises the gas limit — common for contract calls whose estimate is unreliable, and for flows that would otherwise fail with out-of-gas — is silently overridden. The user sees no indication that the site asked for something different from what will be signed.
This is also why #174 does not compare the gas limit between approval and signature: there is nothing stable to compare. Honouring the request would let that field be verified for real, which is the stronger position.
Found while implementing #174; deliberately not fixed there.
Options
gas, subject to a sanity ceiling, display it on the approval screen, and compare it inapprovalVerify. Most correct and most compatible; the gas limit becomes a verified field rather than an unverifiable one.Recommendation
(a). A wallet silently changing a transaction parameter the site asked for is the same category of problem the approval screen exists to prevent, and it currently leaves a consequential field permanently outside verification. (b) is honest but still breaks the dApp's intent. (c) leaves both the compatibility gap and the verification hole.
Assigning to you: this changes what the wallet signs relative to what a site requested, which is a product decision rather than a defect fix.