OT-RFC-12 OriginTrail Parachain TRAC bridges

The OriginTrail ecosystem is a two-layer system, driving its two symbiotic networks by their respective crypto tokens — the OriginTrail Decentralized Network (hosting the multichain OriginTrail DKG, as indicated in the whitepaper) driven by its utility token TRAC, and the underlying blockchains with their respective native tokens used for transactions.

The OriginTrail Decentralized Network utility enabled by the TRAC token therefore requires each of the respective blockchains to support the TRAC token according to the TRAC tokenomics design, and requires necessary bridge infrastructure between relevant chains. TRAC being an ERC20 token on Ethereum has been so far successfully bridged to two blockchains — Gnosis chain (formerly xDAI) and Polygon with their respective bridge infrastructure.

With the launch of the dedicated OriginTrail blockchain on Polkadot — the OriginTrail Parachain — the required bridge infrastructure needs to be created to facilitate the OriginTrail DKG operation on this new chain. Moreover, the same infrastructure will enable further network effects for TRAC on all of Polkadot emerging parachain infrastructure and solutions, such as Acala and its DeFi stack (DEX, aUSD stablecoin, etc).

The purpose of this document is to outline the technical approach to bridging the TRAC token to Polkadot via the OriginTrail Parachain and collect relevant feedback from the OriginTrail community.

Bridging TRAC to OriginTrail Parachain and Polkadot

Polkadot is a network designed to enable high interoperability between blockchains and inter-blockchain trustless operations, such as bridging Polkadot based tokens on connected blockchains. As a multi blockchain network of parachains connected via the common Layer 0 Polkadot Relay Chain, bridging tokens is enabled by the powerful cross chain messaging format XCM. Using these inherent functionalities of Polkadot therefore solves the “bridging problem” within the entire Polkadot ecosystem — once the TRAC token is available on the OriginTrail Parachain, making it available to other parachains is a non-issue.

When it comes to external blockchains such as Ethereum however, there are a multitude of bridging approaches evolving in parallel. Two of the most promising approaches at the moment of writing this RFC are:

• Snowbridge, a general purpose trustless bridge in development by the Snowfork team, yet to be launched,
• Chainbridge, an EVM to Substrate bridge already available and in utilization by parachains such as Moonbeam and Centrifuge.

As development progresses, we can naturally expect new and improved bridging solutions in the years to come. Therefore, bridging of TRAC to the OriginTrail Parachain will, over time, most likely involve a multitude of different bridges and related infrastructure as the Polkadot ecosystem evolves. It is therefore essential to plan for this eventuality from the start and thus enable the bridge infrastructure evolution to be “inherited” by the TRAC bridges on the OriginTrail Parachain.

It is important to note that TRAC token will stay an ERC-20 token on Ethereum and will be implemented as a bridgeable asset on the OriginTrail Parachain, which operates with its native token OTP.

Near term bridging approach — Chainbridge

Out of the two approaches outlined above, the core developers of OriginTrail propose the implementation of the Chainbridge bridge system for the first TRAC bridge between Ethereum and OriginTrail Parachain. Chainbridge is a battle tested, two way bridge, used by several teams within the Polkadot ecosystem to move assets to parachains.

Chainbridge implements a bridge smart contract on the Ethereum side (similar to Gnosis and Polygon bridges), with a respective pallet enabled on the OriginTrail Parachain. Tokens are transferred between the Ethereum bridge contract and the parachain via a set of relayers which listen for bridging events on both blockchains and executing the necessary transfers on the blockchain on the “other side” of the bridge, as illustrated below.

The bridged TRAC token will be implemented as a parachain asset on the OriginTrail Parachain and further bridged to the EVM pallet.

The Chainbridge implementation has been significantly researched by the OriginTrail core developers and progressed in implementation together with assistance from the Parity development team. To our knowledge and experience it is the most mature and tested system within the ecosystem and is the proposed solution for the near term.

However, as most existing bridges (such as Gnosis and Polygon bridges) its trust model can be improved, as explained in the Chainbridge docs:

“In its current state ChainBridge operates under a trusted federation model. Deposit events on one chain are detected by a trusted set of off-chain relayers who await finality, submit events to the other chain and vote on submissions to reach acceptance triggering the appropriate handler. Research is currently underway to reduce the levels of trust required and move toward a fully trust-less bridge.”

Therefore a key component of this proposal is to avoid “bridge lock-in” and enable further development of the OriginTrail bridging infrastructure to involve more trust-minimized solutions (such as Snowfork when ready).

The initial set of bridge relayers will be run by OriginTrail core developers, with an ambition to include additional relayers from the ecosystem in the near future.

Long term approach — multiple bridges

We expect a multitude of improvements as bridging infrastructure evolves to support more than one bridge on the OriginTrail Parachain. These will most likely include improvements in security models (trustless bridges), efficiency and user experience. It’s important to note however that having multiple bridge systems bridging the same asset effectively creates multiple “mirror versions” of the same asset on the OriginTrail Parachain.

To enable a sustainable, long term evolution of the bridging infrastructure therefore 3 key considerations need to be applied from the start:

1. Ensuring equivalence of bridged TRAC tokens as they might need to be implemented as “different” assets on the OriginTrail Parachain — for example, a TRAC token bridged via Chainbridge and a TRAC token bridged via Snowfork might be two “mirror version” assets on the parachain, with essentially the same value (1 TRAC). Equivalence would involve enabling OriginTrail DKG and other systems utilizing TRAC to register all TRAC mirror versions on the Parachain as the same (equivalent).
2. Appropriate mirror asset naming should be applied to avoid confusion, especially as these assets move across the Polkadot ecosystem.
3. “Phase out” capability for mirror assets in case of potential bridge issues (such as a major flaw being discovered), which would enable a safe decommission of potentially problematic bridges, ensuring TRAC tokenomics preservation.

Having these points in place while implementing the first bridge is important and already taken into consideration by the core development team.

Conclusion

This document outlines the near and long term approach of enabling the utilization of TRAC token in the Polkadot ecosystem via the OriginTrail Parachain token. We invite the OriginTrail community to provide their improvement proposals, comments and suggestions via the official RFC repository.

👇 More about OriginTrail 👇

Web | OriginTrail Twitter | OriginTrail Parachain Twitter | Facebook | Telegram | LinkedIn | GitHub | Discord