An oracle marketplace powered by x402 payments

Important notice

This whitepaper describes Oraqle on Solana as it stands on 10 October 2026.

Oraqle has no token. Nothing in this whitepaper depends on one.

1. Executive summary

Oraqle is an Oracle Marketplace on Solana, built to connect data providers with Solana programs, applications, and autonomous AI agents.

Through Oraqle, providers can publish oracle feeds, define their data methodology, set a price, and earn USDC whenever their signed reports are requested. Consumers can discover oracle feeds, pay for individual requests, and independently verify every returned report against the signer sets the Oraqle program keeps on chain.

Oraqle is not a single oracle provider. It is an open marketplace where multiple providers can publish and monetize different types of verifiable data through a shared protocol.

The marketplace may support oracle feeds for:

• Cryptocurrency and foreign exchange markets
• Equities and tokenized assets
• Interest rates and economic indicators
• Commodities
• Real estate
• Real-world assets
• Compute and AI markets
• Environmental observations
• Collectibles
• Prediction markets
• Custom structured data

Oraqle uses x402 as its payment infrastructure.

When a Solana program, application, or AI agent requests a protected oracle report, the endpoint returns an HTTP 402 Payment Required response containing machine-readable payment terms. The buyer authorizes payment in USDC, and Oraqle returns a cryptographically signed oracle report after successful settlement.

This creates a simple oracle transaction:

Discover an oracle. Pay per request. Receive a verifiable report.

Every report is signed twice over the same bytes: with ed25519, and with SLH-DSA-SHA2-128s (FIPS 205), a hash-based signature that no known quantum algorithm breaks. Both can be checked independently against the Oraqle program on Solana, the second one on chain with nothing but SHA-256. Payment confirms access to the report, while cryptographic verification confirms its integrity and authorized origin. After a quantum computer exists, the second signature still rules out a forged report under a signer registered before; section 14.3 says what it does not cover.

Oraqle charges a platform fee on oracle marketplace transactions: 10% of each payment, locked for each provider when that provider registers, and paid to Oraqle’s treasury. The rest of the payment belongs to the provider.

The Oraqle program, the gateway and the marketplace are built and tested on Solana; the program’s mainnet address is published when it is deployed. It lists 116 feeds today from 2 providers.

2. What Oraqle is

Oraqle is a marketplace infrastructure layer for publishing, discovering, purchasing, and verifying oracle data.

Traditional oracle networks generally determine which data sources, operators, and feeds are made available. Oraqle introduces a marketplace model in which independent providers can publish their own oracle feeds under transparent rules.

Each feed may define:

• The observation being reported
• Data sources and methodology
• Report schema
• Update frequency
• Maximum heartbeat
• Price per oracle request
• Available call packs
• Authorized signer
• Signer classification
• Number of upstream sources
• Confidence value
• Provider payout address

Consumers can compare available oracle feeds based on price, methodology, source count, freshness, signer type, and measured reliability.

Oraqle therefore operates as both:

1. An oracle discovery marketplace for finding suitable data feeds.
2. A verification protocol for confirming the integrity and origin of purchased reports.

x402 provides the payment layer that allows these oracle reports to be purchased programmatically.

3. The role of x402

x402 is not the core product of Oraqle. It is the payment protocol used by the Oracle Marketplace.

Its role is to make oracle data commercially accessible to software.

Without x402, buyers may need:

• API accounts
• Subscription plans
• API keys
• Manual billing
• Pre-negotiated provider agreements

With x402, a compatible application or AI agent can:

1. Request an oracle report.
2. Receive its price through HTTP 402.
3. Authorize payment in USDC.
4. Retry the request with payment.
5. Receive the signed oracle report.
6. Verify the report independently.

This allows oracle access to become machine-native, permissionless, and payable per request.

The relationship between the components is:

4. Core positioning

Oraqle should be described as:

An Oracle Marketplace powered by x402 payments.

Or, in a more technical form:

Oraqle is an open marketplace for discovering, purchasing, and verifying signed oracle reports, with per-request payments settled through x402 on Solana.

Oraqle should not primarily be described as:

A data marketplace powered by x402.

That description is not entirely wrong, but it is too broad and does not clearly communicate that the information is structured, signed, registered, and designed for onchain verification.

The term Oracle Marketplace should remain the primary category throughout the website, documentation, whitepaper, and launch communications.

5. The problem

5.1 Oracle infrastructure remains fragmented

Onchain applications depend on external information to operate. Lending markets require asset prices, derivatives require settlement values, tokenized assets require reference data, and autonomous agents require real-world observations before taking action.

