Update ERC-7786: Add requestRelay

ERCS/erc-7786.md

@@ -92,27 +92,27 @@ A gateway MAY be upgraded with support for additional attributes. Once present s
 
 Initiates the sending of a message.
 
-Further action MAY be required by the gateway to make the sending of the message effective, such as providing payment for gas. See Post-processing.
-
 MUST revert with `UnsupportedAttribute` if an unsupported attribute is included. MAY revert if an attribute value is not valid for the key.
 
-MAY accept call value (native token) to be sent with the message. MUST revert if call value is included but it is not a feature supported by the gateway. It is unspecified how this value is represented on the destination.
+MAY accept call value (native token) to be used by attributes or to be sent with the message. In the latter case, it is unspecified how this value is represented on the destination. MUST revert if more call value is included than is needed by attributes and sending value with the message is not a feature supported by the gateway.
 
 MAY generate and return a unique non-zero _send identifier_, otherwise returning zero. This identifier can be used to track the lifecycle of the message in the source gateway in events and for post-processing. _Note that this identifier MAY be different from the `receiveId` that is delivered to the recipient, since that identifier may preferably consist of values like transaction id and log index that are not available in the execution environment._
 
 MUST emit a `MessageSent` event, including the optional send identifier that is returned by the function.
 
+MAY require further action to have the message relayed to the receiver on destination, in particular paying for the gas cost of relaying or delivery. See Post-processing.
+
 #### `MessageSent`
 
 This event signals that a would-be sender has requested a message to be sent.
 
-If `sendId` is present, post-processing MAY be required to send the message through the cross-chain channel.
+If `sendId` is present, further action MAY be required. See Post-processing.
 
 #### Post-processing
 
 After a sender has invoked `sendMessage`, further action MAY be required by the gateways to make the message effective. This is called _post-processing_. For example, some payment is typically required to cover the gas of executing the message at the destination.
 
-The exact interface for any such action is out of scope of this ERC.
+The exact interface for any such action is not mandated by this ERC, but a RECOMMENDED interface is specified further below under Optional Relaying Procedure.
 
 ### Reception Procedure
 
@@ -153,10 +153,60 @@ MUST return `IERC7786Recipient.receiveMessage.selector` (`0x2432ef26`).
 The protocol underlying a pair of gateways is expected to guarantee a series of properties. For a detailed definition and discussion, we refer to XChain Research’s _Cross-chain Interoperability Report_.
 
 - The protocol MUST guarantee Safety: A message is delivered at the destination if and only if it was sent at the source. The delivery process must ensure a message is only delivered once the sending transaction is finalized, and not delivered more than once. Note that there can be multiple messages with identical parameters that must be delivered separately.
-- The protocol MUST guarantee Liveness: A sent message is eventually delivered to the destination, assuming Liveness and censorship-resistance of the source and destination chains and that any protocol costs are paid.
+- The protocol MUST guarantee Liveness: A sent message is eventually delivered to the destination, assuming Liveness and censorship-resistance of the source and destination chains.
 - The protocol SHOULD guarantee Timeliness: A sent message is delivered at the destination within a bounded delivery time, which should be documented.
 - The above properties SHOULD NOT rely on trust in some centralized actor. For example, safety should be guaranteed by some trustless mechanism such as a light client proof or attestations by an open, decentralized validator set. Relaying should be decentralized or permissionless to ensure liveness; a centralized relayer can fail and thus halt the protocol.
 
+### Optional Relay Request Procedure
+
+The delivery of a message to its recipient will incur a gas cost that the protocol must cover. This includes execution on the destination chain, and MAY include other intermediate processing necessary prior to execution, such as proof generation, verification, etc. The following functions of a gateway allow the sender to pay for this cost on the source chain.
+
+Note that relaying SHOULD be permissionless. No relayer should be relied on for liveness of the protocol.
+
+```solidity
+interface IERC7786Relayer {
+    // OPTIONAL
+    function quoteRelay(
+        bytes calldata recipient, // Binary Interoperable Address
+        bytes calldata payload,
+        bytes[] calldata attributes,
+        uint256 value,
+        uint256 gasLimit,
+        address refundRecipient
+    ) external view returns (uint256);
+
+    function requestRelay(
+        bytes32 sendId,
+        uint256 gasLimit,
+        address refundRecipient
+    ) external payable;
+}
+```
+
+#### `quoteRelay`
+
+Returns an estimated amount of native token required to relay a message with the provided parameters and with a certain gas limit.
+
+This function is OPTIONAL, so a sender must be prepared to handle a revert.
+
+#### `requestRelay`
+
+Requests that the message identified by `sendId` be relayed and delivered to the recipient.
+
+Pays via `msg.value` for the execution of the message on the recipient up to `gasLimit`. A relayer fee MAY be deducted, the specifics of which are not standardized and SHOULD be available out of band (e.g., as gateway documentation).
+
+Any surplus after execution at destination SHOULD be refunded to the `refundRecipient` account. The refund can be paid on the source chain or on the destination chain if the `refundRecipient` is a valid account there (or if there is an equivalent account, e.g., by aliasing as applied in rollups).
+
+##### Attribute Form
+
+Instead of calling `requestRelay` as a separate step after sending, the two steps can be combined into one by invoking `sendMessage` with an attribute with the following signature:
+
+```
+requestRelay(uint256 value,uint256 gasLimit,address refundRecipient)
+```
+
+When a message with this attribute is sent through a gateway that supports it, it MUST behave as if the `requestRelay` function was invoked as a second step with the implied `sendId` and `value` as the call value.
+
 ## Rationale
 
 Attributes are designed so that gateways can expose any specific features the bridge offers without having to use a proprietary interface. This should allow contracts to change the gateway they use while continuing to express messages the same way. This portability offers many advantages: