Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revert splitting of Moonbeam receiver contract #185

Open
ebma opened this issue Oct 2, 2024 · 9 comments
Open

Revert splitting of Moonbeam receiver contract #185

ebma opened this issue Oct 2, 2024 · 9 comments

Comments

@ebma
Copy link
Member

ebma commented Oct 2, 2024

Context

To work around issues introduced by the increase in gas cost on Moonbeam, the receiver contract was split into two parts for #137, resulting in additional overhead on the frontend application.

It seems like squidrouter managed to deploy a fix that works around this issue and the original logic would work again. To reduce the overhead, the splitting of the receiver contract should get reverted.

TODO

  • Add changes to allow the execution with either the automatic forwarding or the split receiver contract. When re-adding the logic for the automatic forwarding, point to the old receiver contract 0x066d12e8f155c87a87d9db96eac0594e872c16b2, more info here.
  • Add a simple boolean flag to a config (either hardcoded or supplied via env variable) that defines which approach should be used.
  • Test that the 'old' logic works
@ebma
Copy link
Member Author

ebma commented Oct 2, 2024

@pendulum-chain/product this change will also speed up the offramping process.

@ebma
Copy link
Member Author

ebma commented Oct 2, 2024

@TorstenStueber
Copy link
Collaborator

We should probably also test what Squidrouter did in the mean time. Do they really respect the estimatedGas parameters? Can we change this in the future if we need to (e.g., if Moonbeam changes their weight settings again?)

@gianfra-t
Copy link
Contributor

I would personally leave the code around. Not as an automatic fallback since that would be quite a lot of work for a very unlikely scenario, but such that it's easy to plug the "new" logic back.

@TorstenStueber
Copy link
Collaborator

@gianfra-t so the suggestion would be to have a config parameter that determines what option we want to use? Could make sense that way.

@ebma
Copy link
Member Author

ebma commented Oct 4, 2024

Good point, I changed the description to reflect that.

@vadaynujra
Copy link

@ebma @TorstenStueber, Will the reduction of the overhead as a result of this change result in the off-ramp becoming quicker for the user? By how much would this change quicken flow?

@TorstenStueber
Copy link
Collaborator

Yes. About 10-20 seconds.

@prayagd
Copy link
Collaborator

prayagd commented Nov 7, 2024

@vadaynujra moved this ticket to being prepared in the light of current priority

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants