Molpha Oracle
Programmable decentralized oracle that transforms any public API into an on-chain data feed — instantly
On-chain activity
Molpha Oracle Protocol
Molpha Oracle Protocol implements decentralized oracle infrastructure through bonded verifier nodes coordinated via a leader-coordinator model. The system utilizes Schnorr signature aggregation for efficient signature verification and sparse Merkle tree commitments for data integrity proofs. Feed creators define API endpoints and update frequencies while independent verifier nodes fetch data, validate through job-based verification protecting against lazy-signing attacks, and publish aggregated results on-chain with USDC-denominated subscriptions enabling predictable pricing.
Molpha Oracle
Molpha Oracle is a programmable oracle infrastructure protocol built on Solana. Where established oracle networks publish fixed catalogs of price feeds that developers must petition to add, Molpha takes the opposite approach: any developer can point the protocol at any publicly accessible HTTP API and begin receiving threshold-signed, on-chain-verifiable data within a single transaction. There is no approval queue, no governance vote, and no sales call required.
The Core Problem Molpha Addresses
Traditional oracle networks are feed-centric. A protocol team decides which data sources matter, deploys the aggregation infrastructure for each, and developers integrate against the resulting catalog. This model works for high-liquidity price feeds but creates a bottleneck for every other use case — DePIN telemetry, invoice verification, proof-of-reserves for real-world assets, sports outcomes, compliance registry checks, and weather data all require either a custom integration deal or waiting for a network governance cycle.
Molpha reframes oracles as general-purpose data infrastructure. A "job" in Molpha's terminology is simply a definition of an API endpoint, a value extraction policy (JSON path, numeric type, freshness window), and a signing quorum. Once a job is registered on-chain, any application can request a fresh signed payload from the network on demand.
How Molpha Works
The protocol is pull-native, meaning applications request data when they need it rather than consuming continuously published feed values. The flow has four stages:
Fund. A developer or protocol activates a USDC subscription on Solana. Payment is denominated entirely in USDC — Molpha operates without a protocol token or governance token, which eliminates token-price exposure from infrastructure costs.
Describe. A job is created on-chain specifying the target API endpoint, parsing rules (including how to extract the canonical numeric value from a JSON response), quorum requirements, and freshness policy. Feed identity derives cryptographically from these request parameters, binding the payload to its configuration.
Request. The Molpha SDK sends a request through the Gateway, the protocol's HTTP interface. A deterministic selection process — keyed on job ID, registry version, and canonical timestamp — picks eligible signers from the node network. Independent nodes fetch the API, converge on a canonical value, and each sign using secp256k1 keys. The resulting threshold aggregate Schnorr signature is produced using plain-sum aggregation with proof-of-possession (PoP), which guards against rogue-key attacks at registration time rather than using delinearization coefficients.
Verify. The signed DataUpdateResult payload can be verified on-chain across three distinct virtual machine families — Solana, EVM-compatible chains, and Starknet — using a single signature. No per-chain feed publishing is required, and no cross-chain bridge infrastructure is involved. Stateless verifiers mirror the node key set and execute verification logic against calldata alone, holding no job, round, feed, or reward state themselves.
Technical Architecture
The protocol's five components are designed to minimize trust surface:
The Gateway handles HTTP execution requests and delivers DataUpdateResult payloads to application code via the TypeScript SDK.
The Node Network consists of operator nodes holding secp256k1 keys. Signer selection is deterministic and recalculated on-chain without trusting caller input, and the signersBitmap is encoded directly into each signature to prevent manipulation of which operators participated in a given round.
The Solana Program maintains the on-chain registry, job definitions, subscriptions, and feed state, with permissionless write verification.
The Stateless Verifiers are deployed per EVM chain and for Starknet. Because verification is stateless — everything arrives in calldata — historical rounds remain permanently verifiable and freshness policy is enforced by the consuming application, not the oracle.
The SDK (@molpha-oracle/sdk v0.4.0, TypeScript) abstracts all gateway and Solana interaction and provides chain-agnostic argument builders so the same application code can request and verify data across supported networks.
An additional MCP server (@molpha-oracle/mcp) enables AI agent integration through the Model Context Protocol, with support for Cursor, Claude, and Codex environments. This positions Molpha to serve autonomous agent workflows — for example, an agent acting on verified payment status or portfolio rebalancing signals drawn from web APIs.
Use Cases
The flexibility of the job-based model opens oracle infrastructure to categories of data that price-feed catalogs have historically underserved:
AI Agents can act on verifiable web data — confirmed payment status, API-triggered rebalancing signals, external event outcomes — without trusting off-chain relayers.
Prediction Markets can settle using verified outcomes pulled directly from authoritative sources rather than relying on manual resolution or optimistic dispute windows.
Real-World Assets and Finance can reference off-chain data such as NAV calculations, SOFR rates, and proof-of-reserves directly in on-chain logic.
DePIN Networks can verify network conditions — uptime, coverage metrics, device telemetry — without bespoke oracle integrations.
Compliance and Registries can check license validity, KYC status, or sanctions flags against live API sources, creating on-chain attestations tied to real-time data.
Supply Chain applications can verify logistics events — shipment delivery, customs clearance — against carrier or customs APIs.
Payment Model and Node Incentives
Molpha's decision to denominate everything in USDC rather than a protocol token is an architectural choice as much as a business one. Developers pay predictable monthly subscription fees without exposure to oracle token price volatility. Node operators earn USDC for signing valid data, with bonded collateral at stake to enforce honest behavior. The protocol's design allows permissionless node entry — there is no cap on operators and no governance gate on participation, which is intended to produce a competitive and decentralized verifier network over time.
Current Status
As of 2025, Molpha is in testnet. The project shipped "Albyn," its first public testnet, offering developers 20 testnet USDC and faucet access to test the full flow: subscribing on Solana devnet, creating custom oracle jobs, triggering gateway rounds, receiving threshold-signed payloads, and verifying results on-chain. A subsequent testnet phase, "Brebeneskul," continued development of the permissionless node network and pay-per-request infrastructure. Open-source repositories on GitHub include the TypeScript SDK, the MCP server, and molpha-verifier — a Rust library for verifying DataUpdate aggregate Schnorr signatures using secp256k1 — all published under the Molpha organization.
Contents
- The Core Problem Molpha Addresses
- How Molpha Works
- Technical Architecture
- Use Cases
- Payment Model and Node Incentives
- Current Status
Solana Token Markets
