Solana Riptide Hackathon —  Pyth Ideas

With the ongoing Solana Riptide Hackathon (2nd February — 17th March 2022), Pyth network’s contributors wanted to release some ideas we believe are worth considering. It is of course not a comprehensive list, and taking an idea below to production or submitting a completely original one will not be valued differently for the Pyth prize of $30K.

The ideas listed are essentially of two types:

1. Additional Pyth features or new developments
2. Protocol/Program idea that leverages Pyth product

Pyth Features

# Pyth client in Golang

Currently, Pyth offers a client library for most programming languages. However, there are always gaps to fill!

Existing Pyth libraries:

• pyth-client-rs (crate) — Rust library for on-chain Solana programs or off-chain applications.
• pyth-neon — Neon EVM compatibility layer for Ethereum applications running on Solana. This library provides a drop-in oracle replacement for Ethereum applications migrating to Solana, as it implements the same interface as most popular Ethereum oracles.
• pyth-client-js (npm) — Typescript/Javascript library for off-chain applications, such as displaying the Pyth price on a website.
• pyth-client-py (pypi) — Python library for off-chain applications, such as displaying the Pyth price on a website.

Potential new library:

• pyth-client-go — Golang client for on/off-chain applications such as displaying the Pyth price on a website or incorporating in a smart contract. Past Solana Hackathon: Ignition, saw one team: Poseidon, releasing a high-performance liquidation bot for the borrow and lending platform Solend. Poseidon client was written in Go, but the code has not been made open source, and since Pyth program did receive minor updates requiring tweaks.

# Improvements to Pyth Javascript client library

The javascript client library currently allows users to subscribe to or poll price updates for all symbols at once. However, several users have requested single-price feed versions of both operations. The task here is to update the library to support these requests.

The best way to do this is to make a class representing a single price feed that supports both polling and a subscription method. Users can instantiate this class using https://github.com/pyth-network/pyth-client-js/blob/main/src/PythHttpClient.ts to download the mapping from symbols to accounts

# Oracle Mocking Tools for Testing

The pyth-client-rs should include some mocking libraries that enable users to create Pyth accounts and feed any pricing data they wish. These accounts are needed for downstream protocols to test their instructions end-to-end. The mocking should be good enough for downstream protocols to test account ownership logic.

As a reference, here is Jet Protocol mocking tool: https://github.com/jet-lab/jet-v1/blob/80aa42ef1e064e3f48fdda731d24963f732ab4b2/tests/jet.spec.ts#L103

# Pyth Dune Analytics Dashboard

Recently, Dune Analytics deployed the tooling to track on-chain Solana data.

As of today, 3 dashboards already exist, one being dedicated to Drift for example.

Creating a Dune dashboard would likely be very beneficial to Pyth network participants: from publishers, end-users but also delegators. As Pyth will greatly evolve this year with many features like staking or delegation to be rolled out, the dashboard will have to be continuously completed.

However, there are already some valuable metrics to highlight through Dune. A non-comprehensive list of data points of interest:

• Count of daily transactions of the Pyth Oracle program
• Segmentation of daily transactions per individual publishers // Solana address (design idea)

• Count of all (daily) price updates
• Segmentation of all (daily) price updates per asset/price feed (Drift Dune Dashboard)

• Count the number of assets each publisher (Solana account) quotes (table style)
• Protocols Trading Volume using Pyth (PERP with 01, Bonfida, Drift, Mango, Synthetics with Synthetify, Futures with Zeta, Options with Zeta, Friktion, Chest, PsyFinance, Katana — careful to not double count). This can be shown in multiple graphs with different views: #1 segmenting data by the style of protocol (PERP, Synthetics, Futures, Options), #2 segmenting by protocol name.
• Protocols Open Interest using Pyth (PERP with 01, Bonfida, Drift, Mango).

# Fair LP Price via Fair Asset Reserves

Develop the Fair Asset Reserves idea put forth by Alpha Finance here. Indeed, integrated with the previously released method to calculate the price of a basket of assets, this would enable any protocols to support LP tokens on their platform while reducing to the maximum possible the potential risks they face helping those.

Conclusion extracted from Alpha Finance blog: With the combination of fair asset prices (already available via Pyth) and fair asset reserves (to be created), we can now derive the fair LP token prices that are unmanipulatable and safe from attack vectors such as flash loan attacks.

Developing the Fair Asset Reserves function would enable billions of dollars of assets to become even “more productive” and integrated throughout the Solana DeFi ecosystem.

As of today on Solana, only Port Finance supports LP tokens for borrowing purposes. And actually, only one LP token is supported, and it is an LP from a “stable/pegged” AMM pool (Saber USDC-USDT). Larix, another borrow-lending protocol, offers to supply a set of LP tokens on their platform, but it is not yet possible to borrow them.

Alpha Finance Blog for greater details

# Options IV Calculator

Provide a function (or tool) within Pyth that enables options protocol to calculate options IV through the Black Scholes model. All derived upon a mix of Pyth inputs & custom protocol inputs.

To determine IV, you need the below inputs:

• Market price of the option (protocol input — observable from the protocol markets)
• Underlying stock price (returned from Pyth)
• Strike price (protocol input — observable from the protocol markets)
• Time to expiration (protocol input — observable from the protocol markets)
• Risk-free interest rate (protocol input or potentially returned from Pyth, see below idea)

# DeFi Risk-Free Rate Calculator

Linked to the above idea but not exclusive to it, it would be to create a “DeFi risk-free rate” calculator using Pyth or product (price feed) within Pyth. Then, similarly to independent publishers sending quotes for a specific asset, we could imagine borrow-lending protocols (initially only Solana ones to make the feed specific enough and so useful) sending their ongoing supply rate to a Pyth product. With Pyth aggregation, we would then return a consolidated value representing a “tentative” valuation of risk-free rate on Solana.

USDC supply rates from 15th February 2022 (excludes any additional rewards such paid out in native protocol token):

So imagining all protocols send those values as inputs to Pyth, it would then return a consolidated value that we could consider as the risk-free rate on Solana for USD(C). Here disregarding confidence intervals and their impact on the pyth aggregation, just grossly taking the median value would return 2.11%. Of course, nothing is risk-free, even when tied to US bills (currently how risk-free rate is tracked), so additional parameters such as smart contract risk could be helpful.

Generating this (Solana) DeFi risk-free rate could help in the Options IV calculator mentioned above, but such value and its meaning could actually be implemented elsewhere. We could imagine a protocol offering derivatives of this risk-free rate to track the macro-environment. During bull markets, borrow (and supply) rates increase as opportunity costs arise, while in bear markets, stablecoins supply rate tends to go down as people seek “refuge.”

By this publication, the fantastic Jet team released an open-source tool for fetching interest rates across Solana lending platforms. So with some tweaks, you should be able to spin up the necessary, and don’t forget to thank the Jetters as they did some legwork for you.

Protocol Ideas

# Evolving NFTs

n NFT collection that would see its metadata updated according to the underlying asset it follows. For instance, we could imagine one of the NFT to be BTC related where if the current BTC price is higher than the one 24 hours ago (could be one week, one month…), the NFT metadata would show “Bull” (grossly representing a bull market). The other way around would see the metadata be “Bear” and express the downward market direction.

The above proposal is purely about the pricing of the tracked asset affecting the NFT metadata (as well as its visual potentially). Still, we could further imagine that the asset followed incorporates a pricing or reward mechanism that would create some “rarity” or a real impact whether your BTC NFT is in “Bull” or “Bear” mode.

For instance, when minting the NFT, you must choose between Bear & Bull mode, representing a bet on the following week’s market evolution. If you minted a Bull, and next week’s price is below the current one (and so Bear mode), you would lose your Bull NFT completely (burned from your wallet). While if you were right, you would receive a payout: the latter could come either through token creation or share the “losers” stake.

# Oracle-Based Swap

Build a protocol that offers swaps based upon the oracle price (exchange rate) rather than pool reserves (traditional AMMs design). This Oracle-based swap would have the advantage of providing more competitive pricing to users, especially as this could enable the protocol to offer very low slippage (highly concentrated liquidity) even on large orders.

Rather than “constant” liquidity offered (scaling out from the initial price), the Oracle-based swap should integrate Pyth confidence interval to scale the liquidity according to the price range provided. For example, Pyth returns BTC = 40,000 +/- 10 — so a large swap on the protocol would heavily stay around 40,000, as it is the oracle price. But as the order is substantial (TBD how this is determined), the last fills could skew towards 40,010, which is the end of the Pyth price range for BTC.

# AMMs with Guardrails

When swapping via traditional AMMs (using pool reserves design), the AMM “worst” exchange rate should not go outside the Pyth price +/- confidence interval.

So that any order that would be too large, meaning negatively affecting AMM exchange rate (as it does not track the ‘real price’ anymore until an arbitrageur arrives) would be only partially filled to keep the AMM reserves so that its exchange rate fits with the Pyth range.

This feature could improve (reduce in this case) impermanent losses for liquidity providers though it has to be proven. Another use case would be making “life” easier or at least less risky for newcomers to DeFi and 1st time encounters with AMMs.

In this case, the AMM having integrated the Pyth price +/- its confidence interval would only allow a partial fill to the users. As the AMM price moves along the curve (x * y = k), it will at some point exits the Pyth price +/- confidence interval band. When it does, it means that the potential fill price from the AMM is not a good/efficient one, and as a user, I would/should not make the trade.

Another feature could be to prevent any swap when the AMM price is outside of the Pyth price +/- confidence interval band.

Useful links

• Pyth Website
• Pyth Whitepaper
• Pyth Docs
• Pyth Client Libraries
• Pyth Code Example (in Rust)
• Pyth Workshop Day 1 — Understanding the Pyth Architecture (Publisher oriented but great basics)
• Pyth Workshop — Day 2 — Walking Through the Pyth Whitepaper

We can’t wait to hear what you think! You can join the Pyth Discord and Telegram, follow us on Twitter, and be the first to hear about what’s new in the Pyth ecosystem through our newsletter. You can also learn more about Pyth here.