However, access to oracle data remains fragmented.

Developers frequently need to:

• Integrate different oracle networks
• Negotiate with individual data providers
• Maintain multiple API subscriptions
• Manage separate authentication systems
• Trust centralized endpoints
• Build custom verification logic
• Pay recurring fees regardless of actual usage

Smaller or specialized datasets may not be available through established oracle networks because maintaining every possible feed is operationally inefficient.

This creates a gap between data providers that possess useful information and applications that need verifiable access to it.

5.2 Existing oracles are primarily networks, not marketplaces

Most oracle systems focus on delivering a predefined collection of feeds.

Oraqle introduces a different model.

Instead of acting only as a single oracle provider, Oraqle provides an open marketplace where independent providers can:

• Publish new oracle feeds
• Define their methodology
• Set their price
• Operate their own signer
• Receive payment per request
• Build a measurable reliability history

Consumers can evaluate multiple feeds and choose the oracle that best matches their requirements.

The marketplace model allows long-tail and specialized oracle data to become commercially available without requiring Oraqle to operate every data source directly.

5.3 Traditional data payments are not machine-native

Traditional data APIs often require:

• Account registration
• Monthly subscriptions
• API keys
• Credit-card billing
• Manual invoicing
• Fixed usage tiers
• Commercial agreements

This process is unsuitable for onchain programs and autonomous AI agents.

A machine needs to discover a resource, understand its price, authorize a bounded payment, receive the result, and verify it without human intervention.

x402 enables Oraqle to provide this experience at the HTTP request level.

5.4 Access alone does not prove integrity

Receiving information from an API does not prove:

• Which provider created it
• Which sources were used
• When it was observed
• Whether it has been modified
• Whether the signer is authorized
• Whether the report is still fresh
• Whether a program can verify it

Oraqle addresses this problem by delivering structured oracle reports, signed with ed25519 and with SLH-DSA, that can be verified independently.

6. Protocol design principles

Oraqle is designed around the following principles.

6.1 Marketplace first

Oraqle is an Oracle Marketplace, not a closed collection of centrally selected feeds.

The protocol should allow multiple providers to publish and monetize different categories of oracle data.

6.2 Verification before trust

Consumers verify every report themselves, on chain or with the SDK.

Every purchased report should include the information and cryptographic proof required for independent verification.

6.3 Payment per request

Consumers should be able to purchase the exact oracle report they need without committing to a recurring subscription.

6.4 Stable pricing

Oracle feeds are priced in USDC so providers and consumers can understand the real cost of each request.

6.5 Provider ownership

Providers control:

• Their data methodology
• Their feed configuration
• Their pricing
• Their signer
• Their payout address

Oraqle provides the marketplace, payment, onchain program, and verification infrastructure.

6.6 Agent-native access

AI agents should be able to discover, purchase, and consume oracle reports through machine-readable interfaces while operating under explicit spending limits.

6.7 Transparent economics

Marketplace fees and provider proceeds should be publicly measurable.

7. Protocol participants

7.1 Oracle providers

Oracle providers publish and maintain feeds.

A provider may be:

• A data company
• An independent researcher
• A financial-data provider
• A blockchain analytics platform
• A real-world sensor operator
• A compute marketplace
• A prediction platform
• A protocol
• An autonomous data agent

Providers are responsible for the accuracy, methodology, licensing, and availability of their feeds.

7.2 Oracle consumers

Consumers purchase signed reports.

Consumers may include:

• Solana programs
• Decentralized applications
• Trading applications
• Lending protocols
• Derivatives protocols
• Prediction markets
• Tokenized asset platforms
• Research tools
• AI agents
• Individual developers

Each consumer determines its own acceptable price, signer, freshness, source count, and confidence requirements.

7.3 Signers

Signers create cryptographic signatures for oracle reports.

A valid signature demonstrates that a specific authorized key signed a specific report.

Oraqle may recognize several signer classifications:

Managed signer. A signer operated through infrastructure managed or approved by Oraqle.

Provider signer. A signer operated independently by the oracle provider.

Aggregate signer. A future signer classification that may produce an aggregated report derived from multiple independent providers.

Every report states which classification signed it, and the product says so in words:

7.4 Facilitator

The facilitator verifies x402 payment authorizations and submits the associated settlement transaction.

Its role is the payment process.

Oraqle’s facilitator adds its signature to each payment as the fee payer and submits it. Its key holds a small SOL float for network fees, and payments go straight to the provider’s vault.

7.5 Oraqle protocol

Oraqle operates the shared infrastructure required for:

• Oracle discovery
• Feed registration
• Signer registration
• Marketplace presentation
• Payment negotiation
• Report delivery
• Report verification
• Reliability measurement
• Pack management
• Provider dashboards
• Developer tooling

8. Oracle feed lifecycle

8.1 Feed registration

A provider creates a feed by submitting its configuration to Oraqle.

The configuration should include:

• Feed name
• Feed identifier
• Provider identity
• Category
• Description
• Value type
• Decimal configuration
• Methodology
• Source declarations
• Source count
• Update frequency
• Heartbeat
• Price per request
• Pack options
• Authorized signer
• Signer classification
• Payout address
• Rights declaration

On chain, registering as a provider locks the current platform fee for that provider and fixes the address of its vault. A feed is created with its first signers, up to 16, and its identity (provider, slug, decimals, mode and schema) is fixed from then on.

8.2 Provider verification

Oraqle may require additional verification for certain feed classifications.

A managed or aggregate signer classification comes with an onchain attestation: the program registers one with the signature of Oraqle’s attester in the same transaction.

8.3 Feed publication

After registration, the feed becomes discoverable through the Oraqle Marketplace.

Consumers can review:

• Current price
• Methodology
• Data sources
• Report schema
• Signer classification
• Update heartbeat
• Provider identity
• Measured reliability
• Delayed public preview
• Available call packs

Before a feed is published, the provider attests that it has the rights to the source, and names that source.

8.4 Feed operation

The provider publishes updated signed reports according to its heartbeat.

Oraqle records:

• Observation time
• Publication time
• Expected heartbeat
• Delivered reports
• Feed availability

Reliability comes from Oraqle’s own probes and request log. A feed shows its reliability figures from its seventh day.

8.5 Report freshness

Every report the gateway sells is within twice its feed’s heartbeat, and a call is charged when it returns a report.

8.6 Feed archival

Prepaid call packs stay valid for their full term: a provider archives a feed after its packs have run their course.

9. Oracle request and payment flow

9.1 Discovery

The consumer searches the Oracle Marketplace and selects a feed based on:

• Price
• Category
• Provider
• Methodology
• Signer type
• Reliability
• Source count
• Confidence
• Update frequency

9.2 Initial request

The consumer requests the latest signed report.

If payment is required, the endpoint returns:

HTTP 402 Payment Required

The response includes machine-readable payment requirements.

9.3 Payment requirements

The payment requirements may specify:

• Payment scheme
• Network
• Payment asset
• Amount
• Recipient
• Authorization expiry
• Maximum settlement timeout

On Oraqle the scheme is exact, the network solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp, the asset the USDC mint, and the recipient always the provider’s program account, whose USDC account is its vault.

9.4 Local buyer validation

Before signing, the buyer validates:

• The network is Solana mainnet
• The payment asset is the expected USDC mint
• The requested amount matches the feed price
• The recipient matches the provider account the Oraqle program derives
• The payment remains within the buyer’s budget
• The authorization has an acceptable expiry

9.5 Payment authorization

The buyer partially signs one transaction holding a single USDC TransferChecked.

Signing costs nothing, and the buyer pays no network fee and holds no SOL.

9.6 Settlement

The facilitator validates the payment, adds its signature as the fee payer and submits the transaction.

USDC is transferred to the provider’s vault.

The gateway checks the payment, obtains and checks the signed report, settles on chain and reads the transaction back, in that order. Every charge comes with its report.

9.7 Report delivery

After settlement succeeds, Oraqle returns:

• The signed oracle report
• The report payload
• The signer address
• Feed metadata
• Encoded report data
• Payment settlement metadata
• Transaction signature where applicable

9.8 Verification

The consumer verifies the report before using it.

Payment proves that access was purchased. Verification determines whether the report is authentic and acceptable.

10. x402 payment infrastructure

10.1 Why Oraqle uses x402

x402 transforms a standard HTTP endpoint into a machine-payable resource.

This is particularly useful for Oracle Marketplace transactions because consumers may require one report rather than a full subscription.

x402 allows Oraqle to provide:

• Per-request pricing
• Machine-readable quotes
• Automatic payment negotiation
• Accountless purchases
• Agent-compatible spending
• Standard HTTP integration
• Stablecoin settlement

Any x402 v2 client can buy from Oraqle: a stock client with no Oraqle code in it pays and reads.

10.2 x402 is the payment layer

x402 is a supporting layer within Oraqle.

Its function is to communicate and settle payment requirements for protected oracle resources.

10.3 Separation of payment and verification

Oraqle intentionally separates:

11. USDC settlement

11.1 Stable marketplace pricing

Oraqle uses USDC as the settlement asset for oracle purchases on Solana.

Using a USD-denominated asset provides:

• Predictable provider pricing
• Clear consumer budgeting
• Easier revenue accounting
• Reduced token-price exposure
• Simple comparison between feeds

11.2 Payment without SOL

The payment path is x402’s exact scheme on Solana: the buyer partially signs one transaction holding a single USDC TransferChecked.

The transfer specifies:

• Sender
• Recipient vault
• Mint
• Amount
• A recent blockhash, which bounds its validity to about a minute

The facilitator adds its signature as the fee payer and submits the transaction.

This allows the buyer to pay without holding SOL for each request.

11.3 Settlement verification

Oraqle records a payment after reading the transaction back: it succeeded, and the vault’s USDC balance rose by exactly the price. The same signed payment presented twice is refused, and Solana itself refuses a transaction it has already processed.

11.4 Provider vault settlement

Payments are transferred to provider-specific vaults.

Each provider’s revenue lands in its own vault.

The vault separates:

• Provider proceeds
• Oraqle platform fees

This structure makes the economic relationship more transparent and restricts how provider funds can be withdrawn.

A vault is the USDC account of the provider’s program account, an address the program derives from the provider id and for which no private key exists. withdraw, open to anyone, pays the provider’s share to its payout address and sets the fee aside; sweep_fees sends the fee to Oraqle’s treasury.

12. Call packs

12.1 Purpose

Very small oracle payments may cost more to settle onchain than the data request itself.

Oraqle addresses this through prepaid call packs.

For example:

The buyer settles one payment and receives 100 oracle calls.

Settling one payment costs Oraqle’s fee payer about $0.002 in network fees, which a 10% fee covers from $0.02, and single payments settle from $0.05. A price per call under that floor is sold in packs that cost at least the floor.

12.2 Pack redemption

After purchase, calls can be redeemed without performing one blockchain transaction per request.

The buyer proves control of the purchasing wallet through an authenticated session or uses a restricted API key.

12.3 Current pack policy

The current implementation uses:

• 30-day pack validity
• Wallet-specific pack ownership
• Restricted API-key redemption
• Protection against archiving feeds with active pack obligations

13. Agent integration

13.1 Autonomous oracle purchases

AI agents can use Oraqle to:

• Search for oracle feeds
• Inspect prices
• Compare providers
• Evaluate metadata
• Purchase reports
• Consume existing packs
• Verify signed responses
• Pass reports to Solana programs

13.2 Agent spending controls

Agent clients should support:

• Maximum amount per request
• Maximum total spending
• Approved network
• Approved payment asset
• Approved providers
• Approved categories
• Maximum report age
• Minimum source count
• Accepted signer classifications

Oraqle’s SDK enforces every one of these, checked against the feed before any call is spent.

13.3 Restricted API keys

An Oraqle API key spends calls from an existing pack. Transfers, payments, pack purchases and withdrawals stay with the wallet.

14. Signed oracle reports

14.1 Report structure

An Oraqle report contains:

requestHash is zero today; it is used once parameterized reports exist.

14.2 ed25519 signatures

Reports are encoded in Borsh, 156 bytes of fixed size, and signed with ed25519.

This provides:

• Deterministic report encoding
• A domain string that keeps a report signature from meaning anything else
• Binding to the Oraqle program
• Onchain verification through Solana’s ed25519 precompile
• Protection against modified report fields

The signed message is "oraqle/report/v1", then the Oraqle program’s id (32 bytes), then the report. The program id keeps a signature from being replayed against another deployment of the same code.

14.3 Post-quantum signatures

Every Oraqle report is hybrid: the same message is signed with ed25519 and with SLH-DSA-SHA2-128s, standardized by NIST as FIPS 205, whose security rests on SHA-256.

• Each signer entry in a feed account holds both keys: the ed25519 address and the 32 byte SLH-DSA public key
• The managed attester vouches for both halves of a managed signer in one attestation
• A report is accepted when both signatures verify and both keys are the ones registered for its signer
• A provider keeps one secret: its SLH-DSA key is derived from its ed25519 seed

The SLH-DSA signature is 7,856 bytes, more than a Solana transaction holds, so a consumer that wants the post-quantum check on chain writes it into a buffer account in eight writes, then calls verify_report_pq, which repeats every check of verify_report and verifies the SLH-DSA signature with Solana’s SHA-256 syscall, in 340,000 to 410,000 compute units.

14.4 Sealed provider secrets

A provider’s upstream API key is sealed before it is stored, to two public keys of the worker at once: X25519 and ML-KEM-768 (FIPS 203). Both shared secrets go into one key, so a secret captured today stays sealed even if one of the two schemes falls later.

Solana’s own transaction signatures, which wallets, provider vaults and the signer registry use, are ed25519, as on every Solana program today; the post-quantum layer is the reports and the sealed keys.

14.5 Supplemental payloads

Some oracle reports may contain structured data beyond the primary numeric value.

The payload is canonicalized and hashed. The resulting hash is signed as part of the report.

Consumers can independently confirm that the returned payload matches the signed commitment.

14.6 Consumer verification policy

A consumer should check:

1. The ed25519 signature is valid.
2. The ed25519 signature verifies against the declared signer.
3. The SLH-DSA signature verifies over the same report.
4. The signer is authorized for the feed, with that SLH-DSA key in its entry.
5. The signer classification is acceptable.
6. The feed ID is correct.
7. The decimal configuration matches the feed account.
8. The report is sufficiently fresh.
9. The observation time is at or before the present.
10. The payload hash is correct.
11. The source count meets application requirements.
12. The confidence is acceptable.
13. The reported value falls within application-specific bounds.

The program’s verify_report instruction checks the signature through the ed25519 precompile, the signer set, the signer kind, the decimals and the age, and has no form without a maximum age; verify_report_pq does the same and checks the SLH-DSA signature too. A consumer program calls either through CPI and adds its own value bounds and the rule against going back to an older report.

15. Program architecture

Oraqle runs on one Anchor program on Solana.

15.1 Accounts

The program’s accounts record relationships between:

• Providers
• Feeds
• Schemas
• Decimals
• Authorized signers
• Signer classifications
• Provider vaults
• Fee configurations
• Payout addresses

A new payout address waits 48 hours before it can apply.

15.2 Report verification

The verify_report instruction validates reports against the feed account.

It checks:

• Report encoding
• Signature, through the ed25519 precompile
• Signer authorization
• Signer classification
• Registered decimals
• Feed identity
• Report age

It has no form without a maximum age.

verify_report_pq makes every one of these checks and then verifies the SLH-DSA signature, written into a buffer account beforehand, against the post-quantum key of the signer’s entry.

15.3 Vault derivation

Every vault address is derived from the provider id: the provider’s program account is a program derived address, and its vault is that account’s USDC account.

Clients can compare the payment recipient returned by the gateway with the expected provider account.

Registering creates both accounts and costs their rent.

15.4 Provider vault

A provider vault:

• Receives buyer payments
• Tracks the provider relationship
• Protects provider proceeds
• Separates the platform fee
• Restricts withdrawal destinations

Provider funds are withdrawn to the provider’s payout address.

15.5 Gateway

The Gateway manages:

• x402 quotes
• Payment verification
• Settlement
• Report delivery
• Pack redemption
• Sessions
• Agent credentials
• Rate limits
• API responses

Report validity is decided on chain by the program; the Gateway makes it convenient to reach.

16. Current technical parameters

The current implementation uses the following configuration:

The addresses above come from the deployment manifest, program/deployments/mainnet.json, of the cluster this site runs on.

17. Marketplace economics

17.1 Gross transaction value

Gross Transaction Value represents the total amount paid by a consumer for an oracle report or call pack.

Let:

• G = gross USDC payment
• f = provider-specific platform fee rate
• F = Oraqle platform fee
• P = provider proceeds

The calculation is:

F = G × f

P = G × (1 − f)

17.2 Example using a 10% platform fee

For a purchase of 1 USDC:

The platform fee is swept from the provider’s vault to Oraqle’s treasury.

17.3 Provider fee locking

A provider’s platform fee is fixed when the provider registers.

This gives providers predictable marketplace economics: a provider keeps the fee it registered at, and the fee for new providers is set in the program’s configuration, up to 20%.

18. Security model

18.1 Security objectives

Oraqle ensures that:

• A report shown as verified is verified
• Accepted reports come from authorized signers
• A buyer pays the authorized amount
• Payments use the expected asset and network
• Provider funds go to the provider’s payout address
• API keys spend calls from packs
• Every report carries its age for the freshness check
• Every report payload is bound by its hash

18.2 Buyer controls

Consumers should:

• Pin Solana mainnet as the expected network
• Pin the official USDC mint
• Validate the provider account
• Set a maximum spend per request
• Set a total spending budget
• Restrict accepted providers
• Restrict accepted signer classifications
• Require a maximum report age
• Validate settlement evidence

Oraqle’s SDK pins the network and the USDC mint, checks the provider account, applies a maximum report age and keeps a total budget by default. A cap per request and the accepted providers and signer classifications are one option each.

18.3 Provider controls

Providers should:

• Protect signer keys
• Isolate production infrastructure
• Authenticate Oraqle gateway requests
• Rotate signing keys
• Watch their feeds’ heartbeats
• Watch vault withdrawals
• Publish accurate methodologies
• Maintain legal rights to their sources

18.4 Treasury controls

Oraqle treasury operations should use:

• Dedicated wallets
• Public addresses
• Execution monitoring
• Periodic reconciliation

19. Governance and operations

19.1 Initial governance

During the initial phase, Oraqle is expected to use accountable team-led governance.

The team may manage:

• Provider registration
• Signer attestations
• Program configuration
• Treasury execution
• Protocol releases

The program’s addresses are listed in section 16. In it:

• A vault pays out to its provider’s payout address and the platform fee share
• An existing provider keeps its fee
• Providers manage their own feeds and signers
• A provider’s signing key stays its own
• A provider’s accounts, vault and feeds stay open for it

19.2 Progressive governance

Oraqle may progressively expand community participation in:

• Marketplace standards
• Provider requirements
• Feed categories
• Ecosystem grants
• Treasury reporting
• Protocol integrations
• Non-emergency parameters

20. Roadmap

Phase 1 · Core protocol on mainnet

Planned deliverables:

• Deploy the program on Solana mainnet
• Publish a complete deployment manifest
• Publish a verifiable build of the program
• Publish the Oraqle gateway at its production domain
• Improve protocol monitoring
• Improve provider onboarding

Phase 2 · Oracle marketplace expansion

Planned deliverables:

• Onboard independent providers
• Expand market-data feeds
• Expand economic feeds
• Expand commodity feeds
• Expand real-estate feeds
• Expand RWA feeds
• Expand compute and AI feeds
• Add provider profiles
• Improve reliability analytics
• Improve search and discovery

Phase 3 · Developer and agent infrastructure

Planned deliverables:

• Publish the consumer SDK
• Publish the provider signer SDK
• Publish the program client
• Publish the Rust crate for consumer programs
• Add API-key management
• Add agent spending controls
• Add provider alerts
• Add a public protocol status page
• Improve documentation and examples

The SDKs, the program client and the crate are built and tested, waiting to be published; API-key management and agent spending controls are built too.

Phase 4 · Oracle aggregation and reputation

Objective: Improve the quality and diversity of marketplace oracle feeds.

Potential deliverables:

• Cross-provider aggregate feeds
• Median calculations
• Quorum requirements
• Outlier exclusion
• Provider reputation
• Latency measurement
• Deviation measurement
• Expanded confidence reporting
• Historical performance analytics

Phase 5 · Advanced oracle infrastructure

Objective: Expand compatibility and delivery options.

Potential deliverables:

• Parameterized oracle requests
• Streaming reports
• SSE or WebSocket delivery
• Push-based oracle adapters
• Python SDK
• CSV export

The phases are listed in the order they are planned, without dates.

21. Legal and compliance considerations

Oracle providers must have the necessary rights to publish and commercialize their data.

Each feed carries the provider’s rights declaration, naming its source.

Today Oraqle has terms for buyers and providers, a privacy policy and a rights declaration per feed.

22. Conclusion

Oraqle is an Oracle Marketplace powered by x402 payments.

Its purpose is to create an open market where oracle providers can publish and monetize signed data while Solana programs, applications, and autonomous AI agents can purchase verifiable reports on demand.

Oraqle combines:

• Oracle feed discovery
• Independent data providers
• Transparent feed methodology
• Per-request pricing
• x402 payment negotiation
• USDC settlement
• Payment without SOL for the buyer
• Reports signed with ed25519 and SLH-DSA
• Onchain signer registration
• Onchain report verification
• Provider-specific payment vaults
• Measured reliability
• Agent-compatible access

x402 is the payment infrastructure that makes each oracle request machine-payable.

The Oraqle program makes each report independently verifiable.

The long-term credibility of Oraqle will depend on real Oracle Marketplace usage, reliable providers, and a secure program.