Oracles and LTIPP

General
1

I believe that supporting Pyth over other oracles that are live on Arbitrum, particularly with such a large grant (which I’m not sure how they will actually use, given users pay for the oracle updates), needs to be considered at a wider level across the DAO.

The LTIPP outlined incentives for DeFi protocols to attract liquidity and thus I do not see how 1m ARB to Pyth aligns to the purpose of LTIPP. Maybe I missed something around how the funds will be used and would welcome any further understanding here.

Moreso, from the commentary of the council members any technical aspects of oracles in their decision making are lacking. Most recently we saw stale oracle prices created due to congestion/block issues on solana (as per Chaos Labs tweet). There should be consideration of these technical factors and risks involved if the DAO is to support further adoption of the oracle. Perhaps there should be a separate DAO initiative for supporting oracles that is more equitable and considers the nuances of oracles as a crucial component of DeFi.

I also do not think that this means Pyth should not be supported in this instance, more so keen to start a conversation around a fairer playing field for oracles within the DAO.

2 Likes
2

The approval of the Pyth grant for 1,000,000 ARB vs the rejection of the Chronicle grant for 150,000 ARB is a good example of this and does not represent value for the DAO.

Figures based on: [Pyth Network] LTIPP Application Draft

On Arbitrum
Pyth per update = $0.80
Chronicle per update = $0.007 (Arbitrum Transaction Hash (Txhash) Details | Arbiscan)

Based on the grant request of 1,000,000 ARB ($1,400,000 at current value).
Daily update cost of $20,000 ($0.80 * 25,000) for Pyth
Daily update cost of $175 ($0.007 * 25,000) for Chronicle
And a stable gas value.

Pyth Oracles would remain free to Arbitrum users for: 70 days
($1,400,000/20000=70)

With Chronicle, Oracles would remain free to Arbitrum users for: 21 Years
($1,400,000/175=8000=21.918 Years)

Chronicle Protocol is the second largest Oracle network by TVS (https://defillama.com/oracles). And the first ever Oracle on Ethereum, deployed in 2017 as part of the creation of SAI (single collateral DAI). There is no question of the network or the team’s capability.

Feedback suggested that Oracle diversity is good, and we can agree on that. However, Chronicle was rejected because it only recently spun out of MakerDAO and started its L2 deployment strategy, and therefore didn’t have the metrics on Arbitrum demonstrating adoption.

@Matt_StableLab @stonecoldpat

1 Like
3

Ya pyth metrics didnt seem correct when I reviewed, I do think this warrants a wider discussion around ecosystem public goods, I see oracles as a public good. I also think there should be a wider grant for Oracle Services similar to the Procurement RFP so that we could ask Pyth, Redstone, Chainlink (already a public good on arbitrum), Chronicle, Block Scholes, etc etc to provide their oracles to developers at no cost, and developers are free to use whom they like. I will pencil this in as another initiative the OpCo could support.

2 Likes
4

Hey @Ken_x3

Thanks a lot for the interest and topic raised

One thing to note for this LTIPP is that it is only available to projects that have not received an ARB grant in the past. The Pyth Network fits this criterion.

Regarding the ‘how the funds will be used’: reimburse the costs incurred by applications to update Pyth Price Feeds.

As a reminder, the Pyth oracle works as an on-demand oracle, so that applications can permissionlessly request and update the price of an asset to then use it (fulfil a perp trade, borrow on money-market or perform a liquidation). When apps do so, they have to do a transaction on Arbitrum sending the prices in the Pyth oracle smart contract (and bear the cost of that). Some apps actually defer this action/cost to their end users.

With this LTIPP and ARB, the goal is to refund the costs incurred when doing price updates as those end up being either directly or indirectly charged back to the users (actual tx cost or higher trading fees/slippage charged to subsidize this cost).

In regards to Chaos’ point, this refers to Pyth V1 which works as a push model on Solana. Arbitrum is not impacted. V1 was launched in 2021. Since 2022, all chains (but Solana) use Pyth V2 which follows the on-demand model. The issue put forward here refers to Pyth V1, which is being sunset this quarter.

To @Bbthread’s point, there are actually two types of transactions that can update Pyth prices onchain:

  • regular transaction which sole purpose is to update the Pyth prices onchain
  • complex transaction that not only updates the prices but also use them atomically for a perpetual trade for instance. Bundling the trade with the price update allows applications to implement commit-and-reveal schemes that eliminates the risk of front-running

The cost outlined (80c) is for the latter, the former has a cost below 5c.

1 Like
5

Indeed, Oracle diversity is important for DeFi ecosystem stability and resilience, but also to drive a “free market” or healthy competition, incentivising the highest levels of support for Arbitrum’s builders.

An Oracle Services grant is an interesting idea. This is something that a number of other blockchain foundations/DAOs already do, but they make bilateral agreements directly with the Oracle protocols rather than creating a standalone grants program. The end result is the same, Oracles free at the point of use for “supported” builders on the chain.

Regardless of how it is packaged, the original point still holds considerable weight. Oracle protocols like Chainlink charge millions of dollars a year to support L2s, Pyth’s expensive infra design also warrants millions of dollars of year to cover gas fees. The gas usage of an Oracle protocol, and therefore the size of “gas grant” it requires, should be a key point of consideration for the Grant award methodology. (this metric is also verifiable as it is recorded on chain).

6

Thanks for sharing further detail, @KemarTiti.

Regarding the two types of transaction:

  1. “regular transaction which sole purpose is to update the Pyth prices onchain”

I assume this would update all of Pyth’s supported price feeds on Arbitrum? i.e. Over 400 price feeds. If that’s the case it’s very inefficient and wasteful. The vast majority of those price feeds are not utilized by end users.

To then base the grant on these figures, and at 25k updates per day, is again incredibly wasteful and misleading. The equivalent fee-generating DeFi market on arbitrum to service the cost of this infra is not there. Pyth is simply proposing to bring real-time data on the chain for the sake of it - not in response to demand that would warrant this level of spend by the DAO.

There’s also the proposed 25k updates per day. This too is overkill. Perhaps only Perps Exchanges would make use of this many price updates per day, and this represents a tiny portion of DeFi TVL.

  1. " complex transaction that not only updates the prices but also use them atomically for a perpetual trade for instance. Bundling the trade with the price update allows applications to implement commit-and-reveal schemes that eliminates the risk of front-running"

On this second type of transaction, which is more comparable to a single Chronicle Oracle price update, the gas cost is still considerably higher.

Your claim is a cost below $0.05 (a verifiable link to the blockexplorer would be appreciated).

However, even at that figure, Chronicle (at $0.007 Arbitrum Transaction Hash (Txhash) Details | Arbiscan) per update is over 7x or 86% cheaper.

7

I assume this would update all of Pyth’s supported price feeds on Arbitrum?

No, the requester of the price updates has to specify which price feeds he/she wants updated. In a single tx, a user can update up to 50 feeds, while the cost is not linear — i.e. updating 30 feed in a single tx does not make the tx 30x more costly

In other words, if you are a money market on Arbitrum that supports 10/15 assets, with a single tx you would be able to update all assets at the same time (for almost the cost of just updating a single price feed).

Taking recent examples as reference:

This tx updates 5 feeds and cost $0.03, this one updated 8 feeds for pretty much the same cost (0.03$) while this one updating only 1 cost about $0.05. Of course each tx occurred at a slightly different times and so the L1 and L2 gas might have been different but overall whether you update 1 or 10 feeds, costs is very similar.

The vast majority of those price feeds are not utilized by end users.

This is an additional reason for pull oracles. Given that it is the end users triggering oracle updates, applications don’t need to update prices (and incurring costs) if it is not valuable to the end-user.

Pyth is simply proposing to bring real-time data on the chain for the sake of it

Being a pull oracle, the Pyth network doesn’t send price update onchain proactively and this isn’t the goal because as mentioned above, pushing price updates for the sake of it so while not being used makes no sense. Our goal here is to subsidize the actual usage (when there’s a price update requested)

There’s also the proposed 25k updates per day.

This is in no way what the Pyth oracle commits to push onchain but rather an estimation of the number of price updates requested by protocols powered by Pyth.

So if in practice, downstream applications request only 5 or 10K price updates / day, the cost (or usage of the ARB grant) estimation would 5 or 2x cheaper.

8

I see, thanks for clarifying how the batch updating works for Pyth.

Regarding

with a single tx you would be able to update all assets at the same time (for almost the cost of just updating a single price feed).

I assume you are referring to the cost of updating a single price feed on Pyth? Because as we have established, Chronicle’s gas usage and cost is far, far lower.

Regarding, Pyth is simply proposing to bring real-time data on the chain for the sake of it

If you are simply operating a Pull model and having the end user pay the cost of updating the Oracle every time they interact with the application, then yes, I can see how this wouldn’t resemble “bringing real-time data on the chain for the sake of it.” The quoted 25k daily updates suggested this was the plan in the proposal.

The pull model is well-matched for high-frequency price updates. On that, there is no question. There is always the question of data availability, however, or the lack of any guarantee that data will be available on chain when you need it, with a pull model. This is one of the reasons why the vast majority of DeFi still prefer to use “pushed” data

Where the DAO can get access to cheaper, more secure, and more decentralized Oracles - ensuring resilience and security for its users as well as a longer runway for free Oracles, it seems like a clear victory for the Arbitrum ecosystem.

As with @Ken_x3, I am not suggesting Pyth shouldn’t have received a grant. The high frequency, low latency Pull model is a useful option to have, particularly for on-chain perps.

However, due to the huge gas (cost) savings that Chronicle can bring plus the added resilience for the Arbitrum ecosystem, where Pyth has at least one single point of failure with the Wormhole bridge, such as when data went stale for 25 minute period here, and perhaps another with Pythnet. It’s certainly worth questioning why Arbitrum DAO isn’t also supporting the deployment of Chronicle.

9

I think the above conversation expands on a few areas that could be considered more if there was a support program dedicated to oracles. Things like a) architecture differences b) points of trust c) cost of operation d) security implications (and so much more) should be considered at a deeper level. I’d be really keen to hear the thoughts of delegates on this post.

10

What is the OpCo you speak of sir?