Oracle consensus
The oracle adapter brings an agreed reference FX price into Soroban. It does not execute a bank conversion. The event records the pair, rate orientation, precision, observation policy, approved source, freshness bounds, quorum, and disagreement threshold.
Coverage and ecosystem access
We will bring the full FX rate catalogue currently configured in BlockFinaX to Stellar. The current application registry contains 51 FX pairs, spanning the following quote currencies. This is the migration baseline; it is broader than a two-pair pilot and will follow updates to the existing catalogue.
| Base currency | Quote currencies in the current registry |
|---|---|
| USD | GHS, NGN, KES, ZAR, TRY, XOF, XAF, TZS, UGX, RWF, ETB, EGP, MAD, TND, MZN, ZMW, MWK, AOA, CDF, SDG, GMD, SLL, LRD, BWP, NAD, SZL, LSL, SCR, MUR, DJF, ERN, SOS, BIF, CVE, KMF, MGA, STN |
| EUR | GHS, NGN, KES, ZAR, XOF, XAF, EGP, MAD, TND |
| GBP | GHS, NGN, KES, ZAR, EGP |
Other Stellar projects will be able to query these observations through a documented Soroban interface and API. Each observation will expose the pair, rate, precision, timestamp and source reference, with an explicit status for unavailable or stale data. We will publish a reference consumer contract and access terms.
The implementation will reuse our existing ingestion pipeline and validate the source mapping for every pair. A configured pair is not a guarantee of a fresh observation at every moment. We will check currency identifiers, redenominations, quote conventions and publication cadence during the port, and publish a catalogue-parity report. An oracle feed can cover a pair even when no protection event is offered for it; event availability also depends on the settlement policy and funded capacity.
Sources on Stellar
Reflector is a candidate public provider through SEP 40. Each pair must be checked for actual coverage, methodology, timestamps, and the history needed for the event's expiry policy. Pricing-engine history does not establish live oracle coverage. GHS, NGN, or KES support is not assumed.
For pairs needing custom data, registered operators can submit network-bound signed observations or authorized contract calls. The proposed adapter validates unique signers, source context, expiry window, positive prices, and maximum spread. A centrally operated signer set is labelled as such.
Consensus parameters
| Field | Meaning |
|---|---|
requiredSigners | Distinct approved operators required for a fixing |
toleranceBps | Maximum spread accepted by the selected policy |
maxAgeSeconds | Admissible observation age for that source cadence |
aggregation | Explicit mean, median, or provider policy |
sourcePolicyId | Immutable event reference to the source and observation rules |
The current documentation describes a median, while the inspected EVM contract implementation aggregates accepted rates using an average. The Stellar deployment manifest and tests must state the implemented aggregation explicitly. A chain migration will not silently pretend those methods are equivalent. The proposed default is parity with the existing event's agreed policy; changing it requires a newly versioned policy for newly created events.
Public evidence and failure handling
The planned oracle reads expose signer membership, policy, submissions, source timestamps, and finalized evidence. Duplicate signer submissions cannot satisfy quorum. Stale or conflicting inputs stop the affected fixing and new exposure; no unrestricted one-key price override is promised.
Reflector integration documentation and provider addresses are verified at deployment, not copied permanently into customer code. Sources: Stellar oracle providers and SEP 40.