improve(API): Apply gas mark up to base fee rather than gas cost

[nicholaspai]

depends on across-protocol/sdk#801

Fixes ACX3600

Expected changes to API

See notes here about impact of bumping the sdk version: https://github.com/across-protocol/frontend/pull/1339/files#r1903169393

If we set the environment variables BASE_FEE_MARKUP and PRIORITY_FEE_MARKUP equal to the existing GAS_MARKUP values today then the gas fees should be quoted the exact same. We can fast follow by reducing these markups.

The main differences will be:

• 7777777: Zora will be re-added as an OPStack chain which means the l1 gas cost will be added to all estimation. This will make zora quotes a lot more accurate. This is a good thing. Currently, zora quotes are under-estimating gas This is no longer a change since 3568cea was already merged before this

QA Testing

We can test this by querying /api/gas-prices against the same endpoint on the prod deployment. This will show roughly how the gas costs will change with prod.

Comparing against production fee quoting API

Ultimately, what matters is the gasFeeTotal in the /limits end point and we should compare with prod.

• For WETH:
• query /limits for every single destination chain once on Prod API and once on Preview API
• Write down the gasFeeTotal and compare with Preview API
• Note any differences:
• If Prod API has higher gas fee total, then preview API will reduce gas fees but we need to make sure these gas fees are still deemed profitable by relayer
• If preview API has higher gas fee total, then that’s notable as well
• Can use the preview API from this PR Test: Add gas costs to /gas-prices endpoint #1349 to see the gas cost breakdown from the production API

Comparing against Relayer

Relayer's will only fill deposits that leave enough profits to cover for destination chain gas costs. This means that the relayer's computed tokenGasCosts, including any scaling, should be less than the fee quoting API's tokenGasCosts, otherwise the relayer will consider the API's quotes as unprofitable. A simple way to check this is to check the relayer's log that includes the message "Updated gas cost" (in the "ProfitClient") that will list configs for each chain like:

"at": "ProfitClient",
"message": "Updated gas cost",
...
"1": {
      "nativeGasCost": "131167",
      "tokenGasCost": "961072227772860",
      "gasPrice": "7327088580",
      "scaledTokenGasCost": "276308265484697",
      "gasPadding": "1.15",
      "gasMultiplier": "0.25"
    },
...

I recommend using this relayer PR across-protocol/relayer#1969 to print the above logs and compare with the quoted preview API's fees

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
app-frontend-v3	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 7, 2025 6:57pm
sepolia-frontend-v2	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jan 7, 2025 6:57pm

[james-a-morris]

We should let integrators know about this prior to rolling out. This will change expected fees

[nicholaspai]

One difference here. In the current multiplier use case, the SDK adds the gasMarkup to 1 here.

Whereas, the new SDK change I propose assumes that the passed in multiplier is complete already and doesn't need to be added to anything

[nicholaspai]

This file has a lot of changes but its an API endpoint we don't depend on in production as its mostly here to compare against the current existing API to compare the expected gas total changes. The main changes are:

• Adding gas costs (native and token gas cost) to the API response
• breaking down gas price by base fee and priority fee

[nicholaspai]

I think its important to highlight the importance of not letting gasPrice be undefined here, otherwise the effects of the baseFeeMultiplier, based on the developer-set GAS_MARKUP will be discarded. We could even add an assert here...

[nicholaspai]

This SDK change has two important changes that will materially impact the gasFeeTotal value returned in the API response of the /limits (and /suggested-fees) endpoint:

• Zora chain gets re-added back to OP_STACK family which means the fees will go up since OPStack chains add an L1GasCost component
• GAS_MARKUP will be applied to base fee, not total token gas cost, which will cut many gas fee totals down significantly because base fees are much smaller than priority fees on most chains, for example most OP Stack chains

[nicholaspai]

Made gasPrice, tokenPrice and relayerAddress all required since they're never set undefined in this repo and its better to be more constricting on this type where possible

[nicholaspai]

In other words, the change here is: load both nativeGasCost and tokenGasCost from the SDK and pass them both here when computing gasFeePercent. This is useful because the function getCachedFillGasUsage() call uses the opStackL1GasCostMultiplier when computing the tokenGasCost which will give us more configuration options when quoting gas costs.

We now can play with the following configs:

• baseFeeMultiplier set in latestGasPriceCache
• priorityFeeMultiplier set in latestGasPriceCache
• opStackL1GasCostMultiplier set in getCachedFillGasUsage

We take the resultant gas costs and gas prices and pass them into relayerFeeDetails which simply does some simple multiplication and division to return the fee percentages. There should be no more RPC queries in this getRelayerFeeDetails() call

[james-a-morris]

I tested the endpoint and ran the FE - the values look to be expected.