OpenChainGraph Suite · ART-560 · Derivatives & Oracle Infrastructure

Oracle Price Aggregation

Computes the aggregate price a decentralized oracle network would publish from a set of individual submissions, and gives that print its own citable execution_hash. Four aggregation mechanisms are supported, each named by how it works rather than by any venue that runs it. Supply an optional prev_print_hash and a series of same-pair prints becomes a walkable chain; omit it and the output is byte-for-byte the unlinked print.

Aggregation step only, commit-reveal not modelled Every submission supplied and asserted, zero egress Optional per-print lineage submitter id private-input option (SPEC.md §25)
🔒 All inputs are processed locally in your browser. No data is transmitted. Do not enter real personal data — use synthetic or anonymised inputs only.
⚠ Not a price feed and not a market-data source. This computes what the selected mechanism yields on the submissions you supply. It is not a claim that any real oracle network did, or would, publish this number for this pair at this epoch.
Aggregation

The demo values below are synthetic and already loaded, so you can press Run without entering anything of your own.

Submissions
Outliers
Lineage
Rejected inputs
Execution Hash (SHA-256)
The four mechanisms
median_filtered_confidence_weighted_mean 1. median over ALL submissions (unweighted) 2. flag any submission deviating beyond the threshold from that median 3. aggregate = sum(price_i * confidence_i) / sum(confidence_i) over survivors
stake_weighted_median_frequency sort by price, accumulate weight, take the price at which cumulative weight first reaches 50% of total (a heavier submitter appears MORE OFTEN, it does not pull an average)
three_vote_confidence_median each publisher votes p, p+c, p-c aggregate = median of all votes aggregate confidence = max(dist to 25th pct, dist to 75th pct)
plain_median median of observations, plus an f-of-n readout: n >= 3f+1 tolerable faults, 2f+1 signatures required

Two implementations that disagree on the stake-weighted median convention produce different execution_hash values on identical inputs. This node pins the frequency convention explicitly and rounds every emitted number to a fixed decimal count, so the artifact is reproducible rather than merely plausible.

Per-print lineage

A mark-price history is only citable if the prints are linked. Supply the previous print's execution_hash and this print cites it: the artifact's chain.parent_hashes and chain.parent_tool_ids populate, and the print reports itself as chained. Leave it blank and the wiring contributes nothing at all, so the artifact is byte-identical to one produced with no lineage support. The citation lives in policy_parameters, so it is inside the hash; the chain fields sit outside the hash preimage, so populating them never moves the number.

What this does not do

It does not fetch, verify, or attest any price. Every submission, weight, confidence, timestamp and submitter identifier is supplied by you and merely asserted. It models the aggregation step only: the commit-reveal phase that precedes aggregation in most real networks is not represented, so nothing here shows whether a submission was validly committed before it was revealed. The outlier penalty rate is an informative readout computed from the stated formula, not an assertion that any penalty was applied or by whom.

Related

ART-561 consumes prints from this node: a basket valuation needs one rate per pair, and citing the print each rate came from is what makes the basket value auditable rather than merely stated. Cite this node's execution_hash, aggregated_price and aggregation_method when composing a basket or mark-price evidence pack.