[Core Protocol] FailedRelayedMessage handling

[linkeong88]

Did you check the documentation?

• Yes

Did you read the specs?

• Yes
• No

Did you check for duplicate questions?

• Yes

Issue Description

I have send a bridge from ethereum main net to base chain using the contract bridgeerc20to, however when it arrived on base it shows FailedRelayedMessage but does not proceed further. Now I have a stuck bridge and I’m unable to go forward and unable to revert. What is the handling for this error? I see previously if the message failed it gets reverted back to main net

https://basescan.org/tx/0x3e2ec42e03d20aa8c3c06a38f1b55a502078dcaa80e5113936387eab47c90f28#eventlog

Additional Information

No response

Feedback

No response

[1195597989]

You can try to use the relayMessage to attempt to replay the message1.

[linkeong88]

It will give the same failure. Is there any other way?

[hash1go]

#380 (reply in thread)
According to Lido's guidance, it seems that the deposit's tx of wstETH should be made using this app.
If you issued the transaction through Etherscan, that method is not supported.

If you used the standard bridge, are the transaction details displayed on this page?
If they are displayed, what is the status?

[hash1go]

The past example you provided was successful in relaying the message, hence the revert process was carried out. However, your transaction may have failed in the message relay, which could be why no recovery process has occurred.

[linkeong88]

That’s the problem in the first post, when it shows failedrelaymessage what is the next step in handling? Why given the same methods of deposit the message is handled differently and the message was sent using the steps in documentation provided. This question is for the dev team.

So something was send successfully from L1 and locked up correctly on the L1 bridge but unable to receive on L2 with no proper next steps. The lockup happen like the 100s of other token on the L1 base bridge which means it should be able to bridge back to unlock, the token did not vanish into thin air

[hash1go]

It seems that the destination for message relays in the deposit process for wstETH is different from the standard in L2. However, your deposit transaction appears to have failed in the message relay because it specified the standard address as the destination.

I will inquire with the OP Team about the recovery process, but it may take a few days.

[linkeong88]

Thank you, the previous example I posted also specified the tokens on L2

[hash1go]

Hello. I apologize for the delay in providing an update on this matter.
I checked with the engineer at OP Labs, and it seems that your tokens are stuck and cannot be recovered.

[linkeong88]

I would hope that the dev actually try to see if there are any solutions rather than just brush it off, as the tokens are now held by the chain owners and anyone bridging to the chain had trusted the credibility of the devs, this will take a big hit on the credibility and drive away users. Furthermore this is not an isolated case or edge case that devs are trying to paint as can be seen from previous postings and other people getting stuck