Interesting!
I’ll attempt to restate and summarize in my own words; is this description correct?
- There is a method by which tokens can be transferred en masse from rollup A to rollup B (this requires a base layer transaction and potentially waiting a week)
- Users would not use this method directly. Instead, they would transfer their tokens into a contract on the rollup, and some third party called a Bonder would immediately give them tokens on the destination rollup and in exchange capture that slot in a contract.
Questions:
- Is it really necessary to have a distinct notion of hop tokens? Why not just work with tokens inside the rollup directly?
- One issue I see with (2) is that potentially two bonders could front the funds to the user in the second rollup at the same time. This could be resolved if you require bonders to register their intent before they can front a transfer, and only the first to register would get paid back once the mass transfer completes. Are these the kinds of issues that you’re concerned about when you talk about challenges extending to multiple bonders?
- Do both sides need smart contract capability? Ideally, it would be nice to have a scheme that requires only one side to have smart contract capability (and for that side to be able to be either the sending or receiving side). This way Optimism and/or Arbitrum could serve as hubs, and allow fast transfers not just between each other but also into Loopring, Zksync and other non-EVM rollups.