DEV Community: Pythia Oracle

How to Get AI Market Analysis On-Chain: Backtested Patterns Delivered to Your Smart Contract

Pythia Oracle — Thu, 16 Apr 2026 14:32:39 +0000

What if your smart contract could receive AI-generated market intelligence — not just a price, but a pattern analysis with confidence scores, indicator snapshots, and historical accuracy data — delivered on-chain through Chainlink?

That's what Pythia Visions does. This post walks through the architecture, the on-chain interface, and a full Solidity example that reacts to AI analysis automatically.

The Problem: Smart Contracts Are Blind to Market Context

Price oracles tell your contract that BTC is $72,000. They don't tell you:

Is this a capitulation sell-off or a normal dip?
What do RSI, EMA, Bollinger Bands, and VWAP say right now?
What happened historically when this exact pattern appeared?
How confident should you be in a recovery?

For any of this, you'd need to run your own off-chain pipeline — data sources, indicator computation, pattern detection, historical backtesting. Most builders don't have the time or infrastructure for that.

Pythia Visions solves this by running the full analysis pipeline off-chain and delivering structured, AI-calibrated results on-chain via Chainlink.

What a Vision Contains

A Vision is a structured payload fired on-chain when a historically significant pattern is detected. Here's what arrives in the VisionFired event:

Field	Type	Example
`tokenId`	`bytes32`	`keccak256("BTC")`
`patternType`	`uint8`	`0x11` (CAPITULATION_STRONG)
`confidence`	`uint8`	`86` (AI-calibrated, 55-89 range)
`direction`	`uint8`	`1` (BULLISH)
`price`	`uint256`	BTC price at detection (18 decimals)
`payload`	`bytes`	ABI-encoded: indicators, analysis, feeds

The payload bytes decode to a full analysis package:

Indicator snapshot — RSI, EMA gap, ATR, Bollinger position, VWAP distance, rate of change
Pattern metadata — historical accuracy, average return, sample size, data span
AI analysis — 2-3 sentence explanation of what's happening
Feeds to watch — which Pythia Feeds to monitor for confirmation (with thresholds)

The Patterns (Backtested 2017-2026)

Six patterns validated against years of BTC history, covering four categories:

Pattern	Category
`CAPITULATION_STRONG`	Severe sell-off with multiple confirming indicators
`CAPITULATION_BOUNCE`	Sell-off with early reversal signals
`EMA_DIVERGENCE_STRONG`	Strong trend divergence with momentum confirmation
`EMA_DIVERGENCE_SNAP`	Trend divergence approaching snap-back threshold
`BOLLINGER_EXTREME`	Price at extreme statistical deviation
`OVERBOUGHT_CONTINUATION`	Strong momentum with continuation bias

Each Vision carries its confidence score and the historical accuracy range for the detected pattern — your contract gets the full context to decide how to act.

Browse available Visions at pythia.c3x-solutions.com/visions.

The On-Chain Interface

PythiaVisionRegistry

Deployed on Polygon mainnet at 0x39407eEc3Ba80746BC6156eD924D16C2689533Ed.

interface IPythiaVisionRegistry {
    /// @notice Emitted when AI detects a backtested pattern
    event VisionFired(
        bytes32 indexed tokenId,
        uint8   patternType,   // 0x11 = CAPITULATION_STRONG, etc.
        uint8   confidence,    // AI-calibrated, 55-89
        uint8   direction,     // 1 = BULLISH
        uint256 price,         // 18 decimals
        bytes   payload        // ABI-encoded full analysis
    );

    /// @notice Subscribe to Visions for a token. Free — no LINK.
    function subscribe(bytes32 tokenId) external;

    /// @notice Unsubscribe
    function unsubscribe(bytes32 tokenId) external;

    /// @notice Check subscription status
    function isSubscribed(address subscriber, bytes32 tokenId)
        external view returns (bool);
}

Visions are free. subscribe(keccak256("BTC")) — that's it. No LINK, no fees, no expiry.

The VisionFired events are public. Anyone can read them from the event log. Subscription is optional on-chain registration — useful for contracts that want to filter or for future automation.

Pattern Type Codes

// BTC pattern types
uint8 constant CAPITULATION_STRONG   = 0x11;
uint8 constant CAPITULATION_BOUNCE   = 0x10;
uint8 constant EMA_DIVERGENCE_STRONG = 0x21;
uint8 constant EMA_DIVERGENCE_SNAP   = 0x20;
uint8 constant BOLLINGER_EXTREME     = 0x30;
uint8 constant OVERBOUGHT_CONT      = 0x40;

Reading Visions in Your Contract

The simplest integration: listen for VisionFired events and act on the structured fields.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "./interfaces/IPythiaVisionRegistry.sol";

contract SimpleVisionReader {
    IPythiaVisionRegistry public immutable visionRegistry;
    bytes32 public constant BTC = keccak256("BTC");

    uint8   public lastPattern;
    uint8   public lastConfidence;
    uint256 public lastPrice;
    uint64  public lastTimestamp;

    event VisionReceived(uint8 pattern, uint8 confidence, uint256 price);

    constructor(address _visionRegistry) {
        visionRegistry = IPythiaVisionRegistry(_visionRegistry);
    }

    /// @notice Call once after deployment — free, no LINK needed
    function subscribe() external {
        visionRegistry.subscribe(BTC);
    }

    /// @notice Called by a relay bot when VisionFired is detected
    function onVision(
        uint8 patternType,
        uint8 confidence,
        uint256 price
    ) external {
        lastPattern    = patternType;
        lastConfidence = confidence;
        lastPrice      = price;
        lastTimestamp   = uint64(block.timestamp);
        emit VisionReceived(patternType, confidence, price);
    }

    /// @notice Other contracts read this to check for active signals
    function hasRecentVision(uint64 maxAge) external view returns (bool) {
        return lastTimestamp > 0 &&
               block.timestamp - lastTimestamp <= maxAge;
    }
}

Deploy on Polygon mainnet with _visionRegistry = 0x39407eEc3Ba80746BC6156eD924D16C2689533Ed.

Full Example: Vision-Driven Vault Guard

The real power of Visions is the feeds-to-watch field. Each Vision tells you which Pythia Feeds to monitor for confirmation — with specific thresholds.

For example, a capitulation Vision might include feeds like btc_RSI_1H_14 (watch for oversold exit), btc_VWAP_24H (watch for VWAP reclaim), and btc_EMA_1H_20 (watch for EMA reclaim) — each with a specific condition and threshold tailored to the current market state.

The VisionVaultGuard contract automates this loop:

Vision fires (free) — AI says "BTC capitulation detected, 86% confidence"
Contract auto-subscribes to the recommended Pythia Events (paid LINK) — "tell me when RSI crosses above 35"
Events fire when thresholds are hit — confirmation arrives on-chain
Contract transitions to CONFIRMED — other contracts/bots read the state and act

State machine:

  IDLE → ALERT → WATCHING → CONFIRMED → IDLE
         (vision   (events     (enough        (auto-reset
          fires)    subscribed)  confirmations)  after cooldown)

Here's the core of the contract (full source at pythia-oracle-examples):

contract VisionVaultGuard is ConfirmedOwner {
    enum State { IDLE, ALERT, WATCHING, CONFIRMED }

    IPythiaEventRegistry    public eventRegistry;
    IPythiaVisionRegistry   public visionRegistry;
    bytes32 public constant BTC = keccak256("BTC");

    State public state;
    uint8 public requiredConfirmations = 1;

    struct FeedWatch {
        string  feedName;    // e.g. "btc_RSI_1H_14"
        uint8   condition;   // 0=ABOVE, 1=BELOW
        int256  threshold;   // 8 decimals
    }

    /// @notice Relay bot calls this when VisionFired event is detected
    function processVision(
        uint8 patternType,
        uint8 confidence,
        uint8 direction,
        uint256 price,
        FeedWatch[] calldata feeds,
        string[] calldata meanings
    ) external onlyOwner {
        // Store vision data, transition to ALERT
        // ...

        // Auto-subscribe to each recommended feed as a Pythia Event
        for (uint256 i = 0; i < feeds.length; i++) {
            uint256 cost = eventRegistry.getCost(eventDays);
            LINK.approve(address(eventRegistry), cost);
            uint256 eventId = eventRegistry.subscribe(
                feeds[i].feedName,
                eventDays,
                feeds[i].condition,
                feeds[i].threshold
            );
            // Track subscription for confirmation matching
        }

        // Transition: ALERT → WATCHING
    }

    /// @notice Bot reports when a confirmation Event fires
    function reportConfirmation(uint256 eventId, int256 value) external onlyOwner {
        // Match eventId to tracked subscription, mark as fired
        // If enough confirmations → transition to CONFIRMED
    }

    /// @notice Other contracts read this
    function isActionReady() external view returns (bool) {
        return state == State.CONFIRMED &&
               block.timestamp < lastVision.receivedAt + confirmedTimeout;
    }
}

This creates a Vision → Event → Action loop where:

Visions (free) provide the intelligence — what happened and what to watch
Events (paid LINK) provide the triggers — when confirmations arrive
Your contract acts only when both the pattern AND the confirmations align

Full contract with 26 passing Hardhat tests: 06_VisionVaultGuard.sol

Deploying on Polygon Mainnet

Pythia Vision Registry: 0x39407eEc3Ba80746BC6156eD924D16C2689533Ed
Pythia Event Registry:  0x73686087d737833C5223948a027E13B608623e21
LINK Token:             0xb0897686c545045aFc77CF20eC7A532E3120E0F1

For the VisionVaultGuard, fund the contract with LINK (for Event subscriptions). Visions themselves are free.

AI-Assisted Development

Explore Visions and Feeds programmatically:

pip install pythia-oracle-mcp

Works with Claude, Cursor, Windsurf, or any MCP-compatible AI tool. Ask:

"What patterns does Pythia Visions detect for BTC?"
"Show me the VisionFired event interface"
"What feeds should I watch after a capitulation signal?"

Or use LangChain:

pip install langchain-pythia

from langchain_pythia import PythiaToolkit

toolkit = PythiaToolkit()
tools = toolkit.get_tools()
# 7 tools: feeds, tokens, events, visions info, and more

Why This Architecture

Why not just put AI on-chain?

Running an LLM on-chain is impossible. But the output of an AI — a confidence score, a pattern classification, a set of indicator values — is just data. Data that Chainlink already knows how to deliver.

Pythia's approach:

Mechanical detection (free, deterministic) decides IF something fires
AI calibration (one cheap API call) adds nuance to HOW confident we are
Chainlink delivery (trustless) gets it on-chain

The AI is one step in the middle — not the foundation. If AI is down, Visions still fire with mechanical defaults. The patterns are the product; AI makes them better.

Why backtested patterns?

Every pattern in production has been validated against years of BTC history. Patterns that looked strong on shorter windows but degraded on full history were dropped. Data decides what ships.

What You Can Build With This

Risk management layers — pause lending/vault operations when high-confidence capitulation is detected
Automated DCA strategies — increase position size when AI confidence is above 80%
Alert systems — relay Vision data to Telegram/Discord bots for trading teams
Portfolio rebalancing — shift allocations based on detected market regime
Keeper-style bots — watch for VisionFired events and execute strategies across protocols

Summary

Pythia Visions deliver AI-calibrated market intelligence on-chain via Chainlink
6 backtested BTC patterns covering capitulations, divergences, extremes, and momentum
Free subscription — subscribe(keccak256("BTC")), no LINK
Structured payload: pattern type, confidence, indicators, analysis, feeds-to-watch
VisionVaultGuard example: automated Vision → Event → Action loop
Mainnet contract: 0x39407eEc3Ba80746BC6156eD924D16C2689533Ed

The intelligence is live. The patterns are firing. What you build on top is up to you.

Explore: pythia.c3x-solutions.com/visions | MCP: pip install pythia-oracle-mcp | Examples: github.com/pythia-the-oracle/pythia-oracle-examples

On-Chain Alerts for Smart Contracts Using a Pub-Sub Pattern

Pythia Oracle — Thu, 09 Apr 2026 10:39:04 +0000

Smart contracts are good at executing logic. They're terrible at knowing when to execute it.

If your contract needs to rebalance when RSI drops below 30, or pause deposits when volatility spikes above 8%, you have two options today: run an off-chain bot that polls an oracle every few minutes and calls your contract when conditions change, or set up a keeper network. Both require infrastructure you have to build, fund, and monitor.

There's a third option that works the way publish-subscribe patterns work everywhere else in software: subscribe to a condition, get notified when it's true, done.

This tutorial shows how to build a smart contract that subscribes to on-chain indicator alerts using a pub-sub oracle — no bots, no keepers, no off-chain infrastructure. One transaction to subscribe. One event to listen for.

The Interface

The Pythia Event Registry exposes a minimal interface for subscribing to calculated indicator alerts (RSI, EMA, Bollinger Bands, VWAP, volatility) delivered through a Chainlink oracle node:

interface IPythiaEventRegistry {
    /// Emitted when a subscription's condition is met
    event PythiaEvent(uint256 indexed eventId, int256 value);

    /// Subscribe to an indicator alert. Approve LINK spending first.
    function subscribe(
        string calldata feedName,   // e.g. "bitcoin_RSI_1D_14"
        uint16 numDays,             // 1-365 days to monitor
        uint8 condition,            // 0=ABOVE, 1=BELOW
        int256 threshold            // 8 decimals (RSI 30 = 3000000000)
    ) external returns (uint256 eventId);

    /// Cancel subscription. Remaining whole days refunded in LINK.
    function cancelSubscription(uint256 eventId) external;

    /// Check if a subscription is still active
    function isActive(uint256 eventId) external view returns (bool);

    /// Get the LINK cost for N days at current price
    function getCost(uint16 numDays) external view returns (uint256);
}

You call subscribe() with a feed name, how long to monitor, the condition (above or below a threshold), and a threshold value. The oracle monitors the indicator every 5 minutes. When the condition is met, it fires PythiaEvent on-chain with the triggering value and refunds your unused days in LINK.

No API keys. No webhook endpoints. No keeper contracts. Everything happens on-chain through standard Solidity events.

The Subscriber Contract

Here's a complete contract that wraps the registry interface. This is production code from the Pythia examples repository:

// SPDX-License-Identifier: MIT
pragma solidity 0.8.19;

import "@chainlink/contracts/src/v0.8/shared/interfaces/LinkTokenInterface.sol";
import "@chainlink/contracts/src/v0.8/shared/access/ConfirmedOwner.sol";
import "./interfaces/IPythiaEventRegistry.sol";

contract EventSubscriber is ConfirmedOwner {
    LinkTokenInterface public immutable LINK;
    IPythiaEventRegistry public registry;

    uint256 public lastEventId;

    event Subscribed(uint256 indexed eventId, string feed, uint8 condition, int256 threshold);
    event Cancelled(uint256 indexed eventId);

    constructor(address _link, address _registry) ConfirmedOwner(msg.sender) {
        LINK = LinkTokenInterface(_link);
        registry = IPythiaEventRegistry(_registry);
    }

    /// @notice Subscribe to an indicator alert. Fund this contract with LINK first.
    /// @param feedName e.g. "pol_RSI_5M_14", "bitcoin_EMA_1H_20"
    /// @param numDays  1-365 — how long to monitor
    /// @param condition 0=ABOVE, 1=BELOW
    /// @param threshold 8 decimals (e.g. RSI 30 = 3000000000)
    /// @return eventId Listen for PythiaEvent(eventId) on the registry
    function subscribe(
        string calldata feedName,
        uint16 numDays,
        uint8 condition,
        int256 threshold
    ) external onlyOwner returns (uint256 eventId) {
        uint256 cost = registry.getCost(numDays);
        LINK.approve(address(registry), cost);
        eventId = registry.subscribe(feedName, numDays, condition, threshold);
        lastEventId = eventId;
        emit Subscribed(eventId, feedName, condition, threshold);
    }

    /// @notice Cancel a subscription. Remaining whole days refunded in LINK.
    function cancel(uint256 eventId) external onlyOwner {
        registry.cancelSubscription(eventId);
        emit Cancelled(eventId);
    }

    /// @notice Check if a subscription is still active
    function isActive(uint256 eventId) external view returns (bool) {
        return registry.isActive(eventId);
    }

    /// @notice Update registry address (e.g. after upgrade)
    function setRegistry(address _registry) external onlyOwner {
        registry = IPythiaEventRegistry(_registry);
    }

    /// @notice Withdraw LINK from this contract
    function withdrawLink() external onlyOwner {
        LINK.transfer(msg.sender, LINK.balanceOf(address(this)));
    }
}

The flow: fund the contract with LINK, call subscribe() with your condition, store the eventId, and listen for PythiaEvent on the registry. When the oracle detects your condition is met, the event fires on-chain. Your bot (or another contract) catches it and reacts.

Threshold Scaling

Thresholds use 8 decimal places — not 18 like standard ERC-20 values. This is the most common mistake when setting up subscriptions:

Indicator	Target	Threshold Value
RSI below 30	30.0	`3000000000`
RSI above 70	70.0	`7000000000`
EMA below $2,500	2500.0	`250000000000`
Volatility above 5%	0.05	`500000000`

Two condition types are live:

0 = ABOVE — fires when the indicator value exceeds your threshold
1 = BELOW — fires when the indicator value drops below your threshold

Directional crossing conditions (CROSSES_ABOVE, CROSSES_BELOW) are accepted by the contract for forward compatibility but are not yet processed by the matcher.

Deploying to Testnet

The examples repo includes a Hardhat deploy script for both testnet and mainnet:

git clone https://github.com/pythia-the-oracle/pythia-oracle-examples
cd pythia-oracle-examples
npm install

# Deploy to Polygon Amoy testnet
npx hardhat run scripts/deploy-events.js --network amoy

The script wires the correct LINK token and registry addresses automatically. After deployment:

Get test LINK from faucets.chain.link/polygon-amoy
Fund the contract — transfer LINK to your deployed EventSubscriber address
Subscribe — call subscribe("bitcoin_RSI_1D_14", 3, 1, 3000000000) to monitor BTC RSI below 30 for 3 days
Note the eventId from the Subscribed event
Listen for PythiaEvent(eventId) on the registry contract

Available feeds span multiple tokens (BTC, SOL, AAVE, UNI, MORPHO, CRV, COMP, and more) and indicators (EMA, RSI, Bollinger Bands, VWAP, volatility, liquidity) across timeframes from 5-minute to weekly.

What Happens When It Fires

The oracle monitors all active subscriptions every minute. When your condition matches:

The matcher marks the subscription inactive
A batch transaction calls fireEvents() on the registry — one tx for multiple events
PythiaEvent(eventId, value) is emitted with the triggering indicator value
Remaining whole days are refunded in LINK to your contract

Your subscriber listens for the event:

const myEventId = 42n;

// Real-time listener
registry.on("PythiaEvent", (eventId, value) => {
    if (eventId === myEventId) {
        const rsi = Number(value) / 1e8;
        console.log(`RSI dropped to ${rsi} — condition met`);
        // Trigger rebalance, close position, notify team
    }
});

// Or backfill if your listener was offline — events are permanent
const filter = registry.filters.PythiaEvent(myEventId);
const events = await registry.queryFilter(filter, fromBlock, "latest");

Gas cost per fired event on Polygon: approximately $0.0001. Batch firing 50 events in a single transaction costs under $0.01.

Why Pub-Sub Beats Polling

If your contract polls an oracle for data on a fixed schedule, you pay per request whether the condition is met or not. With pub-sub, you pay a flat daily rate and the oracle handles the monitoring:

Approach	Daily Cost	Infrastructure
Events (pub-sub)	1 LINK/day	None — oracle monitors
Polling via Discovery	2.88 LINK/day (288 req)	Keeper or bot
Polling via Complete	28.8 LINK/day (288 req)	Keeper or bot

Events cost 65% less than polling the cheapest tier, and 97% less than polling the complete tier. If the condition fires early, you get unused days refunded. If you change your mind, cancel and get the remaining days back.

The pub-sub pattern also eliminates infrastructure: no server to run, no keeper to fund, no cron job to monitor. Your contract subscribes once and waits for the callback.

AI Agent Integration

If you're building autonomous DeFi agents, indicator subscriptions can be discovered and configured through AI tooling:

MCP Server (works in Claude, Cursor, Windsurf):

pip install pythia-oracle-mcp

10 tools — discover available tokens, check feed health, look up contract addresses, get pricing, generate integration code.

LangChain tools (for agent frameworks):

pip install langchain-pythia

7 tools — PythiaListTokensTool, PythiaTokenFeedsTool, PythiaHealthCheckTool, PythiaContractsTool, PythiaPricingTool, and Events tools for subscription info and integration guides.

An AI agent can discover which indicators are available for a token, check current pricing, and generate the subscription parameters — all programmatically. The subscription itself is a single on-chain transaction that the agent (or human) approves.

Contract Addresses

Network	Contract	Address
Polygon Mainnet	Event Registry	`0x73686087d737833C5223948a027E13B608623e21`
Polygon Mainnet	LINK Token (ERC-677)	`0xb0897686c545045aFc77CF20eC7A532E3120E0F1`
Amoy Testnet	Event Registry	`0x931Aa640d29E6C9D9fB3002749a52EC7fb277f9c`
Amoy Testnet	LINK Token	`0x0Fd9e8d3aF1aaee056EB9e802c3A762a667b1904`

Resources

Pythia Oracle — live feeds, contracts, documentation
Events — how subscriptions work
Example contracts and tests on GitHub
MCP server: pip install pythia-oracle-mcp
LangChain tools: pip install langchain-pythia
Community: Telegram | X/Twitter

Pythia delivers pre-calculated technical indicators on-chain via standard Chainlink oracle interface — EMA, RSI, VWAP, Bollinger Bands, volatility, liquidity. Any token, any Chainlink-supported chain. Subscribe to conditions with Events, or request data directly. pythia.c3x-solutions.com

Building an RSI-Gated DeFi Vault: Stop Deploying Capital Into Downtrends

Pythia Oracle — Sat, 04 Apr 2026 18:10:38 +0000

DeFi vaults are everywhere. Morpho, Kamino, Pendle, Yearn — billions in TVL running automated yield strategies. They rebalance on schedule, deploy capital on threshold triggers, and compound returns 24/7.

But none of them can answer a simple question: is momentum working for or against this entry?

A human trader checks RSI before deploying capital. If daily RSI is 75 — overbought, momentum fading — they wait. If it's 28 — oversold, potential reversal — they enter. Your vault? It doesn't know. It executes on schedule regardless.

The Problem: Condition-Blind Vaults

Today, vault strategies trigger on:

Time — weekly rebalance, regardless of market state
Price thresholds — rebalance when price moves ±5%
TVL ratios — deploy when utilization drops

None of these factor in momentum. You can be perfectly right about an asset's fundamental value and still deploy capital at exactly the wrong time — RSI at 75, right before a 40% drawdown.

The problem isn't the strategy logic. It's that RSI doesn't exist on-chain. No smart contract can read it. Computing a 14-period RSI requires historical price data, resampling, and the Wilder smoothing formula — none of which is feasible in Solidity.

The Solution: An On-Chain RSI Oracle

What if your vault could read RSI directly from a Chainlink oracle — the same interface you already use for price feeds?

That's what this tutorial builds: a vault with an RSI circuit breaker. An oracle delivers pre-calculated RSI on-chain, and your contract checks it before allowing deposits. No off-chain server, no API keys, no centralized dependency.

An RSI gate doesn't predict the future. It says: don't deploy capital when momentum is strongly against you.

The Architecture (Important: This is Async)

On-chain RSI through Chainlink's Direct Request pattern is asynchronous — not like price feeds (latestRoundData()). You request a value, the oracle computes it off-chain, and delivers it to a callback.

This means the vault works in two phases:

Refresh phase: A keeper (or Chainlink Automation) calls refreshRSI() periodically
Deposit phase: Users call deposit() — the contract checks the cached RSI value and its age

Lifecycle:

Keeper → refreshRSI() → sends LINK → Chainlink request
  ↓
Oracle computes RSI from 4 data sources
  ↓
Chainlink → fulfill() → stores lastRSI + timestamp
  ↓
User → deposit() → checks lastRSI < threshold && data < 2h old → allows

The Contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "@chainlink/contracts/src/v0.8/ChainlinkClient.sol";
import "@chainlink/contracts/src/v0.8/shared/access/ConfirmedOwner.sol";

contract RSIGatedVault is ChainlinkClient, ConfirmedOwner {
    using Chainlink for Chainlink.Request;

    // Pythia oracle config (Polygon mainnet)
    address private constant ORACLE = 0xAA37710aF244514691629Aa15f4A5c271EaE6891;
    address private constant LINK  = 0xb0897686c545045aFc77CF20eC7A532E3120E0F1;
    bytes32 private jobId;
    uint256 private constant FEE = (1 * LINK_DIVISIBILITY) / 100; // 0.01 LINK

    // RSI state
    uint256 public lastRSI;       // scaled 1e18 (e.g. 25.43 = 25430000000000000000)
    uint256 public lastUpdated;   // timestamp of last oracle fulfillment
    uint256 public constant FRESHNESS = 2 hours;
    uint256 public constant RSI_MAX   = 35 * 1e18; // gate: deposit only when RSI < 35

    // Vault accounting
    mapping(address => uint256) public balances;
    uint256 public totalDeposited;

    string public feedName; // e.g. "uniswap_RSI_1D_14"

    event RSIUpdated(uint256 rsi, uint256 timestamp);
    event Deposited(address indexed user, uint256 amount, uint256 rsiAtDeposit);

    constructor(bytes32 _jobId, string memory _feedName)
        ConfirmedOwner(msg.sender)
    {
        _setChainlinkToken(LINK);
        _setChainlinkOracle(ORACLE);
        jobId    = _jobId;
        feedName = _feedName;
    }

    /// @notice Called by keeper or Chainlink Automation to refresh RSI
    function refreshRSI() external returns (bytes32) {
        Chainlink.Request memory req = _buildChainlinkRequest(
            jobId,
            address(this),
            this.fulfill.selector
        );
        req._add("feed", feedName);
        return _sendChainlinkRequest(req, FEE);
    }

    /// @notice Chainlink callback — stores updated RSI
    function fulfill(bytes32 _requestId, uint256 _value)
        public
        recordChainlinkFulfillment(_requestId)
    {
        lastRSI     = _value;
        lastUpdated = block.timestamp;
        emit RSIUpdated(_value, block.timestamp);
    }

    /// @notice Deposit POL — only allowed when RSI is below threshold
    function deposit() external payable {
        require(msg.value > 0, "Zero deposit");
        require(
            block.timestamp - lastUpdated <= FRESHNESS,
            "RSI data stale — keeper must refresh"
        );
        require(
            lastRSI < RSI_MAX,
            "RSI too high — waiting for oversold conditions"
        );

        balances[msg.sender] += msg.value;
        totalDeposited        += msg.value;
        emit Deposited(msg.sender, msg.value, lastRSI);
    }

    function withdraw(uint256 amount) external {
        require(balances[msg.sender] >= amount, "Insufficient balance");
        balances[msg.sender] -= amount;
        totalDeposited        -= amount;
        payable(msg.sender).transfer(amount);
    }
}

Deploying and Testing

Step 1: Get LINK on Polygon mainnet

You need 0.01 LINK per RSI refresh. Get LINK at bridge.chain.link or via any Polygon DEX.

Step 2: Get the Job ID

Use the Pythia MCP server to discover available feeds and the job ID:

pip install pythia-oracle-mcp
# Then in Claude/Cursor/Windsurf:
# "What is the job ID for uniswap_RSI_1D_14?"

Step 3: Deploy

Deploy RSIGatedVault with:

_jobId: The Pythia job ID (bytes32, from MCP server)
_feedName: "uniswap_RSI_1D_14" (or any available Pythia feed — EMA, RSI, VWAP, Bollinger, volatility, liquidity across multiple tokens and timeframes)

Step 4: Fund with LINK and call refreshRSI

// Transfer 0.1 LINK to the vault address, then:
vault.refreshRSI();
// Wait ~30 seconds for oracle fulfillment
// vault.lastRSI() now returns current RSI scaled by 1e18

Step 5: Automate with Chainlink Automation

Register the vault in Chainlink Automation to call refreshRSI() hourly. This keeps RSI data fresh without a centralized keeper.

Test Free with the Faucet

Before committing LINK, test with the Pythia Faucet on Polygon mainnet — pre-funded, no cost to you:

Faucet: 0x640fC3B9B607E324D7A3d89Fcb62C77Cc0Bd420A

The faucet contract holds its own LINK balance. Each request costs 0.01 LINK from the faucet's balance — you don't need to hold any LINK yourself. Up to 5 requests per day. All feeds available. If the faucet runs dry, anyone can top it up by sending LINK (ERC-677) to the faucet address.

What the Data Looks Like

Pythia delivers RSI values scaled by 1e18 on-chain. Here's how to interpret them:

RSI Range	Meaning	Vault Behavior (threshold=35)
0–30	Oversold — momentum suggests potential reversal	Deposits allowed
30–35	Approaching neutral from oversold	Deposits allowed
35–70	Neutral — no strong signal	Deposits blocked
70–100	Overbought — momentum suggests potential pullback	Deposits blocked

Example feeds available: uniswap_RSI_1D_14, aave_RSI_1D_14, bitcoin_RSI_1H_14, solana_RSI_1W_14 — any token Pythia serves, across 6 timeframes (5M, 15M, 1H, 4H, 1D, 1W).

When multiple DeFi tokens show oversold RSI simultaneously, the gate opens — precisely when technical analysis suggests momentum conditions favor entry.

Going Further

This is the simplest RSI gate. Production implementations might add:

Multi-indicator confirmation:

// Deposit only when RSI is oversold AND price is above EMA-20 (trend intact)
require(lastRSI < 35 * 1e18, "RSI too high");
require(lastPrice > lastEMA20, "Below trend — skip entry");

Bollinger Band entries:

Request uniswap_BOLLINGER_1D_LOWER — deposit only when price is within 2% of the lower band (double confirmation with RSI).

Bundle requests — get all indicators at once:

Use PythiaBundleConsumer to fetch EMA_20, EMA_50, RSI_14, BOLLINGER_UPPER, BOLLINGER_LOWER, VWAP, VOLATILITY, and LIQUIDITY in a single request:

Analysis tier (0.03 LINK) — 1H/1D/1W timeframes
Speed tier (0.05 LINK) — 5M timeframe
Complete tier (0.10 LINK) — all 6 timeframes (5M, 15M, 1H, 4H, 1D, 1W)

Full indicator list: EMA_20, EMA_50, RSI_14, BOLLINGER_UPPER, BOLLINGER_LOWER, VWAP, VOLATILITY, LIQUIDITY across 6 timeframes for tokens including BTC, SOL, AAVE, UNI, LDO, Morpho, and more — new tokens added on demand.

Contract Addresses (Polygon Mainnet)

Contract	Address	Fee
Faucet (free trial)	`0x640fC3B9B607E324D7A3d89Fcb62C77Cc0Bd420A`	Pre-funded
Discovery	`0xeC2865d66ae6Af47926B02edd942A756b394F820`	0.01 LINK
Analysis (1H/1D/1W bundle)	`0x3b3aC62d73E537E3EF84D97aB5B84B51aF8dB316`	0.03 LINK
Speed (5M bundle)	`0xC406e7d9AC385e7AB43cBD56C74ad487f085d47B`	0.05 LINK
Complete (all timeframes)	`0x2dEC98fd7173802b351d1E28d0Cd5DdD20C24252`	0.10 LINK
LINK token (ERC-677)	`0xb0897686c545045aFc77CF20eC7A532E3120E0F1`	—
Operator	`0xAA37710aF244514691629Aa15f4A5c271EaE6891`	—

Resources

Live feeds and contracts: pythia.c3x-solutions.com
MCP server (explore feeds in Claude/Cursor/Windsurf): pip install pythia-oracle-mcp
LangChain integration: pip install langchain-pythia

Pythia delivers pre-calculated technical indicators (EMA, RSI, VWAP, Bollinger Bands, volatility, liquidity) on-chain via standard Chainlink interface. Any token, any Chainlink-supported chain. pythia.c3x-solutions.com

On-Chain RSI: How to Read Live Technical Indicators From a Solidity Smart Contract

Pythia Oracle — Thu, 02 Apr 2026 14:59:29 +0000

Why You Can't Calculate RSI On-Chain

RSI requires 14 periods of historical prices. For daily RSI, that's 14 days of data. For hourly, 14 hours.

Storing and computing this in Solidity would cost thousands in gas per calculation. Floating-point math doesn't exist in EVM. It's not viable.

The practical solution: deliver the pre-calculated value via oracle — computed off-chain, delivered on-chain through Chainlink.

How Pythia Feeds Work

Pythia uses Chainlink's Direct Request model (not the AggregatorV3Interface used by price feeds). The pattern is:

Your contract calls requestFeed("bitcoin_RSI_1D_14") and pays LINK
Pythia's off-chain engine computes the indicator from 4 redundant data sources
The Chainlink Operator delivers the result to your contract's fulfill() callback
Your contract stores the value and acts on it

This is two transactions, not a view call — the same async pattern used by Chainlink VRF and Any API.

The Indicators Available On-Chain

Pythia delivers pre-calculated technical indicators for 21 tokens across 4 timeframes (5M, 1H, 1D, 1W):

EMA (20 and 50 periods)
RSI (14 periods)
Bollinger Bands (upper and lower, 20-period, 2 std dev)
Volatility (24H)
VWAP
Liquidity

That's 462 indicator instances on Polygon mainnet, all delivered through Chainlink.

Reading a Single Indicator (Discovery Tier)

The Discovery tier returns one indicator per request for 0.01 LINK. This is Pythia's actual deployed contract — verified on Polygonscan:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "@chainlink/contracts/src/v0.8/ChainlinkClient.sol";
import "@chainlink/contracts/src/v0.8/shared/access/ConfirmedOwner.sol";

contract MyIndicatorReader is ChainlinkClient, ConfirmedOwner {
    using Chainlink for Chainlink.Request;

    uint256 public lastValue;
    string public lastFeed;

    bytes32 private jobId;
    uint256 private fee;

    event FeedRequested(bytes32 indexed requestId, string feed);
    event FeedFulfilled(bytes32 indexed requestId, uint256 value);

    constructor(
        address _link,
        address _oracle,
        bytes32 _jobId
    ) ConfirmedOwner(msg.sender) {
        _setChainlinkToken(_link);
        _setChainlinkOracle(_oracle);
        jobId = _jobId;
        fee = (1 * LINK_DIVISIBILITY) / 100; // 0.01 LINK
    }

    /// @notice Request any single indicator from Pythia
    /// @param feed Feed name, e.g. "bitcoin_RSI_1D_14", "aave_EMA_5M_20"
    function requestFeed(string memory feed) public onlyOwner returns (bytes32) {
        Chainlink.Request memory req = _buildChainlinkRequest(
            jobId, address(this), this.fulfill.selector
        );
        req._add("feed", feed);
        bytes32 requestId = _sendChainlinkRequest(req, fee);
        lastFeed = feed;
        emit FeedRequested(requestId, feed);
        return requestId;
    }

    /// @notice Chainlink callback — stores the indicator value
    /// @param _value The indicator value with 18 decimal places
    function fulfill(
        bytes32 _requestId,
        uint256 _value
    ) public recordChainlinkFulfillment(_requestId) {
        lastValue = _value;
        emit FeedFulfilled(_requestId, _value);
    }

    function withdrawLink() external onlyOwner {
        LinkTokenInterface link = LinkTokenInterface(_chainlinkTokenAddress());
        require(link.transfer(msg.sender, link.balanceOf(address(this))));
    }
}

Deploy, fund with LINK, call requestFeed("bitcoin_RSI_1D_14"). The result arrives in fulfill() — scaled by 1e18 (so RSI of 42.72 comes back as 42720000000000000000).

A Real Use Case: RSI-Gated Vault Deposits

Yield vaults typically accept deposits at any time. But depositing during extreme oversold conditions (RSI below 25) often means buying into a temporary panic — the market recovers and the vault captures the rebound.

A vault can use Pythia's RSI feed to only accept deposits when conditions are favorable:

contract RSIGatedVault is ChainlinkClient, ConfirmedOwner {
    using Chainlink for Chainlink.Request;

    uint256 public latestRSI;
    bool public depositsOpen;

    // RSI thresholds (scaled by 1e18)
    uint256 public constant RSI_OPEN = 40 * 1e18;   // Open deposits below RSI 40
    uint256 public constant RSI_CLOSE = 70 * 1e18;  // Close deposits above RSI 70

    bytes32 private jobId;
    uint256 private fee;

    constructor(address _link, address _oracle, bytes32 _jobId) ConfirmedOwner(msg.sender) {
        _setChainlinkToken(_link);
        _setChainlinkOracle(_oracle);
        jobId = _jobId;
        fee = (1 * LINK_DIVISIBILITY) / 100;
    }

    /// @notice Keeper calls this periodically to refresh RSI
    function refreshRSI() external returns (bytes32) {
        Chainlink.Request memory req = _buildChainlinkRequest(
            jobId, address(this), this.fulfillRSI.selector
        );
        req._add("feed", "bitcoin_RSI_1D_14");
        return _sendChainlinkRequest(req, fee);
    }

    function fulfillRSI(bytes32 _requestId, uint256 _value)
        public recordChainlinkFulfillment(_requestId)
    {
        latestRSI = _value;
        // Automatically gate deposits based on RSI
        if (_value < RSI_OPEN) {
            depositsOpen = true;
        } else if (_value > RSI_CLOSE) {
            depositsOpen = false;
        }
    }

    function deposit() external payable {
        require(depositsOpen, "Deposits closed — RSI too high");
        // ... vault deposit logic
    }
}

The keeper calls refreshRSI() periodically. When RSI drops below 40 — indicating oversold conditions — deposits open automatically. When RSI rises above 70 — overbought — deposits close. No off-chain server needed for the decision logic.

Another Pattern: EMA Crossover Signal

EMA crossovers (short-term EMA crossing above long-term EMA) are one of the most common trading signals. With Pythia's bundle tier, you can get both EMAs in a single on-chain call:

/// @notice Request all indicators for a token (Analysis tier — 0.03 LINK)
function requestBundle(string memory token) public onlyOwner returns (bytes32) {
    Chainlink.Request memory req = _buildChainlinkRequest(
        bundleJobId, address(this), this.fulfillBundle.selector
    );
    req._add("token", token);
    req._add("mode", "bundle");
    return _sendChainlinkRequest(req, bundleFee);
}

function fulfillBundle(bytes32 _requestId, uint256[] memory _values)
    public recordChainlinkFulfillment(_requestId)
{
    // Bundle slot [2] = EMA 1H (20-period)
    // Bundle slot [13] = EMA 1D (20-period)
    // Bundle slot [14] = EMA 1W (20-period)
    uint256 ema1d20 = _values[13];
    // Compare with EMA 50 from a separate Discovery request, or
    // use the 1H vs 1D EMA spread as a momentum proxy
    lastBundle = _values;
}

The bundle returns all indicators for a token in one call. Slot positions are stable — new indicators are appended, never reordered.

Live Data — What the Feeds Return Right Now

Here's what Pythia returns on-chain as of April 2, 2026 (values from most recent oracle fulfillment):

Token	Feed Name	What It Returns
BTC	`bitcoin_RSI_1D_14`	Daily RSI (14-period) x 1e18
BTC	`bitcoin_EMA_1D_20`	20-day EMA price x 1e18
BTC	`bitcoin_EMA_1D_50`	50-day EMA price x 1e18
BTC	`bitcoin_BOLLINGER_1D_UPPER`	Upper Bollinger Band x 1e18
SOL	`solana_RSI_1H_14`	Hourly RSI x 1e18
AAVE	`aave_EMA_5M_20`	5-minute EMA x 1e18

Feed names follow the pattern: {engine_id}_{INDICATOR}_{TIMEFRAME}_{PARAM}

21 tokens available including BTC, SOL, AAVE, UNI, SUI, TAO, RENDER, ONDO, and more.

Try It Free (No Signup Required)

Pythia runs a free faucet on Polygon mainnet — PythiaFaucet. No LINK needed, 5 requests per day per address. Call requestIndicator("bitcoin_RSI_1D_14") directly on Polygonscan.

For AI-assisted development:

pip install pythia-oracle-mcp

Use with Claude, Cursor, Windsurf, or any MCP-compatible AI tool. Ask your assistant "What RSI feeds does Pythia have for Bitcoin?" — it calls get_token_feeds("bitcoin") and returns every available feed name, timeframe, and contract address.

Solidity examples:

Full contract examples at github.com/pythia-the-oracle/pythia-oracle-examples

Summary

You cannot calculate RSI, EMA, or Bollinger Bands on-chain economically
Pythia delivers pre-calculated indicators via Chainlink's Direct Request pattern
Your contract sends a request + LINK, receives the value in a fulfill() callback
All values scaled by 1e18. Feed names: {engine_id}_{INDICATOR}_{TIMEFRAME}_{PARAM}
Real use cases: RSI-gated vaults, EMA crossover signals, volatility circuit breakers
Free faucet on Polygon mainnet — no signup, no LINK needed

The feeds are live. The only thing left is what you build with them.

Explore feeds: pip install pythia-oracle-mcp | Docs: pythia.c3x-solutions.com

Making Your Gamma LP Range Indicator-Aware with On-Chain Bollinger Bands

Pythia Oracle — Wed, 01 Apr 2026 08:32:57 +0000

Gamma Strategies' own research repository uses Bollinger Bands to calculate LP range bounds. The insight: a Bollinger Band is a statistical measure of how wide a price range needs to be to capture most of the volatility — which is exactly what you want for a Uniswap v3 LP position.

The problem is that Gamma's implementation runs off-chain. The range computation happens in Python, then gets submitted to the Hypervisor contract via rebalance().

This tutorial shows how to move that decision fully on-chain using Bollinger Band feeds, so a keeper contract can rebalance autonomously without any off-chain computation.

How Gamma positions work

A Gamma Hypervisor holds two simultaneous Uniswap v3 positions:

Base position (baseLower to baseUpper) — straddles the current price, holds both tokens
Limit position (limitLower to limitUpper) — one-sided, holds surplus of one token

A rebalance() call burns both positions, sets new tick bounds, and re-mints liquidity. The key function:

function rebalance(
    int24 _baseLower, int24 _baseUpper,
    int24 _limitLower, int24 _limitUpper,
    address _feeRecipient,
    uint256[4] memory inMin,
    uint256[4] memory outMin
) external onlyOwner

From Bollinger Bands to Uniswap ticks

Uniswap v3 positions are defined in ticks, where price = 1.0001^tick. Uniswap provides TickMath.getTickAtSqrtRatio(uint160 sqrtPriceX96) for this conversion — there's no direct price→tick helper. You compute sqrtPriceX96 first:

sqrtPriceX96 = sqrt(rawPrice) × 2^96 / 10000

...where rawPrice is the Pythia/Chainlink feed value scaled 1e8. Bollinger Bands give you upper and lower price bounds — convert each to sqrtPriceX96, call TickMath.getTickAtSqrtRatio(), round to tick spacing, and you have your LP range.

Note on token ordering: Uniswap v3 prices are always token1/token0 sorted by address. Verify your pool's ordering — if inverted, use the reciprocal price.

The interface

interface IPythiaFeed {
    function latestAnswer() external view returns (int256);
}

interface IHypervisor {
    function rebalance(
        int24 _baseLower, int24 _baseUpper,
        int24 _limitLower, int24 _limitUpper,
        address _feeRecipient,
        uint256[4] memory inMin,
        uint256[4] memory outMin
    ) external;
    function baseLower()  external view returns (int24);
    function baseUpper()  external view returns (int24);
}

The keeper contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.18;

import "@uniswap/v3-core/contracts/libraries/TickMath.sol";

contract BollingerKeeperGamma {
    IPythiaFeed public immutable bollingerUpper;
    IPythiaFeed public immutable bollingerLower;
    IPythiaFeed public immutable spotPrice;
    IHypervisor public immutable hypervisor;

    address public owner;
    int24   public tickSpacing;
    int24   public limitBuffer = 500;
    uint256 public rebalanceThresholdBps = 500; // 5%

    constructor(
        address _bollingerUpper, address _bollingerLower,
        address _spotPrice, address _hypervisor, int24 _tickSpacing
    ) {
        bollingerUpper = IPythiaFeed(_bollingerUpper);
        bollingerLower = IPythiaFeed(_bollingerLower);
        spotPrice      = IPythiaFeed(_spotPrice);
        hypervisor     = IHypervisor(_hypervisor);
        tickSpacing    = _tickSpacing;
        owner          = msg.sender;
    }

    /// @notice Calculate new tick ranges from current Bollinger Bands.
    function calculateRanges()
        public view
        returns (int24 baseLower, int24 baseUpper, int24 limitLower, int24 limitUpper)
    {
        int256 upper = bollingerUpper.latestAnswer();
        int256 lower = bollingerLower.latestAnswer();
        int256 spot  = spotPrice.latestAnswer();

        baseLower = (priceToTick(lower) / tickSpacing) * tickSpacing;
        baseUpper = ((priceToTick(upper) / tickSpacing) + 1) * tickSpacing;

        if (spot >= (upper + lower) / 2) {
            limitLower = baseUpper;
            limitUpper = baseUpper + limitBuffer * tickSpacing;
        } else {
            limitLower = baseLower - limitBuffer * tickSpacing;
            limitUpper = baseLower;
        }
    }

    /// @notice Returns true if the current range has drifted beyond threshold.
    function shouldRebalance() public view returns (bool) {
        (, int24 newBaseUpper,,) = calculateRanges();
        int24 currentUpper = hypervisor.baseUpper();
        int24 drift = newBaseUpper > currentUpper
            ? newBaseUpper - currentUpper
            : currentUpper - newBaseUpper;
        return uint256(uint24(drift)) * 10000 /
            uint256(uint24(currentUpper > 0 ? currentUpper : int24(1)))
            > rebalanceThresholdBps;
    }

    /// @notice Execute rebalance. Callable by keeper when shouldRebalance() is true.
    function rebalance() external {
        require(msg.sender == owner || shouldRebalance(), "not needed");
        (int24 bL, int24 bU, int24 lL, int24 lU) = calculateRanges();
        uint256[4] memory zeros;
        hypervisor.rebalance(bL, bU, lL, lU, owner, zeros, zeros);
    }

    /// @dev Uses Uniswap TickMath for accurate price→tick conversion.
    ///      sqrtPriceX96 = sqrt(rawPrice) * 2^96 / 10000  (for 1e8-scaled prices)
    function priceToTick(int256 price) public view returns (int24 tick) {
        require(price > 0, "invalid price");
        uint256 sqrtP = _sqrt(uint256(price));
        uint256 sqrtPriceX96 = (sqrtP * (2 ** 96)) / 10000;
        tick = TickMath.getTickAtSqrtRatio(uint160(sqrtPriceX96));
        tick = (tick / tickSpacing) * tickSpacing;
    }

    function _sqrt(uint256 x) internal pure returns (uint256 y) {
        if (x == 0) return 0;
        uint256 z = (x + 1) / 2;
        y = x;
        while (z < y) { y = z; z = (x / z + z) / 2; }
    }
}

