RWA Perpetuals

A design for the oracle / mark-price / discovery-bounds / funding stack behind perpetuals on equities, gold and oil — centred on the core tension that the underlying closes, but the contract never does. Benchmarked against trade.xyz (Hyperliquid HIP-3) and Binance TradFi Perps, with four differentiation directions, computable models, and a parameter-calibration method.

Benchmarks: docs.trade.xyz · Binance TradFi Perps FAQ · model figures are illustrative — the scaling relationships are the takeaway.

0Core tension & thesis

Crypto perps can anchor directly to spot because spot also trades 24/7. The underlying markets for equities, gold and oil close — weekends, overnight, holidays and daily maintenance windows leave no external price to track. All of the design complexity in these products stems from "the underlying closes, but the contract never does."

Architectural philosophy of the benchmarks

Binance TradFi Perps: centralized exchange computation, two prices — Price Index (anchored to the real external market) and Mark Price (used for margining / liquidation / funding). Everything runs in a server black box.

trade.xyz: runs on a Hyperliquid HIP-3 deployment (HyperCore matching), splitting price into three — oracle price, mark price, external price. A Relayer cluster broadcasts on-chain roughly every 3 seconds, with the oracle updater's on-chain address published. A hybrid of on-chain settlement + off-chain oracle — but the Relayer remains a single operator.

·Three-way comparison (by session)

We also bring in ETFs — TradFi's mature solution to the same problem. An ETF's NAV ≈ external price, iNAV (every 15s) ≈ open-session oracle, market price ≈ contract price, premium/discount ≈ basis, and creation/redemption arbitrage ≈ funding.

1Decentralized, verifiable oracle

A "decentralized oracle" is really two separable things that requirements often bundle together:

• A. Decentralize the feeding/computation: a consensus value across many parties, solving liveness (single-point downtime) and correctness (single-point malice).
• B. Make the pricing on-chain-verifiable: publish "inputs + formula" so anyone can recompute, falsify and slash misbehaviour — solving accountability.

trade.xyz today has neither A nor true B: the on-chain address only proves "it pushed some number," not "the number was computed correctly" — the inputs and the EWMA process still sit in an off-chain black box. A very weak form of "verifiable."

Design ladder (weak to strong)

Recommended landing architecture

• Source: N Relayers with deliberately disjoint vendor sets (break common-cause failure), spanning different geographies / data providers.
• Aggregation: on-chain contract takes a stake-weighted median + t-of-n threshold signatures, tolerating a misbehaving minority.
• Verifiability: input hashes + output on-chain, deterministic and recomputable formula; plus optimistic dispute + slashing.
• Latency compensation: absorb aggregation latency with a longer τ during thin closed sessions.
• Degradation guards: when live Relayers fall below t, or vendor data goes stale, enter a conservative mode (freeze + tighten discovery bounds).

2Cross-anchored fair-value oracle

The danger of closed-session self-reference is not just "a single source" but the feedback loop: go long → push your own impact price up → oracle moves up → longs gain / counterparties approach liquidation → forced-liquidation buys push the book higher again → oracle keeps rising. Price becomes determined by "the venue's internal position structure." Cross-anchoring fundamentally reintroduces a gravitational centre outside the venue.

A four-step model

① Choose the proxy basket (four criteria, all required): still trading while the target is closed, highly correlated with the target, itself liquid and hard to manipulate, and with a data source disjoint from the primary vendor.
② Estimate beta (regress on overlapping hours when both are open):

The key outputs, beyond $\beta_i$, are $R^2$ (how much variance the proxies explain) and the residual variance $\sigma_\varepsilon^2$.
③ Construct the fair value (extrapolate from proxies' cumulative return since the close):

④ Dynamic blend:

$w_t$ adjusts with proxy reliability: fresh data, high $R^2$, and agreement between the two signals → high $w_t$; stale proxies or a dark session → $w_t\to 0$, falling back to the order book.

Use $R^2$ as an asset classifier

Degradation guards (the model's most fragile point)

1. Monitor $|\text{Orderbook}-\text{FairValue}|$ in real time; if it exceeds $k\sigma_\varepsilon$ and persists → cautious mode.
2. Proxies within the basket contradict each other → lower $w_t$.
3. Dark session (e.g. all of Saturday, no live proxy) → $w_t=0$ + tighten bounds + long τ.
4. Drive discovery-bound width by $\sigma_\varepsilon$: the more uncertain, the narrower the bound.

3Manipulation economics

We model the attack under "ratchet discovery bounds" as a computable cash-flow problem, then back out defensive parameters. An attacker (pushing price up) has net payoff:

Profit engine = liquidating shorts

Pushing price up only creates paper gains; to realize them, someone must be forced to buy at the inflated price — namely liquidated shorts (liquidation = forced market buy).

$N$ re-anchors determine the hard cap $H$; the wider the ratchet, the more shorts can be swept.

Manipulation cost = absorbing honest sell flow against an inflated bid wall

True price hasn't moved; the attacker maintains a bid wall $\delta$ above true price, and the EWMA drags the oracle up with time constant $\tau$. Climbing the range $R$ takes $T=R\tau/\delta$, during which honest flow sells to the attacker at rate $f$:

Back-solving the defensive parameters

Set profit < cost:

1. First measure $\text{OI}_{\text{liq}}$ and $f$ (from the real book and positions, not guesswork) — two state variables the product must monitor continuously.
2. Single-name equities (high idiosyncrasy, thin book, small $f$) → long τ, small N, narrow bounds.
3. Indices/commodities (deep book, large $f$, has a cross-anchor) → can widen N, shorten τ.
4. Make parameters a dynamic function of OI/liquidity, not static constants — a direct upgrade over per-asset static reset counts.

4Funding design & one-sided harvesting

The biggest blind spot in the docs. Conclusion: closed-session funding systematically "harvests those who are directionally right and subsidizes those who are wrong," and the knob controlling it is the very τ from Step 3.

Which price does closed-session funding use → self-reference

Funding is driven by the premium index $P=(\text{perp mark}-\text{oracle})/\text{oracle}$. When open, oracle = external truth, which is healthy; when closed, the oracle becomes a lagging EWMA of the venue's own book, so the reference becomes "perp price vs. a lagged smoothed version of itself" — self-reference. The problem is the lag.

Why it systematically harvests the trend side

A first-order EWMA fed a ramp of slope $g$ has a steady-state lag of exactly $g\tau$. During an uptrend:

But longs are the ones who are directionally right, driving genuine price discovery; shorts are wrong and being liquidated. You are using funding to subsidize the wrong side. The fraction of the move eaten by funding:

Opportunity: decouple the funding reference from the mark reference

The root flaw is making funding and liquidation share the same lagging oracle, yet the two have opposite requirements: liquidation must be responsive (slow = wrongful liquidation), funding must reflect deviation from true fair value (a lagging self-referential price manufactures a fake basis). The enhanced product separates the two:

1. Liquidation/mark keeps using a responsive oracle (short τ).
2. Switch the funding reference to Step 2's fair-value oracle → basis = perp − fair value = true premium. When the trend side is right, fair value rises in lockstep, the basis no longer pins positive, and the harvesting disappears; in dark sessions with no proxy, fall back to the internal EWMA + tighten.
3. Keep the "average premium index $\bar P$" (defends against settlement-timing games), and make the pay/receive caps symmetric to avoid structural one-sided draining.

·The pivotal parameter τ: triple coupling

Put the four steps together and one τ simultaneously controls three mutually conflicting objectives. This is the master pivot of the whole design, and the real reason trade.xyz cut τ from 8h to 30min — not just for responsiveness, but to plug funding harvesting.

·Parameter calibration (by asset)

Make parameters a mapping from "asset characteristics → parameters," adjusted dynamically with live OI/liquidity. Starting defaults below (illustrative; calibrate with real data per the Step 3 formula).

·Design decisions / open questions

1. Decentralization tier: stop at ladder level 1 (multi-Relayer median) or go to level 3 (optimistic/ZK verification)? Latency budget?
2. Layered decentralization: light decentralization for speed during active sessions, heavy decentralization + long τ for stable verifiability when closed — adopt or not?
3. Fair-value model choice: linear beta regression vs. Kalman filter vs. third-party vendor? How to set the correlation-breakdown degradation threshold?
4. Dark-session strategy: for proxy-less windows like all of Saturday, freeze vs. pure order book? How tight should bounds get?
5. Liquidation-side coupling: how tightly to couple "suspend liquidation outside bounds" with the ratchet? Does it pile up liquidations into the reopen?
6. Funding dual-price split: engineering complexity and consistency risk of using different price sources for mark vs. funding?
7. MM subsidy vs. tuning: model the cost of subsidizing f (weekend depth) against the opportunity cost of parameter tuning.
8. Transparency disclosure: expose basis/funding/premium-discount history as a public dashboard? For a data-first brand this is a product, not a burden.

·Appendix: runnable model code

import numpy as np
S0,d,theta = 100.0, 0.05, 0.90          # close / instant bound (1/leverage) / re-anchor threshold
short_OI, liq_span, liq_penalty = 10_000_000.0, 0.20, 0.005
scale = 0.5

def hard_cap(N):                         # hard cap H = S0*(1+d)^(N+1)
    H = S0*(1+d)**(N+1); return H, H-S0

def profit(N):                           # profit engine = shorts within liquidation reach
    H,R = hard_cap(N); move = R/S0
    frac = min(move/liq_span, 1.0)
    liqn = short_OI*frac; avgp = move/2
    return liqn*(avgp+liq_penalty), liqn, move

def burn(N, tau_min, f, delta_frac=0.01, cooldown_min=0.0):
    H,R = hard_cap(N); move = R/S0
    tau_hr = tau_min/60; dp = delta_frac*S0
    T = R/(dp/tau_hr) + N*cooldown_min/60        # climb time + cooldown
    return f*T*(move/2), T                        # cost ≈ f·T·avg premium

def net(N, tau_min=30, f=500_000, delta=0.01, cd=0.0):
    P,_,mv = profit(N); B,T = burn(N,tau_min,f,delta,cd)
    return P-B, P, B, T, mv

# Defense threshold: set profit < cost  ->  tau > delta·OI_liq / (f·R)
for N in [0,1,2,3]:
    n,P,B,T,mv = net(N)
    print(f"N={N}  move{mv*100:4.1f}%  profit${P:,.0f}  cost${B:,.0f}  net${n:,.0f}")

import numpy as np
scale, clamp = 0.5, 0.0005
r_h = 0.055/(365*24)                      # 5.5% annualized carry -> hourly

def sim_ramp(tau_min, move_pct=10.0, wh=48, fi=1):
    """Weekend genuine rise; oracle = lagging EWMA; compute the fraction longs keep"""
    n = int(wh*60); p = np.linspace(100, 100*(1+move_pct/100), n)
    o = np.zeros(n); o[0] = 100.0
    for t in range(1, n):
        b = np.exp(-1.0/tau_min); o[t] = b*o[t-1] + (1-b)*p[t]
    prem = (p-o)/o; fp = 0.0
    for s in range(0, n, fi*60):
        seg = prem[s:s+fi*60]
        if len(seg)==0: continue
        Pb = seg.mean()
        fp += scale*(Pb + np.clip(r_h-Pb, -clamp, clamp))   # longs pay F per interval
    return fp*100, (move_pct/100 - fp)/(move_pct/100)*100   # paid % , kept %

for tau,label in [(480,'8h'),(60,'1h'),(30,'30min'),(15,'15min')]:
    paid, kept = sim_ramp(tau)
    print(f"tau={label:5}  longs pay funding {paid:6.2f}%  keep move {kept:6.1f}%")

A write-up of an internal technical discussion, restyled for Axios Lab. Model parameters are illustrative; the value lies in the mechanism relationships and the calibration method, not the absolute numbers. Benchmark sources: trade.xyz official docs and the Binance "Perpetual Futures on Traditional Assets" FAQ. Before shipping, recalibrate every parameter with real order-book, position and vendor data. · Draft v0.1