Paycall #170
Paycall #170
Conversation
|
|
||
| /// @notice Constant buffer for gas overhead | ||
| /// This is a constant to accounted for the gas used by the Paycall contract itself that's not tracked by gasleft() | ||
| uint256 internal constant GAS_OVERHEAD = 75000; |
There was a problem hiding this comment.
After several testing in forge test and tried to figure out the proper buffer for the gas estimate for the final payment at the end of the call. I found the gas overhead is hovering around 50k ~ 60k depends on the function that's get executed underneath. And in forge test, the first transaction is hovering around 100k ~ 110k. (So if repeatedly running same operations it's like 109139, 56839, 56839)
So I decided to put 75000 as gas overhead to find the middle ground of it.
(We might also want to add couple more buffer to account for price slippages and the risk we have during converting the asset back to ETH ?)
There was a problem hiding this comment.
Is the first transaction cheaper simply because of how forge works? IIRC, forge executes the entire test in a single transaction, so the subsequent calls are only cheaper because of warm loads. If that's the case, than the 56k numbers aren't really realistic for us to consider.
There was a problem hiding this comment.
Hm, this sounds really high, right? Like it should be 21K + some small overhead like 5K? The first creation is pretty meaningless since that only happens once ever.
There was a problem hiding this comment.
Ah I see. Then unfortunately :( looks like the gas_overhead is higher than we expected.
Yeah I was only using 21K, then realized some numbers are off between forge reported gas 😓
|
|
||
| /// @notice Constant buffer for gas overhead | ||
| /// This is a constant to accounted for the gas used by the Paycall contract itself that's not tracked by gasleft() | ||
| uint256 internal constant GAS_OVERHEAD = 75000; |
There was a problem hiding this comment.
Is the first transaction cheaper simply because of how forge works? IIRC, forge executes the entire test in a single transaction, so the subsequent calls are only cheaper because of warm loads. If that's the case, than the 56k numbers aren't really realistic for us to consider.
test/quark-core-scripts/Paycall.t.sol
8000
Outdated
| @@ -79,8 +83,13 @@ contract PaycallTest is Test { | |||
| ethcallAddress = codeJar.saveCode(ethcall); | |||
| multicallAddress = codeJar.saveCode(multicall); | |||
| paycall = abi.encodePacked(type(Paycall).creationCode, abi.encode(ETH_PRICE_FEED, USDC)); | |||
| paycallUSDT = abi.encodePacked(type(Paycall).creationCode, abi.encode(ETH_PRICE_FEED, USDT)); | |||
There was a problem hiding this comment.
Wrong price feed?
Also nit: ETH_USD_PRICE_FEED/ETH_USDT_PRICE_FEED
There was a problem hiding this comment.
Sure 🤣 I was too lazy on this particular one, that I assumed USDT is 1:1 pegg in this test lol.
But yeah I will update to the USDT price feed then. 👍
There was a problem hiding this comment.
Probably going to stay with USD price list.
Found out chainlink only has USDT / ETH but not ETH / USDT.
So if we want to use USDT pricefeed, we need some solidity code to inverse it. :(
Co-authored-by: Kevin Cheng <kevincheng96@hotmail.com>
Co-authored-by: Kevin Cheng <kevincheng96@hotmail.com>
Co-authored-by: Kevin Cheng <kevincheng96@hotmail.com>
delegatecallso at the end it can direclty call transfer() to pay for gas without requiring user to approve the contract