Switchboard Documentation
  • Switchboard On Demand
  • Understanding Switchboard
    • Introduction
      • Why Switchboard Oracles?
      • Vision & mission
      • Brief History and Key Achievements to Date
      • Switchboard’s Architecture, Tech Stack and Security
        • Trusted Execution Environments (TEEs)
        • Oracle Queues
        • Node Architecture
  • Product Documentation
    • Data Feeds
      • Getting Started with Switchboard Data Feeds
      • Solana / SVM
        • Part 1: Designing and Simulating Your Feed
          • Option 1: Drag-and-Drop Feed Builder
          • Option 2: Designing a Feed in Typescript
        • Part 2: Deploying your Feed On-Chain
        • Part 3: Integrating your Feed
          • Integrating your Feed On-Chain
          • Integrating into Frontends
        • Costs
        • Integrating on Eclipse
      • EVM
        • Part 1: Prerequisites and Quick Start Guide
        • Part 2: Designing and Creating Your Feed
          • Option 1: Drag-and-Drop Feed Builder
          • Option 2: Designing a Feed in Typescript
        • Part 3: Integrating your Feed
          • Integrating your Feed On-Chain
          • Integrating your Feed with Typescript
          • Integrating into Frontends (EVM)
      • Aptos
      • Sui
      • Movement
      • Starknet
      • Optional Features
        • Switchboard Secrets
      • Task Types
    • Aggregator
      • How to use the Switchboard Oracle Aggregator
    • Randomness
      • Why Randomness is important?
      • Switchboard's Approach to Verifiable Randomness
      • Tutorials
        • Solana / SVM
        • EVM
  • Tooling and Resources
    • Crossbar
      • Run Crossbar with Docker Compose
    • Switchboard Command Line Interface
    • Technical Resources and Documentation
      • SDKs and Documentation
      • Solana Accounts
      • EVM Identifiers
      • Code Examples (Github)
  • Switchboard Protocol
    • (Re)staking
      • What is (re)staking?
      • What are Node Consensus Networks (NCNs)?
      • What are Vault Receipt Tokens (VRTs)?
      • The Node Partner Program
      • The Switchboard NCN
    • Running a Switchboard Oracle
      • Prerequisites
        • Knowledge about Linux, containers and Self-Hosting
        • Hardware Requirements and AMD SEV SNP
        • Software Requirements
        • Network Requirements
      • Hardware: tested providers and setup
        • OVH
      • Platform: Kubernetes + AMD SEV SNP
        • Bare Metal with Kubernetes (K3s)
      • The Git Repo: Clone Our Code
        • Repo Structure
      • Configuration: Tweaking Configurations
        • cfg/00-common-vars.cfg
        • cfg/00-devnet-vars.cfg and cfg/00-mainnet-vars.cfg
      • Installation: Setup Via Scripts
        • Bare Metal with Kubernetes (K3s) + AMD SEV SNP
  • Frequently Asked Questions and Glossary
    • FAQ
    • Glossary
Powered by GitBook
On this page
  • How does Switchboard use (re)Staking to secure the Switchboard network?
  • Incentivizing Oracle Performance with Stake
  • Managing Usage Limits with Stake
  • Summary
  1. Switchboard Protocol
  2. (Re)staking

The Switchboard NCN

PreviousThe Node Partner ProgramNextRunning a Switchboard Oracle

Last updated 1 month ago

How does Switchboard use (re)Staking to secure the Switchboard network?

Switchboard oracles are a scarce and valuable resource. To protect the network from abuse (e.g., spam, denial-of-service attempts), and to maximize oracle performance, the network uses a staking-based mechanism powered by the Jito NCN framework.

Incentivizing Oracle Performance with Stake

Although Switchboard oracles operate within secure Trusted Execution Environments (TEEs), they are still subject to real-world limitations like CPU load and network throughput. To incentivize optimal uptime, responsiveness, and resource management, Switchboard integrates with Jito’s staking vaults.

Stakers can delegate their stake to oracles. High-performing oracles will receive more stake over time, creating a reward feedback loop. Oracles with the most stake are prioritized in routing for new price requests, ensuring that the most performant nodes serve critical traffic.

Managing Usage Limits with Stake

To prevent misuse of the network (e.g., users flooding price requests), Switchboard enforces a default rate limit of 20 requests per second (RPS) per user.

Users can raise this limit by staking $SWTCH tokens. When submitting a request, users can sign it with a wallet that holds stake, proving their economic commitment to the network. The more stake held, the higher the RPS limit granted to that user. This ties resource consumption directly to network value.

Summary

By integrating staking into both supply (oracles) and demand (users), Switchboard ensures a secure, performant, and economically aligned oracle network.