Live Bollinger Bands right now

BTC Bollinger Bands (1D) are currently extremely tight: $67,335 to $67,790 — a $455 range. That's a Band squeeze, which typically precedes a breakout. A keeper running this contract would have set a narrow base position and widened the limit buffer to catch the move.

// Read live Bollinger Bands on-chain (Discovery tier — 0.01 LINK per request)
requestIndicator("bitcoin_BOLLINGER_1D_UPPER");  // → fulfill() receives upper band x 1e18
requestIndicator("bitcoin_BOLLINGER_1D_LOWER");  // → fulfill() receives lower band x 1e18

// Free trial: use PythiaFaucet (0x640fC3...0A) — no LINK needed, 5 requests/day

To discover all available Bollinger feeds before writing your contract, use the Pythia MCP server — it works with Claude, Cursor, Windsurf, and any MCP-compatible AI tool:

pip install pythia-oracle-mcp

Then ask your AI assistant: "What Bollinger Band feeds does Pythia have for Bitcoin?" — it calls get_token_feeds("bitcoin") and returns every available feed name, timeframe, and integration details.

Automating the keeper

Wire rebalance() to Chainlink Automation or Gelato with shouldRebalance() as the trigger condition. The keeper checks the Bollinger Band width against the current position and rebalances only when the range has drifted enough to matter. No off-chain Python, no subgraph queries.

What else is available

All feeds — EMA, RSI, VWAP, Bollinger Bands, volatility, liquidity — are available on-chain via Pythia as standard Chainlink-compatible feeds. 22 tokens, 4 timeframes, Polygon mainnet. Free testnet faucet, no signup.

How to Get On-Chain RSI, EMA, and Bollinger Bands in Your AI Agent

Pythia Oracle — Wed, 25 Mar 2026 16:38:00 +0000

If you're building an AI agent that touches DeFi — a trading bot, a vault rebalancer, a risk monitor — you've probably hit this wall: you can get price data on-chain, but not the indicators traders actually use.

RSI, EMA, Bollinger Bands, VWAP, volatility — these all require historical price series and rolling calculations. Smart contracts can't do that natively, and most oracles only deliver spot prices.

Pythia solves this. It's an Chainlink oracle that calculates technical indicators off-chain and delivers the results on-chain. hundreds of indicator feeds across a growing list of tokens, updated continuously.

Here's how to use it in your AI agent or smart contract.

Option 1: MCP Server (for AI Agents)

If you're building with Claude, Cursor, Windsurf, or any MCP-compatible AI agent, the fastest path is the MCP server:

pip install pythia-oracle-mcp

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "pythia-oracle": {
      "command": "pythia-oracle-mcp"
    }
  }
}

Claude Code

claude mcp add pythia-oracle -- pythia-oracle-mcp

Cursor / Windsurf / VS Code

Add to your MCP settings:

{
  "pythia-oracle": {
    "command": "pythia-oracle-mcp"
  }
}

Once connected, your AI agent can query Pythia directly:

"What's the current RSI for Bitcoin?"
"Show me all indicator feeds for Solana"
"Is the oracle healthy? Check uptime."
"Give me a Solidity contract to consume the speed bundle"

The MCP server exposes 7 tools: list_tokens, get_token_feeds, get_market_summary, check_oracle_health, get_contracts, get_pricing, and get_integration_guide.

Option 2: LangChain (for Python Agents)

If you're building with LangChain or LangGraph:

pip install langchain-pythia

from langchain_pythia import PythiaOracleTool

# Create the tool
pythia = PythiaOracleTool()

# Use in any LangChain agent
from langchain.agents import AgentExecutor, create_tool_calling_agent
agent = create_tool_calling_agent(llm, [pythia], prompt)

The tool handles natural language queries about tokens, feeds, health, contracts, and integration code — same capabilities as the MCP server.

Option 3: Direct Smart Contract Integration

For on-chain consumption, your contract calls Pythia through Chainlink's oracle pattern. Here's the minimal Solidity:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "@chainlink/contracts/src/v0.8/ChainlinkClient.sol";contract MyDeFiAgent is ChainlinkClient {
    using Chainlink for Chainlink.Request;

    uint256 public btcRsi;

    // Pythia operator on Polygon
    address constant OPERATOR = 0x2b12c1eC4e1109D1D8f78CfA1b454a4903E8f68;

    function requestBtcRsi() external {
        Chainlink.Request memory req = _buildChainlinkRequest(
            "DISCOVERY_JOB_ID", // 0.01 LINK per request
            address(this),
            this.fulfill.selector
        );
        req._add("feed", "bitcoin_RSI_1H_14");
        _sendChainlinkRequestTo(OPERATOR, req, 0.01 ether);
    }

    function fulfill(bytes32 requestId, uint256 value) 
        public recordChainlinkFulfillment(requestId) 
    {
        btcRsi = value; // RSI scaled to 1e18
    }
}

Pricing Tiers

Tier	Cost	What You Get
Discovery	0.01 LINK	Single indicator per request
Analysis	0.03 LINK	Category bundle (all EMAs, all RSIs, etc.)
Speed	0.05 LINK	All indicators for one timeframe
Complete	0.10 LINK	Everything for a token

There's also a free faucet contract — 5 requests/day, no LINK needed. Perfect for testing.

What Indicators Are Available?

Pythia calculates 5 indicator types across 4 timeframes for each token:

EMA (Exponential Moving Average) — trend direction
RSI (Relative Strength Index) — overbought/oversold
Bollinger Bands (upper + lower) — volatility channels
Volatility — realized price volatility
USD Price — spot price baseline

Timeframes: 5-minute, 1-hour, 1-day, 1-week

Currently covering 20+ tokens including BTC, SOL, TAO, RENDER, ONDO, FET, SUI, INJ, TIA, POL, AAVE, UNI, LINK, COMP, CRV, and more — with new tokens added regularly

These aren't just price feeds — they're the same calculated metrics that quantitative traders and DeFi protocols need for automated decision-making.

Why This Matters for AI Agents

Most AI agents that interact with DeFi are flying blind. They can see prices, but they can't see momentum, volatility regimes, or mean-reversion signals without building their own indicator pipeline.

With Pythia, your agent gets pre-calculated, on-chain-verified indicators with a single call. Use cases:

Vault rebalancing — trigger rebalance when RSI crosses 70 or Bollinger width expands
Risk monitoring — alert when volatility spikes above threshold
Trading signals — combine EMA crossovers with RSI for entry/exit logic
Portfolio analysis — real-time calculated metrics across all supported tokens

Get Started

MCP Server: pip install pythia-oracle-mcp (PyPI)
LangChain: pip install langchain-pythia (PyPI)
Solidity Examples: pythia-oracle-examples
Live Feed Explorer: pythia.c3x-solutions.com
GitHub: pythia-the-oracle

If you're building AI agents for DeFi, this is the missing data layer.