feat: incentivized cross domain message delivery #272

hamdiallam · 2025-04-22T18:34:08Z

Description

Incentivized relays settlement framework leveraging the data provided in #266

tremarkley · 2025-04-22T22:23:50Z

ecosystem/incentivized-relays-mvp.md

+contract L2ToL2CrossDomainGasTank {
+    uint256 constant MAX_DEPOSIT = 0.01 ether;
+
+    mapping(address => uint256) public balanceOf;


What are your thoughts on having a second mapping keying balance by root message hash?

mapping(address => uint256) public txOriginBalanceOf; mapping(bytes32 => uint256) public messageBalanceOf;

This could still enforce a MAX_DEPOSIT to mitigate risk of a large amount of stuck funds for a given account. The deposit flow would looks like this:

function deposit(bytes32 rootMsgHash) nonReentrant external payable { uint256 amount = msg.value; require(amount > 0); uint256 newTxOriginBalance = txOriginBalanceOf[msg.sender] + amount; require(newTxOriginBalance < MAX_DEPOSIT); txOriginBalanceOf[msg.sender] = newTxOriginBalance; uint256 newRootMessageBalanceOf = messageBalanceOf[rootMsgHash] + amount newRootMessageBalanceOf[rootMsgHash] = newRootMessageBalanceOf }

Then in claim you would have to deduct cost from both balance mappings:

txOriginBalanceOf[txOrigin] -= cost; messageBalanceOf[rootMsgHash] -= cost;

The main benefit of messageBalanceOf is that it removes complexity from the relayer around determining whether L2ToL2CrossDomainGasTank contains enough funds for the gas required to relay a message because relayer can check the balance per message hash instead of having to check for other pending messages that might be associated with that tx.origin. Another benefit, is down the line when we support withdrawals, we could add timeouts per message hash on withdrawals, which would guarantee that the balance for the message hash would exist up until a given block timestamp.

However, a potential downside I see of the messageBalanceOf approach is that it would require a new deposit for every new root message hash. And a potential risk of this approach is that someone could assign a balance of MAX_DEPOSIT to a single message hash (or across multiple message hahes), that ends up not being relayable, and then that account ends up "stuck" and cannot fund any additional messages because the account balance cannot exceed MAX_DEPOSIT. However, this risk becomes mitigated if we assume L2ToL2CrossDomainGasTank is not "production-ready" until there is withdrawal support.

wdyt?

yea this is a great point! I was actually thinking of having support for this not in replacement but for 3rdparty integrator that wants a different fee payer thantx.origin.

The reason it can't replace is that this requires native integration with someone using the L2ToL2CrossDomainMessenger. You'd have to wrap every sendMessage call with a call to deposit. Instead of a replacement, this would be an additive API.

One easy usecase. Lets say Layerzero wants to integrate this feature. Someone sends a message from Solana -> OPM that then spawns a bunch of operations. You dont want the LZ relayer from Sol->OPM to be the fee payer. However, the LZ DVN that integrates the L2ToL2CDM can use this api to specifically just push whatever gas was provided from the original tx as the deposit for the given root msg hash. Then everything just works. And if the provided gas wasn't enough, the person can top up the given root msg hash with more funds

Does this make sense?

100% agree that this first version should actually include this, i'll add it today

The reason it can't replace is that this requires native integration with someone using the L2ToL2CrossDomainMessenger. You'd have to wrap every sendMessage call with a call to deposit. Instead of a replacement, this would be an additive API.

when you say additive API, are you saying that the gas tank will support balance tracking and claiming by tx.origin and by msg hash?

by default claiming by tx.origin unless the rootMsgHash has an explicit balance set.

If the rootMsgHash has a balance set, i think it should not claim by tx.origin. Is there a scenario where you think it should fallback to tx.origin after depleting the funds associated with the msg hash?

If the rootMsgHash has a balance set, i think it should not claim by tx.origin. Is there a scenario where you think it should fallback to tx.origin after depleting the funds associated with the msg hash?

Hmm, if we are going to support balances by tx.origin and by msgHash then we should fallback to tx.origin. Otherwise, a bad actor could potentially try to make it more difficult for a msg to relay by setting a very small balance to any msg hash they want to prevent from being relayed, and then the user would have to intervene and increase the balance on that msg hash in order to get it to relay.

The other option here is to just simplify things and only support msgHash balances. Even though it will always require an extra deposit, can't that be simplified by something like 7702?

tremarkley · 2025-04-22T22:39:08Z

ecosystem/incentivized-relays-mvp.md

+}
+```
+
+We cap the deposits in order to cut scope in supporting withdrawals. This makes our first interation super simple since as withdrawal support introduces a race between deposited funds and a relayer compensating themselves for message delivery. With a relatively low max deposit, we eliminate the risk of a large amount of stuck funds for a given account whilst the amount being sufficient enough to cover hundreds of sub-cent transactions.


Are we planning to launch this to mainnet without withdrawal support? My understanding was that prior to launching to mainnet withdrawal support would be a requirement.

yes I think that's right Harry!

I think all the way till mainnet is an open question. This lets us get to a first version and maybe we have time to iterate on a version with withdrawal support for mainnet

ecosystem/incentivized-relays-mvp.md

tremarkley · 2025-04-23T21:57:14Z

ecosystem/incentivized-relays-mvp.md

+        require(messenger.sentMessages[rootMsgHash]);
+
+        // ensure unclaimed, and mark the claim
+        bytes32 claimId = keccak256(abi.encode(rootMsgHash, callDepth));


isn't it possible to have two messages with the same rootMsgHash and callDepth? For example, if a message goes from A -> B and then from B two more messages are kicked off (B -> C and B -> D), then I believe C and D will both have the same rootMsgHash and callDepth. why not just use msgHash here?

yep i really should just use the msg hash here. Idk why i'm creating a new unique identifier when one exists

What if we use full msgHash + chainId + receipt blockNumber; this guarantees uniqueness even for identical sub-calls (A→B then A→C), right? Just thinking of ways to further protect against double spend.

tremarkley · 2025-04-23T22:03:53Z

ecosystem/incentivized-relays-mvp.md

+contract L2ToL2CrossDomainGasTank {
+    uint256 constant MAX_DEPOSIT = 0.01 ether;
+
+    mapping(address => uint256) public balanceOf;


If the rootMsgHash has a balance set, i think it should not claim by tx.origin. Is there a scenario where you think it should fallback to tx.origin after depleting the funds associated with the msg hash?

Hmm, if we are going to support balances by tx.origin and by msgHash then we should fallback to tx.origin. Otherwise, a bad actor could potentially try to make it more difficult for a msg to relay by setting a very small balance to any msg hash they want to prevent from being relayed, and then the user would have to intervene and increase the balance on that msg hash in order to get it to relay.

The other option here is to just simplify things and only support msgHash balances. Even though it will always require an extra deposit, can't that be simplified by something like 7702?

ecosystem/incentivized-relays-mvp.md

fainashalts · 2025-04-23T02:33:04Z

ecosystem/incentivized-relays-mvp.md

+
+With an incentivation framework, we can ensure permissionless delivery of cross domain messages by any relayer. Very similar to solvers fulfilling cross chain [intents](https://www.erc7683.org/) that are retroactively paid by the settlement system.
+
+This settlement system is built outside external to the core protocol contracts, with this iteration serving as a functional MVP to start from. Any cut scope significantly simplifies implementation and can be re-added as improvements in further versions.


Suggested change

This settlement system is built outside external to the core protocol contracts, with this iteration serving as a functional MVP to start from. Any cut scope significantly simplifies implementation and can be re-added as improvements in further versions.

This settlement system is built outside of the core protocol contracts, with this iteration serving as a functional MVP to start from. Any cut scope significantly simplifies implementation and can be re-added as improvements in further versions.

ecosystem/incentivized-relays-mvp.md

fainashalts · 2025-04-24T21:29:44Z

ecosystem/incentivized-relays-mvp.md

+        require(messenger.sentMessages[rootMsgHash]);
+
+        // ensure unclaimed, and mark the claim
+        bytes32 claimId = keccak256(abi.encode(rootMsgHash, callDepth));


What if we use full msgHash + chainId + receipt blockNumber; this guarantees uniqueness even for identical sub-calls (A→B then A→C), right? Just thinking of ways to further protect against double spend.

ecosystem/incentivized-relays-mvp.md

fainashalts · 2025-04-24T21:39:29Z

ecosystem/incentivized-relays-mvp.md

+
+1. The relayer must simulate the call and ensure the emitted tx origin has a deposit that will cover the cost on the originating chain.
+2. The relayer should also track the pending claimable `RelayedMessageGasReceipt` of the `rootMsgHash` callstack to maximize the likelihood that the held deposit is sufficient.
+3. The relayer should claim the receipt within a reasonable time frame to ensure they are compensated. An unrelated relayer not checking (2) might claim newer transitive message that depletes the funds.


should we add blockTimestamp to RelayedMessageGasReceipt and let the gas tank owner set maxReceiptAge?

tremarkley · 2025-04-24T22:15:58Z

ecosystem/incentivized-relays-mvp.md

+        uint256 newBalance = balanceOf[msg.sender] + amount;
+        require(newBalance < MAX_DEPOSIT);
+
+        balanceOf[msg.sender] = newBalance;


I think it would be good to emit a deposit event

karlfloersch · 2025-04-29T19:26:05Z

Idea -- Add a intermediate version of this where there is a flat fee which is paid to a single relayer. Even though it doesn't work in all cases, it would get us to an 80% solution without having to implement the more complex logic in the onchain bounty

hamdiallam · 2025-05-09T16:05:07Z

Idea -- Add a intermediate version of this where there is a flat fee which is paid to a single relayer. Even though it doesn't work in all cases, it would get us to an 80% solution without having to implement the more complex logic in the onchain bounty

Check out the alternatives considered sections. Added a bit about an intermediate permissioned gas tank iteration that we can do

hamdiallam self-assigned this Apr 22, 2025

hamdiallam changed the base branch from l2tol2cdm-gasreceipt to main April 22, 2025 18:34

hamdiallam changed the base branch from main to l2tol2cdm-gasreceipt April 22, 2025 18:38

tremarkley reviewed Apr 22, 2025

View reviewed changes

tremarkley reviewed Apr 23, 2025

View reviewed changes

ecosystem/incentivized-relays-mvp.md Show resolved Hide resolved

fainashalts reviewed Apr 24, 2025

View reviewed changes

hamdiallam mentioned this pull request Apr 24, 2025

RelayedMessageGasReceipt & Propagated Message Context #273

Open

fainashalts reviewed Apr 24, 2025

View reviewed changes

tremarkley reviewed Apr 24, 2025

View reviewed changes

This was referenced May 7, 2025

feat: L2ToL2CDM SentMessage ctx #266

Open

feat: L2ToL2CDM RelayedMessageGasReceipt #282

Open

hamdiallam force-pushed the incentivized_relays branch from a1b54bf to 81af36b Compare May 9, 2025 15:56

hamdiallam changed the base branch from l2tol2cdm-gasreceipt to l2tol2cdm-gasreceipt-only May 9, 2025 15:56

incentivized relays

e25f7d9

hamdiallam force-pushed the l2tol2cdm-gasreceipt-only branch from c4b947e to 8c3dae0 Compare May 9, 2025 15:58

hamdiallam force-pushed the incentivized_relays branch from 81af36b to e25f7d9 Compare May 9, 2025 15:58

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: incentivized cross domain message delivery #272

feat: incentivized cross domain message delivery #272

hamdiallam commented Apr 22, 2025

tremarkley Apr 22, 2025

hamdiallam Apr 23, 2025 •

edited

Loading

hamdiallam Apr 23, 2025

tremarkley Apr 23, 2025

hamdiallam Apr 23, 2025

tremarkley Apr 23, 2025

tremarkley Apr 22, 2025

fainashalts Apr 23, 2025

hamdiallam Apr 23, 2025

tremarkley Apr 23, 2025 •

edited

Loading

hamdiallam Apr 24, 2025

fainashalts Apr 24, 2025

tremarkley Apr 23, 2025

fainashalts Apr 23, 2025

fainashalts Apr 24, 2025

fainashalts Apr 24, 2025

tremarkley Apr 24, 2025

karlfloersch commented Apr 29, 2025

hamdiallam commented May 9, 2025


		With an incentivation framework, we can ensure permissionless delivery of cross domain messages by any relayer. Very similar to solvers fulfilling cross chain [intents](https://www.erc7683.org/) that are retroactively paid by the settlement system.

		This settlement system is built outside external to the core protocol contracts, with this iteration serving as a functional MVP to start from. Any cut scope significantly simplifies implementation and can be re-added as improvements in further versions.

feat: incentivized cross domain message delivery #272

Are you sure you want to change the base?

feat: incentivized cross domain message delivery #272

Conversation

hamdiallam commented Apr 22, 2025

Choose a reason for hiding this comment

hamdiallam Apr 23, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tremarkley Apr 23, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

karlfloersch commented Apr 29, 2025

hamdiallam commented May 9, 2025

hamdiallam Apr 23, 2025 •

edited

Loading

tremarkley Apr 23, 2025 •

edited

Loading