Native Meta Transactions

[LayneHaber]

Summary

The proposed upgrade makes meta-transactions a first class citizen within the TransactionManager.sol. The current contracts rely on msg.sender checks, specifically for the routers, preventing the use of relayer networks like ITX or Gelato.

Motivation

Should allow all functions to accept meta transactions at any point. This will allow routers and users to access any relayer network, providing a different option to relieve a long-standing problem of transaction sending problems. Currently, this problem is addressed by creating a separate Router contract which adds gas overhead to every transaction when using relayers.

Proposed Solution

All TransactionManager functions should accept an additional RelayerFeeDetails parameter:

struct RelayerFeeDetails {
  address relayerFeeAssetId
  uint256 relayerFee
  bytes calldata relaySignature // sig of participant on details + transactionId + function signature
}

In each function, if the msg.sender is not the appropriate participant, then the signature should be validated and relayer fees distributed.

Test Cases

The following tests should be implemented for both user and router relayer fees:

it("should work without a relayer fee", () => { ... })
it("should work with a relayer fee in the same asset as transfer", () => { ... })
it("should work with a relayer fee in a different asset than transfer IFF participant has liquidity stored onchain", () => { ... })
it("should fail if fee is worth more than transfer amount and it is the same asset", () => { ... })
it("should fail if there is not enough liquidity to support relayer fee if it is a different asset", () => { ... })
it("should fail if the signature is invalid", () => { ... })
it("should work for multipath fees", () => { ... })

Outstanding Questions

• How should multipath relayer fees be handled? Should the RelayerFeeDetails passed in to the functions be an array i.e. RelayerFees[5]?
• If users transfer junk assets, will they not be eligible to use relayers (assuming relayers do not support that asset)?
• If we are allowing relayer fees to be in separate assets from the transfer, should we store relayerFee liquidity in a separate mapping from transfer liquidity?

Tasks

• Implement relayer fee helper utility
• Add relayer fee helper to all external TransactionManager functions
• Tests

[wanglonghong]

I don’t think its the right way. because the first blocker is that we couldn’t deploy price oracle some chains especially on moonbeam. Also, we couldn’t set aggregator or dex record even though we deployed price oracle. This was the main difficult point when we calculated the gas fees. so we just used mainnetEquivalent for all the networks.
The second blocker is that we have to calculate gasUsed after getting the end gas and calculate the next gas to transfer relayerFeeAsset.
If we use hardcoded gasLimits, it will be upgradable?

[rhlsthrm]

Not only does this create a huge dependency for a local onchain price oracle for each asset we want to transfer (which several routers have pushed back on because of low liquidity everywhere except Ethereum), but this construction also creates a vulnerability:

This is only for the gas calculation, the asset paid to the relayer can (and probably will) be different than the asset being transferred.

Also, this is optional to include the price oracle and is potentially a nice optimization to not have to pass this information in, can scale better to full-onchain systems such as DAOs fulfilling transfers. Instead of the oracle, you can pass in an exchange rate.

There is no upper limit on the amount of fees that can be given to relayers from a given user transaction. This means that miners or frontrunning bots are now economically incentivized to bump gas such that they consume 100% of the transacted amount in order to get the maximum relayerFeePercentage possible.

This is why I agree with @jakekidd 's suggestion to use a flat fee for relayers instead of a percentage. If we do that I think we would not have this problem.

In theory, this also means that routers could cancel a transaction if it is going to be unprofitable for them. With onchain gas calculation, it becomes much more likely that routers now have many unprofitable transactions because they have no control over the costs paid to relayers.

They could calculate if it's unprofitable by estimating the gas and seeing how much it will cost.

[jakekidd]

They could calculate if it's unprofitable by estimating the gas and seeing how much it will cost.

Imo, it should be the responsibility of relayers to determine whether a tx is profitable. That should be what we strive for here.

The reason I say we should delegate that responsibility is because it's bigger than just estimateGas - it's also simulating the tx on-chain and seeing if it returns a profit - which is easy enough to do with ganache, etc, if you run a node.

