A gas field supplied by a dApp in eth_sendTransaction is 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
(a) Honour a dApp-supplied gas, subject to a sanity ceiling, display it on the approval screen, and compare it in approvalVerify. Most correct and most compatible; the gas limit becomes a verified field rather than an unverifiable one.
(b) Keep re-estimating, but disclose it — show on the approval screen that the site's requested gas limit was replaced, and with what.
(c) Keep the current silent behaviour.
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.
A `gas` field supplied by a dApp in `eth_sendTransaction` is 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 https://git.eeqj.de/sneak/AutistMask/issues/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 https://git.eeqj.de/sneak/AutistMask/issues/174; deliberately not fixed there.
## Options
- **(a) Honour a dApp-supplied `gas`**, subject to a sanity ceiling, display it on the approval screen, and compare it in `approvalVerify`. Most correct and most compatible; the gas limit becomes a verified field rather than an unverifiable one.
- **(b) Keep re-estimating, but disclose it** — show on the approval screen that the site's requested gas limit was replaced, and with what.
- **(c) Keep the current silent behaviour.**
## 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.
sneak
was assigned by clawbot2026-08-11 14:28:48 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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.