We appreciate the well-thought-out proposal, and overall, we believe this will further safeguard the fidelity of Pyth data.
We have the following suggestions for the community to consider:
Removing the Z factor in the reward calculation: Removing the Z factor from the reward calculation could create stronger incentives for data publishers to compete amongst themselves. This could foster a more competitive environment, potentially leading to higher-quality data submissions.
Considering the time to unstake: The time to unstake is an important consideration. Since slashing events are managed by the DAO, the unstake period would need to be sufficiently long to allow the DAO to effectively manage the actual slashing operations. However, a prolonged lock-up period may necessitate a higher yield to compensate for the time value of money, which could become an overhead for the protocol in the long run.
The min function in the reward formula: We believe the inclusion of the min function in the reward formula is a positive step, as it can help avoid centralization to some extent by reducing the yield for over-delegation. This approach can incentivize a more distributed network of data publishers.
Identifying misprints: Misprints can be challenging to identify algorithmically, as the outlier can theoretically be the correct information while the majority is incorrect. In such cases, the process of slashing would need to go through a formal proposal, which can be an onerous and time-consuming task. To address this issue, it may be beneficial to explore a more efficient way to define and identify misprinting after the proposal process.
Overall, these suggestions aim to further enhance the competitiveness, operational efficiency, and decentralization of the Pyth data ecosystem. Itâs great to see the team engaging in such thought provoking proposals and discussion. We are excited to see this getting implemented and would encourage the community to consider the above factors!
The proposal offers an interesting mechanism to protect against losses due to data quality issues, which can increase usersâ confidence in the DeFi system. This is very interesting to attract more participants and ensure that the data is reliable and of high quality. The fact that the design of the mechanism is community-led is a positive point, I really like it, because it decentralizes and ensures that everyoneâs needs and concerns are considered. If I could make a suggestion, it would be to have some way of avoiding the concentration of power among a few editors.
Great and important proposal. Within any system, itâs crucial to have clear and sustainable incentives for good actors, as well as disincentivize malicious and irresponsible behavior.
I believe I can contribute to the discussion by sharing the experience of another web3 protocol that shares many common traits with Pyth: The Graph, thegraph[.]com.
Since Day 1 of The Graph Network, The Graph has implemented a mechanism that is quite similar to the one outlined in this proposal: data providers (called Indexers) must stake Graph Tokens ($GRT) in order to sell their data services through the network. These staked tokens can be slashed if Indexers perform their work maliciously.
In The Graph, delegated stake will not be slashable, because this encourages a trust relationship between Delegators and Indexers that could lead to winner-take-all mechanics and hurt decentralization.
The Graph also enforces a limit on how much delegated stake an Indexer can accept for every unit of their own stake. This âdelegation capâ ensures that Indexers always put some amount of their own funds at stake to participate in the network.
The Graph Network has been live since Dec 17, 2020, and there has not been any significant issue with this particular architecture that Iâm aware of. I believe it can be a valuable experience for us all to learn from.
Hereâs a blog post that goes in-depth into the mechanism, the math behind it, and the general design of the network: thegraph[.]com/blog/the-graph-network-in-depth-part-2/
love the idea in general, but i think it should be simpler for simple stakers. what i mean is, staking depending on delegation might be a little hard for the simple holder/staker. mybe this can be reward pyth users.
But for normal stakers, perhaps simpler unspecified to one entity, more general choice would be nicer, even if less rewarding.
As someone who holds PYTH tokens and is actively involved in the Pyth community, Iâm really excited about the proposed Community Integrity Pool (CIP).
I think itâs great that theyâre introducing staking in a way that not only rewards data publishers but also holds them accountable for the quality of the data they provide.
Iâm intrigued by the idea of delegating my tokens to different publishers. It seems like a smart way to spread out the risk while still earning rewards. It gives me more confidence knowing I can diversify my stake across multiple sources.
The mention of governance and having a say in network decisions through a DAO is also promising, which is important for the long-term health of any project.
Of course, there are some details Iâd like to understand better, like how rewards will be funded initially and how they plan to handle multiple claims effectively. Getting those things right will be key to making sure the CIP runs smoothly.
Overall, though, I think the CIP has the potential to make Pyth even stronger. Itâs exciting to see the community coming together to build something that benefits us all.
Thanks to CMS for this well thought out proposal and to the entire community in the discussion.
Douro Labs has been the biggest code contributor to the Pyth Network to date. We care deeply about making the system more robust and self-sustaining over the long term and making defi better and safer for everyone. This staking proposal sets Pyth up as the first fully secured oracle for users which is objectively better for the future of Defi.
We will develop the code for this component based on the details outlined
While we acknowledge that this proposal doesnât explicitly address the issue of accuracy, it is a step function in making the system better while being very easy to understand. We appreciate Ivoâs thoughtful comments on this topic and think these can be phased in over time.
We agree that the competitiveness of such staking program is dependant of the size of rewards available within the integrity pool. We invite the Pyth Data Association to consider sponsoring the program.
As we develop this component, we will continue to monitor this forum post for comments, and then will submit a PIP for DAO voting in a few months.
I think inherently this will work well for publishers and delegators. The only build I could have, is to maintain decentralisation and ensure that not only the largest data providers are gaining the majority of delegator votes a system could be produced to allow existing and new data publisher entrants or smaller publishers to offer âbribesâ to delegators with additional benefits and tokens. This will facilitate bootstrapping new data publishers, and also reward delegators to place strong consideration on which publishers they may want to delegate their Pyth to.
I fully subscribe the goals stated and the mathematical design proposed above by @CMS.
Though rare, previous data quality issues (like the BTC/USD incident in Sept 21, (pyth.network/blog/pyth-root-cause-analysis) could have been addressed with the existence of the community pool to cover some of the losses that a subset of data publishers may have been responsible for.
I am looking to seeing this project implemented, for the benefit of the Pyth Network and the many applications it powers.
First Iâd like to thank you all for this thoughtful conversation on bettering the Pyth Network and further empowering network participants: from data publishers to Pyth data users and, of course, Pyth DAO members
The Pyth Data Association (PDA) believes that the Community Integrity Pool is worthwhile to pursue, and if approved by the Pyth DAO by an on-chain vote, would be willing to further bootstrap its practical implementation
As the other Pyth DAO members are, we are now looking forward to the technical proposal and the related discussion for the launch of such program
Publisher Staking: It makes a lot of sense to us that publishers should be rewarded for good quality data and slashed for malicious / wrong submissions and behavior, similar to PoS networks. This creates the right economic incentives and we strongly agree with this.
Delegated Staking & Delegation Fee: It should definitely be the case that participants can delegate their PYTH stake to the publisher of their choice and for the publisher to take a cut of the staking rewards, as in every other PoS network. We suggest having the fee capped at 5-10% such that users donât get tricked by publishers who charge a small fee to start and then hike that fee to over 10% of the staking rewards. It happens in so many instances that fees go to 20% or more and users, mostly retail, are not aware as they do not regularly check for updates after delegating their tokens.
Publisherâs Stake: We believe that a data publisherâs own stake requirement should be kept at sensible number in USD terms, ideally on the lower side, to have low barriers to entry for new network participants.
Reward Cap: It is not clear to us that there should be a cap and it is also not clear how exactly it would work - we would like to understand more of this. Moreover, we donât think we should discourage price feeds with few publishers. If anything, new feeds should receive more incentives to bootstrap their organic growth and reliablility.
Slashing: There is a debate whether delegators should or should not be slashed for bad behavior conducted by the publishers they delegate to. We believe that publishers are well incentivized to submit good quality data in order not to get slashed. Perhaps making them 100% responsible and slashing just them would be too extreme. On the other hand, believers in the Pyth ecosystem should just be able to delegate their tokens and not be scared every day that they may get slashed for bad data feeds they cannot control. In order to increase the amount of participants in the ecosystem and make it more decentralized, we recommend perhaps capping the slashing % for the delegators to a low number and putting the remaining slashing pressure on the publishers. The more people that delegate to more publishers, the higher the chances of having more decentralized and reliable data feeds. For people to take the risks and delegate to less-established publishers, they should not risk massive slashing but equally they should have something to lose to prevent collusion between publishers and stakers.
Slashing 2: Perhaps a solution here would be a convex-looking slashing function for stakers. i.e. the bigger your stake, the more you can actually get slashed? This would cover institutional-like accounts who should be more thoughtful about their actions - i.e. the usual retail between 0-$100k doesnât get slashed, the $100k-1m staker gets slashed a low %, the $1m-5m staker gets slashed much more, the $5m+ has the same skin in the game as a publisher.
Data Layer potential: It was mentioned that this proposal opens the way for Pyth to become a âData Layerâ, which is something that indeed sounds very exciting and from a product / outreach perspective can be very beneficial: investors have a more clear understanding of the value proposition and accrual of the token, whilst potential partners better understand the ârebrandâ to a âData Layerâ.
Conclusion: The most important aspect of this proposal is that it aligns the economic incentives of both token holders (who can now delegate their Pyth and earn rewards) as well as data publishers (who would be even more incentivized to submit high quality data in order to build a delegated stake that they can earn extra income on). Moreover, the improved, sophisticated tokenomics would incentivize long-term economic behavior across market cycles and further decentralize the network.
Big things are on their ways. Is someone keeping track? This is Pyth history in the making. Canât wait to see the fruition of CIP, a much-needed (in my opinion) mechanism for the network and a very interesting potential source of yield for stakers
Exciting to see so much constructive feedback. Though Iâd share my thoughts on these ideas as a contributor:
Delegation fee cap: While this design doesnât make a statement about what the delegator fee should be, I do agree itâd be healthy to impose a cap.
Reward Cap: I think the per publisher reward cap here is the way the design splits the pie between publishers. It also prevents too much concentration of delegated stake in one publisher.
Less crowded symbols: thereâs definitely an incentive to publish less crowded symbols, with the number of publishers per symbol in the denominator in the summands for the publisher cap. However the Z parameters counterbalances this so that less published symbols are not orders of magnitude more rewarded than full symbols (without Z you make x32 more rewards being the first publisher to a feed than being a publisher in a feed with 32 symbols).
Slashing: Delegators being less exposed to slashing might make sense since they have less priority for rewards. Since the proposal doesnât describe the slashing mechanisms precisely, further designs will be required to concretize this.
Slashing2: I donât seem to agree though with the convex-looking function since delegators can easily split up their stake into many accounts (Sybil style).
Reward Cap: We imagine it would be hard to get to a monopoly/duopoly given the healthy and strong competition between publishers.
Less crowded symbols : This makes a lot of sense to us - may we ask what is the latest link to the Maths / Z symbol definition?
Slashing2: We have thought indeed that this may be arbitraged via a Sybil style account split. More thought needs to be put here such that the potential slashing on genuine retail accounts is as little as possible.
For what itâs worth, re: the maths for parameters like the Z symbol, M symbols, and others outlined by CMS above, I imagine some of these would (or should) be up to the Pyth DAO
Thank you to all the Pyth contributors, publishers, and community members for your ideas, healthy debate and discussion, and efforts towards pushing the Pyth Network forward.
I personally am excited for the future of Pyth, our shared oracle network, and what it can do to elevate everything we do in DeFi, as a user, a builder, a supporter
OIS and Pyth Governance (PG) are two separate programs that can be accessed from the Pyth Staking Dashboard. The ways to get involved in the Pyth Network have expanded!
This is huge! Pyth has single handedly showcased the power of community and governance through the release of OIS. The community came together voiced their thoughts and ideas to encourage the Pyth team to build something tangible and real.
Unlike many protocols that mention governance and donât really utilize it, Pyth once again shows how they plan on paving a new path forward in this ecosystem. OIS was created through decentralized governance and thatâs a WIN for crypto.
Love to see Pyth crushing it and everyone involved should be proud
OIS is the cornerstone of an ACTUALLY decentralized oracle system. Excited to see this both hold data providers accountable and reward them, as well as reward community members doing their part to protect DeFi!