I'm ok with, in the short-term, Gelato covering things even when it's not profitable for them, and sending us the bill. But that doesn't seem like a sustainable business model for both parties

[ArjunBhuptani]

Huh? Relayers don't bump gas. Relayers are given a signed metatx with a preset gasPrice and gasLimit. The upper limit is the gasLimit lol. *EDIT: Or is this no longer the case with these changes? lol, guess we would have to add the gasPrice to the transaction data to solve this then

Yes, in this construction, the gasPrice is set by the relayer. Having it be signed by the router and passed in is what exists currently and is the only way to avoid relayers bumping up gas to frontrun each other and consume all of the transferred amount in gas costs.

FYI, relayers can't currently consume more gas than is needed. We overestimate the gasLimit for the purpose of relayer fees (which isn't capital efficient but is a necessity), and that same gasLimit is assigned to the transaction.

In the current construction, the router can specify a relayer fee of X as part of the tx. If the relayer ends up using 2X when sending onchain, they still only get X in fees. This is what I meant in the orignal comment.

This is only for the gas calculation, the asset paid to the relayer can (and probably will) be different than the asset being transferred.

Sure we can have routers sign this and pass it in, but then why not also do that for gas price.

This is why I agree with @jakekidd 's suggestion to use a flat fee for relayers instead of a percentage. If we do that I think we would not have this problem.

We would definitely still have this problem, except now relayers are frontrunning each other for a flat amount rather than scaling amount. The core problem is: this construction allows for relayers to frontrun each other for free.

Imo, it should be the responsibility of relayers to determine whether a tx is profitable. That should be what we strive for here.

Yes 100% - this is what we have live currently. With the proposed construction, relayer txs are always profitable and the onus is instead shifted to routers, which is bad.

[jakekidd]

Sure we can have routers sign this and pass it in, but then why not also do that for gas price.

agreed, yes, we 100% need to sign that param

We would definitely still have this problem, except now relayers are frontrunning each other for a flat amount rather than scaling amount. The core problem is: this construction allows for relayers to frontrun each other for free.

I think the responsibility to not get frontrunned is on the relayers. And, assuming they are doing it right (i.e. use flashbots, run your own node, and/or have large network of providers to inject in mempool, etc) and with the necessary requirement of a fixed gasPrice (signed gasPrice) it would be pretty hard to frontrun.

[ArjunBhuptani]

I think the responsibility to not get frontrunned is on the relayers

This is still the relayer's responsibility. But it is impossible to guarantee that the signed tx data from a router will not be leaked when being broadcasted to one or many relayer networks (especially when we have an auction chain where all signed txs are now publicly available to anyone who indexes the chain).

It is our responsibility to avoid game theory that incentivizes free frontrunning/MEV.

[jakekidd]

1. At the start of the function call gasLeft to get the starting gas

This step is not necessary. Instead of subtracting final gas from starting gas, just subtract gasLeft from gaslimit at the end before paying relayer fees, and that's the amount of gas you've consumed so far.

[liu-zhipeng]

I think we can't get gasLimit of transaction in solidity. If we want to use gasLimit on solidity we have to pass that variable. (We can just get gasLimit of block in solidity)

[jakekidd]

you are right! I was misled

source confirms: https://ethereum.stackexchange.com/questions/18370/can-solidity-access-the-gaslimit-not-just-the-remaining-gas

[jakekidd]

Just a fair note, if you do include the gasLeft in step 1 in this case, we need to add to that the exact amount of gas it costs to call gasLeft lol

[LayneHaber]

Yes there are some gas assumptions we would have to add in here

[jakekidd]

If the priceOracleAddress is supplied, use the PriceOracleInterface to get the rate of the relayerFeeAsset to the native asset. Otherwise, just use the supplied exchangeRate

How much does it save on gas to use exchangeRate ? If the price oracle is a TWAP (a lagging indicator) anyway, I feel like, as the router, I'm almost always going to read from the price oracle off-chain and pass in the exchangeRate to save a lil bit of gas.

