Thank you all for your additional points. Based on feedback from the community, there seems to be consensus on version 0.6 to be a good compromise with only minor points raised (that will be addressed below) and a general sentiment expressed on moving forward with the DAO voting proposal. For this reason, we expect the DAO voting proposal on version 0.6 of the compensation plan to go live later today.
On the “first come, first served” alternative sniping option proposed (cc: @bavibull ). This could be an option, but we see both PROs and CONs in implementing such a method as opposed to the previously proposed one. For example, the current option creates a rush for pBTC-on-BSC holders who are interested in joining and encourages them to subscribe as soon as possible, while this alternative option would not address this point (hence encouraging a behaviour where people wait until the very last minute to join, that is not ideal). For this reason, we will maintain the current proposal unchanged (in the interest of moving forward), stated that this is an implementation detail and not a major point, so this could still be changed if there is a strong request for using the alternative option instead (this would need to be expressed before the implementation starts).
On automatically merging 10 NFTs into a 10xNFT (compatible with running a light node) (cc: @lapisdei ). While I understand your point, inserting such an automation directly within the NFT smart contract would create extra complexity both from a technical perspective and from a user perspective since this would effectively create two kinds of NFTs (for example, this would create confusion should someone be willing to resell the NFTs). As this is a bit controversial, it would be useful to see additional opinions from the community (again, this is an implementation detail).
In any case, specific rules can be implemented (outside of the NFT smart contract) that would obtain a similar result into simplifying the creation of light nodes via the NFTs. If the goal is simplifying the experience for perspective node operators, I would go with this option.
On pNetwork governance via BSC (cc: @lapisdei ). Voting for PNT-on-BSC holders will be enabled starting today, while DAO staking requires more technical work.
On the USD-countervalue included in each tranche of Step 2 (cc: @lapisdei @marcodalponte ). The USD-countervalue is calculated based on the algorithm defined as $ 5,400,000 / pBTC in circulation. As correctly explained in @marcodalponte’s reply, the actual amount per tranche may be lower or higher based on the number of pBTC-on-BSC tokens that are removed from circulation via Step 1. The amount presented in the compensation plan ( $ 1,950 ) represents the worst case scenario (277 pBTC in circulation).
As the phrasing in version 0.6 refers to “at least $ 1,950” I don’t see a need for changes in the compensation plan proposal.
On the point of “unilaterally redefine the pBTC token” (cc: @jay ). All steps included in the compensation plan proposal (Step 0 + Step 1 + Step 2) do require pBTC-on-BSC holders to take action for accessing the USD-countervalue distributed as part of the compensation plan. Specifically, they are required to claim the USD-countervalue and when doing so they accept the terms of the compensation plan. There is no obligation for pBTC-on-BSC holders to participate in the compensation plan.
As the compensation plan is a compromise that takes into consideration the various parties involved and has been openly discussed with the community, our hope is that the majority of pBTC-on-BSC holders will consider this acceptable.
Your proposal to create a different token to be used for the compensation plan is an option that we have discussed internally as a core team, but it presented various complexities in terms of technical implementation. Since there didn’t seem to be strong support by the community for that specific implementation, we decided to propose the current option that seemed to achieve a similar result while having a simpler configuration.
Finally, the compensation plan proposal has been discussed both with lawyers and exchanges. As for the former, the opinions received doesn’t seem to highlight the warnings that you give for granted. As for the latter, the feedback received up to this point is positive.
On defining the compensation plan in terms of BTC (cc: @jay ). The reason why this is not a feasible solution has been discussed at length and repeated during the community call.
On disabling the trading of pBTC (cc: @jay ). Regardless of their level of decentralization, emergency shutdowns are a very common practice for projects as a protection mechanism against balck swan events. Specifically in cases where lose-lose situations may occur, triggering emergency shutdowns is considered acceptable even in decentralized ecosystems.
On decentralized governance, censorship and pBTC-on-BSC holders representation within the compensation plan (cc: @jay ). pNetwork follows a progressive decentralization roadmap - there are various levels of decentralization within the ecosystem depending on the specific components. For more details, information is available on the blog as deep-dives and on the website.
Defining the current compensation plan proposal was such a long process exactly because every party involved was given the possibility to contribute to it. In fact, the current version of the proposal was vastly community driven. That said, we understand that it’s not possible to obtain a situation where 100% of the parties agree. If someone decided to sell their pBTC-on-BSC that was their decision to exchange this risk profile with someone that, on the other hand, decided to buy the tokens.
Step 0 of the compensation plan has as a goal involving pBTC-on-BSC holders in the decision-making process of the compensation plan. Should, as it was suggested by @jay, the majority of pBTC-on-BSC be against the current compensation plan they will vote against (as PNTs were distributed proportionally to holdings). The voting proposal on the compensation plan that will be opened on BSC has indeed the scope of determining whether there is support for it or not.