Discussion for OT-RFC-18 RFC

[NZT48]

Hi Tracers,

I am delighted to announce our latest RFC on Growing the Trusted Knowledge Foundation: TRAC delegation & OTP incentives.

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!

[BLITOW]

Hi,

I think it's great that OTP is used for incentivisation of DKG growth and it's a good bootstrapping method. This is of course not sustainable long term. I was wondering if there are ideas to promote the growth of public knowledge long term?

Has the team thought about putting a tax on private knowledge? This tax would go to a DAO that has the function to increase the total amount public knowledge on the DKG? This way mostly private for profit companies pay for a public good, instead of OTP holders paying for it by dilution. The cost for using the DKG for private data is also a lot cheaper, because most data is hosted privately(I could be mistaken here). This way more trac flows to DKG nodes and OTP gains more value because the DAO is hosted on the origintrail parachain. The DAO could be controlled by trac and/or OTP holders.

Just some ideas, trace on!

[Valcyclovir]

Great RFC about OTP incentivization and TRAC delegation, 2 long awaited hot topics.

I wholeheartedly agree with the two-pronged approach to incentivize trusted knowledge creation and supporting the DKG infrastructure.

OTP should seamlessly blend in with the flow of the TRAC token and be seen as an added bonus to promoting network growth and this RFC correctly reflects this vision. In other words, OTP is being rewarded for both KA creation and for node runners / delegators.

The RFC lacks a bit of details on how much OTP would be rewarded per asset created. In my opinion, OTP should only be rewarded for the growth of public knowledge. The OTP incentive should also be proportional to the asset size, epoch number and bid price. In other words, the higher the publishing cost, the more OTP rewarded for publishing. This should promote the publishing of quality and long term assets on the DKG, while also counter balancing bid/ask market forces, creating a fair pricing environment for both asset publisher and node runners.

As for incentivizing trusted infrastructure, I am fully in agreement with the RFC on how to handle TRAC delegation and how to incentivize delegation through OTP. However, I am in disagreement that OTP should be used to incentivize growth of the DKG V6 on other blockchains than OT Parachain. OTP is tailored to OT Parachain and its primary goal is to incentivize growth of the DKG on OT Parachain, not other chains. If incentivization is required to grow the DKG V6 on other chains, TRAC token should be used instead of OTP just like during SFC staking, and distributed in intervals to prevent users from getting the reward and moving out of the chain right away. OTP token should remain specific to OT Parachain and all activities growing the DKG V6 on our parachain, which includes supporting TRAC DeFi on Moonbeam (bridgeTRAC - xcTRAC pool).

Regarding the delegate vs delegate and lock function, I believe it should be a scale rather than choosing one of the two options. Users who choose to delegate and withdraw their TRAC within 1 month will receive no OTP incentives. Users who choose to delegate their TRAC and withdraw within 1-6 months will receive a small percentage of OTP, and so on up to a maximum of OTP incentives for long term delegators. It would also be great if this incentive is retroactive to reward those who ran nodes early to support the infrastructure. For example, node runner X who ran a V6 node for 8 months should have the lock period starting at 8 months completed.

I hope my input would help drive more discussion points towards this very crucial RFC.

Cheers!

[hottogo]

My comments cover two main topics, OTP Incentives and Delegation, then some Suggestions.

OTP Incentives:

• To me it seems ineffective to offer OTP incentives to delegators

o There is no benefit to the network in having more and more delegation, whereas more knowledge creation and more node infrastructure are worth incentivizing. o I assume then the only reason for this is to promote delegation to new blockchain integrations that would otherwise struggle to have the minimum 5m Trac required to enable enough nodes on that blockchain layer. o This incentive to delegate assumes there will be a lack of returns in Trac available on other blockchains and some other incentive is required. o OTP incentives may not be enough to attract a node operator to another chain, so the new network would be reliant on a goodwill node from the network developer or team.

• I agree with the above RFC comment that it would be strange to offer OTP to promote other blockchains.

o Although as above I see it as the only reason you would offer OTP to delegators. o OTP Blockchain would not benefit but the DKG ecosystem would. o This goes against the planned feedback loop of OTP being paid to promote use of the DKG which would promote fees of OTP being paid. o OTP does not need to be an investment vehicle, so perhaps this doesn’t matter. o OTP token just needs to retain a minimum value to ensure collators are still happy to run the OTP network. o Upon reflection I support this, as our goal doesn't need to be to support OTP value

• I strongly recommend that there is retrospective incentive for those who were early to conduct knowledge creation and to run trusted infrastructure (i.e. nodes)

o Those early knowledge creators paid a premium to have their knowledge hosted on the DKG, they deserve incentive more than those who follow. o Early knowledge creators also were pioneers in using an unknown technology, whereas those who follow have already seen the obvious value. o The same with nodes, early v6 node operators have been running nodes on the DKG sometimes at a loss, waiting while volume grows, they deserve the incentive more than those who follow when activity has picked up.

Delegation:

• In my opinion it is too early for delegation to go live

o Node operators are running the services at a marginal profit or a loss right now. o Why would they share the minimal to no returns with delegators? o I understand the network is growing extremely quickly so this will change over time. o The only benefit I can see is if delegators help to fund nodes on new networks that do not yet have much activity, so no other return. o However, someone still has to run the node on these new networks.

• The lack of returns due to sharing minimal Trac rewards with delegators could force node operators to shut down their nodes.

o This would lead to more centralization of the network. o Delegation in this early stage of the network will lead to a severe lack of profitability and purpose of running a node.

• The operator_fee is a good idea in theory, with nodes able to set how much they need to retain to cover server fees and their own time.

o The issue is that competition and goodwill nodes will push this % down. o As the RFC explained, nodes with larger amounts of Trac staked earn more publishing fees. o To attract delegators, nodes will need to have a low operator_fee % to share more rewards to delegators. o This will limit the viability of running a node, with delegators taking a large portion of earnings but node operators having 100% of the server costs and labor. o This will obviously be a fluid environment with increasing network activity and changing number of nodes and amount of delegation. o Theoretically the market will dictate the outcome and it will be fair to all, but this assumes there are no team “goodwill nodes” that are not incentivized by node profit. o Team nodes may be happy to generously share the earnings of their nodes with delegators, putting significant pressure on profit motivated nodes to match the low operator_fee %

• This could lead to the number of nodes decreasing under delegation.

o As above, sharing earnings with delegators may lead to a lack of viability in running a node. o Node operators may not be able to make enough of a return at the optimum operator_fee to compete. o They may then choose to shut down the node and just become a delegator, which has some return with no server costs and time/effort. o This could lead to less nodes on the network and less decentralization.

Suggestions:

• Only knowledge creators and node operators need to be incentivized further to promote a robust network on OTP Parachain

• To ensure enough nodes on new networks are available, only delegation to new networks should be incentivized while activity is low (although as above this will be at the detriment to OTP value but I think that is ok).

• Those who operate nodes on new networks should be strongly incentivized, as they are incurring the server costs and significant time and effort for potentially little other reward if activity has not yet grown on the new network

• Any Team “Goodwill Nodes” should set their operator_fee % share to 100% so they do not unfairly influence the market mechanism of profit incentivized nodes trying to attract delegation.

o This will allow the market to dictate the % to share to delegators, especially important while activity is still growing

• Retrospective incentive for those who were early to conduct knowledge creation (i.e. DC's) and to run trusted infrastructure (i.e. nodes)