Skip to main content

Switchboard Protocol

Switchboard Protocol — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Switchboard Protocol — an Infra / Oracles project on Solana, token (symbol: SWTCH).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: an “on‑demand” oracle network that delivers external data to smart contracts using trusted execution environments (TEE) and economic incentives.
  • Who it’s for: dApp developers (DeFi/games/applications) who need external data/VRF/custom computations.
  • Why onchain/token: the blockchain is needed to verify the signatures of oracle nodes and feed updates; the SWTCH token — for staking/delegation and for governing network parameters.

How it works (very briefly)

  1. The user does: a dApp (or a user) initiates a request to update a feed (for example, a price) in its own transaction.
  2. The system does: the gateway selects a set of oracle nodes by stake/health; the nodes execute the workload in protected environments (TEE), fetch the data and sign the result.
  3. The user gets: the transaction contains “just‑in‑time” signatures/data and can atomically update the feed and execute business logic (for example, issuing a loan).
  4. Where the blockchain is: signature verification and the recording/updating of data feed state happen onchain.
  5. Token role: SWTCH is used in the economic security model (staking/delegation, subsidies/rewards, governance).

Quick links: AI thesis fit

Project passport

Field Value
Project name Switchboard Protocol
Also known as (aliases) Switchboard, Switchboard On‑Demand, SWTCH
Logo (logo) ../assets/192_switchboard-protocol_logo.svg
Token symbol (ticker) SWTCH
Category Infra | Oracles
Primary chain (chain) Solana
Type non-EVM
Network status mainnet
Consensus (consensus) PoS (Solana)
Launch date (launch_date) —
Project status (status) active
Token (standard) SPL
Token contract SW1TCHLmRGTfW5xZknqQdpdarB8PD95sJYWpNp9TbFx
Token model (token_type) utility (staking + governance)
Max supply 1,000,000,000 SWTCH (total supply; per the whitepaper)
Issuance fixed (per the whitepaper total supply)
Tokenomics (tokenomics, brief) 1B total supply; distribution by categories with vesting (see the whitepaper)
Governance onchain governance via SWTCH/svSWTCH (per the whitepaper)
Admins/keys —
Audit —
Bug bounty —
Team (team) —
Funding (investors/funding) —
AI component (ai_component) —
Use‑case (use_case) on-demand oracle data feeds, VRF, custom tasks
DecAI Fit — AI thesis fit 0/6 — no AI reality and no AI intent (ai_score=0)
DecAI Fit component summary 0 / 2 / 2 / 2
Last verified 2026-02-11

General project overview

Switchboard Protocol is positioned as an “on‑demand oracle network” that allows dApps to obtain external data (including custom sources) not through constant “streaming” updates, but by executing a workload at the moment of the request and delivering the signed result into the user’s transaction.

The key idea from the whitepaper: economic incentives (SWTCH staking/delegation) and hardware‑protected environments (TEE) are used to increase trust in the execution of oracle nodes and to reduce latency in data delivery.

Features/modules

  • On‑Demand data feeds: updating a feed at the moment of the request (“just‑in‑time”) to minimize data staleness.
  • Gateways + oracle selection: routing requests to oracle nodes taking into account stake and health/performance indicators.
  • TEE execution: a protected environment for executing workloads and for hidden secrets (for example, API keys).
  • VRF and custom tasks: verifiable randomness and secure execution of limited user code (as described in the whitepaper).
  • Cross‑chain verification (claimed): porting the oracle node registry to other networks to verify signatures and updates on the target network.

Typical scenarios

  • Scenario 1 (DeFi lending): a protocol, in a single transaction, updates the collateral price → calculates the LTV → issues a loan, using fresh signatures of oracle nodes.
  • Scenario 2 (games/VRF): a smart contract requests verifiable randomness to transparently determine a loot drop/the outcome of an event.
  • Scenario 3 (custom source): a team creates its own feed (an API/another oracle layer) and defines the aggregation/signing rules.

Getting started (wallet/network)

  • What you need: a Solana wallet (for working with SPL assets) and access to the project’s SDK/documentation.
  • Network/chain: Solana.
  • Fees: network fees (SOL) + payments/rewards in the protocol economy (described in the whitepaper).

Architecture/tech (non‑AI)

  • Components: oracle nodes (operators), gateways (routing), onchain data feeds, oracle registry, client SDKs.
  • Participant roles: users/dApps, node operators, stakers/delegators.
  • Where logic runs: offchain execution of workloads on oracle nodes (TEE); onchain — signature verification and feed updates.
  • Dependencies: TEE technologies, the Solana network.

Token/economics (expanded, no forecasts)

  • Token utility: staking/delegation for economic security, governance, participation in subsidies/rewards (per the whitepaper).
  • Protocol necessity drivers: the whitepaper describes a model where the wrapped stake (svSWTCH) affects node prioritization and rewards.
  • Who pays fees: data consumers (dApps/users), paying for feed updates (in the chain’s gas token) and participating in the SWTCH economy (per the whitepaper).
  • Where fees go: into the rewards vault and are distributed to nodes/stakers per epoch (per the whitepaper).
  • Issuance/burn: total supply is fixed at 1B; distribution and vesting are described in the whitepaper.
  • Security/incentive mechanisms: staking, delegation, subsidies; slashing details are described conceptually in the whitepaper.

Governance

  • Who makes decisions: SWTCH/svSWTCH holders (governance per the whitepaper).
  • How protocol parameters change: via governance procedures (described at the level of principles in the whitepaper).

Security and incidents

  • Audits: no public reports on specific contracts/components were found.
  • Incidents: —.
  • Threat model: the whitepaper emphasizes the role of TEE and economic security (stake/delegation) for reducing attacks and increasing data reliability.

Project status and timeline

  • Current status: claimed as a working protocol (mainnet; the exact launch date is not recorded).
  • Key releases/milestones: see GitHub releases and publications.
  • Roadmap: see the link to the Medium post.

Ecosystem/integrations

  • Integrations: the target market — dApps that need data feeds/VRF/custom computations; a list of specific integrations is not enumerated in this card.

AI component of the project

  • What is real AI here? Per Tier‑1 sources, the project describes oracle infrastructure (TEE, signatures, data feeds). No AI component (model/inference/training) was identified.
  • What is truly onchain? Verification of oracle signatures, updating of data feeds and registry mechanics (described in the whitepaper).
  • Why is a token needed? Economic security (stake/delegation), reward distribution and governance parameters (described in the whitepaper).
  • Red flags (based on the information found): AI‑washing — high (the project is not about AI); what to double‑check: the actual onchain programs/addresses of the protocol on Solana (other than the token mint) and the economic parameters in the implementation.

DecAI Fit component summary

  • DecAI Fit: 0/6 — no AI reality and no AI intent (ai_score=0)
Component Level Score
AI reality low 0
Onchain necessity medium 2
Token necessity medium 2
Evidence Tier‑1 partially present 2
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): no Tier‑1 intent about AI as a separate module was found.
  • Evidence: Tier‑1 — https://switchboard.foundation/whitepaper
  • Why sufficient / why not (one line): the sources describe an oracle network, not AI functionality/an AI roadmap.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 0
  • Claim (one line): AI functions are not described as part of the product.
  • Evidence: Tier‑1 — https://switchboard.foundation/whitepaper
  • Why sufficient / why not (one line): the presence of TEE/data aggregation is not an AI component.
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 0
  • Claim (one line): a demo of an AI component is absent.
  • Evidence: Tier‑1 — https://switchboard.foundation/whitepaper
  • Why sufficient / why not (one line): the product examples are about oracle feeds, not about AI.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —
  • Context (version/date/how measured): —
  • Evidence: Tier‑1 — https://switchboard.foundation/whitepaper
  • Why sufficient / why not (one line): AI metrics are not applicable: no AI component is recorded.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 0
  • Claim (one line): there is a technical description, but not about an AI model/inference.
  • Evidence: Tier‑1 — https://switchboard.foundation/whitepaper
  • Why sufficient / why not (one line): the architecture of an oracle network is not a technical description of an AI component.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Solana
  • Addresses/identifiers: SWTCH mint SW1TCHLmRGTfW5xZknqQdpdarB8PD95sJYWpNp9TbFx
  • Evidence: Tier‑1 — https://solscan.io/token/SW1TCHLmRGTfW5xZknqQdpdarB8PD95sJYWpNp9TbFx
  • Why sufficient / why not (one line): there is a specific onchain identifier of the token on the network.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 1
  • What useful logic is onchain: verification of oracle signatures and updating of data feeds (described as an onchain procedure in the whitepaper).
  • Evidence: Tier‑1 — https://switchboard.foundation/whitepaper ; https://raw.githubusercontent.com/switchboard-xyz/on-demand/main/README.md
  • Why sufficient / why not (one line): the whitepaper describes onchain signature verification and feed updates as part of the protocol’s operation.
  • Conflict note (if any): the official GitHub lists the default quote program ID orac1eFjzWL5R3RbbdMV68K9H6TaCVVcL6LjvQQWAbz; the addresses of the other programs/deployments on Solana are not enumerated in this card.

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: an oracle service can be replaced with a centralized server; no Tier‑1 proof that “it breaks down without the blockchain” was found.
  • Evidence: Tier‑1 — https://switchboard.foundation/whitepaper
  • Why sufficient / why not (one line): the whitepaper contains arguments about security/trust, but no operational proof of criticality.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the protocol has a token, SWTCH.
  • Evidence: Tier‑1 — https://switchboard.foundation/whitepaper
  • Why sufficient / why not (one line): the tokenomics and total supply are described in the whitepaper.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): payment for feed updates is described as a fee in the network’s gas token, not necessarily in SWTCH.
  • Evidence: Tier‑1 — https://switchboard.foundation/whitepaper
  • Why sufficient / why not (one line): per the description in the whitepaper, fees are charged in the gas token; SWTCH is the staking/governance layer.
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 1
  • Claim (one line): SWTCH is used for staking/delegation and for distributing rewards to operators and stakers.
  • Evidence: Tier‑1 — https://switchboard.foundation/whitepaper
  • Why sufficient / why not (one line): the svSWTCH economy, epochs and reward distribution are described.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): SWTCH/svSWTCH grant governance rights over protocol parameters.
  • Evidence: Tier‑1 — https://switchboard.foundation/whitepaper
  • Why sufficient / why not (one line): governance is described in the whitepaper (upgrades/parameters).
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): in the whitepaper, the token is described as a core element of economic security and governance.
  • Evidence: Tier‑1 — https://switchboard.foundation/whitepaper
  • Why sufficient / why not (one line): for the target model (stake/delegation/governance), the token is the protocol’s native instrument.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://switchboard.foundation/whitepaper the on‑demand oracle architecture, onchain signature verification, the role of SWTCH (staking/rewards/governance), total supply and distribution
Tier‑1 https://solscan.io/token/SW1TCHLmRGTfW5xZknqQdpdarB8PD95sJYWpNp9TbFx the onchain identifier (mint) of the SWTCH token on Solana
Tier‑1 https://raw.githubusercontent.com/switchboard-xyz/on-demand/main/README.md a Tier‑1 artifact in the official GitHub: the on‑demand SDK and a mention of the default quote program ID
Tier‑2 https://www.coingecko.com/en/coins/switchboard reference profile

No comments to display

Back to top