Switchboard Feed Design Skill
Purpose
Turn a data requirement into a robust, verifiable feed definition:
Design
OracleJob[]pipelines with stable parsing and source diversityNormalize scaling/decimals consistently
Choose aggregation strategy and consumer validation policy defaults
Identify and mitigate substitution, outliers, and schema brittleness risks
Dependencies
Use exact pins from the SDK Version Matrix.
@switchboard-xyz/[email protected]
This skill designs feed definitions. Integration details (atomic update+use, on-chain verifier patterns) belong to chain-specific skills.
Preconditions
OperatorPolicyexists (especially if paid APIs, X402, or job storage is involved).
Inputs to Collect
Required:
target metric (price/index/rate/event outcome) and units
target chain(s) and consumer type (how the value will be used)
value-at-risk / criticality (UI display vs liquidation vs settlement)
allowed/forbidden sources
required secrets (API keys, auth headers, payment headers)
Optional (only if relevant):
expected request frequency / external API rate limits
This matters if the user plans to run a crank/keeper or high-frequency bots.
On-demand does not impose a cadence by itself, but your infrastructure and upstream APIs still do.
Security Invariants
Variable overrides are secrets-only.
Hardcode market IDs, selectors, URLs, JSON paths, multipliers in the job definition.
Prefer 3+ independent sources when possible.
Minimal Example
Playbook
1) Specify output contract
Define:
numeric scaling (e.g., 1e18)
signedness (allow negative or not)
bounds and failure mode (reject vs clamp)
2) Choose sources
diversify upstream origins (avoid mirrored endpoints)
prefer reliable schemas with stable versioning
add at least one fallback source where possible
commonly used free spot APIs (availability varies by region): Binance, Coinbase, Kraken, Bitstamp, OKX
3) Production templates
Template 1: Single source (tutorial baseline)
Template 2: 3-source median (production minimum, 2 of 3 required)
Template 3: 5-source with fallback tolerance (production recommended)
Template 4: Custom API with auth headers (variable override pattern)
Variable override rule reminder:
only use
${...}for auth credentials (keys/tokens)never use
${...}for URLs, paths, symbols, multipliers, or selection logic
4) Error handling and rate limiting
set
min_successful_requiredso one source outage does not break updates (for example 2-of-3, 3-of-5)set
max_range_percentfor drift/outlier protection before median is acceptedstagger polling and cap request rate to provider quotas (especially free tiers)
back off exponentially on HTTP 429/5xx and keep at least 3 independent sources
5) Recommended Validation Defaults (suggest, don’t enforce)
These are primarily consumer policy defaults (freshness/deviation) and oracle sample requirements (responses/signatures) that you apply when verifying/using the feed.
Start from
OperatorPolicypresets in the top-level Switchboard Skill, then tune per feed risk and volatility.minResponses/minSampleSize: 3 for higher-risk flows; 1 for dev/non-criticalaggregation: median (or median-of-means where supported)
deviation:
majors: 100–200 bps for high-risk flows; ~500 bps for standard flows
long-tail / volatile: wider deviation may be needed as an explicit override from preset defaults
staleness:
bots/liquidations: 15–60 seconds (or chain-equivalent)
UI/general: 60–300 seconds
6) Produce outputs
Produce a FeedBlueprint including:
OracleJob[]JSONsources + rationale
aggregation choice
required secrets and override variable names
suggested consumer validation defaults (staleness/deviation/min responses)
simulation plan (Crossbar or local job runner)
References
https://docs.switchboard.xyz/custom-feeds/task-types
https://docs.switchboard.xyz/custom-feeds/advanced-feed-configuration/data-feed-variable-overrides
https://docs.switchboard.xyz/tooling/crossbar
Last updated