Improve Event Data

[LayneHaber]

Summary

By including fee data in the events, we would be able to get the fees earned from the subgraphs much easier.

Motivation

It is extremely difficult to calculate ROI from the transactions, and being able to include the fees in the event data would be hugely valuable. Right now the easiest way to get that information is by using internal router-monitoring tools (i.e. Prometheus)

Proposed Solution

The TransactionManager should be updated to calculate the receiver amount based on itemized fee data passed into the prepare function:

// Includes all information needed
struct FeeDetails {
  uint256 routerFeePercentage
  uint256 price // from the VAMM 
  uint256 gasCosts // in receiving asset
}

// The invariant data should also include a `sendingChainAmount`
function prepare(InvariantTransactionData invariant, FeeDetails fees) { ... }

Additionally, the event can include the gasConsumed and relayerFeePaid by the transaction.

Test Cases

The following should be implemented:

it("should properly calculate the receiving amount", () => { ... })
it("should emit relayer fees in event", () => { ... })
it("should emit gasConsumed in event", () => { ... })

Outstanding Questions

• Should the routerFee and gasCosts be hardcoded into the TransactionManager? (if hardcoding gas costs, should add the rate of transacting asset to native asset in the fee details)
• Is passing in all of the information to calculate the receiving amount onchain worth the extra gas costs?

Tasks

• Update the TransactionData to include sendingAmount
• Update the VariantTransactionData to include receivingAmount
• Update prepare to calculate the receiving amount properly

[sanchaymittal]

During offsite, we discussed a solution that will allow on-chain calculation for relayerFee.
If we add it then for the updated structure, we only need to send the price offered by the router using vAmm. And oracle address which will share price for feeAsset.

Highlights:

• routerFee global variable of TransactionManager Contract: Instead of passing the routerFee percentage it should be a part of Contract.
• For relayerFee Calculation: Contract will need an oracle address for feeAsset, which could be possibly be passed as param or could be a part of contract global variables. If part of params it should be under InvariantTransactionData which will be passed by the user.

// @param price from the VAMM
// The invariant data should also include a `sendingChainAmount`
function prepare(InvariantTransactionData invariant,  uint256 price ) { ... }

[jakekidd]

I think the solution we discussed is included in #748 , right?

Please note the issue that I shared with it (nothing blocking, just something we need to investigate).

But yeah, agree with the above

[liu-zhipeng]

I agree with @sanchaymittal . Storing some invariant variables on smart contract will save gas.

[ArjunBhuptani]

I made some comments on #748 about this - posting here to make sure those are taken into consideration when finalizing specs.

[LayneHaber]

I think there's two things going on:

1. Router passing in an exchangeRate to calculate the amount they should be preparing on whichever receiving chain
2. Relayer fee being passed in onchain.

Realistically, they don't have to be decided on together because the contract can calculate what the router prepare amount should be with either calculating a relayerFee onchain, or using a passed in one. I'll focus on calculating the prepare amount here, and leave #748 comments for the relayer fee.

Pros:

• Routers aren't allowed to race to the bottom on fees
• Everything is cleanly emitted in events

Cons:

• More gas on each router prepare
• Gas costs of the opposite chain (i.e. when executing SenderFulfill cannot be accounted for)
• Adds dependence on a price oracle
• Cannot iterate on calculations as easily

It's important to note that an easy way to get the event benefits is to just pass in the sending chain prepare amount. You wouldn't be able to solve the race to the bottom with fees that way though, but this is also the current state. In my opinion, the cons outweigh the pros here

[LayneHaber]

After a conversation with @rhlsthrm :

To get the profit for a successfully fulfilled transaction, you must pass the following into the SenderFulfill call:

• Gas cost of receiver chain prepare
• Gas price of receiver chain prepare
• Relayer fee of receiver chain prepare
• Relayer asset of receiver chain prepare
• Relayer asset decimals of receiver chain prepare
• Exchange rate at time of receiver prepare for relayer asset:USD
• Exchange rate at time of receiver prepare for sending asset:USD (to calculate relayer fee in sending asset)
• Relayer fee of sending chain fulfill (already declared)
• Relayer asset of sending chain fulfill (already declared)
• Relayer asset decimals of sending chain fulfill
• Exchange rate at time of sending fulfill for relayer asset:USD
• Exchange rate at time of sending fulfill for sending asset:USD (to calculate relayer fee in sending asset)
• Amount prepared on the receiving chain
• Receiving chain asset decimals
• Sending chain asset decimals
  This data will only be available accurately at the time of sender fulfill, so all profits will only be available on the sending chain subgraph.

To get the cost of an expired transaction, you must pass in the following:

• Relayer asset decimals of receiver chain prepare
• Exchange rate at time of receiver prepare for relayer asset:USD
• Exchange rate at the time of receiver prepare for receiver asset:USD
• Relayer asset decimals of receiver chain cancel
• Exchange rate at time of receiver cancel for relayer asset:USD
• Exchange rate at the time of receiver cancel for receiver asset:USD
  All gas costs are on the receiving chain and easily accessible via subgraph without additional input.

This is a lot of data to be passed in, and adds unnecessary overhead. If the true requirement is easier ROI, then the better route is to lean on a comprehensive subgraph collation layer (especially since the true ROI would not be available without going between chains anyway).

I propose we do not make any contract changes with respect to making it easier to calculate ROI on the subgraph.

[ArjunBhuptani]

jfc. Yes we absolutely should scrap this. Note that calldata increases L2 costs!

[LayneHaber]

Scrapping!