Discussion for OT-RFC-13 TRAC Token deployment on Polkadot

[branarakic]

Hi everyone,

This is the place to discuss OT-RFC-13 TRAC Token deployment on Polkadot

Your feedback and ideas are much appreciated!

Trace on!

[FamousAmos-ChillZone]

Great RFC, I vouch for option 2!

[DalSlacker]

Approach 2 is the only reasonable option, however it is paramount that it not delay launch by an excessive amount of time. It is better to be patient and wait for a superior product.... but only up to a point.

[mucke12]

option 2 should be the way to go

[Valcyclovir]

Approach 2 seems like the obvious choice here. I hope this gets approved quickly so we get to work on the deployment of TRAC on OT Parachain quickly!

[botnumberseven]

You listed two options here, which suggests each of them are actually potential path forward (not just theoretically existing path). By your own assessment option #2 is superior to option #1 in all criteria. So from the RFC is not really clear what would be a scenario when option #1 could be a preferable choice.

[mucke12]

@botnumberseven with option 1 we could go live instantly but it would take even longer to get where we want to be. So we would be siloed with trac to OTP till EVM 2.0 support.

R5 — Effective time of deployment — grade: PARTIALLY SATISFIED — in order to reach the fully deployed state of TRAC on Polkadot, a significant time investment would be required to plan and execute the migration activities in detail, both by the core developers as well as by the OriginTrail community (estimated at several months). The partially satisfied grading of the requirements stems from the fact that it allows immediate deployment of the (non-Polkadot) version of TRAC tokens as no additional updates to the OriginTrail Parachain are needed.

[botnumberseven]

@mucke12 ok, but then what? I mean some level of deployment is not the end goal, right? I was trying to understand who/what actually wins with option #1, and so far I failed here.

The way i read RFC - we have two options: bad one and good one, team suggests to do with a good one. And if that's the case, why do we even list option #1.

[mucke12]

@botnumberseven lets say V6 would be ready next week, we could instantly deploy the trac and get the publishing’s going. With option 2 we would be on hold till this option is deployed

[Valcyclovir]

The one reason to choose #1 over #2 is to have TRAC available for v6 mainnet right away (while sacrificing many other aspects in the way) However, since we're talking about less than a month to get EVM2.0 fully implemented without dealing with the hurdle of migrating (again), the benefits far outweight the wait.

[DalSlacker]

@botnumberseven lets say V6 would be ready next week, we could instantly deploy the trac and get the publishing’s going. With option 2 we would be on hold till this option is deployed

Right, but V6 doesn't appear to be close to ready either Where are those RFCs? We still don't know how the V6 tokenomics (lambda in particular) will work. Likewise for OTP I suppose

[branarakic]

Thanks for the comments folks, your feedback is much appreciated.

As you've seen this RFC details the possible options, and luckily one of those looks superior to the others. The intention here is to enable inclusivity by allowing the entire community to participate in this important decision, as well as be informed on what choices are available, as it influences the entirety of the TRAC holder community.

With regards to v6 details, related RFCs are in the works (OT-RFC-14 is on TRAC tokenomics and is planned for publication next week).

[drMurlly]

We all agree with the #2 approach, and there is no more need to discuss option #1 in my opinion.

[DalSlacker]

Thanks for the comments folks, your feedback is much appreciated.

As you've seen this RFC details the possible options, and luckily one of those looks superior to the others. The intention here is to enable inclusivity by allowing the entire community to participate in this important decision, as well as be informed on what choices are available, as it influences the entirety of the TRAC holder community.

With regards to v6 details, related RFCs are in the works (OT-RFC-14 is on TRAC tokenomics and is planned for publication next week).

That's great Not sure I've ever looked forward to reading an RFC before, but I'm definitely looking forward to #14

[rainmelon]

Agree with #2, but am also curious about what this would mean for TRAC tokens that enter polkadot via other bridges.

Presumably as other TRAC tokens are bridged across using third-party bridges they would be ERC20 and not DOT-native, so how would they interact with the OT Parachain, or in liquidity pools on say Acala with DOT-native TRAC? I don't understand why the current bridging plan is time bounded - once the initial 100M tokens are bridged over using the Teleport will it be possible to generate further DOT-native TRAC without requiring the team's assistance?

I would love to see the teleport being available as a permanent one-way bridge for converting ERC20 TRAC to DOT-native TRAC so that other parachains don't need to grapple with how to handle two different tokens for liquidity, loans, etc. I believe this would also risk basically reducing the circulating supply to 100M since the 400M that remained as ERC20 wouldn't be supported where all the action is. If DOT-native TRAC is the only functional utility token, we could see a divergence in price as it would have way more demand than the comparatively less useful ERC20 TRAC.

[branarakic]

Hi @rainmelon thanks for the questions,

The Teleport mechanism is intended as a one-way bridge until the deployment of a fully fledged two-way Polkadot <-> Ethereum bridge is available (check out the graphic in OT-RFC-13 which involves the bridge migrator contract and the Polkadot bridge contract). Also the amount of 100M designated for teleporting doesn't prevent additional TRAC being transferable to Polkadot once the bridge is available.

On third-party bridges - the approaches presented do not preclude third-party bridges to utilize TRAC tokens as deployed in ways listed in OT-RFC-14. With the multichain nature of the DKG the TRAC token will be utilized in different blockchain ecosystems (as it has been so far with third party bridges), the OriginTrail Parachain being one of those, between which TRAC remains liquid and transferable as it has been so far.

Having that said, one of core Polkadot's power is interoperability. With integrations and XCM features on Polkadot we expect TRAC movement to be even easier between the Polkadot parachains than between Ethereum ecosystem chains. It's seems unlikely to have TRAC therefore deployed on other parachains as just a ERC20, as the teams doing this would be using TRAC in a way suboptimal to the "DOT-native" Polkadot implementation we're about to perform on OriginTrail Parachain, and would require additional work from their developers. Bridging "DOT-native" TRAC from the OT Parachain will be way easier and user-friendly, so I'd doubt anyone will go any other way.

[branarakic]

Thanks everyone for the great discussion and contributions. Given the clear support in favour of Approach 2, in the interest of time the core development team has already started the implementation in that direction as of yesterday. Therefore we will conclude the OT-RFC-13 discussion here.

Trace on!