Also, the user signs the received amount, so they are signing the relayer fees in this case... meaning there's no way for the router to collude with relayer and fudge a stupid exchange rate for the relayer fee on receiver fulfill. Right?

[LayneHaber]

How much does it save on gas to use exchangeRate ?

Not exactly sure, would have to do both the implementations and compare.

If the price oracle is a TWAP (a lagging indicator) anyway, I feel like, as the router, I'm almost always going to read from the price oracle off-chain and pass in the exchangeRate to save a lil bit of gas.

Could go either way -- more beneficial to read from TWAP or offchain depending on the direction of the price changes.

Also, the user signs the received amount, so they are signing the relayer fees in this case... meaning there's no way for the router to collude with relayer and fudge a stupid exchange rate for the relayer fee on receiver fulfill. Right?

User doesn't sign the received amount, the idea here is to delegate all relayer fee calculations to the contract so the user/router can just trust the contract logic instead of having to sign things. Also, the relayer fee used would be deducted from each person, so the router wouldn't have any bearing on the users relayer fee. Instead, the received amount would vary based on what that fee is.

[jakekidd]

increment by the relayerFeePercentage

Personally, I 100% disagree with paying relayers a percentage. I think it doesn't make any sense - relayers should take any transaction that is profitable so long as they make enough profit over time to maintain their offchain servers/hosting/infrastructure.

Let's just pay them a flat fee per tx. We can negotiate what that should be with the relayer aggregators, e.g. Gelato.

[LayneHaber]

Sure, that's a better idea.

[liu-zhipeng]

I think the main blocker would be calculating gas fee after getting last gasLeft.
We need some extra operations to calculate token amount from gasPrice and gasUsed.

...
uint gasUsed = startGas - gasLeft();
uint gasInToken = gasUsed * tokenPriceFromEth;
....
emit Event(...);
return xxxx;

So we have to decide gas fee for the last extra operations, and it seems that is the only way to calculate gas amount from solidity opcode and hardcode. But it could be different on all chains and changeable over time. So there is no way to resolve this problem perfectly.

[LayneHaber]

Yeah -- we would have to do some opcode analysis and set a configurable estimation for this

[rhlsthrm]

But it could be different on all chains and changeable over time. So there is no way to resolve this problem perfectly.

Why would it be changeable over time? Wouldn't that require a hardfork?

[liu-zhipeng]

Yeah, hardfork would be a good example. So I think it should be a kind of configurable or something.

[base0010]

This is very true, there is some interesting way you could do this onchain and make it publically callable to reset the opcode price in case of hardfork I think

[jakekidd]

From a discussion with @LayneHaber:
This will add to the overhead of a transfer, yes. But currently we run the calculation based on the total gas limit (which is in all cases, an overestimation), not the gas spent.

How much extra are routers spending on relayer fees based on this overestimation? It's a good question - we don't know exactly, but we can determine this by looking at the receipts in the logs (for like the past couple weeks) and see what the average amount we are overestimating by is (in terms of gas units). The receipts have a totalGasUsed value or something for this.

If the average amount of gas units by which we overestimate when determining relayer fees is >= the cost of adding this overhead to the transfer, then this addition would save money (or just be about how much we were spending anyway).

If the avg overestimate is by < the cost of adding this overhead, then we may want to reconsider (based on how much additional overhead we're adding vs convenience)

[jakekidd]

We can move ahead with this spec as-is as far as I'm concerned and assign this tasking as part of the testing phase.

[LayneHaber]

Updated the above spec to reflect that relayer fees should be passed in.

[wanglonghong]

Another unclear thing is if we can get l1gasUsed and l1gasPrice for optimism network and gasPriceBid for arbitrum network. because during the analysis of gasLimits for all networks, I found out that I couldn't get that information using getTransaction and getTransactionReceipt function. If we can get those on contracts, its really good, but if not, we will have to think another cases for optimism and arbitrum.

[LayneHaber]

Still relevant with the updated direction