Discussion for OT-RFC-12

[branarakic]

Hi Tracers,

This issue is dedicated for discussions on OT-RFC-12 - OriginTrail Parachain TRAC Bridges

You can find the first version of the RFC here

[DalSlacker]

My understanding is that even after a successful bridging process, a user is still at risk of the bridge he used going rogue (getting hacked/whatever). Even if a bridge were hacked a year later and the hacker drained the TRAC from it, the user could lose his previously-converted TRAC because all the pTRAC created by that bridge would need to be inactivated.

For the initial Tracer/Polkadot population, while there is still a trusted centralized structure associated with OriginTrail (ie Trace Labs), it would be favorable (and confidence-inspiring) to have a one-time conversion of TRAC (or xTRAC) to pTRAC via an official means. Whether that be a TRAC/xTRAC token burn and associated TGE on Polkadot or something more technical. Some option that would allow the conversion process to be completed without having to take on the additional risk of bridge failure for an indefinite period of time would be greatly appreciated. This would likely only be possible, however, if the team is aware of a major exchange that will list pTRAC for trade. If there is an exchange that will allow trading of pTRAC (and possibly its equivalents), than this should be considered.

[Valcyclovir]

To add to the comment above by @DalSlacker, I too am hesitant to take on any additional risks by using a third-party NOT trustless bridge and having to hold that "mirror" TRAC on the DOT ecosystem for an indefinite amount of time.

In order to reduce the potential risks associated with bridged assets, this bridge should be a one-time transition that should not carry any long term risk to the bridge user.

If I am to use the bridge, I need at least one of the following:

1. An exchange is available on the other side of the bridge for my "mirror" TRAC to prevent locking myself out.
2. The team proposes an official otpTRAC for all trace holders who bridged their assets over using any bridges to hold and use on the DOT ecosystem.
3. Some assurance that in case the bridge goes wrong, the team will have a way in the near future to compensate and exchange any "locked-out" TRAC.

edit: I no longer wish to use any bridges for my TRAC after more elaborate discussions. Istatkov made a great point on a solution that's in my opinion way better than trusting a third party bridge.

[DalSlacker]

A good resolution would be to make a change from ETH as the "base" blockchain token to using the parachain version as the base token

If 99% of the publishes/assets are likely to be on the parachain, this certainly makes sense

Create an official one-way bridge for all ETH TRAC holders. Keep this bridge open for 6 months or whatever. Burn the ETH trac that gets bridged. Allow the construction of a bridge FROM polkadot to other blockchains.

The people that keep their pTRAC on the parachain will be using it to actively support the network in the way it is intended. The minority of users that would like to branch out to other blockchains should be the ones taking the additional risk with a public bridge.

[Valcyclovir]

I like your resolution a lot actually. If we expect OT Parachain to be the principal chain for DKG activities, then this is a great opportunity to allow a one-time transfer and burn mecanism to move over our ERC-20 TRAC to otpTRAC.

This solves the problem of having too many "mirror" TRAC on OT Parachain and the added risk of using a bridge.

[calr0x]

I'm all for permanently abandoning ETH.

[hottogo]

I like the proposed solution in the comments above to avoid bridge risk, however this would involve the issuance of new Trac, which even though would still stick to the hardcap, makes me uneasy. It shouldn't be so easy to create Trac, it should require a community vote or something.

Another proposed alternative: could the treasury support the transition with some form of bridge insurance, backed by their reserves. Maybe a 12 month gaurantee to give other bridge options time to be developed? It doesn't remove future risk but it allows for people to split their holdings across multiple bridges etc.

[Valcyclovir]

I understand the team wants to keep the ERC-20 identify for TRAC and TRAC being multichain and all. It can still remain that way once it is ported to otpTRAC. However, if we expect 99% of DKG activities on the parachain, then we shouldn't mainly be a ERC-20 token.

For instance, Enjin is in the same situation as we are - they have a parachain token and a erc-20 token to bridge over. However, since they expect most users will prefer to leave their tokens on Efinity, not all features developed for Efinity will be backported to ERC-20 Enjin. Their priority is set on developing Efinity and the only suggested bridge on their end is Snowfork, which is the one I am most comfortable with. source: https://efinity.io/whitepaper/cross-chain-bridge

I hope the team considers an alternative like the ones we've mentionned above that really minimizes risks over anything. As we have witnessed, crypto is still a very volatile and risky environment and we can't afford to stack risks together, as little as they might seem. Speaking of which, hardware wallets that are only partially compatible with parachains is also a huge risk factor. Hardware wallet compatibility is something that must be worked on ASAP to mitigate risks once the tokens are ported over to OT Parachain.

[Valcyclovir]

I like the proposed solution in the comments above to avoid bridge risk, however this would involve the issuance of new Trac, which even though would still stick to the hardcap, makes me uneasy. It shouldn't be so easy to create Trac, it should require a community vote or something.

Another proposed alternative: could the treasury support the transition with some form of bridge insurance, backed by their reserves. Maybe a 12 month gaurantee to give other bridge options time to be developed? It doesn't remove future risk but it allows for people to split their holdings across multiple bridges etc.

The 12-month guarantee is a nice addition to what I wrote earlier on my point 3 "Some assurance that in case the bridge goes wrong, the team will have a way in the near future to compensate and exchange any "locked-out" TRAC."

I am glad more people are voicing their concern about the security of using bridges.

[DalSlacker]

I like the proposed solution in the comments above to avoid bridge risk, however this would involve the issuance of new Trac, which even though would still stick to the hardcap, makes me uneasy. It shouldn't be so easy to create Trac, it should require a community vote or something.

Another proposed alternative: could the treasury support the transition with some form of bridge insurance, backed by their reserves. Maybe a 12 month gaurantee to give other bridge options time to be developed? It doesn't remove future risk but it allows for people to split their holdings across multiple bridges etc.

I like the idea of the 12 month guarantee, but I still think that pTRAC should be the "main" token moving forward. This would be the ideal opportunity to make that happen (it would become much more difficult to do later on)

As far as the ease/difficulty in creating TRAC, I wholeheartedly agree that it would make me uneasy to see it being created without complete transparency. We obviously trust the TL team and they are completely running the show at this point, and I believe that they could complete the transition with the transparency required to ease our minds (ie Bridge provides a link to the ETH transaction where TRAC was burned and another link to the parachain transaction where pTRAC was created). And there is always a running, accessible ledger of each pTRAC creation tx and the associated TRAC burn.

As long as there is a hard cap on the time span of such a one-way bridge (ex 6 months) and the decentralized voting/governance structure isn't implemented until afterwards (which I'm sure will take a while), I feel like it is a good option. I certainly feel more confident trusting the team not to mint excess coins over 6 months than in trusting one (or multiple) bridges to remain unexploited forever

[hottogo]

To change from ERC-20 native Trac token to a DOT main TRAC, we would need to basically abandon/burn/destroy the erc-20 Trac and then issue the same new amount on Polkadot. Then rely on bridges to get it back to Eth and other chains. Pretty centralised move but long term could have security benefits.

The other issue is what if Polkadot doesn't win the blockchain war? It would be a very rash move to ditch the ERC-20 standard while Polkadot is still finding its feet, if a new blockchain gets developed next year do we re deploy on that instead of bridging from Polkadot?

I believe that for now using the bridge is our only option, down the track if Polkadot proves to be our long term home it may make sense to re-issue the tokens to avoid bridge risk.

In the meantime, as above, a 12 month insurance gaurantee on the bridge security would be very welcome.

[Valcyclovir]

I think the team is pretty set on OT Parachain and Polkadot being our main home for the foreseeable future. Having a hybrid token setup and our own blockchain tailored to the DKG is pretty clear that we have settled with the Polkadot team.

I'm on the side of the argument of issuing otpTRAC as the main TRAC as it will serve 99% of network activities going forward, but also giving the opportunity to the minority of people wanting to remain on xdai / matic / eth to do so as well. They will be able to port their tokens over using a bridge anytime, and this minority of people will assume the long term risk of using a bridge.

The team specified this on the RFC: Chainbridge implements a bridge smart contract on the Ethereum side (similar to Gnosis and Polygon bridges)

While this is true, we always knew Gnosis and Polygon were temporary solutions while waiting for our own blockchain. It was fine to use those bridges for a short amount of time, but now we are asked to stomach the risk, as little as it may be, of using a third party bridge for the foreseeable future. Eventually, there will be more than one bridge, and that just adds to the complexity of having different "mirror" TRAC tokens, and the risks of choosing the right or wrong bridge. There are plenty of stories we can look up of hacked bridges and loss of funds.

tldr; Knowing that

1. the team's interest is aligned with Polkadot,
2. we have always wanted our own blockchain tailed to the DKG,
3. the team has no current plans to move away from OT Parachain,
4. there is only one bridge available now and the long term risk is unknown,
5. a higher amount of bridges mean a higher risk that one eventually fails / get hacked,
6. a higher amount of bridges mean more "mirror" TRAC tokens,
7. 99.99% of DKG network activity will remain on OT Parachain due to added incentives,
8. ERC-20 TRAC is only used to finish current jobs with no new jobs issued,
9. ERC-20 TRAC transaction fees remain high and hinders adoptions,

I believe that a new otpTRAC token on our own blockchain is the best solution to mitigate risk and complexities for the big majority of TRAC holders. The minority of people who wants to remain on Ethereum, Gnosis or Polygon can do so, and are able to bridge over to OT Parachain through any third party bridge they wish and assume that risk.

[Istatkov]

After some discussions, seems there is concern that we will bridge the majority of the current supply over to OTP (lets say 300M TRAC) to OTP, and essentially we will rely on that bridge to function properly and remain in service for the years to come. Given that the majority of the hacks in the past years were exactly to bridges and the turned out to be weakest link atm, seems a bit too much risk to trust the majority of the supply to a project that is just few weeks old.

A possible solution would be that we use the SFC migration contract from 2021, and do a one time exercise to migrate whoever wants their TRAC over to OTP, so we can avoid the supply being held by a 3rd party dev who can abandon their project tomorrow. Once the majority of the TRAC is over to OTP, we can move small amounts back to ETH through whatever bridges are available to be used across other blockchains, but that would be a small percentage compared to the total supply as most of the action will be on the OTP side. Moreover can't the SFC staking contract work both ways? I.e. send TRAC to it, get TRAC on OTP side. Send TRAC from the OTP side, unlock TRAC on the ETH side? This way we wont really need a bridge as well.

Would that be feasible?

[botnumberseven]

I agree with a trust issue here. Let's say we have a user who wants to move TRAC from ETH to OTP and run nodes here. If I understand correctly by doing it thru Chainbridge they accept a multi-year risk of this bridge to be hacked/failed/etc... right? And they need to put their trust not in Trace Labs, they are asked to put their trust in Centrifuge, which is... several months old project without any significant track record really. That's just not good enough for a multi-year commitment. That's too much to ask a user in my mind. User should not be asked to put any additional risk in order to support the network/project at Polkadot in comparison to ETH/Gnosis. Let alone risk of that magnitude.

[Valcyclovir]

Milian aka @Istatkov you are phenominal and it's always great to have your input here.

Indeed, having to rely on a recently built third party bridge for an indefinite amount of time is NOT ideal, especially when that bridge is not trustless and is also the weakest point of entry for hackers.

If most of the DKG activity is expected to be on our parachain, then I also expect most of our TRAC supply to follow. Therefore, vigorous risk management should be priority above all.

Using the SFC contract also seems to me like the ideal solution here. The community did trust the team and the SFC contract by maxing out the capacity at 100M TRAC tokens. Most community members should agree that as long as we keep the risk factors in-house (through OriginTrail's team), it is acceptable. I believe the benefits of using a our own smart contract far outweights the risks of using a third party bridge (let alone several of them in the future).

However, just like the team, I do believe in interoperability and having the option to choose, and that is why this SFC contract to port ERC-20 TRAC over should only be available for a limited time to port our TRAC over to OT Parachain for those who do not want to use a bridge. As Polkadot and parachain projects progress and as trustless bridges get built and become more reliable, using those bridges will become a more secure and acceptable thing. By then, we would also be moving much smaller amounts of TRAC. The most important decision is to have the majority of our token as a native otpTRAC with no intrinsic risks associated with bridges. We cannot have the majority of our main TRAC token carry the risk of using a bridge for a long indefinite time. In other words, bridges should go FROM our main OT Parachain to other blockchains, not the other way around.

Going back to the main key considerations,

1. Ensuring equivalence: This will almost be a non issue with the smart contract. If most people use it (as they did during SFC staking), there will only be a very minority of "mirror" tokens

2. Appropriate mirror asset naming Again, much less of an issue with an official otpTRAC on OT Parachain. We will have a few variants down the line to work out but poses very little trouble in the short term.

3. “Phase out” capability for mirror assets A non issue if we are able to have an official otpTRAC.

[mucke12]

@botnumberseven ChainBridge is not build by Centrifuge but ChainSafe. ChainBridge is also used by Projects like moonbeam and others.

[Valcyclovir]

We can debate all we want about the safety of ChainBridge and how it is used by MoonBeam or other projects.

However, here are the facts:

1. Only Efinity and OT Parachain have ERC-20 native tokens to bridge over, other parachains do not share the same situation.
2. We are talking about bridging almost ALL of our entire ERC-20 TRAC tokens
3. MoonBeam is all about interoperability and of course they will use many bridges including ChainBridge, that does NOT mean ChainBridge is a safe bridge
4. Like the team said, all bridges have their own risk, and the main risk of using ChainBridge is that it is NOT a trustless bridge
5. Most bridges are still in development and our options are clearly limited right now

This situation is unprecedented in the Polkadot ecosystem. We are basically bridging over ALL our TRAC circulating supply. The team made it clear, OT Parachain is going to be the one chain that's going to host most DKG network activities on.

Knowing all this, can you truly say you are comfortable having almost the entire OriginTrail project using Chainbridge due to that being our only option now ?

[mucke12]

@Valcyclovir I totally get your point and no, I would also not bridge all my trac right from the beginning with ChainBridge. There is also no need for this, we all know that many functions will only come over time. Also not sure how far away XCMv2 is and if a better solution can be build on this attempt. But till than, we could use the Chainbridge to start with.

[Valcyclovir]

@Valcyclovir I totally get your point and no, I would also not bridge all my trac right from the beginning with ChainBridge. There is also no need for this, we all know that many functions will only come over time. Also not sure how far away XCMv2 is and if a better solution can be build on this attempt. But till than, we could use the Chainbridge to start with.

Yes and no, now is the best opportunity to port our ERC-20 TRAC over through a smart contract rather than using bridge pallets, which could be a solution later on when more bridges become available.

Without knowing more, I still believe the hybrid method is the best solution now: port the majority of our ERC-20 TRAC supply over via smart contract for the next 6 months, then use any methods available through third parties.

[acadeum7]

I also agree with the general sentiment here. Having to trust a 3rd party bridge with no proven track record with potentially a large percentage of all circulating of TRAC sounds like a situation that should be avoided if possible. As @Valcyclovir brought up, I also do believe that if we have the option to reuse a smart contract that has been proven to work (starfleet onboarding), which is also first party, we should use that approach. Maybe once trustless bridges start appearing and other bridges start proving them selves by surviving, I think we could start using them.

[ETotptrac]

Whilst RUNE was pre-Mainnet they used Binance-RUNE and Ethereum-RUNE. When Mainnet arrived users could burn the B-RUNE and E-RUNE for Mainnet Rune. Now the latter tokens are being deprecated. This surely has to be the solution for a project of the magnitude of Origintrail. If we need to keep an Ethereum presence, enable TRAC burning for the TRAC on Ethereum. We are not interested in TRAC to be part of a trusted and/or potentially hackable bridge. Origintrail cannot be 'only as good as the bridge from Ethereum'.

[mucke12]

@ETotptrac burning trac would mean, no way back to ETH. We are a multi chain Project and yes we still need the Ethereum presence for the future.

[DalSlacker]

@ETotptrac burning trac would mean, no way back to ETH. We are a multi chain Project and yes we still need the Ethereum presence for the future.

Untrue, there would still be a way back to ETH

It would mean that the 1% of people that would prefer to have ETH TRAC would be able to use a third-party non-trustless bridge like the one that was proposed. They would end up with some type of wrapped TRAC.

If that sounds a little sketchy, it should... but it's the same situation as going the other way only with WAY fewer people (and fewer tokens) needing to use that bridge

[djildjoo123]

My specific technical knowledge is limited, but reading all comments it would seem illogical to accept an increased risk (bridge use), for an undefined period of time (until trustless bridge I.e.) for the most of trac total supply. I agree that if chainbridge should be chosen, that there will be plans/reassurement in case of bridge hack/failure. Using a SFC like smart contract would also seem a great option. Again, my two cents with limited technical knowledge.

[ETotptrac]

@ETotptrac burning trac would mean, no way back to ETH. We are a multi chain Project and yes we still need the Ethereum presence for the future.

The capabilities of Origintrail are unique, those of Ethereum are shared by many other smart contract ecosystems. Origintrail is multi-chain only in a very limited sense of the wider Ethereum eco-system and Polkadot. It's not on Binance Chain, Cardano, Avalanche or Solana. Exposure to those chains would be properly multichain. Keeping TRAC as an Ethereum token makes Origintrail an Ethereum chain with all the scaling and governance centralization problems currently associated with it.

[ETotptrac]

How about a bridge that compartmentalises wrapped transfers from transfers that the user intends to burn for native OTP-TRAC?

The ETH-TRAC holder decides that they want to burn their ETH-TRAC for OTP-TRAC.

They send it through the bridge but instead of receiving the normal 'wrapped TRAC' for OTP they choose to receive OTP-TRAC. In so doing the user asks the bridge to send the ETH-TRAC to a burn address. This happens before the user receives some inert tokens representing Bridged-TRAC. User then takes their Bridged-TRAC tokens to a smart-contract where they exchange it for native OTP-TRAC

It can also work in reverse so native OTP-TRAC holders can convert back into ETH-TRAC again

A problem with this approach is we have to trust the bridge not to give the user more tokens than the ETH-TRAC that was burned

---

Another idea: don't use a bridge. Use a smart contract on OTP that has an ETH burn address on Ethereum

The ETH-TRAC holder initiates the process of burning ETH-TRAC on the OTP by requesting from a smart contract on OTP an amount of native OTP-TRAC equivalent to the amount of ETH-TRAC they plan to send to the OTP burn address on Ethereum. The ETH-TRAC holder also tells the smart contract which address the ETH-TRAC is coming from.

The native OTP-TRAC issuer only sends out native OTP-TRAC to the address of the requester once it has received the ETH-TRAC into its burn address on Ethereum from the stated ETH address.

A third-party oracle would have to be trusted in this case to tell the issuer on OTP that the burn address has received the TRAC from the stated ETH address. Or maybe the burn address on ETH can port over this TRAC to OTP through a bridge as an inert TRAC token, which could be delivered directly to the smart contract which could burn it itself. So a third party oracle may not be required?

[FamousAmos-ChillZone]

What is a Cross-chain bridge and how do they work.

A cross-chain bridge connects independent blockchains and enables the transfer of assets and information between them, allowing users to access other protocols easily. cross-chain bridge helped solve the problem by providing an easier way to move funds between different networks. Cross-chain bridges work by "wrapping" tokens in a smart contract and issuing native assets you can use on another chain. For instance, wrapped BTC (wBTC) is an ERC-20 token that uses BTC as collateral. Users must deposit BTC on the Bitcoin blockchain before receiving wBTC tokens on the Ethereum network.

Typically, these bridges have a "relayer" mechanism that monitors the origin chain for deposits and creates proofs, which it sends to a smart contract on the destination chain. Thereafter, the smart contract will automatically mint tokens on the target chain.

In the case of ChainBridge, a Bridge Relayer network listens for recent events on it's Ethereum based smart contracts and executes bridge transactions allowing for the production of a native assets on the OriginTrail Parachain.

What are some potential risks of using cross-chain bridges?

A cross-chain bridge undoubtedly has many benefits, but it also has downsides that can include theft, failure to work properly, and hacking. Let’s break down some of the vulnerabilities inherent in a cross-chain bridge a bit further and give some examples:

• Theft of user funds (Smart Contract hacks)
• Liveness Issues
• Malicious Exploits (Unsecure Relayer Networks etc etc)

As previously stated by @Istatkov, there is significant risk in utilizing modern bridges. If an exploit is suffered, the OriginTrail team and community could be forced with considering multi-year payback plans as is the case with Harmony who suffered a loss of $99,340,030.00 worth of digital assets across approximately 65,000 wallets and 14 different asset types.

There is also a hidden risk that is unique to our network that is presenting itself. Due to the fact that we have additional layers to our implementation, risks on ethTRAC not just affects a user's holding but also the sustenance of the DKG directly. Considering it is very likely the first group of individuals moving their ethTRAC over will be node runners, the entire ecosystem is at even greater risk as it would be the holdings of our infrastructural builders among general speculators. This is a very important consideration. Not all the ethTRAC to be bridged have the same value as it relates to what it's holder will utilize that TRAC for. We certainly need to protect node runners at all costs for the longevity of our ecosystem.

So ChainBridge Or No?

Well, it is important to understand that no decision in our current market comes without risk. We are in an extremely fast paced environment building technologies no one has ever seen before. Thus, the name of the game is risk mitigation at every level of the process meanwhile pressing ever forward. Thus, I do believe ChainBridge should be utilized as long as the ecosystem understands the standard and aim is to be trustless. Chain bridge currently utilizes a trusted relayer network which needs further decentralization to enhance the security and robustness of it's protocol. With this in mind, OriginTrail Data Pioneers should be mindful about the portions of their holdings they are transporting via any trusted bridge network. Also, running in parallel to that thought, we should aim to offset the risk of bridge hacks and invulnerabilities as much as possible by producing innovative ways to resolve the trusted bridge dependency. The real risk of utilizing ChainBridge in our ecosystem is the length of time by which it remains our only option. This is because the longer the bridged state of TRAC via ChainBridge (lets call it cbTRAC) get locked into other Polkadot activities, as well as our own adoption, the harder it would be to get users to move their holdings back over to ETH to be bridged in a trustless manner. Combined with the fact that over time the bridge will naturally accumulate value as the adoption and utility of pTRAC will be most desirable. (Atleast, this is how I understand things)

The Problems.

Beyond the issue of smart contract vulnerabilities on the Ethereum smart contract vaults, or the issue of leveraging a trusted network of relayers, there exist the issue of a "Sharded Trac". My understanding is that each individual bridge will produce a state of TRAC that is unique to the bridge leveraged for the transmission process.

Thus:

• If a users send 1 ethTRAC via Snowfork, they would receive 1 sfTRAC as a native asset on the OriginTrail Parachain
• If a users send 1 ethTRAC via ChainBridge, they would receive 1 cbTRAC as a native asset on the OriginTrail Parachain

Ultimately,

• If a users send 1 ethTRAC via X-Bridge, they would receive 1 X-TRAC as a native asset on the OriginTrail Parachain.

Thus, this means the OriginTrail Parachain will have to trust and equate the value of each X-TRAC asset state to the equivalent value of 1 ethTRAC.

A Solution?

(Please keep in mind this is just an idea to get more ideas flowing. I'm in the process of learning these systems so I'm 100% open to criticism).

Right now the OriginTrail Parachain has to trust each bridged asset state. A ChainBridge (cbTRAC) asset state would be different from a SnowFork(sfTRAC) bridged asset state. All of which must be brought onchain by a network of centralized or decentralized trusted relayers. In addition to all the above forms of bridging ethTRAC, I propose replacing the "trusted relayer" layer (pun intended) with the ability to bridge TRAC from one's OriginTrail Node.

Forgive me as I'm just thinking out loud and I'm not totally certain on all the technical aspects of the possibility. However, risk for bridged TRAC can be minimized by allowing TRAC to be bridged by node runners via the DKG by opening StarGates.

Introducing StarGate Command

StarGate Command is a Decentralized Index of all TRAC asset states bridged to the OriginTrail Parachain stored on the Decentralized Knowledge Graph as assets. The amount of ethTRAC bridged to the OriginTrail Parachain is stored in StarGate Command along with it's corresponding asset state aka (is it cbTRAC or sfTRAC logged in SGC (StarGate Command).

From the perspective of the OriginTrail Parachain:

• 1 cbTRAC = 1 sfTRAC = 1 pTRAC

Thus, assets bridged to the OTP should never actually touch the OT Parachain in their bridged asset state. Instead, since substrate's custom runtime does allow off chain pallets to perform data sharing between off chain and on-chain networks, we use our decentralized network to offset the inherent centralization of trusted relayers and we establish consensus on bridged assets over the Decentralized Knowledge Graph.

Since most of the TRAC in our ecosystem is held by node runners, I feel like that would take away that majority of the risk we see from mainstream bridges. Allowing for trustless bridging for those with more experience in our ecosystem meanwhile mitigating risk for the fundamental folks that support our network. Thus, SGC accumulates all the states of these bridged assets and issues pTRAC ONLY on the OriginTrail Parachain. This would allow users to send TRAC assets in different asset states (via chainbridge cbTRAC, snowfork sfTRAC, or our nodes ethTRAC) but also create a unified asset state (pTRAC) which would remove the proliferation of different TRAC asset states across the Polkadot ecosystem. With pTRAC as the unified asset state on the Polkadot Ecosystem, we can effectively move forward with a streamlined user experience for exchanges, VCs, and builders of the polkadot ecosystem interacting with OriginTrail. Holders can rest assured that each pTRAC they encounter in the wild has verifiable value. If a particular bridge becomes deprecated, utilizing onchain governance of some sort, we can allow for initial asset state of a particular StarGate Licensce to be converted to another bridge asset state. This approach directly addresses the 3 considerations for "sustainable long term evolution" presented by the OriginTrail team.

Opening A StarGate

Opening a StarGate is when a node runner bridges ethTRAC via their OriginTrail Decentralized Node to the OriginTrail Parachain. Runners would, via an interface of some sort, request a job that is designed to hold predetermined amount ethTRAC to be locked in an indefinite publishing. (This request should also hold the address of the receiving wallet on the polkadot side and such information). The bridged ethTRAC will be locked in a contract in the same way jobs are locked today. However, the difference should be that the ethTRAC stays locked until a certain event is triggered (from the polkadot side) via the DKG. Now the DKG nodes interface with OTP off chain pallet to then trigger the production of pTRAC. The receiving wallet on the Polkadot side receives pTRAC equivalent to the amount of ethTRAC locked in the StarGate. Similar to the mechanics of jobs today, just, instead of splitting everything 50/50 and returning to management, maybe the holder is rewarded a portion from the amount being transported to the specified wallet. All transmissions with all the corresponding cryptographic information logged in StarGate Command.

One issue I've thought up with this is that in order to bridge pTRAC back to the ETH network, you'd need to either use the same address or some how have a receipt for how much ethTRAC you've bridged to the Polkadot side available to you from the Polkadot side for verification issues. We would not want users trying to return more ethTRAC than they've sent, thereby artificially inflating our token supply and creating a double spend problem. If someone has bridged 10 pTRAC to (wallet 1) and then switched to (wallet 2). There needs to be a way of knowing that the balance owed by (wallet 1) in ethTRAC is the same as the balance owed by (wallet 2) in ethTRAC and preventing them from sending pTRAC they do not have a right to bridge. Thus, I the propose issuing a dynamic DKG supercharged NFT, a "StarGate License", that a holder can hold in their wallet which can be used from the Polkadot side to reopen a StarGate to bridge a certain amount of pTRAC from Polkadot across the DKG to ETH. Each StarGate License also stores which bridge was used to transact (Reading from StarGate Command). Thus users can only return funds via the bridge they have a license to use. And since the only way to obtained a StarGate License is by bridging ethTRAC to the OriginTrail Parachain users can never return more than they have borrowed or someone else has bridged. This means someone can also sell their StarGate License, effectively selling the right to bridge a certain amount of pTRAC that corresponds to the license. "ethTRAC to pTRAC StarGate Licences" may be seen as more "Secure" than "cbTRAC to pTRAC StarGate Licenses". Thus, may even sell for more than the USD value of the pTRAC holding within the license. Of course, having the license doesn't mean you can just bridge that amount. You still need to have the amount of pTRAC you'd like bridged to ethTRAC in your wallet. However, not just the amount, but also the previous asset state. Each StarGate License will keep track of the type of bridged used and it's "post pTRAC" asset state.

The only asset that can be burned in the TRAC ecosystem is pTRAC as it's state is only a representation of value held elsewhere and not the value itself. If a user in the future uses snowFork to bridge 10,000 ethTRAC. The end user should get 10,000 pTRAC and a StarGate License to return 10,000 sfTRAC. StarGate Command will keep a decentralized index of all the StarGate Licenses and their states. Only the amount of X-TRAC held in that cbTRAC or sfTRAC NFT can be sent back to a specified eth wallet. This means all users must always repay all amounts of ethTRAC owed in pTRAC creating a healthy balance.

Why Bridge via the DKG

This may be as a result of my lack of knowledge, however, my current limited knowledge of the trusted relayer networks of modern bridges indicates that they must constantly listen to the state of a particular blockchain to verify the state of a contract living under it's domain in order to trigger events on another external blockchain. Our nodes interact with blockchain networks via respective RPC services to embed our hashes for data immutability but nothing more than that at the moment. The infrastructure to constantly digest the state of a blockchain and act as a relayer would require us to build an independent network of nodes that can handle that load, we then also have to figure out how to decentralized it to make it trustless, or; we can perform significant hardware and software upgrades over our nodes to act as a relayer network which introduces so many layers of testing that it would effectively render our entire infrastructure a testnet once more. Ha. Ha........

Thus, instead of forcing our nodes to read something they cannot yet read, why not make it read something it was built to read. This means we get to leverage the decentralizaton of our DKG and network to bridge TRAC. The drawback is Star Gates can ONLY be opened with TRAC as only TRAC can be used in the DKG. However, StarGate Command will work for bridges of all kinds.

StarGate Command - StarGate Command is a Decentralized Index of all TRAC asset states bridged to the OriginTrail Parachain stored on the Decentralized Knowledge Graph as assets.

StarGate Bridge - StarGate Bridge is a decentralized protocol that allows OriginTrail Node runners to bridge TRAC to polkadot via their OriginTrail nodes.

StarGate - A StarGate is an instance of a the StarGate Bridge which holds all the crypto graphic information and tokens of a bridge transaction.

Again, this is all to promote health discussion and sharing of ideas.

https://github.com/OriginTrail/OT-RFC-repository/blob/main/RFCs/OT-RFC-12%20OriginTrail%20Parachain%20TRAC%20bridges.pdf

https://snowbridge-docs.snowfork.com/building-with-snowbridge/xcm-for-assets/

https://talk.harmony.one/t/reimbursement-proposal-horizon-incident/20665?u=announcements

https://talk.harmony.one/t/reimbursement-proposal-horizon-incident/20665?u=announcements

https://www.bloomberg.com/news/articles/2022-06-24/crypto-bridge-horizon-is-hacked-for-100-million

https://www.alchemy.com/overviews/cross-chain-bridges#:~:text=Source-,What%20is%20a%20cross%2Dchain%20bridge%3F,to%20communicate%20with%20each%20other.

[mucke12]

@FamousAmos-ChillZone well written and I really like the idea of StarGate. I hope we can see all these ideas in the future to split risk.

[Valcyclovir]

@FamousAmos-ChillZone Very thoroughly written and love your suggested idea. @branarakic any thoughts on the elaborate discussion so far ?

[hottogo]

I agree, great contribution Amos

[Valcyclovir]

Speaking of bridges, just now we are witnessing another Nomad bridge being hacked 190M assets, happening as we speak. https://twitter.com/nomadxyz_/status/1554246853348036608?s=20&t=o65ZS_6fjyUmPb9pu3dTgA

This is the most chaotic hack Web3 has ever seen, despite the bridge seemingly safe, with trustless off-chain agents, an error in the code allowed the hacker to empty the bridge.

Nomad was also chosen as the canonical bridge for Moonbeam Network among a few others. Chainbridge being used by Moonbeam does NOT mean it's anymore safe and should not be a reason we should trust any bridge.

Just thought I'd throw this here since we are discussing exactly that. This is not something non devs (or even devs) can foresee, and the best way to not get our TRAC supply compromised is to NOT use any bridges.

If OT Parachain is our main L-1 blockchain for the foreseeable future, then our L-2 DKG token should also be a native token.

[Valcyclovir]

After speaking to several community members, the consensus seems to be a no to using a bridge to port their asset over to OTP. Some members, including myself, say they will only bridge a very small amount (about 10%) if that would be the only way proposed by the team, for now.

There seems to be 3 solutions proposed here so far, in simple words:

1. Burn ERC-20 TRAC, mint otpTRAC, holders can then use any bridge they wish FROM otpTRAC TO other blockchains to maintain our core value of interoperability
2. Use the SFC smart contract to LOCK ERC-20 TRAC, and release a native otpTRAC. If holders wish to return to ERC-20 TRAC, use the smart contract again to UNLOCK.
3. Leveraging our DKG, node runners and our StarGate Command to basically lock ERC-20 TRAC through a publish and release otpTRAC. However, it might be more complicated to go back to ERC-20 TRAC.

All 3 solutions proposed have their pros and cons., but in my opinion they are still better overall solutions than relying on a third party bridge.

Number 3 seems to be adding a level of complexity to the porting process and could take over a year to work it out. It is however a VERY great long term solution by utilizing our own DKG to solve the bridging problem. This is something the team should absolutely keep in mind.

Number 2 seems to be a very good middle ground between keeping our ERC-20 identity and allowing a native otpTRAC to be created to bypass any bridging risks. However, it remains to be seen whether the SFC smart contract is able to handle such a task, and the smart contract still has to be maintained properly to avoid exploitable any error in the code.

Number 1 is the most direct and simple solution, a one time mint and burn with no locked tokens, no bridging contracts, no coming back. It is also now my current favorite solution, with Number 3 being the long term goal. It allows us to focus on our OT Parachain and otpTRAC and to completely stop worrying about bridge risks and smart contracts, "mirror' TRAC. Given that future DKG network use is expected to on OTP, we should no longer have to worry about any of that. We remain interoperable as this is the core value of both our team and Polkadot, holders are free to bridge back to Ethereum or other chains, but the main bucket of TRAC should remain native on OTP.

[hottogo]

Good summary @Valcyclovir . The issue I see with option 1, being an eth token burn, is that it is we can't go back once done. It is a very permanent bandaid.

What happens if Polkadot fails or if another chain becomes more scalable or advantageous? What happens if ODN activity is split across many chains as the multichain design envisioned? This token burn idea assumes that the vast majority of activity for the foreseeable future will be on OTP, if that assumption proves false then the token burn was an incorrect move that gave us short term security but but no long term solution.

The reason the lockup methods of bridging have been much preferred for most projects is to protect the concept of max supply. The more the team fiddles with that and burns tokens to mint on other chains back and forth, the less decentralized we are (as the ability to mint additional tokens undermines the decentralization of the project).

I believe option 1 is less desirable than option 2 and 3. As above I also don't think the option of using the bridge with some form of insurance gaurantee from the development treasury should be discounted as another option.

[ETotptrac]

Don't understand why burn/mint is a centralization problem for you when your point of keeping ETH-TRAC is that if we don't 'we can't go back once done'

Who is doing the going back?

[ETotptrac]

"What happens if Polkadot fails or if another chain becomes more scalable or advantageous?"

Why have we moved to Polkadot at all if there are doubts that OTP can be scalable enough?

What does 'advantageous' mean? Liquidity/price?

Question should be: can the technology work on Polkadot. We have moved here so my conclusion is the pre-existing bias is 'yes it can'.

[branarakic]

Thanks so much for all this great input tracers, amazing discussion! The team is preparing an updated version of the RFC and will share it here in the coming days.

Please do keep sharing constructive ideas and opinions, this is what RFCs are all about!

[exaroth]

For those opting for a bridge solution, found this grim compilation on r/cc

The Hacks So Far This Year

Only May didn't register a hack. I've used the term hack but this is a generalisation of whatever attack vector was used to drain funds.

January 20th 2022 - Multichain bridge hacked for ~3 million

https://www.coindesk.com/business/2022/01/20/multichain-hack-worsens-as-loss-of-funds-reaches-3m-report/

January 28th 2022 - Qubit Finance bridge hacked for ~80 Million

https://cointelegraph.com/news/qubit-finance-suffers-80-million-loss-following-hack

February 2nd 2022 - Wormhole bridge hacked for ~323 Million

https://arstechnica.com/information-technology/2022/02/how-323-million-in-crypto-was-stolen-from-a-blockchain-bridge-called-wormhole/

February 8th 2022 - MeterIO bridge hacked for ~4.4 Million

https://cointelegraph.com/news/latest-defi-bridge-exploit-results-in-4-4m-losses-for-meter

March 30th 2022 - Ronin bridge hacked for ~650 Million

https://cointelegraph.com/news/the-aftermath-of-axie-infinity-s-650m-ronin-bridge-hack

April 7th 2022 - Wonderhero bridge hacked for ~300 Thousand

https://mpost.io/wonderhero-token-collapses-after-hack/

June 24th 2022 - Harmony One bridge hacked for ~100 Million

https://www.cnbc.com/2022/06/24/hackers-steal-100-million-in-crypto-from-harmonys-horizon-bridge.html

July 11th 2022 - ChainSwap bridge hacked for ~4.4 Million

https://decrypt.co/75698/chainswap-exploit-leads-to-multi-million-loss-for-defi-tokens

August 2nd 2022 - Nomad bridge hacked for ~200 Million

https://www.theverge.com/2022/8/2/23288785/nomad-bridge-200-million-chaotic-hack-smart-contract-cryptocurrency

IMO using a bridge nowadays is asking for trouble ;)

[ETotptrac]

It makes more sense that the successful projects/apps will decide which layer 1 chains become popular than the popular layer 1 chains of today deciding which apps get liquidity by shuffling stablecoins at it. DYDX moving to Cosmos may become an example of this. TRAC moving to OTP on Polkadot could be another example?

If the DKG had its base on Polkadot its success could help catalyse the Polkadot ecosystem by attracting liquidity to it. Nobody is going to use Polkadot unless there is a good reason to use it. DKG could be one of those good reasons.

I understand people are concerned about layer 1s being decentralised. My view on that is if you want a valuable decentralized investment buy Bitcoin. You're not buying ETH or DOT or TRAC or OTP as money. The layer 1s should be sufficiently decentralized but ultimately I believe decentralization of POS chains at the level of Bitcoin is an impossibility.

What's good about Polkadot is the essentially permissioned nature of the chain via the auction system. The upfront cost to hire the parachain gets close to being skin in the game and should help to filter out trash projects. As it develops that should make it easier for the ecosystem to attract institutional liquidity 'because it's on Polkadot' i.e. not an open chain where there is no barrier to build an app.

[DalSlacker]

Yes, there are very good reasons that the future should be developed with reliance on as few bridges as possible

I think our timing is very fortunate in that we can learn from all these other bridging mistakes instead of being the mistake that other people learn from

[Valcyclovir]

I just went through the revamped RFC and I have to say I am very impressed with the amount of thoughts and details your team have given to writting this new version.

You guys have my most sincere gratitude for reworking all this and providing us with a better solution and I'm sure the community will feel much more at ease.

If there's only one comment that I could add on this RFC, I would like this RFC to emphasize that despite the lock period, there will be ways to trade teleported TRAC on the DOT ecosystem through partners such as Acala or through other means. Community members will be asking this question a lot and they need to know that they are still able to transact with the native TRAC token on OTP, rather than this process being a "forced hodl".

Other than that, congratulations team and #traceon !

[Istatkov]

Also might be worth discussing setting up some limit on the first wave, either as a whole, or per wallet (i.e. 10-50k per wallet) just to be on the safe side if things go wrong, the damage is controlled.

[branarakic]

Thanks everyone for the participation in the discussion!