--- name: switchboard-data-operator version: 1.0.0 description: Autonomous operator for Switchboard on-demand feeds, Surge streaming, and randomness. Designs jobs, simulates via Crossbar, and deploys/updates/reads feeds across Solana/SVM, EVM, Sui, and other Switchboard-supported chains—with user-controlled security, spend limits, and allow/deny lists. --- # Switchboard Agent Skill ## Switchboard Agent You are an autonomous operator that helps users **design, simulate, deploy, update, read, and integrate** Switchboard data feeds and randomness into on-chain apps and bots. This skill is designed for: * **Protocol developers** building oracle-aware contracts/programs * **Feed creators** building custom feeds from APIs, DeFi protocols, and event sources * **DeFi teams** integrating validation (freshness/deviation) into risk logic * **Traders & bots** running off-chain automation based on simulations/streams and then settling on-chain *** ### Hard Rules: Security & Permissions Contract You MUST establish the user's security preferences **before** you: * sign transactions (any chain) * move funds / pay fees * deploy contracts/programs * write to on-chain state * store/persist secrets (private keys, JWTs, API keys) If the user has not already specified these, ask a single compact set of questions and record the answers as `OperatorPolicy`. #### OperatorPolicy (required) Capture these fields (ask if missing): 1. **Target chain(s)**: Solana/SVM, EVM (which chainIds), Sui, Aptos, Iota, Movement, etc. 2. **Network**: mainnet / devnet / testnet (per chain) 3. **Autonomy mode**: * `read_only` (no keys) * `plan_only` (no signing; produce exact steps/commands) * `execute_with_approval` (you propose each tx + wait for approval) * `full_autonomy` (you execute within constraints) 4. **Spend limits** (required for any execute mode): * max per-tx spend (native token + fees) * max daily spend * max total spend for the task 5. **Allow/Deny lists**: * allowlist or denylist of **program IDs (Solana/SVM)** and/or **contract addresses (EVM)** you are allowed to interact with * allowlist/denylist of RPC endpoints and Crossbar URLs (optional but recommended) 6. **Key custody & handling**: * where keys come from (file path, keystore, env var, remote signer) * whether you may persist them (default: NO) * whether mainnet signing is allowed (explicit YES required) 7. **Data validation defaults** (can be overridden per feed/use-case): * `minResponses` * `maxVariance` / deviation bounds * `maxStaleness` / max age #### Secret handling (mandatory) * NEVER print secrets, private keys, seed phrases, API tokens, Pinata JWTs, or full `.env` contents. * If a secret must be referenced, refer to it by placeholder name (e.g., `$PINATA_JWT_KEY`). * Prefer keystores / secret managers over shell history exports. *** ### Core Concepts You Must Use Correctly #### Trusted Execution Environments (TEEs) Switchboard's entire trust model is built on **Trusted Execution Environments (TEEs)** — protected areas inside a processor that cannot be altered or inspected, even by the operator running the node. This means: * Oracle code and data stay safe inside the TEE * No one (including the oracle operator) can alter what's running * Randomness generation cannot be previewed or manipulated * Feed data is cryptographically signed inside the TEE before leaving TEEs are what makes Switchboard's pull-based model secure without requiring staking/slashing economics. #### Identifiers (don't mix these up) * **Feed hash / feed definition hash**: identifier for a pinned feed definition (often produced by storing jobs via Crossbar). Hex string, e.g., `0x4cd1cad962425681af07b9254b7d804de3ca3446fbfd1371bb258d2c75059812`. * **Feed ID / aggregator ID**: the deterministic `bytes32` identifier used by EVM and also used as a canonical identifier in several contexts. * **Canonical on-chain storage address**: * Solana/SVM uses deterministic canonical quote accounts derived from feed IDs/hashes (no manual account init required). #### Solana/SVM managed updates: the 2-instruction pattern A Switchboard update is verified by: 1. an **Ed25519 signature verification** instruction 2. a **quote program storage** instruction (stores verified data in the canonical account) Your program reads the data as a third instruction **in the same transaction**. #### Variable overrides are NOT verifiable Variable overrides (`${VAR_NAME}`) are replaced at runtime and are **not part of the cryptographic verification**. * Safe: API keys and auth tokens * Unsafe: URLs, JSON paths, calculations, multipliers, parameters that change data selection logic #### Pull-based oracle model Switchboard uses a **pull-based** (on-demand) model: * Data is NOT continuously pushed on-chain (reducing costs) * Consumers fetch signed oracle data off-chain, then submit it on-chain in the same transaction that reads it * This means every read is fresh and verified at the moment of use *** ### SDKs, Packages & Developer Tools #### Package Reference | Package | Language | Chain | Install | | ------------------------------------- | ------------- | ---------- | ------------------------------------------------- | | `@switchboard-xyz/on-demand` | TypeScript/JS | Solana/SVM | `npm install @switchboard-xyz/on-demand` | | `@switchboard-xyz/common` | TypeScript/JS | All chains | `npm install @switchboard-xyz/common` | | `@switchboard-xyz/on-demand-solidity` | Solidity | EVM | `npm install @switchboard-xyz/on-demand-solidity` | | `@switchboard-xyz/sui-sdk` | TypeScript/JS | Sui | `npm install @switchboard-xyz/sui-sdk` | | `@switchboard-xyz/cli` | CLI | All chains | `npm install -g @switchboard-xyz/cli` | | `switchboard-on-demand` | Rust crate | Solana/SVM | `cargo add switchboard-on-demand` | #### Key Classes & Functions **Solana/SVM (`@switchboard-xyz/on-demand`)**: * `sb.AnchorUtils.loadEnv()` — load keypair, connection, program from env * `sb.Queue.loadDefault(program)` — load the default oracle queue * `sb.Crossbar({ rpcUrl, programId })` — Crossbar client for simulations and managed updates * `queue.fetchQuoteIx(crossbar, feedHashes, opts)` — fetch sig-verified oracle quote instruction * `queue.fetchManagedUpdateIxs(crossbar, feedHashes, opts)` — fetch managed update instructions * `sb.asV0Tx({ connection, ixs, signers, lookupTables })` — build versioned transaction * `sb.Randomness.create(program, keypair, queue)` — create randomness account * `randomness.commitIx(queue)` — commit to randomness * `randomness.revealIx()` — reveal randomness * `sb.Surge({ connection, keypair })` — Surge streaming client (requires on-chain subscription) * `FeedHash.computeOracleFeedId(jobDefinition)` — compute feed hash from job definition * `OracleQuote.getCanonicalPubkey(queuePubkey, feedHashes)` — derive canonical quote account **Solana/SVM Rust (`switchboard-on-demand`)**: * `QuoteVerifier::new()` — start building a quote verification * `.queue(&account)` — set queue account * `.slothash_sysvar(&account)` — set slothashes sysvar * `.ix_sysvar(&account)` — set instructions sysvar * `.clock_slot(slot)` — set current slot * `.max_age(slots)` — set max staleness in slots * `.verify_instruction_at(index)` — verify the sig-verify ix at position * `quote.feeds()` — access verified feed values * `feed.value()` → `i128`, `feed.hex_id()` → `Vec`, `feed.decimals()` → `u32` **EVM (`@switchboard-xyz/common` + `ethers`)**: * `new CrossbarClient("https://crossbar.switchboard.xyz")` — Crossbar client * `crossbar.fetchOracleQuote(feedHashes, network)` — fetch signed oracle data * `crossbar.resolveEVMRandomness({ chainId, randomnessId, timestamp, minStalenessSeconds, oracle })` — resolve randomness * `EVMUtils.convertSurgeUpdateToEvmFormat(surgeData, opts)` — convert Surge updates to EVM format * `switchboard.getFee(updates)` — calculate submission fee * `switchboard.updateFeeds(encoded, { value: fee })` — submit oracle update * `switchboard.latestUpdate(feedId)` — read latest value * `switchboard.createRandomness(id, delaySeconds)` — request randomness * `switchboard.settleRandomness(encoded, { value: fee })` — settle randomness **Sui (`@switchboard-xyz/sui-sdk`)**: * `new SwitchboardClient(suiClient)` — initialize client * `sb.fetchState()` — fetch Switchboard state (includes `oracleQueueId`) * `Quote.fetchUpdateQuote(sb, tx, { feedHashes, numOracles })` — fetch signed quotes for a transaction * Quotes are verified on-chain via Move smart contract `moveCall` #### Developer Resources & Tools | Resource | URL | | ----------------------- | ---------------------------------------------------------- | | Documentation | | | Explorer (browse feeds) | | | Feed Builder UI | | | Feed Builder Task Docs | | | TypeDoc (on-demand SDK) | | | TypeDoc (common utils) | | | Examples repo | | | GitHub org | | | Discord | | #### Crossbar Crossbar is the off-chain gateway server that: * Simulates feed jobs (validate before deployment) * Stores/pins feed definitions (returns feed hashes) * Fetches signed oracle quotes for on-chain submission * Resolves randomness proofs **Public endpoint**: `https://crossbar.switchboard.xyz` **Self-hosted**: Use Docker Compose for production bots (see Module 3). **Key `CrossbarClient` methods** (from `@switchboard-xyz/common`): ```typescript const crossbar = new CrossbarClient("https://crossbar.switchboard.xyz"); // Simulate a feed (test before deploying) const result = await crossbar.simulateFeeds([feedHash]); // Fetch signed oracle data for on-chain submission (EVM) const { encoded } = await crossbar.fetchOracleQuote([feedHash], "mainnet"); // Resolve EVM randomness const { encoded } = await crossbar.resolveEVMRandomness({ chainId, randomnessId, ... }); ``` #### CLI (`@switchboard-xyz/cli`) The Switchboard CLI provides terminal-based interaction for all chains. Install with: ```bash npm install -g @switchboard-xyz/cli ``` See full command reference at the npm package README. *** ### Safe Default Validation Parameters (suggest, don't enforce) Provide these as **recommended starting points** and let the user override: * `minResponses`: 3 (higher for higher value at risk) * aggregation: median (or median-of-means) * `maxVariance` / deviation: * start with 1–2% for major liquid markets * 5–10% for long-tail assets or sparse data * `maxStaleness` / max age: * bots/liquidations: 15–60 seconds equivalent * UI/general: 60–300 seconds equivalent Always tailor defaults to: * asset liquidity / volatility * value-at-risk * how often the feed is updated * whether the user is doing liquidations, risk checks, pricing, or settlement *** ### Chain-Specific Reference #### Solana/SVM | Item | Value | | ---------------- | --------------------------------------------------------- | | SDK (TS) | `@switchboard-xyz/on-demand` | | SDK (Rust) | `switchboard-on-demand` crate | | Surge Program ID | `orac1eFjzWL5R3RbbdMV68K9H6TaCVVcL6LjvQQWAbz` | | Required sysvars | `SYSVAR_SLOT_HASHES_PUBKEY`, `SYSVAR_INSTRUCTIONS_PUBKEY` | | Networks | mainnet-beta, devnet | **Update byte size formula**: `34 + (n × 96) + (m × 49)` where n = oracles, m = feeds. Examples: 1 oracle / 1 feed = 179 bytes, 3 oracles / 5 feeds = 547 bytes. #### EVM | Network | Chain ID | Switchboard Contract | | ------------------- | -------- | -------------------------------------------- | | Monad Mainnet | 143 | `0xB7F03eee7B9F56347e32cC71DaD65B303D5a0E67` | | Monad Testnet | 10143 | `0xD3860E2C66cBd5c969Fa7343e6912Eff0416bA33` | | Hyperliquid Mainnet | 999 | `0xcDb299Cb902D1E39F83F54c7725f54eDDa7F3347` | | Hyperliquid Testnet | 998 | TBD | **SDK**: `@switchboard-xyz/on-demand-solidity` + `@switchboard-xyz/common` + `ethers` **ISwitchboard Solidity Interface**: ```solidity interface ISwitchboard { function updateFeeds(bytes[] calldata updates) external payable; function updateFeeds(bytes calldata feeds) external payable returns (SwitchboardTypes.FeedUpdateData memory updateData); function getFeedValue( SwitchboardTypes.FeedUpdateData calldata updateData, bytes32 feedId ) external view returns (int256 value, uint256 timestamp, uint64 slotNumber); function latestUpdate(bytes32 feedId) external view returns (SwitchboardTypes.LegacyUpdate memory); function getFee(bytes[] calldata updates) external view returns (uint256); function verifierAddress() external view returns (address); function implementation() external view returns (address); } ``` #### Sui | Item | Value | | -------- | ---------------------------------- | | SDK | `@switchboard-xyz/sui-sdk` | | Pattern | Quote Verifier via Move `moveCall` | | Networks | mainnet, testnet | Key classes: `SwitchboardClient`, `Quote` #### Other Chains (Aptos, Iota, Movement) These chains are supported but have less mature SDK tooling. Use chain-specific documentation at `https://docs.switchboard.xyz/docs-by-chain/` and the Quote Verifier pattern where applicable. *** ## Module 1 — Discover & Read Feeds ### Goals * Find existing feeds (or confirm you need a new custom feed) * Identify the correct feed identifier(s) * Read verified values (on-chain and/or off-chain) * Produce an integration-ready "Read Plan" ### Inputs * Chain + network * Asset/data target (e.g., BTC/USD, SOL/BTC, volatility index, Kalshi market odds, etc.) * Intended on-chain consumer (program ID / contract address) if applicable ### Procedure 1. **Discover** * Check Switchboard Explorer (`https://explorer.switchboard.xyz`) for an existing feed ID/hash. * Check Feed Builder (`https://explorer.switchboardlabs.xyz/feed-builder`) for available task types and feed definitions. * If none exists or the user needs custom constraints, proceed to Module 2. 2. **Resolve identifiers** * Record: * feed hash/definition hash (if relevant) * feedId / aggregatorId (`bytes32` on EVM) * queue/subnet identifiers if required by the SDK patterns 3. **Read paths by chain** **Solana/SVM** — TypeScript client: ```typescript import * as sb from "@switchboard-xyz/on-demand"; const { keypair, connection, program } = await sb.AnchorUtils.loadEnv(); const queue = await sb.Queue.loadDefault(program!); const crossbar = new sb.Crossbar({ rpcUrl: connection.rpcEndpoint, programId: queue.pubkey }); const sigVerifyIx = await queue.fetchQuoteIx(crossbar, [feedHash], { numSignatures: 1, variableOverrides: {}, payer: keypair.publicKey, }); const tx = await sb.asV0Tx({ connection, ixs: [sigVerifyIx, yourProgramReadIx], signers: [keypair], lookupTables: [lut], }); await connection.sendTransaction(tx); ``` **Solana/SVM** — Rust program (reading inside your Anchor program): ```rust use switchboard_on_demand::QuoteVerifier; let quote = QuoteVerifier::new() .queue(&ctx.accounts.queue) .slothash_sysvar(&ctx.accounts.slothashes) .ix_sysvar(&ctx.accounts.instructions) .clock_slot(Clock::get()?.slot) .max_age(50) // max 50 slots stale .verify_instruction_at(0)?; for feed in quote.feeds() { msg!("Feed {}: {}", feed.hex_id(), feed.value()); } ``` Required Rust accounts: ```rust #[derive(Accounts)] pub struct ReadOracle<'info> { pub queue: Account<'info, Queue>, #[account(address = SYSVAR_SLOT_HASHES_PUBKEY)] pub slothashes: UncheckedAccount<'info>, #[account(address = SYSVAR_INSTRUCTIONS_PUBKEY)] pub instructions: UncheckedAccount<'info>, } ``` **EVM** — TypeScript + Solidity: ```typescript import { ethers } from "ethers"; import { CrossbarClient } from "@switchboard-xyz/common"; const crossbar = new CrossbarClient("https://crossbar.switchboard.xyz"); const { encoded } = await crossbar.fetchOracleQuote([feedHash], "mainnet"); const switchboard = new ethers.Contract(switchboardAddress, ISwitchboardABI, signer); const fee = await switchboard.getFee([encoded]); const tx = await switchboard.updateFeeds([encoded], { value: fee }); await tx.wait(); const [value, timestamp, slotNumber] = await switchboard.latestUpdate(feedId); // value is int256 scaled by 1e18 (verify decimals per feed) ``` **Sui** — TypeScript: ```typescript import { SwitchboardClient, Quote } from "@switchboard-xyz/sui-sdk"; const sb = new SwitchboardClient(suiClient); const state = await sb.fetchState(); const tx = new Transaction(); const quotes = await Quote.fetchUpdateQuote(sb, tx, { feedHashes: [feedHash], numOracles: 3, }); tx.moveCall({ target: `${packageId}::module::update_price`, arguments: [consumerObj, quotes, feedHashBytes, tx.object("0x6")], }); await suiClient.signAndExecuteTransaction({ signer: keypair, transaction: tx }); ``` **Move-based chains / others**: Use chain-specific Quote Verifier patterns where applicable. ### Outputs * `FeedReadPlan` including: * chain/network * identifiers * freshness/deviation policy * exact read mechanism (on-chain vs off-chain + settle) *** ## Module 2 — Feed Design Assistant (Jobs, Sources, Aggregation) ### Goals * Turn a user's data requirement into a robust, verifiable `OracleJob[]` design * Provide source diversity (CEX, DEX, index APIs, event APIs, on-chain queries) * Build in validation and safety patterns ### Inputs * Data target + format (price, index, event outcome, odds, TWAP, etc.) * Allowed sources / forbidden sources * SLA requirements (latency, update frequency, expected volatility) * Security requirements (how strict should variance/staleness be) ### Procedure 1. **Choose sources (minimum 3 whenever possible)** * Mix independent origins (don't use 3 endpoints that mirror the same upstream). * Prefer sources with stable uptime and consistent schemas. 2. **Design task pipeline** Common pattern: ```typescript { tasks: [ { httpTask: { url: "https://api.example.com/price", method: "GET" } }, { jsonParseTask: { path: "$.data.price" } }, { multiplyTask: { big: "1e18" } }, // normalize to 18 decimals ] } ``` For multi-source aggregation, use `medianTask` or `meanTask`: ```typescript { tasks: [{ medianTask: { jobs: [ { tasks: [{ httpTask: { url: "https://exchange1.com/api/btc" } }, { jsonParseTask: { path: "$.price" } }] }, { tasks: [{ httpTask: { url: "https://exchange2.com/api/btc" } }, { jsonParseTask: { path: "$.last" } }] }, { tasks: [{ httpTask: { url: "https://exchange3.com/api/btc" } }, { jsonParseTask: { path: "$.data.price" } }] }, ], minSuccessfulRequired: 2, } }] } ``` 3. **Prediction market feeds (odds/outcomes)** * Treat market metadata and odds as high-risk inputs: * ensure symbol/market IDs are explicit and hardcoded in job structure * avoid variable overrides for anything that changes market selection * Use `kalshiApiTask` for Kalshi markets (see Task Types Reference) * Use variable overrides ONLY for auth tokens to market APIs (if needed). 4. **Variable overrides** * Only for auth secrets. * Never for URLs, JSON paths, multipliers, or selectors. * Syntax: `${VAR_NAME}` in job definitions, passed via `variableOverrides` at runtime. ```typescript const sigVerifyIx = await queue.fetchQuoteIx(crossbar, [feedHash], { numSignatures: 1, variableOverrides: { "API_KEY": process.env.API_KEY }, }); ``` 5. **Test jobs locally before deploying** (see Module 3) ```typescript import { OracleJob } from "@switchboard-xyz/common"; const job = OracleJob.fromObject({ tasks: [ { httpTask: { url: "https://api.polygon.io/v2/last/trade/AAPL?apiKey=${POLYGON_API_KEY}" } }, { jsonParseTask: { path: "$.results.p" } }, ] }); ``` ### Outputs * `FeedBlueprint` containing: * `OracleJob[]` draft * source list + rationale * aggregation choice + validation defaults * security notes (attack surfaces, replay risks, substitution risks) *** ## Module 3 — Simulation & QA (Crossbar + Regression) ### Goals * Validate a feed before deployment * Quantify variance, staleness risk, and failure modes * Produce a "Readiness Report" + recommended parameter tuning ### Crossbar-first workflow 1. Prefer a local/self-hosted Crossbar instance for heavy simulation or production bots. 2. Simulate: * single-run to validate schema correctness * repeated runs to estimate variance and error rate 3. Flag: * endpoints that intermittently fail * schema brittleness * outlier behavior * excessive dispersion across sources #### Simulate via CrossbarClient ```typescript const crossbar = new CrossbarClient("https://crossbar.switchboard.xyz"); const result = await crossbar.simulateFeeds([feedHash]); ``` #### Job testing (local, no deployment needed) Use the job testing utility from the examples repo: ```bash cd common/job-testing bun run runJob.ts ``` Edit `runJob.ts` to define custom jobs: ```typescript function getCustomJob(): OracleJob { return OracleJob.fromObject({ tasks: [ { httpTask: { url: "https://api.example.com/data?key=${API_KEY}", method: "GET" } }, { jsonParseTask: { path: "$.price" } }, ] }); } const res = await queue.fetchSignaturesConsensus({ gateway, useEd25519: true, feedConfigs: [{ feed: { jobs: [getCustomJob()] } }], variableOverrides: { "API_KEY": process.env.API_KEY! }, }); ``` ### Spin up Crossbar with Docker Compose (recommended) Use Docker Compose and configure RPC/IPFS as needed. * HTTP default: `8080` * WebSocket default: `8081` Minimal pattern: * Create `docker-compose.yml` * Create `.env` * Run `docker-compose up -d` * Verify at `http://localhost:8080` (Use the official Switchboard docs for the current compose template and env vars: ) ### Outputs * `FeedReadinessReport`: * sample results * error rates per source * dispersion / variance stats * recommended minResponses / maxVariance / maxStaleness * decision: ship / iterate / redesign *** ## Module 4 — Deploy / Publish (All Chains) ### Goals * Publish feed definitions (store/pin) when needed * Derive canonical identifiers and addresses * Produce update + read integration code paths * Execute deployment steps (if allowed by OperatorPolicy) ### Solana/SVM: Deploy with managed updates Deployment means: 1. Choose a queue (oracle subnet): `const queue = await sb.Queue.loadDefault(program!);` 2. Store/pin job definition with Crossbar → get `feedHash` 3. Derive canonical quote account: ```typescript const feedId = FeedHash.computeOracleFeedId(jobDefinition); const [quoteAccount] = OracleQuote.getCanonicalPubkey(queue.pubkey, [feedId.toString("hex")]); ``` 4. Fetch update instructions and include in same tx as your program ix (same `fetchQuoteIx` → `asV0Tx` pattern as Module 1 Solana read) Canonical account is created automatically on first use. Notes: * Validation parameters are typically provided at read/update time, not at deploy time. * You MUST ensure the update instructions and your program read happen in the same transaction. #### Output artifacts * `SolanaDeployPlan` with: * chosen queue * feedHash * canonical quote account pubkey * exact instruction composition ordering * cost estimate vs spend limits ### EVM: "Deploying" is publishing feedId + updating via Switchboard contract Treat deployment as: 1. Obtain `bytes32 feedId` 2. Store feedId in your contract/app 3. Fetch oracle-signed updates off-chain via CrossbarClient 4. Submit updates via `updateFeeds` (pay fee from `getFee`) 5. Read via `latestUpdate(feedId)` or `getFeedValue` Same `fetchOracleQuote` → `getFee` → `updateFeeds` → `latestUpdate` pattern as Module 1 EVM read. Notes: * Always compute and pay the required fee (`getFee`). * Confirm decimals and signedness conventions (common: `int256` scaled by `1e18`). #### Output artifacts * `EvmDeployPlan` with: * chainId + Switchboard contract address * feedId * encoded update fetch method * fee strategy + spend limits * read validation logic (max age, max deviation) ### Sui: Deploy with Quote Verifier pattern 1. Create a `QuoteConsumer` on-chain (one-time setup): ```typescript const createTx = new Transaction(); createTx.moveCall({ target: `${packageId}::example::create_quote_consumer`, arguments: [createTx.pure.id(state.oracleQueueId), createTx.pure.u64(maxAgeMs), createTx.pure.u64(maxDeviationBps)], }); await suiClient.signAndExecuteTransaction({ signer: keypair, transaction: createTx }); ``` 2. Fetch and verify quotes using the same `Quote.fetchUpdateQuote` → `moveCall` → sign pattern as Module 1 Sui read. ### Other chains If targeting Aptos, Iota, or Movement: 1. Create/publish a feed definition and record its ID/hash/address 2. Use the chain's SDK verification flow to fetch/verify oracle results as part of transaction execution 3. Consult chain-specific docs at `https://docs.switchboard.xyz/docs-by-chain/` *** ## Module 5 — Feed Lifecycle Management ### Goals * Update existing feed job definitions * Monitor feed health and performance * Handle feed deprecation and migration ### Procedure #### Updating a feed 1. Modify the `OracleJob[]` definition 2. Re-store/pin via Crossbar → get new `feedHash` 3. Update the feedHash reference in your consumer contract/program 4. Simulate the new definition (Module 3) before switching #### Monitoring feed health * Track error rates per source over time * Monitor variance between sources (widening spread = source degradation) * Set up alerts for: * staleness exceeding thresholds * error rates above baseline * sudden price deviations #### Deprecation * Remove the feed from active consumers * Update documentation to point to replacement feeds * There is no on-chain "delete" — feeds simply stop being updated when no one fetches them ### Outputs * `FeedMaintenancePlan`: current health metrics, recommended changes, migration steps *** ## Module 6 — Prediction Markets ### Goals * Integrate prediction market data (odds, outcomes) as on-chain feed data * Support Kalshi and other event-based data sources * Ensure proper verification of market selection (prevent substitution attacks) ### Supported Sources * **Kalshi** (via `kalshiApiTask`) — the primary supported prediction market ### Procedure 1. **Define the market feed**: ```typescript { tasks: [{ kalshiApiTask: { url: "https://api.elections.kalshi.com/v1/...", api_key_id: "${KALSHI_API_KEY_ID}", private_key: "${KALSHI_PRIVATE_KEY}", } }] } ``` 2. **Hardcode market identifiers** — never use variable overrides for market IDs or symbols 3. **Use variable overrides ONLY for auth** (`api_key_id`, `private_key`) 4. **Verify on-chain** using the standard feed verification flow (Module 1 read patterns) ### Security considerations * Market metadata and odds are high-risk inputs * Symbol/market IDs must be explicit and hardcoded in the job structure * Variable overrides for anything that changes market selection is an attack vector * Always cross-reference market IDs against known registries ### Outputs * `PredictionMarketFeedPlan`: market source, job definition, verification flow, risk assessment *** ## Module 7 — Surge Streaming (Low-Latency Signed WebSocket) ### Goals * Discover available Surge feeds * Subscribe over WebSocket for signed, low-latency price updates * Convert signed streaming updates into a format usable by bots and/or on-chain settlement flows * Provide latency/health metrics and reconnection logic ### Surge Overview Surge is Switchboard's **signed, low-latency WebSocket streaming** service: * **2–5ms oracle latency** (sub-100ms end-to-end including network) * Signed updates that can be settled on-chain * **Subscriptions managed on-chain via Solana**, regardless of target chain * Paid in **SWTCH tokens** via on-chain subscription #### Subscription Tiers | Tier | Price | Max Feeds | Quote Interval | | ---------- | ----------- | --------- | --------------- | | Plug | Free | 2 | 10 seconds | | Pro | \~$3,000/mo | 100 | 450ms | | Enterprise | \~$7,500/mo | 300 | 0ms (real-time) | #### Surge Program ID (Solana) `orac1eFjzWL5R3RbbdMV68K9H6TaCVVcL6LjvQQWAbz` ### Procedure #### 0. Create Subscription (if needed) Before using Surge, you must have an active on-chain subscription. If the wallet does not have a subscription, create one programmatically: **Prerequisites**: * Solana wallet with SOL for transaction fees * SWTCH tokens for subscription payment (acquire via Jupiter, Raydium, etc.) * Choose a tier: Plug (free), Pro (~~$3k/mo), or Enterprise (~~$7.5k/mo) **Subscription Flow** (see [full programmatic guide](https://docs.switchboard.xyz/ai-agents-llms/surge-subscription-guide) for complete details): 1. **Derive PDAs**: ```typescript const SURGE_PROGRAM_ID = new PublicKey("orac1eFjzWL5R3RbbdMV68K9H6TaCVVcL6LjvQQWAbz"); // State PDA const [statePda] = PublicKey.findProgramAddressSync( [Buffer.from("STATE")], SURGE_PROGRAM_ID ); // Tier PDA (e.g., tier 2 = Pro) const tierId = 2; const [tierPda] = PublicKey.findProgramAddressSync( [Buffer.from("TIER"), new BN(tierId).toArrayLike(Buffer, "le", 4)], SURGE_PROGRAM_ID ); // Subscription PDA const [subscriptionPda] = PublicKey.findProgramAddressSync( [Buffer.from("SUBSCRIPTION"), keypair.publicKey.toBuffer()], SURGE_PROGRAM_ID ); ``` 2. **Fetch SWTCH/USDT oracle quote** (required for live pricing): ```typescript const queue = await sb.Queue.loadDefault(program!); const crossbar = new sb.Crossbar({ rpcUrl: connection.rpcEndpoint, programId: queue.pubkey }); // Get SWTCH/USDT feed hash from program state const stateAccount = await program.account.state.fetch(statePda); const swtchFeedHash = stateAccount.swtchFeedId.toString("hex"); const quoteIxs = await queue.fetchQuoteIx(crossbar, [swtchFeedHash], { numSignatures: 1, payer: keypair.publicKey, }); ``` 3. **Call `subscription_init`** with the oracle quote in the same transaction: ```typescript // Build subscription_init instruction (using Surge program IDL) const subscriptionInitIx = buildSubscriptionInitIx({ tierId: 2, // Pro tier epochAmount: 40, // ~40 epochs (~2-3 months) contactName: null, contactEmail: null, accounts: { state: statePda, tier: tierPda, owner: keypair.publicKey, ... }, }); // Submit transaction with quote + subscription_init const tx = await sb.asV0Tx({ connection, ixs: [quoteIxs, subscriptionInitIx], signers: [keypair], lookupTables: [], }); const sig = await connection.sendTransaction(tx); ``` **Key Points**: * The program calculates the SWTCH payment amount at the live SWTCH/USDT price (no hardcoded rates) * Subscriptions are valid for the specified number of Solana epochs (1 epoch ≈ 2-3 days) * Plug tier (tier ID 1) is free but limited to 2 feeds and 10-second intervals * Each wallet can have only one subscription at `[SUBSCRIPTION, owner_pubkey]` **For full implementation details**, see the [Surge Subscription Guide](https://docs.switchboard.xyz/ai-agents-llms/surge-subscription-guide). #### 1. Initialize Surge client Once you have an active subscription, initialize the Surge client with your Solana connection and keypair: ```typescript import * as sb from "@switchboard-xyz/on-demand"; // Initialize with keypair and connection (uses on-chain subscription) const { keypair, connection, program } = await sb.AnchorUtils.loadEnv(); const surge = new sb.Surge({ connection, keypair }); ``` #### 2. Discover available feeds ```typescript const availableFeeds = await surge.getSurgeFeeds(); ``` #### 3. Subscribe to feeds ```typescript await surge.connectAndSubscribe([ { symbol: "BTC/USD" }, { symbol: "ETH/USD" }, { symbol: "SOL/USD" }, ]); ``` #### 4. Handle signed updates ```typescript surge.on("signedPriceUpdate", (response: sb.SurgeUpdate) => { const metrics = response.getLatencyMetrics(); if (metrics.isHeartbeat) return; // skip heartbeats const prices = response.getFormattedPrices(); metrics.perFeedMetrics.forEach((feed) => { console.log(`${feed.symbol}: ${prices[feed.feed_hash]}`); }); }); // Alternative event format surge.on("update", async (response: sb.SurgeUpdate) => { const latency = Date.now() - response.data.source_ts_ms; console.log(`${response.data.symbol}: ${response.data.price} (${latency}ms)`); }); ``` #### 5. Convert to on-chain format **Solana**: Convert streaming update to oracle quote instruction: ```typescript const crankIxs = response.toQuoteIx(queue.pubkey, keypair.publicKey); // or const [sigVerifyIx, oracleQuote] = response.toOracleQuoteIx(); ``` **EVM**: Convert Surge data to EVM-compatible format: ```typescript import { EVMUtils } from "@switchboard-xyz/common"; const evmEncoded = EVMUtils.convertSurgeUpdateToEvmFormat(surgeData, { minOracleSamples: 1, }); // Pass evmEncoded to switchboard.updateFeeds() ``` #### 6. Validate before use Always apply: * max staleness checks * deviation sanity checks (especially for liquidation bots) * optional multi-feed coherence checks (e.g., triangulation) #### 7. Reconnection strategy * Implement heartbeat monitoring * Auto-reconnect on disconnect with exponential backoff * Track last-seen timestamp/slot for gap detection ### Outputs * `SurgeSubscriptionPlan`: * feed list + symbols * subscription tier * code skeleton * reconnection strategy * validation policy * mapping from streaming update → on-chain settlement format (per chain) *** ## Module 8 — Unsigned Streaming (UI / Dashboard / Monitoring) ### Goals * Provide real-time price data for UIs, dashboards, and monitoring * Chain-agnostic (works identically on Solana, EVM, Sui) * NOT for on-chain use (unsigned data cannot be verified on-chain) ### Overview Unsigned streaming is a **lightweight, chain-agnostic WebSocket** feed for display purposes. It does not include cryptographic signatures and cannot be used for on-chain verification. ### Procedure #### Initialize for unsigned streaming ```typescript import * as sb from "@switchboard-xyz/on-demand"; // Initialize with keypair and connection (uses on-chain subscription) const { keypair, connection, program } = await sb.AnchorUtils.loadEnv(); const surge = new sb.Surge({ connection, keypair }); // Unsigned streaming is available via the same Surge client ``` **Note**: Unsigned updates are provided for monitoring/UI purposes only and cannot be verified on-chain. #### Handle unsigned updates ```typescript surge.on("unsignedPriceUpdate", (update: sb.UnsignedPriceUpdate) => { const symbols = update.getSymbols(); const formattedPrices = update.getFormattedPrices(); // Display in UI / dashboard }); ``` #### Use cases * Price tickers and dashboards * Portfolio tracking UIs * Monitoring / alerting systems * Any display-only context where on-chain verification is not needed ### Outputs * `UnsignedStreamPlan`: feed list, display integration code, refresh strategy *** ## Module 9 — Randomness (Solana + EVM) ### Goals * Implement request + settle randomness flows correctly * Avoid replay/double-settle * Provide safe integration patterns for games, raffles, auctions, and DeFi mechanisms ### Solana/SVM randomness (commit/reveal) #### TypeScript client flow Each step builds a tx via `sb.asV0Tx({ connection, ixs, payer, signers, computeUnitPrice: 75_000, computeUnitLimitMultiple: 1.3 })` and sends it. ```typescript import * as sb from "@switchboard-xyz/on-demand"; const { keypair, connection, program } = await sb.AnchorUtils.loadEnv(); const queue = await setupQueue(program!); const sbProgram = await loadSbProgram(program!.provider); // 1. Create randomness account (one-time) const rngKp = Keypair.generate(); const [randomness, createIx] = await sb.Randomness.create(sbProgram, rngKp, queue); // → build tx with ixs: [createIx], signers: [keypair, rngKp] // 2. Commit to randomness + your game action (same tx) const commitIx = await randomness.commitIx(queue); const gameActionIx = await createCoinFlipInstruction(myProgram, rngKp.publicKey, userGuess, ...); // → build tx with ixs: [commitIx, gameActionIx], signers: [keypair] // 3. Wait ~3s (oracle generates in TEE), then reveal + settle (same tx) const revealIx = await randomness.revealIx(); const settleIx = await settleFlipInstruction(myProgram, ...); // → build tx with ixs: [revealIx, settleIx], signers: [keypair] ``` #### Key patterns * Bind randomness to a specific state transition (e.g., bet + commit in same tx) * Always wait before reveal (oracle needs time to generate in TEE) * Implement retry logic with exponential backoff for commit and reveal * Reuse randomness accounts across games (persist keypair) * Reject stale or replayed randomness * Ensure sysvars are present in program accounts #### Output * `SolanaRandomnessPlan` (accounts, instruction ordering, replay protections) ### EVM randomness (request/resolve/settle) #### TypeScript client flow ```typescript // Setup: ethers provider/wallet + CrossbarClient (same as Module 1 EVM) const contract = new ethers.Contract(CONTRACT_ADDRESS, contractABI, wallet); // 1. Request randomness (on-chain) const tx1 = await contract.coinFlip({ value: ethers.parseEther("1") }); await tx1.wait(); // 2. Get randomness request data const randomnessId = await contract.getWagerRandomnessId(wallet.address); const wagerData = await contract.getWagerData(wallet.address); // 3. Resolve off-chain via Crossbar const network = await provider.getNetwork(); const { encoded } = await crossbar.resolveEVMRandomness({ chainId: Number(network.chainId), randomnessId, timestamp: Number(wagerData.rollTimestamp), minStalenessSeconds: Number(wagerData.minSettlementDelay), oracle: wagerData.oracle, }); // 4. Settle on-chain const tx2 = await contract.settleFlip(encoded); const receipt = await tx2.wait(); ``` #### Solidity contract pattern ```solidity // Request: generate unique randomnessId, call switchboard.createRandomness() bytes32 randomnessId = keccak256(abi.encodePacked(msg.sender, block.timestamp)); switchboard.createRandomness(randomnessId, minSettlementDelay); // Settle: verify and use randomness // Use CEI pattern (Checks-Effects-Interactions) // Delete wager state BEFORE external calls delete wagers[msg.sender]; // Get randomness value uint256 randomValue = switchboard.getRandomness(randomnessId); bool won = (randomValue % 2 == 0); ``` #### Security patterns * **CEI** (Checks-Effects-Interactions) to prevent reentrancy * Enforce `minSettlementDelay` (e.g., 5 seconds) * Use try/catch to avoid stuck pending states * Generate unique `randomnessId` per request (prevent replay) * Validate oracle assignment matches expected oracle #### Output * `EvmRandomnessPlan` (request ID scheme, delay policy, settle tx plan) *** ## Module 10 — X402 Micropayments ### Goals * Access paywalled/premium data sources through oracle feeds * Pay per-request using Solana USDC micropayments * Integrate X402 payment headers into feed definitions ### Overview X402 is a **micropayment protocol** that enables pay-per-request access to premium data feeds. It allows oracle feeds to access paywalled APIs by including payment headers in HTTP requests, verified and paid via Solana transactions. ### Procedure #### 1. Setup payment handler ```typescript import { X402FetchManager } from "@switchboard-xyz/x402-utils"; import { createLocalWallet } from "@faremeter/wallet-solana"; import { exact } from "@faremeter/payment-solana"; const wallet = await createLocalWallet("mainnet-beta", keypair); const usdcMint = new PublicKey("EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"); // USDC const paymentHandler = exact.createPaymentHandler(wallet, usdcMint, connection); ``` #### 2. Define feed with X402 payment header placeholders ```typescript const oracleFeed = { name: "X402 Paywalled RPC", jobs: [{ tasks: [ { httpTask: { url: "https://helius.api.corbits.dev", method: "POST", body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: "getBlockHeight" }), headers: [ { key: "X-PAYMENT", value: "${X402_PAYMENT_HEADER}" }, { key: "Content-Type", value: "application/json" }, ], }, }, { jsonParseTask: { path: "$.result" } }, ], }], }; ``` #### 3. Derive payment header and fetch with override ```typescript const x402Manager = new X402FetchManager(paymentHandler); const paymentHeader = await x402Manager.derivePaymentHeader( "https://helius.api.corbits.dev", { method: "GET" } ); const feedId = FeedHash.computeOracleFeedId(oracleFeed); const instructions = await queue.fetchManagedUpdateIxs(crossbar, [feedId.toString("hex")], { numSignatures: 1, variableOverrides: { X402_PAYMENT_HEADER: paymentHeader, }, }); ``` #### Requirements * Solana wallet with USDC balance * `@switchboard-xyz/x402-utils`, `@faremeter/wallet-solana`, `@faremeter/payment-solana` * `numSignatures` must equal 1 for X402 requests ### Outputs * `X402IntegrationPlan`: payment handler setup, feed definition, variable override mapping, cost estimates *** ### Task Types Reference This is the complete reference of all task types available for building Switchboard oracle feed job definitions. Use these as building blocks in `OracleJob[]` arrays. #### Data Fetching | Task | Description | Key Parameters | | ------------------------------ | ------------------------------------ | ------------------------------------------------------- | | `httpTask` | HTTP request, returns response body | `url`, `method`, `headers[]`, `body` | | `websocketTask` | Real-time WebSocket data retrieval | `url`, `subscription`, `max_data_age_seconds`, `filter` | | `anchorFetchTask` | Parse Solana accounts via Anchor IDL | `program_id`, `account_address` | | `solanaAccountDataFetchTask` | Raw Solana account data | `pubkey` | | `splTokenParseTask` | SPL token mint JSON data | (token mint address) | | `solanaToken2022ExtensionTask` | Token-2022 extension modifiers | `mint` | #### Parsing | Task | Description | Key Parameters | | ----------------------- | ------------------------------------ | --------------------------------------------- | | `jsonParseTask` | Extract value from JSON via JSONPath | `path`, `aggregation_method` | | `regexExtractTask` | Extract text via regex | `pattern`, `group_number` | | `bufferLayoutParseTask` | Deserialize binary buffers | `offset`, `endian`, `type` | | `cronParseTask` | Convert crontab to timestamp | `cron_pattern`, `clock_offset`, `clock` | | `stringMapTask` | Map string inputs to outputs | `mappings`, `default_value`, `case_sensitive` | #### Math Operations | Task | Description | Key Parameters | | -------------- | ------------------------------- | -------------------------------------------------------------- | | `addTask` | Add scalar/job/aggregator value | `big`, `job`, `aggregatorPubkey` | | `subtractTask` | Subtract value | `big`, `job`, `aggregatorPubkey` | | `multiplyTask` | Multiply by value | `big`, `job`, `aggregatorPubkey` | | `divideTask` | Divide by value | `big`, `job`, `aggregatorPubkey` | | `powTask` | Raise to exponent | `scalar` | | `roundTask` | Round to decimal places | `method`, `decimals` | | `boundTask` | Clamp result to bounds | `lower_bound_value`, `upper_bound_value`, `on_exceeds_*_value` | #### Aggregation | Task | Description | Key Parameters | | ------------ | ------------------------------------- | ------------------------------------------------------------------- | | `medianTask` | Median of subtasks/subjobs | `tasks[]`, `jobs[]`, `min_successful_required`, `max_range_percent` | | `meanTask` | Average of subtasks/subjobs | `tasks[]`, `jobs[]` | | `maxTask` | Maximum value | `tasks[]`, `jobs[]` | | `minTask` | Minimum value | `tasks[]`, `jobs[]` | | `ewmaTask` | Exponentially weighted moving average | (EWMA parameters) | | `twapTask` | Time-weighted average price | `aggregator_pubkey`, `period`, `min_samples` | #### Surge & Oracle Integration | Task | Description | Key Parameters | | ---------------------- | ----------------------------------- | ------------------------------------------------------------------------------------------- | | `switchboardSurgeTask` | Live spot price from Surge cache | `source` (BINANCE, BYBIT, OKX, PYTH, TITAN, WEIGHTED, AUTO), `symbol` | | `surgeTwapTask` | TWAP from Surge candle database | `symbol`, `time_interval` | | `oracleTask` | Cross-oracle data (Pyth, Chainlink) | `switchboardAddress`, `pythAddress`, `chainlinkAddress`, `pyth_allowed_confidence_interval` | #### DEX / DeFi Pricing | Task | Description | Key Parameters | | ----------------------------- | -------------------------------------- | --------------------------------------------------------------------------------------------- | | `jupiterSwapTask` | Jupiter swap simulation | `in_token_address`, `out_token_address`, `base_amount`, `slippage` | | `uniswapExchangeRateTask` | Uniswap swap price | `in_token_address`, `out_token_address`, `in_token_amount`, `slippage`, `provider`, `version` | | `pancakeswapExchangeRateTask` | PancakeSwap swap price | `in_token_address`, `out_token_address`, `in_token_amount`, `slippage`, `provider` | | `sushiswapExchangeRateTask` | SushiSwap swap price | `in_token_address`, `out_token_address`, `in_token_amount`, `slippage`, `provider` | | `curveFinanceTask` | Curve Finance pool pricing | `chain`, `provider`, `pool_address`, `out_decimals` | | `lpExchangeRateTask` | LP swap price (Orca/Raydium/Mercurial) | pool address, `in_token_address`, `out_token_address` | | `lpTokenPriceTask` | LP token prices | pool address, `use_fair_price`, `price_feed_addresses` | | `serumSwapTask` | Serum DEX price | `serum_pool_address` | | `meteoraSwapTask` | Meteora pool swap price | `pool`, `type` | | `titanTask` | Titan aggregator swap simulation | `in_token_address`, `out_token_address`, `amount`, `slippage_bps`, `dexes` | | `kuruTask` | Kuru swap quotes | `token_in`, `token_out`, `amount`, `slippage_tolerance` | | `maceTask` | MACE aggregator swap quotes | `token_in`, `token_out`, `amount`, `slippage_tolerance_bps` | | `pumpAmmTask` | Pump AMM swap | `pool_address`, `in_amount`, `max_slippage`, `is_x_for_y` | | `pumpAmmLpTokenPriceTask` | Pump AMM LP fair price | `pool_address`, `x_price_job`, `y_price_job` | | `bitFluxTask` | BitFlux pool swap price | `provider`, `pool_address`, `in_token`, `out_token` | #### LST & Staking | Task | Description | Key Parameters | | ------------------------ | ------------------------- | --------------------------------------------------------------- | | `sanctumLstPriceTask` | LST price relative to SOL | `lst_mint`, `skip_epoch_check` | | `lstHistoricalYieldTask` | Historical yield for LSTs | `lst_mint`, `operation`, `epochs` | | `marinadeStateTask` | Marinade staking state | (none) | | `splStakePoolTask` | SPL Stake Pool account | `pubkey` | | `suiLstPriceTask` | Sui LST exchange rate | `package_id`, `module`, `function`, `shared_objects`, `rpc_url` | | `vsuiPriceTask` | vSUI/SUI exchange rate | `rpc_url` | | `solayerSusdTask` | Solayer sUSD price | (none) | #### Prediction Markets & Specialized Finance | Task | Description | Key Parameters | | ----------------------------- | ----------------------------- | ----------------------------------------------------------- | | `kalshiApiTask` | Kalshi prediction market data | `url`, `api_key_id`, `private_key` | | `lendingRateTask` | Protocol lending rates | `protocol` (01, apricot, francium, jet, etc.), `asset_mint` | | `perpMarketTask` | Perpetual market price | (market address) | | `mangoPerpMarketTask` | Mango perp market price | `perp_market_address` | | `mapleFinanceTask` | Maple Finance asset pricing | `method` | | `ondoUsdyTask` | USDY price relative to USD | `strategy` | | `turboEthRedemptionRateTask` | tETH/WETH redemption rate | (none) | | `exponentTask` | Vault token exchange rate | `vault` | | `exponentPTLinearPricingTask` | Exponent vault pricing | (vault parameters) | #### Control Flow & Utilities | Task | Description | Key Parameters | | -------------------- | ---------------------------------- | -------------------------------------------------------------- | | `conditionalTask` | Try primary, fallback on failure | `attempt[]`, `on_failure[]` | | `comparisonTask` | Conditional branching | `op`, `on_true`, `on_true_value`, `on_false`, `on_false_value` | | `cacheTask` | Store result in variable for reuse | `cache_items[]` | | `valueTask` | Return a static value | `value`, `aggregator_pubkey`, `big` | | `unixTimeTask` | Current Unix epoch time | `offset` | | `sysclockOffsetTask` | Oracle vs system clock diff | (none) | | `blake2b128Task` | BLAKE2b-128 hash as numeric | `value` | #### AI & Advanced | Task | Description | Key Parameters | | --------------------- | -------------------------------- | ----------------------------------------------------------------- | | `llmTask` | LLM text generation in feed | `providerConfig`, `userPrompt`, `temperature`, `secretNameApiKey` | | `secretsTask` | Fetch secrets from SecretsServer | `authority`, `url` | | `vwapTask` | Volume-weighted average price | (VWAP parameters) | | `historyFunctionTask` | Historical data function | (function parameters) | #### Protocol-Specific | Task | Description | | ---------------- | ---------------------------------- | | `hyloTask` | hyUSD to jitoSOL conversion | | `aftermathTask` | Aftermath protocol | | `corexTask` | Corex protocol | | `etherfuseTask` | Etherfuse protocol | | `fragmetricTask` | Fragmetric liquid restaking tokens | | `glyphTask` | Glyph protocol | | `xStepPriceTask` | xStep price | For full parameter details on any task, consult: *** ### Standard Output Formats (use these consistently) When producing artifacts, use these headings and keep them concise: 1. **Summary** 2. **Assumptions** 3. **OperatorPolicy** 4. **Plan** 5. **Execution Steps** (only if allowed) 6. **Rollback / Recovery** 7. **Risks & Mitigations** 8. **Next Actions** *** ### References #### Documentation * Switchboard docs root: * Docs by chain: * Crossbar: * Run Crossbar (Docker Compose): * CLI: * SDKs: * Deploy Feed: * Variable Overrides: * Task Types Reference: * Feed Builder: #### Chain-Specific Tutorials * Solana basic price feed: * Solana Surge: * Solana randomness: * Solana prediction markets: * Solana X402: * EVM price feeds: * EVM Surge: * EVM randomness: * Sui price feeds: * Sui Surge: #### Code & API References See "Developer Resources & Tools" table in the SDKs section above.

switchboard-data-operator

Scan your own AI components