[API-3392] Profitability Checks #3
Conversation
…s to submit txs to be relayed, introduce max gas price pct config option and store in db
…at a tx should be relayed
…n evm chains in uusdc
…plicit relay via db polling
| transfer_value TEXT, | ||
| max_gas_price_pct INTEGER, |
There was a problem hiding this comment.
relay profitability options are now stored in the db along with the transfers info
| @@ -190,47 +206,67 @@ func (c *HyperlaneClient) getISMAddress(ctx context.Context, recipient string) ( | |||
| } | |||
|
|
|||
| func (c *HyperlaneClient) Process(ctx context.Context, domain string, message []byte, metadata []byte) ([]byte, error) { | |||
There was a problem hiding this comment.
slightly refactored the Process function just to pull some logic out into helpers (getting signer and getting address) since that logic is now also needed in QuoteProcessUUSDC
| // find settlement txns in the db and insert them as pending | ||
| // hyperlane txns in the hyperlane table | ||
| if err := r.findSettlementsToRelay(ctx); err != nil { | ||
| return fmt.Errorf("finding settlements txns to relay: %w", err) | ||
| } | ||
|
|
||
| // find timeout txns in the db and insert them as pending hyperlane | ||
| // txns in the hyperlane table | ||
| if err := r.findTimeoutsToRelay(ctx); err != nil { | ||
| return fmt.Errorf("finding timeout txns to relay: %w", err) | ||
| } | ||
|
|
There was a problem hiding this comment.
no longer polling the db for timeouts rows and settlement rows, these services will call the SubmitTxToRelay function on the relayer runner. this forces services that need hyperlane relaying to explicitly require the relayer runner as a dependency
| // note that there is no profitability option being passed to the relayer | ||
| // here, timeouts transfer no value to the solver so if we pass a config | ||
| // for a min allowed gas % the timeout will never be relayed | ||
| return r.relayer.SubmitTxToRelay(ctx, txHash, initiateTimeoutChain, hyperlane.RelayOpts{}) |
There was a problem hiding this comment.
curious if people have thoughts on the comment here? the issue is the normal profitability checks look at the value that the hyperlane relay will give to the relayer, and decides if the gas fee % of the total value is < their specified max fee %. however for timeout relays there is no value being transferred to the solver (the solver just does this at a loss). the only metric I could think of would be to have a minimum gas fee in uusdc or gwei specific to the relay destination chain and just not relay until gas is lower than that amount (or eth price drops if specified in uusdc). but again, relaying the timeouts is kind of 'for the good of the protocol', so maybe we don't want to allow people to wait to submit timeout relays since that would be a worse experience for users?
|
two small comments otherwise lgtm 🙏 |
… uusdc calculation
This PR adds checks when relaying a settlement (or any type of relay, but this is only implemented for settlements for now) that the settlement is going to be profitable for the relayer (since gas costs can be very high for the settlement relay on evm chains). Profitability is determined as follows:
Processcall on the evm side (processis the function that delivers the hyperlane message and calls the recipient contract, in our case that the is gateway contract).processcall to get the estimated tx fee in gweiThis also does some refactoring work around how hyperlane relays are submitted from other services that require replying. The order settler and the order fulfiller (specifically the timeout portion of the order fulfiller) have been refactored to directly call
SubmitTxToRelayon the hyperlane relayer runner, instead of there being an impact dependency on them inserting a row into the submitted tx's table, and the hyperlane relayer runner polling that table for transfers to relay.