Oracom does not push data. If you fetch and receive a timestamp, that is our best efforts based on information we reasonably believe to be correct at that moment. Want to know with certainty? Verify it.
Your smart contract fetches from api.oracom.io/read/~DJIA on whatever schedule you set. We handle the source connection behind that URL. When Yahoo Finance changes their endpoint in 2028, we update our mapping. Your contract keeps running. The ~CODE is the permanent address. The source behind it is our problem, not yours.
Read returns the last known value from our daily sweep — free, instant, no account required. Fetch queries the source live right now. Both are free.
When your contract fires for real, use Verify. Oracom fetches the source at your exact timestamp, generates a ZK proof, and records delivery on two chains. Keep the proof with your contract records.
Every index has a permanent six-character code. Maximum six characters. Hard limit. Geography prefix (2–3 chars) plus measure suffix (2–3 chars).
MUBIHT = Mumbai High Temperature. USUNEMP = US Unemployment Rate. DJIA retains its four-character universal code.
Once assigned, a code never changes.
Every index card in the directory has three actions:
Returns the last known value from the most recent daily sweep. Free. No authentication. Instant. Use this during development and testing.
Queries the original source right now and returns a fresh value. Free. Slightly slower because it hits the upstream source in real time.
Fetches the source at your specified timestamp, generates a zero-knowledge proof, and records delivery on Base mainnet and the ChronX DAG. This is the production action. This is what you use when money moves.
A MOSAIC is a composite index built from multiple underlying sources. You define the formula — which sources, what weights, what aggregation method. Oracom executes it and proves the computation.
Example: a parametric insurance contract might need a MOSAIC of three weather stations within 50km of the insured property. The MOSAIC aggregates all three with equal weight, and the ZK proof covers the entire computation — not just the final number, but every input and every step.
MOSAIC formulas are versioned. Every change is logged in the public changelog. Once locked, a formula cannot be silently modified.
Every Oracom response includes: fetched_at (when we last polled the source), next_poll_in_seconds (when we poll next), freshness ("live", "cached", or "live_fetch"), and batch_id (unique ID for this poll batch).
Tier 1 daily indexes are polled once per day at 06:00 ET. The value is the same all day. The timestamp tells you exactly when we got it.
High-demand indexes are polled more frequently as traffic warrants — from hourly to every 60 seconds during market hours.
Streaming subscribers receive guaranteed sub-minute polling. Contact us for pricing.
Your contract should always check fetched_at and decide if the data is fresh enough for its purposes. If not — call /fetch for a live source query. If you need a proof — call /verify. The choice is yours.
When you request a Verify, Oracom runs a zero-knowledge proof circuit that confirms:
1. The named source was queried at the specified timestamp.
2. The returned value matches what was delivered to you.
3. The computation (including any MOSAIC aggregation) was performed correctly.
The proof is recorded on two independent chains: Base mainnet (Ethereum L2) and the ChronX DAG. Neither is controlled by Oracom. The proof file is delivered to you and can be independently verified by anyone, at any time, without contacting Oracom.
Coming soon. The SDK will allow you to request Read, Fetch, and Verify directly from your contract code. TypeScript and Rust first, with Solidity hooks for on-chain verification.
A watch is a monitoring instruction. You tell Oracom: "Monitor ~DJIA for when it goes above 42,000." Oracom checks the index on every poll cycle. Results are available via GET /watch/<id>/status. Oracom does not push data.
Watch conditions: equals, above, below, changes. One-shot watches check once and deactivate. Recurring watches check every time the condition is met.
Oracom does not push data.
All data is provided in response to explicit fetch requests from the caller. Every response includes a UTC timestamp indicating when Oracom retrieved the data from the named source. That timestamp represents our best efforts based on information we reasonably believe to be correct at that moment.
Oracom does not originate, validate, or warrant any index data. The continued existence, methodology, weighting, and accuracy of any index is owned exclusively by its respective author or publisher.
Oracom does not participate in contract execution, trigger payouts, or initiate any action on behalf of any caller. Oracom is a reporter and notary. We report what public sources say. We prove what they said on request. Nothing more.
For certainty: verify it.
Every index and data point includes a two-character ds field indicating how the data was obtained. This is core to Oracom's notary function.
| Code | Meaning | Trust |
|---|---|---|
AP | Live API endpoint | Highest |
RT | Real-time stream | Highest |
CS | Official CSV/file download | High |
MN | Manually entered by Oracom | High |
WS | Scraped from official web page | Medium |
CA | Calculated from other indexes | Medium |
ML | AI or ML estimated | Medium |
SC | Digitized from scanned document | Lower |
IM | Estimated from chart image | Lower |
US | User-submitted | Unverified |
When ds is IM, SC, US, or ML, Oracom displays a warning on the index detail page and in API responses. Data points with these codes appear as hollow circles on charts.
Coming soon. REST endpoints for programmatic access to the full catalog, proof requests, and delivery status.