Discussion for OT-RFC-16

[NZT48]

Hi Tracers,

I am delighted to announce the latest RFC on bridges implementation for the OriginTrail Parachain.

You can access the PDF version of the RFC through the following link. Additionally, we welcome your feedback and comments on the proposal, which you can provide by opening a PR or reviewing the markdown file.

As always your feedback and comments are much appreciated.

Trace on!

[othub-io]

Great RFC, simple, to the point and a great strategy to mitigate risks across chains.

We particularly like the intermediary TRAC where all mirror TRAC (from different bridges) come together and needs to be converted through a DEX to become the main XC20 TRAC to be used on OT Parachain's DKG. Allowing different mirror TRAC from different bridges would only backfire in the future in case of a hack and we are glad the team is taking this security aspect very seriously.

As for the 2-way teleport, it is a great temporary strategy allowing people to securely (albeit slowly) move their XC20 TRAC back on Ethereum. The only comment we would make is the date and time of the teleportation must be clearly communicated to the community to reduce anxiety.

As for using Moonbeam as an intermediary for phase 2, the idea is good but we are wondering if there would be any way to use OTP instead to give it more utility.

That's it for our feedback for now!

OTHub

[hottogo]

Sounds great but I am not sure phase 2 is worth putting time and effort into, why not just use the XC20 already teleported (monthly) for any parachain implementations. Waiting once a month for a teleport either direction seems fine until the phase 3 hub is up and running.

[drMurlly]

Hi, I emphasize the importance of team communication and clarity about the exact date and time when the teleportation process will be finished. That is important to reduce anxiety and potentially unnecessary additional questions from bridge users about the teleportation process. I would also like to know if, in the whole process, the possibility of adding the utility value to the OTP token.

[Valcyclovir]

@hottogo you need to consider that phase 2 isn't a temporary measure so the effort to develop it isn't wasted. It allows users to choose the bridge they want and bridge their erc20 TRAC to the polkadot ecosystem. BridgeHub is only one way to bridge (albeit the most secure), but users should be allowed to use alternative chains if they wish to. The DEX to exchange bridged TRAC to XC20 TRAC is a great way to ensure the security of XC20 TRAC in case of a bridge hack.

[CosmiCloud]

Not sure if the team is interested in this kind of solution, but Chainlinks CCIP is available for whitelisted developer groups. It could be an interesting alternative to your typical bridge. https://chain.link/cross-chain

[NZT48]

Thank you for your feedback! We want to clarify that the focus of this RFC is primarily on TRAC, and efforts to provide utility to OTP are already underway. We appreciate your understanding and support as we work towards enhancing both TRAC and OTP functionalities.

As for phase 2, it plays a crucial role in providing users with more options and flexibility. Our vision is to empower the community to choose their preferred bridge for bridging TRAC to the Polkadot ecosystem. Offering multiple bridge options allows users to make decisions based on factors such as security and cost, catering to their individual needs and preferences.

Note: The RFC-16 will remain open for comments until Friday Aug 4th 1pm UTC.

[NZT48]

Not sure if the team is interested in this kind of solution, but Chainlinks CCIP is available for whitelisted developer groups. It could be an interesting alternative to your typical bridge. https://chain.link/cross-chain

Thanks for suggestion @CosmiCloud, I took a quick look and I don't see Polkadot under supported networks. Maybe I missed something. :)

[NZT48]

Hi Tracers,

Thanks everyone for the feedback and support for this RFC. We are closing this discussion and continuing with the plan proposed in RFC-16.

Cheers!