Addressing the risk of inaccurate Pyth data to increase the security of DeFi


  • The need for additional economic levers to protect DeFi against oracle integrity issues and better share common risks
  • Oracle integrity is paramount to the health of DeFi
  • Current consensus-based integrity can fail in extreme scenarios. DeFi protocols and their users should be assisted in such extreme events


  • Align incentives of data producers with consumers who are paying for the data consumed (despite the current close-to-zero pricing)
  • Increase security of Pyth’s price feeds through an additional layer of economic security that tackles the risk of using Pyth’s service

Proposed Solution:

  • the implementation of a staking mechanism for data publishers to protect users from the risks impacting data integrity
  • prioritize the protection against the inaccuracy of the price data produced
  • data producers should be awarded, proportionately to their stake, for continuous production of valuable and accurate data, yet they also need to be exposed to slashing risks, proportionately to their stake, in order to enhance the cryptoeconomic security of the service
  • only applications that can show on-chain proof for payments for Pyth’s data service should be eligible for any loss protection


  • If the Pyth price deviates from a reasonable level that is representative of the market conditions for liquidity and recent executions, resulting in unwarranted liquidations, the publishers for such price aggregate should be investigated by the DAO and slashing should be actioned in case evidence is deemed compelling from the community
  • Such applicable events need clear definition and means to observe and measure
  • Everyone staking should share in the economics of the pool
  • Slashing can be socialized between publishers of the impacted feed(s)
  • the amount of slashing should be calibrated for the amounts that DeFi protocols have been impacted for and the number of such protocols
  • All amounts should be calculated in $PYTH

Questions and Uncertainties:

  • Amounts of rewards and penalties, and criteria for loss protection are uncertain and require further design
  • Addressing the risk of inaccurate data should involve stakeholders outside of data publishers. it is unclear if and how $PYTH holders could participate in staking

Would be great to have a way where the broader Pyth community can be part of this proposal.


This is an interesting proposal. Let’s see what the Pyth core team think.


Highly reminiscent of some of the ideas discussed early throughout the community and even in the first whitepaper.

I quite like the direction of this idea. Has anyone out there thought a bit on the economic math for such a stake/slash mechanism?


Economic math map out would be super interesting, I’m following the updates.


The proposed staking mechanism for data publishers is an intriguing solution to protect against oracle integrity issues. It’s clear that aligning incentives and ensuring accurate data is crucial for DeFi’s health.

The example of investigating price deviations and the potential for slashing adds a layer of accountability that could significantly bolster the system’s integrity. However, the uncertainties around rewards, penalties, and loss protection criteria need to be addressed.

It’s also worth considering how $PYTH holders could be involved in this process to further strengthen the system.

Looking forward to more insights on this.


Fun fact: there is already tooling available for tracking the timeliness, accuracy (calibration and predictiveness of the aggregate price series), and uptime of data providers

Shoutout to those who remember this classic blog post celebrating the launch of the Publisher Metrics.

You can find these metrics for any data provider by clicking on any of the price components for a feed in Price Feed Oracles for DeFi Apps | Pyth Network

I bring this up as a reminder that there’s plenty of measurements by which one can hold the data providers accountable and assign e.g. rewards and penalties


Just out of curiosity, is this a problem at the moment?
I’ve not heard anything about delays or incorrect data.

1 Like

There isn’t! However it would be cool to have proof of stake model for Pyth, where anybody can stake / delegate and earn rewards for providing security.


This is a really interesting proposal that:

  • Rewards data producers for data integrity while punishing bad behaviour
  • Improves the likelihood of higher quality/accurate data for consumers
  • Adds additional security for Pyth as an Oracle
  • Allows DAO community/retail participation + oversight into how data producers are performing in comparison to each other (informed DAO = very good)

Accurate data from Oracles like Pyth work as the backbone of our Web3 Defi ecosystem! This proposal among all the things mentioned above fosters a more safe and secure DEFI for everyone. We should punish bad actors and reward parties that take ownership + responsibility over the quality of their data. There’s Billions of $$ in TVL being secured here, if we want Web2 to take Defi seriously we need to minimize the risk of large unwarranted liquidations.

For uncertainties on the amount of rewards and penalties I think we should start small in order to get max participation. For criteria I think we should look at PYTH’s internal metrics on evaluating Data providers if they have one. For involving $PYTH holders I think any of the DAO related aspects of this proposal covers their participation but I’m sure we can think of some more unique ways to tap them into this.

Overall, I think this proposal is being overlooked as the topic its discussing is right at the core of Pyth’s main offering, which is accurate and secure data for all of DEFI. I hope the team and community goes forward with this proposal, happy to discuss below if you guys have comments.


Based take here - def. need more detailed thought out comments & direction like this to ensure Pythia thrives !!

1 Like

Thanks Ape! Excited to see all the interesting discussing taking place in this forum, this one stands out for me cause its directly improving Pyth’s core offering!

Yes, exactly! Old school whitepaper ideas

I’m quoting here, but the ideas were along the lines of:

“Delegators stake tokens and earn data fees in exchange for potentially losing their stake if the oracle is inaccurate.”

" Data staking allows delegators to stake tokens to earn data fees. The delegators in aggregate also determine the level of influence that each publisher has on the aggregate price. In addition, this mechanism determines whether delegators’ stakes are slashed."

“Finally, the mechanism collects data fees from consumers and distributes a share to delegators. The remainder goes into a reward pool that is distributed to publishers.”

The context for the final passage about the data fees from consumers was in reference to a different idea than the (currently implemented) cross-chain fees generated by the Pyth pull oracle.

Nevertheless, there’s maybe a world where the data fees generated by Pyth (see the opBNB fees discussion) could go into such a “delegator mechanism” that makes the Pyth Price Feeds more robust.

The weightings of data providers for each price feed, for example, is one of those topics that’s long overdue, IMO


What I like here is the fact that this is a long term sustainable model which provides security for the network and allows anyone to participate in the incentive models.

Some other discussions taking place in the forum are extremely short term and naiive.


There have been many situations in the past (mostly Chainlink) where incorrect data or delayed data has caused unwarranted liquidations. This proposal is being proactive in helping secure the data and improve accuracy, even than it doesn’t 100% stop issues but creates a framework that works to minimize it!

This is a super important topic. If you consider that this problem (inaccurate data) has factually happened in other oracles (hence @RealPythGod comment).

More than that, yesterday I was at the Pyth event here in Brazil in discussions with Brazilian players that have tokenized almost 1 billion Brazilian reais (~$200M USD) - these are non-treasury bills RWAs, check this out to learn more about what is happening in the Brazilian economy: google for “Drex for gringos” (can’t post links here).

So imagine Pyth being used by TradFi players and relaying an inaccurate data… This would be a big problem in the trustfulness of that oracle in the eyes of that traditional institution. I’m extrapolating here to bring you some real case where an economy and moving towards a tokenized economy.

DeFi is the backbone of Web3 and both of its ethos are around aligned incentives!


This is a super important proposal, since the future of DeFi is extremely dependent on fast and accurate oracles that pull information rather than push it.

Following the pythians’ ideas here


Yeah I’m surprised its not getting as much attention! This impacts Pyth core offering making it probably one of the most important proposals


I think this thread needs more details, right now we have had a request or an idea but nobody has any further tangible details. In my opinion thats why engagement is low


Welcome long time listener first time caller please take some thoughts on the below for a proposal to introduce a staking reward and the mechanics surrounding it.

For some reason this forum refuses to give me permissions to make forum posts to putting this here for the conversayion.

Community Proposal for the Design of the Community Integrity Pool (CIP)

Context & Positioning

The initial suggestion from OracleMaxi sparked excitement in the community about the benefits DeFi can gain from a staking mechanism that offers loss protection against data quality issues. As a long-time data publisher, we believe that data publishers should be rewarded for their contributions and share in the risk of slashing for data issues.
The design for such a mechanism should be community-led, empowering both publishers and consumers to impact the final design.


After discussions with community members, my proposal for the CIP includes:

  • Publisher Staking: Each publisher must stake for each symbol they publish, making them eligible for rewards and subject to slashing.
  • Delegated Staking: Non-publishing $PYTH stakers can delegate their stake to one or many publishers.
  • Reward Cap: A cap on publisher rewards based on the number of symbols contributed, discouraging price feeds with few publishers.
  • Delegation Fee: Publishers can set a delegation fee, applied pro-rata to the reward amount attributed to the delegated stake.

Pool Design

Pyth stakers can delegate their unlocked, staked tokens to publishers, with each token being delegated to a single publisher. The total publisher stake is the sum of the stake from all delegators plus the publisher’s self-delegated stake. Staking to a publisher makes delegators (including the publisher themselves) eligible for rewards and subject to slashing.


A publisher’s “stake cap” (as a soft cap) is calculated to avoid symbols with very few publishers increasing the cap too much. The total staking rewards of a publisher are given by a formula that considers the publisher stake yield rate, the total publisher stake, and the publisher’s stake cap.
Reward Split: Publishers get priority over the rewards. The reward split considers the self-delegated publisher stake and the delegation fee, which can be set by the publisher or determined by the DAO.

Incentive Properties

Publishers: Publishers benefit by increasing their symbols and attracting more delegators, thereby increasing their delegation fees.
Delegators: Delegators will delegate to publishers such that their stake reaches the publisher’s cap, ensuring that the rewards are efficiently spent, aligning with the market rate.

Total Rewards

Total rewards are bounded by the number of symbols and the target stake per symbol. Adding new symbols requires either an increase in total rewards or a decrease in individual rewards.


The total slashable amount for a publisher is capped per slashable event, with conditions for slashing determined by the DAO. Misprints leading to slashing allow affected parties to file claims with the DAO. If claims exceed the total slashable amount, it is distributed proportionally.

Questions and Uncertainties

  • Bootstrap Contributions: It is unclear which parties would contribute to the pool to pay off rewards.
  • Delegation Fee: Fixing the delegation fee for all publishers could reduce launch complexities.
  • Multiple Claims: Further design work is needed to handle multiple claims within a single epoch.