Real-Time Prices for Stellar’s $4B Tokenized Assets Economy

Editor’s note: The Stellar network’s oracle ecosystem is expanding. This post is a technical guide for developers and teams building on the Stellar network. It covers how to evaluate and integrate oracle price feeds in Stellar smart contracts, with a focus on Pyth’s recent mainnet launch alongside other available providers. The Stellar Development Foundation (SDF) does not endorse, recommend, or warrant any specific oracle provider, and this post is not investment, financial, or legal advice. Developers should conduct their own due diligence before integrating any third-party service.

The Stellar network hosts $4 billion in tokenized real-world assets—up roughly 360% this year. These assets trade 24/7, even when their underlying markets don’t, making timely, reliable pricing data essential for anything built on top. Pyth’s launch expands what’s possible: 3,500+ feeds across equities, commodities, FX, and crypto, sourced first-party from exchanges and trading firms, now consumable from any Stellar smart contract. If your product depends on prices for assets whose markets close, this post is for you.

In the spirit of “don’t trust, verify,” this post also walks through the due-diligence step that belongs before any integration: proving to yourself and users that the mainnet deployment is configured correctly and rejects tampered data—without spending a single stroop.

Pyth is useful if you’re developing:

• Lending markets that take RWA collateral and need to value it continuously
• Vaults holding multi-asset portfolios that need marking around the clock
• Payment apps that need live FX rates
• Any protocol whose liquidations currently wait on a once-a-day NAV print

There’s already a live example of the pattern on the Stellar network: Centrifuge’s deRWA tokens (deJTRSY and deJAAA), with Blend named as a lending partner. Tokenized funds as collateral only work as well as their price feed.

Pyth on the Stellar network uses a pull model with three parts:

• Offchain, you subscribe to signed price updates. Pyth’s low-latency service streams updates over WebSocket in a leEcdsa format designed for Stellar smart contracts’ native secp256k1 verification. Your application (or your protocol’s price-pusher) receives a compact signed payload—a few hundred bytes carrying price, exponent, and a microsecond timestamp.
• Onchain, a verifier contract checks the signature. Pyth deployed a verifier at CACZ3GBAKUPIAFRILUFO27J5RUH5GJ2VSJ46LP6GJYSKGDRTQ5MS3HCH (mainnet). Its verify_update function recovers the signer from the payload’s ECDSA signature and checks it against an onchain list of trusted signers. Verification is permissionless—anyone can call it; only receiving the data feed requires a subscription.
• Your contract consumes the verified payload. The pyth-lazer-stellar-sdk crate wraps the cross-contract call:

pub fn update_price(env: Env, payload: Bytes) -> Result<StoredPrice, ParseError> {
    let lazer: Address = env.storage().instance().get(&DataKey::Lazer).unwrap();
    let update = PythLazerClient::new(&env, &lazer).verify_update(&payload)?;

    let feed = update.feeds.iter().find(|f| f.feed_id == 1).expect("BTC/USD missing");
    Ok(StoredPrice {
        price: feed.price.expect("price missing"),
        exponent: i32::from(feed.exponent.expect("exponent missing")),
        timestamp_us: feed.feed_update_timestamp.expect("timestamp missing"),
    })
}

Snippet from Pyth’s Stellar integration guide, which has the full working example.

One rule from Pyth’s own guide worth repeating: always call verify_update from inside your contract. Never trust a pre-parsed update handed to you by an offchain caller.

Everything below runs against mainnet using only simulation—no wallet, no XLM, no transaction submitted. Stellar RPC’s simulate endpoint executes the contract’s real WASM against real ledger state, so the results are authoritative.

1. Check the trusted signer.

stellar contract invoke \
  --id CACZ3GBAKUPIAFRILUFO27J5RUH5GJ2VSJ46LP6GJYSKGDRTQ5MS3HCH \
  --rpc-url https://mainnet.sorobanrpc.com \
  --network-passphrase "Public Global Stellar Network ; September 2015" \
  --source-account GBTKQ2WYNYE5TJW3N5LH7PGGERX2EIBDIIN7X6LFHMVQQZCZT36KA3PC \
  -- list_trusted_signers

You’ll get back one key: 03a4380f…155b. That’s the same signer key Pyth governance approved for other chains (see OP-PIP-45 on the Pyth forum), and it matches the testnet deployment exactly.

2. Fetch a live signed payload. With a Pyth API token (the 14-day free trial works):

curl -X POST "https://pyth-lazer.dourolabs.app/v1/latest_price" \
  -H "Authorization: Bearer $YOUR_TOKEN" -H "Content-Type: application/json" \
  -d '{"priceFeedIds":[1],"properties":["price","exponent","feedUpdateTimestamp"],
       "formats":["leEcdsa"],"channel":"fixed_rate@200ms","jsonBinaryEncoding":"hex"}'

3. Verify it on mainnet. Pass the hex leEcdsa.data from the response to verify_update (same invoke pattern as above, with -- verify_update --data <hex>). Simulation returns the verified inner payload—signature checked against the onchain signer, live BTC/USD price extracted.

4. Try to cheat. Flip one byte of the price inside the payload and call again:

error: transaction simulation failed: HostError: Error(Contract, #6)

Error #6 is SignerNotTrusted—tampering with the message makes signature recovery produce a different public key, and the contract rejects it. That one failing command confirms the onchain signature check is live.

The contract was audited by Zellic (report), and the same checks run against the testnet deployment at CAYFT5JE3UQTKT4Q6ZOZK4FXVYVT6RE3MFC7STA4UB6WAEGBT65MRU52.

Pyth joins a growing set of oracles on the Stellar network including Reflector, DIA, and RedStone, which went live earlier this year. Chainlink is on the way. Each is suited to different product needs:

• Pyth Pro is first-party data. Feeds published directly by exchanges, market makers, and banks with sub-second latency and the deepest cross-asset catalog at launch: equities, ETFs, commodities, FX, fixed income such as US Treasury yields and prices, and 24/7 Indices for assets whose markets close. It’s a subscription product: the protocol pays for the data stream; onchain verification is free for everyone.
• Chainlink Data Streams and Data Feeds are coming to the Stellar network: Stellar joined Chainlink Scale and is adopting them alongside CCIP, with the integration still in progress. Chainlink validates third-party data through a decentralized network, and its biggest draw will be portability: protocols already built on Chainlink elsewhere can bring their integration to the Stellar network largely as-is.
• Redundancy beats either alone. For anything holding user funds against volatile collateral, the institutional posture is two independent sources with divergence checks—cross-reading Pyth against RedStone costs little and reduces reliance on a single point of failure.

The short version: if your product touches assets that trade on traditional markets, Pyth Pro covers a broad range of them.

• Pyth Terminal—browse feeds and start the 14-day trial
• REST API reference—pyth.dourolabs.app/docs for history, search, and point-in-time price endpoints
• Stellar integration guide
• Contract addresses
• Pyth’s launch announcement
• Stellar docs: oracle providers
• Pyth on the Stellar ecosystem directory—filter by category “Cross-Chain & Infrastructure” → sub-category “Oracles,” or category “DeFi”

Building something that needs continuous pricing? Come talk to us in the Stellar Developer Discord.

Disclaimer: SDF provides this post for informational and educational purposes only. References to specific projects, products, or services do not constitute an endorsement, recommendation, or warranty by SDF. Code examples are illustrative and have not been audited by SDF; developers should independently verify all code before deploying to mainnet. SDF is not responsible for the performance, security, or availability of any third-party oracle or data feed. Nothing in this post is intended as investment, financial, or legal advice.