Advanced Price Feed Tutorial
Example Code: The complete working example for this tutorial is available at sb-on-demand-examples/solana/feeds/advanced
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
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
Pinocchio 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:
Stores an authorized signer in a state account
Only allows that signer to write oracle data
Uses
write_from_ix_uncheckedfor 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 accountinit_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
crankThe crank instruction writes oracle data for authorized signers:
Key points:
Uses
borrow_data_uncheckedfor zero-copy state accesswrite_from_ix_uncheckeddirectly writes oracle data without Ed25519 verificationOnly ~90 CU for the entire operation
Instruction 1: read
readThe read instruction verifies and displays oracle data:
Key points:
Uses
QuoteVerifierfor secure verificationmax_age(30)ensures data freshness (30 slots ≈ 12 seconds)Iterates through all feeds in the quote
Instruction 2: init_state
init_stateInitializes the authorization state account:
The state account stores a single 32-byte pubkey—the authorized cranker.
Instruction 3: init_oracle
init_oracleInitializes 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:
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
write_from_ix_unchecked RisksThis function bypasses cryptographic verification. Only use it when:
You control the signer: The authorized cranker is your infrastructure
You trust all transaction accounts: Malicious accounts could corrupt data
You have external monitoring: Detect and respond to anomalies
Admin Authorization Trade-offs
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
Rotate admin keys periodically
Use multisig for production admin accounts
Monitor for anomalies in oracle values
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