Advanced Price Feed Tutorial

Example Code: The complete working example for this tutorial is available at sb-on-demand-examples/solana/feeds/advancedarrow-up-right

This tutorial demonstrates how to build an ultra-optimized Switchboard oracle integration using the Pinocchio framework, achieving ~90% reduction in compute units compared to the basic Anchor implementation.

Why Optimize Compute Units?

On Solana, compute units directly impact transaction costs. Every CU saved means lower fees for your users and operators. This matters especially for:

  • High-frequency oracle updates: If you're cranking prices every few seconds, those CUs add up fast

  • Production DeFi protocols: Lower costs improve margins and user experience

  • MEV-sensitive operations: Smaller, faster transactions have competitive advantages

Metric
Basic (Anchor)
Advanced (Pinocchio)
Savings

Compute Units

~2,000 CU

~190 CU

~90%

Framework Overhead

High

Minimal

-

Transaction Size

Standard

Optimized with LUTs

~90%

What You'll Build

An ultra-optimized oracle program with:

  • Admin authorization for trusted crankers

  • Four modular instructions: init_state, init_oracle, crank, read

  • Direct oracle writes bypassing expensive verification (for authorized users)

  • QuoteVerifier for secure reads with staleness checks

Prerequisites

  • Completed the Basic Price Feed tutorial

  • Rust and Cargo installed

  • Familiarity with Pinocchio framework concepts

  • Solana CLI installed and configured

  • A Solana keypair with SOL

Key Concepts

Pinocchio Framework

Pinocchioarrow-up-right is a zero-abstraction Solana program framework that provides:

  • Direct syscall access without runtime overhead

  • Zero-allocation account parsing

  • #[inline(always)] instruction dispatch

  • ~100 CU framework overhead vs ~2,000 CU for Anchor

Admin Authorization Pattern

Instead of verifying every oracle update cryptographically (expensive), this pattern:

  1. Stores an authorized signer in a state account

  2. Only allows that signer to write oracle data

  3. Uses write_from_ix_unchecked for direct writes

This trades decentralization for efficiency—suitable when you control the cranker.

Modular Account Initialization

The program separates account creation into dedicated instructions:

  • init_state: Creates the authorization state account

  • init_oracle: Creates the quote storage account

This allows conditional initialization only when needed.

The On-Chain Program

Program Structure

The instruction discriminator is a single byte—no Anchor discriminator overhead.

Instruction 0: crank

The crank instruction writes oracle data for authorized signers:

Key points:

  • Uses borrow_data_unchecked for zero-copy state access

  • write_from_ix_unchecked directly writes oracle data without Ed25519 verification

  • Only ~90 CU for the entire operation

Instruction 1: read

The read instruction verifies and displays oracle data:

Key points:

  • Uses QuoteVerifier for secure verification

  • max_age(30) ensures data freshness (30 slots ≈ 12 seconds)

  • Iterates through all feeds in the quote

Instruction 2: init_state

Initializes the authorization state account:

The state account stores a single 32-byte pubkey—the authorized cranker.

Instruction 3: init_oracle

Initializes the oracle quote account:

Account Initialization Helpers

The utils.rs module handles PDA derivation and account creation:

Quote Account Initialization

State Account Initialization

The TypeScript Client

The client handles initialization, quote fetching, and transaction building:

Running the Example

1. Clone the Examples Repository

2. Install Dependencies

3. Build and Deploy the Program

Unlike the basic example, the advanced program must be deployed:

4. Run the Example

Expected Output

When to Use This Pattern

Use the advanced pattern when:

Scenario
Recommendation

High-frequency cranking (sub-second)

Advanced

Compute-sensitive DeFi protocols

Advanced

You control the cranker infrastructure

Advanced

Learning / prototyping

Basic

Decentralized, trustless updates

Basic

Simple integrations

Basic

Security Considerations

write_from_ix_unchecked Risks

This function bypasses cryptographic verification. Only use it when:

  1. You control the signer: The authorized cranker is your infrastructure

  2. You trust all transaction accounts: Malicious accounts could corrupt data

  3. You have external monitoring: Detect and respond to anomalies

Admin Authorization Trade-offs

Aspect
Managed Updates (Basic)
Admin Auth (Advanced)

Trust Model

Trustless (cryptographic)

Trusted admin

Cost

Higher CU

~90% lower CU

Decentralization

Anyone can update

Only admin

Security

Ed25519 verified

Admin key security

Recommendations

  1. Rotate admin keys periodically

  2. Use multisig for production admin accounts

  3. Monitor for anomalies in oracle values

  4. Consider hybrid approaches: Admin writes + periodic cryptographic verification

Next Steps

  • Custom Feeds: Learn to create custom data feeds in Custom Feeds

  • Multiple Feeds: Batch multiple price feeds in a single transaction

  • Randomness: Explore verifiable randomness in the Randomness Tutorial

Last updated