When building useful peer-to-peer economies, your internal accounting often needs to understand what's happening in other contexts.
This week's release allows communities to securely bring external pricing data, both crypto and fiat, into their peer-to-peer accounting environments, enabling individuals to view price estimates converted to their preferred currency and unlocking dynamic smart agreements.
The Feature: Configurable Pricing Oracles
An oracle is a trusted data bridge for reporting price information from other contexts so that participants can make make decisions based on current market values.
Since Unyt applications can't natively "see" outside themselves, an oracle acts as a verified messenger — telling the system "here's what this asset is worth as of the latest price check." The Unyt Sandbox now makes use of an Oracle for both cryptocurrency prices (BTC, ETH, etc) and forex (foreign exchange) for traditional currency exchange rates (USD, EUR, TRY, etc.)
Because Unyt apps are built on Holochain, execution must be deterministic. If every node independently fetched the price of ETH from an API during validation, not only would that be quite expensive but slight timing differences could cause problems with regard to disagreements about which price is in effect.
To solve this, Unyt uses a hybrid approach:
- Designated Oracle: A Unyt app's
GlobalDefinitionexplicitly authorizes a specific "Pricing Oracle" key. - Off-Chain Fetching: An external bot holding that key fetches data from Web2 APIs.
- On-Chain Determinism: The bot publishes a
ConversionTableentry (a price sheet) to the network's shared storage (DHT) that is valid for a specific window of time (whether 1 minute, 1 hour, etc). This specific window of time can be thought of as a defined price cycle and the price sheet info can only be used as a valid input for smart agreement executions performed during that price cycle.
Because the data is committed as an immutable entry, all peers validate smart agreements against the exact same data point. The core Unyt application code remains lean and secure, while external data is allowed in through a strictly validated cryptographic doorway.
Initially, we are just using this price information for conversion to people's preferred currency when they are preparing to transact in units where external price information is available.
Easier to notice: $4000 for bandwidth or some extra zeros on an already long number?
Building Resilience: The Multi-Source Strategy
While pulling data from an API is standard practice, relying on a single API is risky. If the one oracle you are relying on glitches and reports ETH at $1 (something that recently happened), you don't want your smart agreements executing based on that bad data.
To protect against this, we've mapped out a multi-source resilience strategy for price information. Currently, the Unyt Sandbox release is using CoinGecko, CoinMarketCap, and CoinAPI for crypto prices as well as Twelve Data, and CoinAPI for Forex prices.
The Resilience Patterns:
- Single Source: Basic, but vulnerable to API glitches. Not recommended for production.
- Dual Source: The bot queries two APIs and averages them. However, if the two prices differ by more than a set margin (e.g., 5%), the bot drops the update for that cycle entirely. If price data for a time window is missing, automatically priced executions would be delayed temporarily. For our context, this is likely preferable to executing on demonstrably unreliable data.
- Triple Source (The Standard): The bot queries three APIs and averages them. If one source is an outlier (differing significantly from the other two), it is dropped, and the average of the remaining two is used. If all three wildly disagree, the unit is dropped for this cycle.
In the triple-source scenario, the system becomes resilient to any single API glitch messing up the network's perception of external price information.
Building Resilience: Answering Additional Concerns
The initial version is showing off this Oracle pattern demonstrated with a single agent acting as the Pricing Oracle.
For mission critical trading platforms, having a single internal oracle could lead to concerns about single point of failure similar to the ones described above.
However, a resilience pattern similar to what is being described for external price data sources can be used within a Unyt app with multiple authorized Oracles to enable a more robust price oracle system.
This implementation of oracles is primarily intended to
- enable users to be able to see and think about value in whatever units they are most comfortable thinking in and
- have pricing information to provide some guidance or sanity around proposed trades.
This is not configured for high frequency trading. For that, you would want to use different data sources and custom validation of the correctness and timeliness of data from those sources.
What This Release Enables for Communities
Oracles aren't magic, but they are a useful piece of infrastructure for connecting any particular Unyt network to the broader economic landscape.
- Preferred Currency Summarization Commmunities can allow their users to view proposed transaction values (or balance summaries) as converted to their preferred currency.
- Coordinated Smart Agreements: You can now build smart agreements that adjust dynamically based on external contexts. Imagine an escrow agreement that releases funds based on a USD value, or a recurring billing agreement that charges a dynamic amount of native units equivalent to €50.
- Seamless Trading: The Unyt UI now utilizes these on-chain price sheets to display real-time estimated values during multi-currency trades. This may enable a quick apples-to-apples comparison when trading different units with external price information, or just a sanity check thanks to translating price to a form you are more familiar with.
Try It Out
This functionality is live in the latest release of the Unyt Sandbox.
What would your project be able to coordinate if your internal accounting could securely react to external market data?
Get Started:
