Skip to content
Open
10 changes: 5 additions & 5 deletions Cargo.lock

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
[package]
name = "pyth-lazer-solana-contract"
version = "0.7.1"
version = "0.7.2"
edition = "2021"
description = "Pyth Lazer Solana contract and SDK."
license = "Apache-2.0"
Expand All @@ -19,7 +19,7 @@ no-log-ix-name = []
idl-build = ["anchor-lang/idl-build"]

[dependencies]
pyth-lazer-protocol = { path = "../../../../sdk/rust/protocol", version = "0.16.0" }
pyth-lazer-protocol = { path = "../../../../sdk/rust/protocol", version = "0.17.0" }

anchor-lang = "0.31.1"
bytemuck = { version = "1.20.0", features = ["derive"] }
Expand Down
4 changes: 2 additions & 2 deletions lazer/publisher_sdk/rust/Cargo.toml
Original file line number Diff line number Diff line change
@@ -1,13 +1,13 @@
[package]
name = "pyth-lazer-publisher-sdk"
version = "0.14.0"
version = "0.15.0"
edition = "2021"
description = "Pyth Lazer Publisher SDK types."
license = "Apache-2.0"
repository = "https://github.com/pyth-network/pyth-crosschain"

[dependencies]
pyth-lazer-protocol = { version = "0.16.0", path = "../../sdk/rust/protocol" }
pyth-lazer-protocol = { version = "0.17.0", path = "../../sdk/rust/protocol" }
anyhow = "1.0.98"
protobuf = "3.7.2"
serde_json = "1.0.140"
Expand Down
4 changes: 2 additions & 2 deletions lazer/sdk/rust/client/Cargo.toml
Original file line number Diff line number Diff line change
@@ -1,12 +1,12 @@
[package]
name = "pyth-lazer-client"
version = "8.2.2"
version = "8.2.3"
edition = "2021"
description = "A Rust client for Pyth Lazer"
license = "Apache-2.0"

[dependencies]
pyth-lazer-protocol = { path = "../protocol", version = "0.16.0" }
pyth-lazer-protocol = { path = "../protocol", version = "0.17.0" }
tokio = { version = "1", features = ["full"] }
tokio-tungstenite = { version = "0.20", features = ["native-tls"] }
futures-util = "0.3"
Expand Down
2 changes: 1 addition & 1 deletion lazer/sdk/rust/protocol/Cargo.toml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
[package]
name = "pyth-lazer-protocol"
version = "0.16.0"
version = "0.17.0"
edition = "2021"
description = "Pyth Lazer SDK - protocol types."
license = "Apache-2.0"
Expand Down
3 changes: 3 additions & 0 deletions lazer/sdk/rust/protocol/src/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,8 @@ mod feed_kind;
pub mod jrpc;
/// Types describing Lazer's verifiable messages containing signature and payload.
pub mod message;
/// Types describing Lazer's feed & asset metadata catalog APIs.
pub mod metadata;
/// Types describing Lazer's message payload.
pub mod payload;
mod price;
Expand All @@ -28,6 +30,7 @@ use serde::{Deserialize, Serialize};
pub use crate::{
dynamic_value::DynamicValue,
feed_kind::FeedKind,
metadata::{AssetClass, AssetResponseV3, FeedResponseV3, InstrumentType},
price::{Price, PriceError},
rate::{Rate, RateError},
symbol_state::SymbolState,
Expand Down
138 changes: 138 additions & 0 deletions lazer/sdk/rust/protocol/src/metadata.rs
Original file line number Diff line number Diff line change
@@ -0,0 +1,138 @@
//! Types describing Lazer's metadata APIs.

use crate::FeedKind;
use crate::{symbol_state::SymbolState, PriceFeedId};
use serde::{Deserialize, Serialize};

/// The pricing context or type of instrument for a feed.
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, Serialize, Deserialize)]
#[serde(rename_all = "lowercase")]
pub enum InstrumentType {
/// Spot price
Spot,
/// Redemption rate
#[serde(rename = "redemptionrate")]
RedemptionRate,
/// Funding rate
#[serde(rename = "fundingrate")]
FundingRate,
/// Future price
Future,
/// Net Asset Value
Nav,
/// Time-weighted average price
Twap,
}

/// High-level asset class.
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, Serialize, Deserialize)]
#[serde(rename_all = "kebab-case")]
pub enum AssetClass {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One of the reasons for opting in a dynamic metadata was to not go through a code change when new asset classes are added to the system. I know that users (on both sides) rely on these, and that's probably why you opted for explicit definition here. But if that's the case, you might actually remove any dynamic field and make everything very explicit. Being in the middle (some explicit metadata, some implicit dynamic) is probably worse.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should stick with our decision and use fully dynamic metadata in the protocols. In Rust that would be BTreeMap<String, serde_value::Value>. We can revisit it later if we feel like the metadata structure is very stable and future-proof, but I doubt that it will happen soon.

Copy link
Contributor Author

@tejasbadadare tejasbadadare Oct 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah my main goal in adding these explicit types is to ensure end users can depend on a stable API contract across different versions. I.e. the different types like the existing SymbolResponse and the new FeedResponseV3 can handle the differences between v1 and v3 representations derived from the same internal dynamic metadata representation.

/// Cryptocurrency
Crypto,
/// Foreign exchange
Fx,
/// Equity
Equity,
/// Metal
Metal,
/// Rates
Rates,
/// Net Asset Value
Nav,
/// Commodity
Commodity,
/// Funding rate
FundingRate,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this really an asset class?

Copy link
Contributor Author

@tejasbadadare tejasbadadare Oct 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm.. we currently consider it an asset class in the V1 API, but i agree that conceptually it doesn't really fit. We can introduce an AssetClassV3 that excludes these.

But then the question is what we'd set for asset_class for funding rate feeds. Maybe it's reasonable to leave it as FundingRate? Or we can set it to the underlying asset's class. Will check with @YaserJazouane on this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caught up, yes funding rate is not an asset class. It'll be a feed_kind (as it already is).

}

/// Feed metadata as returned by the v3 metadata API.
#[derive(Debug, Clone, PartialEq, Eq, Hash, Serialize, Deserialize)]
pub struct FeedResponseV3 {
/// Unique integer identifier for a feed. Known as `pyth_lazer_id` in V1 API.
/// Example: `1`
pub id: PriceFeedId,
/// Short feed name.
/// Example: `"Bitcoin / US Dollar"`
pub name: String,
/// Unique human-readable identifier for a feed.
/// Format: `source.instrument_type.base/quote`
/// Examples: `"pyth.spot.btc/usd"`, `"pyth.redemptionrate.alp/usd"`, `"binance.fundingrate.btc/usdt"`, `"pyth.future.emz5/usd"`
pub symbol: String,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i recommend opting for a specific type with validation here to ensure it's correct.

q: what if the asset has no quote asset? (such as rates)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A type with validation to enforce the string format is a good idea.
Not sure about a feed with no quote asset. If such a feed is valid it poses a deeper problem with the data model, since it revolves around feed being an asset/quote pair. Fwiw currently funding rates are USD denominated.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay caught up with @YaserJazouane on this and yep we should make the quote asset optional. There are cases like yields, indices, fundingrates that aren't quoted in any currency. Our existing funding rate example is denominated in USD which is incorrect.

tldr:

  • We're amending the format to be source.instrument_type.base[/quote] where the quote asset is optional
  • We're making quote_asset_id optional

/// Description of the feed pair.
/// Example: `"Pyth Network Aggregate Price for spot BTC/USD"`
pub description: String,
/// The Asset ID of the base asset.
/// Example: `"BTC"`
pub base_asset_id: String,
/// The Asset ID of the quote asset.
/// Example: `"USD"`
pub quote_asset_id: String,
/// The pricing context.
/// Example: `"spot"`
pub instrument_type: InstrumentType,
/// Aggregator or producer of the prices.
/// Examples: `"pyth"`, `"binance"`
pub source: String,
/// The trading schedule of the feed's market, in Pythnet format.
/// Example: `"America/New_York;O,O,O,O,O,O,O;"`
pub schedule: String,
/// Power-of-ten exponent. Scale the `price` mantissa value by `10^exponent` to get the decimal representation.
/// Example: `-8`
pub exponent: i32,
/// Funding rate interval. Only applies to feeds with instrument type `funding_rate`.
/// Example: `10`
pub update_interval_seconds: i32,
/// The minimum number of publishers contributing component prices to the aggregate price.
/// Example: `3`
pub min_publishers: i32,
/// Status of the feed.
/// Example: `"active"`
pub state: SymbolState,
/// High-level asset class. One of crypto, fx, equity, metal, rates, nav, commodity, funding-rate.
/// Example: `"crypto"`
pub asset_type: AssetClass,
/// CoinMarketCap asset identifier.
/// Example: `"123"`
#[serde(skip_serializing_if = "Option::is_none")]
pub cmc_id: Option<String>,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i wonder whether you considered @jayantk suggestion on having a nested struct as "external mappings". It's probably more difficult on the DB layer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah i did consider it, but i figured that a nested struct in the dynamic metadata opened the door to making its own table to ensure proper types in the DB. FIgured it was simpler to leave it flat.

/// Pythnet feed identifier. 32 bytes, represented in hex.
/// Example: `"e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43"`
pub pythnet_id: String,
/// Nasdaq symbol identifier.
/// Example: `"ADSK"`
#[serde(skip_serializing_if = "Option::is_none")]
pub nasdaq_symbol: Option<String>,
/// ISO datetime after which the feed will no longer produce prices because the underlying market has expired.
/// Example: `"2025-10-03T11:08:10.089998603Z"`
#[serde(skip_serializing_if = "Option::is_none")]
pub feed_expiry: Option<String>,
/// The nature of the data produced by the feed.
/// Examples: `"price"`, `"fundingRate"`
pub feed_kind: FeedKind,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm so we do have a feedkind and an instrument type. I wonder whether we can merge them.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think they're capturing slightly different things.
Afaik feed_kind is meant to be the coarsest discriminator of feeds, which we use to trigger different aggregation logic (price feeds, non price feeds like funding rates). Whereas instrument_type is a bit more specific, and describes the pricing context (spot price, averaged price, etc.).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consensus on this topic was that the two fields capture different things as mentioned above, so planning on keeping it this way.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've managed to eliminate most Enums from the payload. Considering FeedKind is used for aggregation, could we also make this a String in this payload? Just to not complicate adding new aggregation types. It's likely the case that a new feed kind requires dev effort to implement first, so we can safely convert the existing Enum to String for these responses, with an expectation that Governance would do the same when initially adding to state.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, forgot about this one! will update

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are going to add beta soon to SymbolState as well -- I'll also make that a string.

}

/// Asset metadata as returned by the v3 metadata API.
#[derive(Debug, Clone, PartialEq, Eq, Hash, Serialize, Deserialize)]
pub struct AssetResponseV3 {
/// Unique identifier for an asset.
/// Example: `"BTC"`
pub id: String,
/// A short, human-readable code that identifies an asset. Not guaranteed to be unique.
/// Example: `"BTC"`
pub ticker: String,
/// Full human-readable name of the asset.
/// Example: `"Bitcoin"`
pub full_name: String,
/// High-level asset class.
/// Example: `"crypto"`
pub class: AssetClass,
/// More granular categorization within class.
/// Example: `"stablecoin"`
#[serde(skip_serializing_if = "Option::is_none")]
pub subclass: Option<String>,
/// Primary or canonical listing exchange, when applicable.
/// Example: `"NASDAQ"`
#[serde(skip_serializing_if = "Option::is_none")]
pub listing_exchange: Option<String>,
}