Update ERC-7786: Add requestRelay
#981
Conversation
|
✅ All reviewers have approved. |
I don't think this should be part of the standard. I think gas services will implement this, but it shouldn't be required. |
I think so. I think more generally there should just be an estimate fee mechanism, that returns exactly what the user should pay to get the message delivered and executed. So it would also include any sort of fixed costs, in addition to the gas price. |
I think the gateway should include these functions, so that way everything a user needs to send a cross chain message is encapsulated in one contract. But it should be possible for a separate contract to implement just the gas service part of the interface, so that way users can use a different gas service than whatever is tied to the gateway. |
ERCS/erc-7786.md
Outdated
|
|
||
| Requests that the message identified by `outboxId` be delivered to the receiver (i.e., relayed). | ||
|
|
||
| Pre-pays via `msg.value` for the execution of the message on the receiver up to `gasLimit`. A `relayerFee` should be deducted from this to compensate the relayer. |
There was a problem hiding this comment.
what if the destination chain has a different custom base token?
There was a problem hiding this comment.
This is another open question for me. It could have to be paid directly in the destination chain gas token, but this may not be the UX we want. It may need to be swapped for the destination chain token, either at source or destination, though this sounds like it may leave the sender vulnerable to attacks if not designed correctly.
| string[] calldata refundReceivers | ||
| ) external returns (uint256); | ||
|
|
||
| function requestRelay( |
There was a problem hiding this comment.
In a protocol where the sending & the relay requesting are not separated, what should this function do?
There was a problem hiding this comment.
In this case, sendMessage would not actually interact with the protocol, the message would be stored until requestRelay is invoked. Alternatively, the requestRelay parameters are included as an attribute and it can all be done in one go.
There was a problem hiding this comment.
Sounds like the sendMessage function would be quite the misnomer then 😄
Why separate the sendMessage & relay functionality in this standard at all? I know this closely follows the Axelar workflow so maybe @cjcobb23 can comment
Questions: