Percent ADDED to the gas estimate on every write, over 100. 25 means the limit sent is
1.25 times the estimate (MK-035).
Measured, not conventional. Every write path the SDK exposes was run 12 times from a
byte identical evm_snapshot, so nothing but the block timestamp differed between
attempts. The gas the SAME call consumed varied by:
addCollateral 10.16%, withdrawCollateral 9.84%, borrow 7.97%, refinance 7.88%,
adjustTrove 7.66%, repay 3.35%, liquidate 2.74%, openTrove and redeem 0% in that window
against margins viem's own estimate happened to leave of 1.51% (openTrove) to 18.14%
(redeem), with five of the nine measured paths having a SMALLER margin than their own
spread. Separately, one redeemCollateral tail case grew from 610270 to 710023 gas, 16.4%,
and that is the one that reverted.
25 is roughly 1.5 times the worst growth observed (16.4%) and 2.5 times the worst typical
spread (10.16%). It is not a round number chosen because buffers are usually round; it is
the worst measurement with a factor on top, and if the measurements move it should move.
What it costs the caller, established on the fork rather than assumed:
Nothing in fees. Unused gas is refunded exactly: a send with a 5000000 limit that
used 351910 charged gasUsed * effectiveGasPrice to the wei.
A higher balance requirement. The account must hold gasLimit * gasPrice + value
up front or the send is rejected outright ("The total cost (gas * gas fee + value) ...
exceeds the balance of the account"). A 25% larger limit means 25% more native balance
must be sitting there, unspent.
A higher number in the wallet's confirmation screen, which is the maximum, not the
charge.
Latency: none added. viem skips its own estimation when gas is set, so this is
the same count of eth_estimateGas calls as before, and the estimate runs in parallel
with the simulation rather than after it.
What it does NOT do. It does not close the window. The estimate is still taken before
the block the transaction mines in, so a large enough jump still exhausts it. See
diagnoseRevertedWrite for what a caller can learn when that happens.
Percent ADDED to the gas estimate on every write, over 100.
25means the limit sent is 1.25 times the estimate (MK-035).Measured, not conventional. Every write path the SDK exposes was run 12 times from a byte identical
evm_snapshot, so nothing but the block timestamp differed between attempts. The gas the SAME call consumed varied by:addCollateral 10.16%, withdrawCollateral 9.84%, borrow 7.97%, refinance 7.88%, adjustTrove 7.66%, repay 3.35%, liquidate 2.74%, openTrove and redeem 0% in that window
against margins viem's own estimate happened to leave of 1.51% (openTrove) to 18.14% (redeem), with five of the nine measured paths having a SMALLER margin than their own spread. Separately, one
redeemCollateraltail case grew from 610270 to 710023 gas, 16.4%, and that is the one that reverted.25 is roughly 1.5 times the worst growth observed (16.4%) and 2.5 times the worst typical spread (10.16%). It is not a round number chosen because buffers are usually round; it is the worst measurement with a factor on top, and if the measurements move it should move.
What it costs the caller, established on the fork rather than assumed:
gasUsed * effectiveGasPriceto the wei.gasLimit * gasPrice + valueup front or the send is rejected outright ("The total cost (gas * gas fee + value) ... exceeds the balance of the account"). A 25% larger limit means 25% more native balance must be sitting there, unspent.gasis set, so this is the same count ofeth_estimateGascalls as before, and the estimate runs in parallel with the simulation rather than after it.What it does NOT do. It does not close the window. The estimate is still taken before the block the transaction mines in, so a large enough jump still exhausts it. See
diagnoseRevertedWritefor what a caller can learn when that happens.