6. Oracle

Configuration & Mutability

Configuration: In the market configuration, the creator must specify the address of the oracle contract. The only permitted oracles on Perp City are index oracles which are generated by the beacon contract factory and listed in the beacon contract registry (See: Strobe Protocol).

Each oracle is designed to serve as the index for a perp market, where beacon templates are used to enforce the behavior of the index and the way that it interprets data.

Mutability: Currently, the oracle source is immutable and cannot be changed once a market has been published. In the future, we have plans for index oracles to be verifiably upgradeable, which is important for ML measurements that are prone to degradation over time.

Index Behavior for Liquidity Provisioning

Perp City index constructions offer guarantees not only about manipulation-resistance but also index behavior. This means an index can be engineered to have properties amenable to market making. Provisioning liquidity for new and exotic markets is difficult, but if the immediate risks faced by market makers can be bounded or mitigated by design, then the challenge becomes tractable.

Market makers attempts to quote the narrowest spread possible as consistently as possible. Their ability to do so depends primarily upon the following behavioral features of an index:

1. Volatility. The higher the short-term volatility of the index, the greater the uncertainty in inventory value between trades. Moderate, well-characterized volatility encourages activity; excessive volatility forces wider spreads and reduces liquidity.
2. Gap Risk. Discontinuous jumps — large, sudden changes in index level — are especially dangerous because they cannot be hedged in real time. When gap risk is high, market makers must charge a premium in the spread to compensate for potential instantaneous losses.
3. Hedgeability. Market makers depend on the ability to offset temporary inventory imbalances, either directly by trading the same underlying or indirectly through correlated assets. An index that evolves in a way that allows continuous or approximate hedging supports tight, stable spreads; one that does not requires larger buffers and more capital.

In short, an index should be smooth enough to hedge, but not so static as to discourage trading. Because Perp City's initial indices have no underlying spot markets, direct delta hedging is not possible. However, indices can be constructed that are correlated external liquid markets, enabling cross-hedging. Correlation allows market makers to partially offset inventory risk — the event that a market maker is caught with directional exposure and the price moves against them. Higher correlation lowers the value at risk of their positions and thus the capital required to withstand volatility. Ultimately, hedgeability depends on what an index tracks and how well. This is an empirical data science problem for which the Perp City index development environment provides tooling.

By contrast, volatility and gap risk can be addressed directly via the mathematics of index functions. Assuming the efficient operation of Perp City markets — contract prices track indices and funding remains smooth — index functions can be designed to provide to endow indices with specific, risk-mitigating behaviors. Different contexts will call for different properties, and therefore different index functions. Here are a few such properties:

• Semimartingale. Baseline good behavior; no-arb pricing theory applies; continuous hedging and self-financing strategies are well-defined; true of all Perp City index functions.
• Bounded Jumps. Limits how far an index can move on any update, directly controlling gap risk.
• Finite Activity. Controls how frequently an index updates; particularly relevant when event times are irregular.
• Volatility Targeting. Sets "spread temperature" so market makers can plan around a known variance budget.
• Reliable Mean Reversion. Embeds mean-reversion with long term mean and reversion rate — particularly relevant when direct hedging is unavailable.
• Bounded Range. Establishes explicit floors and ceilings, bounding worst case losses.

Index Functions

A measurement stream by itself cannot be exposed as a tradeable index in most cases. For example, if the measurement space is small and discrete (as in the case of a binary classification model) then the measurement stream will not be suitable as an index. Or, if the measurement stream is real-valued but highly volatile, then it will also be unsuitable.

Index functions transform measurement streams into tradeable indices. They look at index history until present and the next measurement in order to compute the next index value. Explicitly, given a measurement space $\mathsf{M}$, an index function is a recursive function

$$f_{\mathsf{idx}}: \mathbb{R}_{+}^{l > 0} \times \mathsf{M} \longrightarrow \mathbb{R}_{+}.$$

Given a stream of index values until time $t^{*}$, $(x_{t})_{t \le t^{*}}$ and a measurement $m_{t^{*}+1}$ for time $t^{*}+1$, the index value at time $t^{*}+1$ is then computed as

$$x_{t^{*}+1} = f_{\mathsf{idx}}((x_{t})_{t \le t^{*}}, m_{t^{*} +1}).$$

Index Function Considerations

One immediate consideration is how $f_{\mathsf{idx}}$ should be parameterized. In the first example given above, one chooses a volatility and class imbalance parameter. This is advantageous in the sense that the creator of the index can intentionally choose $\sigma$, for example, to be very small, creating near linear evolution in log space, favoring resilience to short-term fluctuations, clear trends, and smoothness suitable for regime identification. In practice, parameterization of index functions requires a combination of opinionated design and statistical analysis of historical data. The class imbalance parameter would be obtained by back-predicting historical data.

Practically, $f_{\mathsf{idx}}$ is implemented in a smart contract and requires gas for computation and storage. In the second example given above, the index function is parameterized by $w$, requiring $w$ index values to be stored.

End-to-End Guarantees

At a high level, in order to guarantee index integrity, not only must measurement and index function computations be honest, but so must data provenance and query strategies. An index is defined by data source $s$, query strategy $f_{\mathsf{query}}$, computational sensor $f_{\mathsf{sense}}$, and index function $f_{\mathsf{idx}}$. We therefore require the following guarantees for the end-to-end security of an index:

1. Honest Data Stream $(d_{t})_{t \ge 0}$. This requires two conditions to hold:
   • Honest Provenance. Every sample $d_{t}$ in the data stream comes from $\mathsf{D}_{s}$
   • Honest Sample Selection. Every sample in the data stream is the result of running query strategy $f_{\mathsf{query}}$
2. Honest measurement stream $(m_{t})_{t \ge 0}$. Given an honest data stream, $m_{t} = f_{\mathsf{sense}}(d_{t}) \; \forall t$.
3. Honest Index Updates. Given an honest measurement stream and index until time $t^{*}$, the next index value is computed as $x_{t^{*}+1} = f_{\mathsf{idx}}((x_{t})_{t \le t^{*}}, m_{t^{*}}+1)$

Data provenance is in general not a simple problem to solve and depends greatly on $s$. However, there are many form evidence may take that $d_{t} \in \mathsf{D}_{s}$, depending on $s$. These range from signatures by trusted authorities, which may be necessary in cases of proprietary collection methodologies, to zkTLS, which can be used to verify any API response, and simple set membership proofs. In the case of physical sensors, an honest measurement stream can be attested directly by hardware signatures.

Likewise, honest sample selection is also not trivial, but is enabled, for example, by recent advances in verifiable databases that offer proof of SQL query. In this case, $f_{\mathsf{query}}$ is literally specified as in SQL. Each time a sample is appended to the data stream, it can be be accompanied by such a proof. Of course, full infrastructure of honest data streams is more involved than just composing proof of data provenance with a verifiable database. We are actively working towards such infrastructure.

In the case that the $s$ is public, updates can be optimistic relative to the honesty of the data stream. Disputed index updates can be adjudicated and vindicated disputers paid out.