Skip to main content
This guide covers how to integrate Range’s Onchain Risk Verifier (ORV) into a Solana program. The ORV brings real-world risk intelligence onchain - allowing programs to reject high-risk or sanctioned addresses at the protocol level using cryptographically signed, tamper-proof data.
Prerequisites: You need a Risk API key, a Solana development environment (Anchor or Pinocchio), and familiarity with Switchboard On-Demand Oracles.

How It Works

The Onchain Risk Verifier uses Switchboard On-Demand Oracles to fetch signed risk data from Range’s Risk API and verify it inside your Solana program. No persistent data feeds are required - quotes are requested on demand.

Security Model

  • Tamper-proof: The program reconstructs the exact same feed definition onchain and hashes it. Any change to the URL, headers, or processing tasks changes the hash, causing verification to fail.
  • Cryptographic verification: Switchboard oracles run in Trusted Execution Environments (TEEs) and sign results with Ed25519. The program verifies these signatures Onchain.
  • Freshness checks: The program rejects quotes older than a configurable number of slots (e.g., 50 slots ≈ 20 seconds).
  • API keys stay off-chain: Range API keys are injected as variable overrides at the oracle level - they never appear Onchain.

Use Cases


Step 1: Define the Oracle Job (TypeScript)

The Oracle Job tells Switchboard what data to fetch and how to process it. This job calls Range’s Address Risk Score endpoint, parses the riskScore, scales it to 0–100, and bounds the result.
The address is embedded directly in the Oracle Job URL. This is intentional, the Switchboard feed ID is a deterministic hash of the entire feed definition (including the URL). Your onchain program reconstructs the same URL using the query_account pubkey and hashes it to verify the oracle returned data for the correct address. A new Oracle Job must be created for each address you want to check.
The ${RANGE_API_KEY} placeholder is resolved by the Switchboard oracle at runtime using variable overrides. Your API key is never exposed onchain or in transaction data.

Step 2: Request a Signed Quote (TypeScript)

Use the Switchboard SDK to request a signed quote and build the Ed25519 verification instruction.

Step 3: Build and Send the Transaction (TypeScript)

Combine the signature verification instruction with your program instruction in a single transaction.
The Switchboard SDK (@switchboard-xyz/on-demand) uses @solana/web3.js types internally. The transaction building code below uses web3.js for compatibility with the SDK.

Step 4: Verify Onchain (Rust)

The Solana program reconstructs the same feed definition, hashes it, and compares against the oracle quote to ensure data integrity.

Step 5: Run the Example

Range provides a complete working example with both Anchor and Pinocchio implementations.
The test requires a funded Solana devnet wallet. If you don’t have one, generate a keypair with solana-keygen new -o keypair.json and airdrop devnet SOL with solana airdrop 2 --keypair keypair.json --url devnet.
Expected output:
The repository includes both an Anchor and Pinocchio implementation. Both are functionally identical - choose whichever framework your project uses.

Customizing for Your Program

Adjusting the Risk Threshold

Modify the onchain program to enforce your risk policy:

Checking Different Networks

Update the URL in both the TypeScript OracleJob and the Rust feed reconstruction to query different networks:
The feed definition must be identical in both the client-side OracleJob and the onchain feed reconstruction. Any difference - even in field ordering or default values - will change the hash and cause verification to fail.

Production Considerations

  • Increase numSignatures - Use more than 1 signature for production to increase consensus requirements.
  • Tune staleness - The example uses 50 slots (~20 seconds). Tighten this for time-sensitive operations.
  • Use mainnet queue - Switch from getDefaultDevnetQueue to getDefaultQueue for production deployments.
  • Handle errors gracefully - Decide whether a failed risk check should block the transaction or allow it with a warning flag.

Cross-Chain Support

The Onchain Risk Verifier is currently implemented for Solana. The same architecture could be adapted for EVM (Solidity) and CosmWasm smart contracts, the core pattern of oracle-fetched signed data with onchain signature and feed integrity verification is framework-agnostic. If you’re interested in an EVM or CosmWasm implementation, get in touch.

What’s Next

Address Risk Score

Full endpoint reference for the Risk API endpoint used by the oracle job.

Switchboard Docs

Switchboard On-Demand Oracle documentation and SDK reference.

Example Repository

Complete working implementation with Anchor and Pinocchio frameworks.

Wallet Integration

For off-chain risk screening in wallets and dApps.
Last modified on June 17, 2026