Anyperp

Abstract

Anyperp is a perpetual futures service on Solana on artists' monthly listeners: the count of unique listeners that a streaming platform shows on each artist's public profile page. Each artist is one market. A trader goes long or short the artist's index with USDC margin at up to 3× leverage, and one USDC vault takes the other side of every market. Two independent attestation roots observe the count in every 15-minute round, and a round prints only when both roots' signed observations agree within 0.5 %; the print is their median. An order fills at the first print whose observations were all fetched after the order landed. Open interest on each side of a market is capped at a quarter of the open interest at which buying a move in the count breaks even, so an attack on the number loses money at every push size. Markets enter through a bonded proposal, 14 days of shadow rounds, approval by three of five curators, a 48-hour timelock and 30 days of probation at a quarter of their caps. This paper sets out the mechanism, the two on-chain programs that enforce it and the services that operate it.

What Anyperp is

Anyperp turns a public audience number into a continuous market. The number is monthly listeners, an integer the platform publishes on each artist's profile page and updates as listening changes. Anyperp reads it, attests it through two independent roots and prints it as an index every 15 minutes. A perpetual on that index lets a trader hold a view on an artist's audience for as long as the view lasts: positions have no expiry, so nothing has to be rolled and no single snapshot decides the payout. A long gains when the audience grows, a short gains when it shrinks, and both pay or receive funding while they stay open.

Traders open isolated positions with USDC margin. Liquidity providers (LPs) deposit USDC into the vault and hold its share token, a receipt on the vault's net asset value (NAV). Proposers post a USDC bond to bring a new artist to market and earn a share of its trading fees. Curators, five members of whom three must agree, approve listings and their caps. Reporters post the roots' signed observations, and keepers finalize rounds, fill orders and liquidate; both roles are permissionless, because the programs check what is submitted, not who submits it. A guardian can pause a market for a bounded time and halt it once rounds have stopped printing, and it cannot write a price or move funds.

Two Anchor programs hold all state. anyperp_oracle runs the rounds, verifies the roots' signatures and keeps each metric's price history. anyperp_perps holds the vault, the markets, the orders and the positions, and takes its prices only from finalized oracle rounds. Sentinel, an off-chain service, drafts market specs and the cost dossiers behind each cap and flags anomalies for curators. It has no on-chain authority.

Two questions every metric market answers

A market on a web metric has to settle two matters before it is safe to trade: who attests the number, and what stops someone from moving it.

Anyperp answers the first with two attestation roots that do not depend on each other. Root 1 is a set of Reclaim attestors identified by secp256k1 keys. Root 2 is an independent notary with an Ed25519 key. Both key sets are allowlisted on chain, and the oracle program verifies each signature through Solana's signature precompiles in the same transaction that submits the observation. A round needs one valid observation from each root, and the two values must agree within 0.5 % before the round prints. No account, the admin included, can write a price.

Anyperp answers the second with arithmetic. Buying a move in the count costs money, and the cost grows with the size of the move and with the artist's level. A position profits from the same move in proportion to its notional. Below a certain open interest, the cost exceeds the profit whatever the size of the move. Anyperp caps each side's open interest at a quarter of that break-even point, so an attacker holding the largest position the market allows still loses at least three quarters of what the push costs. Chapter 3 derives the cap in full.

The design at a glance

Two-root oracle

A round opens every 15 minutes. Each root signs an observation whose source and fetch times fall inside the round, bound to that metric, that round and that root. finalize_round requires both observations, checks that they agree within 50 bps, takes their median, normalizes it to a fixed9 index and checks it against a ±10 % circuit band around the close 24 hours earlier. A round that fails a check prints nothing; the next round starts clean.

Capped open interest

Each market has a long cap and a short cap in USDC, set at listing from its cost dossier: $cap_{long} = \kappa\, c_{up} L$ and $cap_{short} = \kappa\, c_{down} L$, with $\kappa = 0.25$. Pushing a count down costs more than pushing it up, so the short cap is the larger of the two. Every opening fill is checked against its side's cap, counting all accounts on that side at the index of the print where it fills.

Next-print execution

An order is a request. It escrows margin, names an acceptable price and waits. It fills at the first print whose observations from both roots were all fetched after the order landed. An order placed after the source changes fills at a print that already contains the change, so a stale index never sets a fill price.

One USDC vault

One vault takes the net skew of every market. Fill prices carry a skew premium, $I_t\left(1 + \frac{s_{before} + s_{after}}{2S}\right)$, funding drifts toward the side that reduces the vault's exposure, and a borrow fee rises as a side fills toward its cap. Deposits are priced at the next complete NAV and withdrawals wait in a 72-hour queue, so LPs cannot enter or leave ahead of a print they can already see.

Curated, bonded listing

Anyone can propose a market by posting a bond of 5,000 to 25,000 USDC with a market spec and a cost dossier. The oracle runs the market in shadow mode for 14 days, and the roots must agree on at least 99 % of its rounds. Three of five curators approve its caps at or below the dossier's target, a 48-hour timelock follows, and the market trades for 30 days of probation at 25 % of the approved caps. A market that completes probation goes live at its full caps and the bond returns to the proposer. A market that fails during probation halts, and its bond goes to the insurance fund.

The ANYPERP token

ANYPERP has a fixed supply of 1,000,000,000, all of it released in one public launch on equal terms. The protocol's 20 % share of every trading, liquidation and borrow fee buys ANYPERP on the market and burns it, so the supply falls as the markets are used.

Launch parameters

The service runs with the launch parameters below, set in protocol configuration. The programs enforce production bounds on several of them and reject a configuration outside those bounds. Chapter 14 lists every parameter.

How this paper is organized

Chapter 2 defines the metric, the index and the instrument: what a position is, how it is sized and valued, how markets relate to artists and to each other, and the states a market passes through. Chapter 3 derives the open-interest cap from the economics of an attack on the count and follows a worked example through to the checks that enforce it at fill time. Chapter 4 describes the oracle: the round, the two roots, what each root signs, the on-chain verification of every observation, the conditions under which a round prints, and the history and settlement prices the perps program reads.

Chapter 5 covers trading: next-print execution on the round clock, fill pricing, margin and liquidation. Chapter 6 covers funding and the borrow fee, chapter 7 the vault, its NAV, the withdrawal queue and the fee split, chapter 8 halts, settlement and claim balances, and chapter 9 the listing pipeline from proposal to live market. The chapters that follow describe the programs' accounts and the authority model, chapter 13 the off-chain infrastructure that keeps the system running, chapter 14 every parameter with its launch value, and chapter 15 the ANYPERP token: its supply, its launch and the buyback the protocol's fee share funds.

The metric

Each market follows one artist's monthly listeners: the integer shown on the artist's public profile page on a streaming platform, read logged out. The count is a rolling tally of unique listeners, so it moves gradually as an audience grows or fades instead of jumping with each play. The platform removes artificial streams from the public count before it publishes it.

A market's MetricSpec account in anyperp_oracle fixes what is read and how. It holds a 32-byte metric_id, the SHA-256 of the metric's provider name and the artist's 22-character profile ID; a spec_hash that commits to the source, the extraction rule and the normalization; and the oracle parameters of the market: index_divisor, cadence_seconds, tolerance_bps, band_bps, side_pause_seconds, confirmation_rounds and failed_rounds_before_halt. No instruction changes a spec once it exists.

$L$ denotes the level at the last print: the artist's monthly listeners, as an integer.

The index

The oracle prints a fixed9 index, an unsigned integer with 9 implied decimals. Each market sets an index divisor $D$ in its spec. When the two roots observe raw counts $v_1$ and $v_2$ in round $t$, the round prints

$$m_t = \min(v_1, v_2) + \left\lfloor \frac{|v_1 - v_2|}{2} \right\rfloor, \qquad I_t = \left\lfloor \frac{10^9 \cdot m_t}{D} \right\rfloor$$

where $m_t$ is the floored median of the two observations and $I_t$ is the index in fixed9 units. One index point is $D$ listeners. Launch markets use $D$ = 1,000,000, one index point per million listeners.

For an artist at 60,000,000 listeners, the index reads 60.000000000 and is stored as 60,000,000,000. A move of 600,000 listeners is a move of 0.6 index points. The divisor sets the scale of the quote and nothing else: notional, PnL and caps are all computed from size × index, and size is quoted in the same index units.

A perpetual on the level

A position has a side, a size $q$ in index units (fixed9), an entry price, isolated USDC margin and checkpoints into the market's cumulative funding and borrow indices. Its notional at a print is

$$N = q \cdot I_t$$

which the programs compute in USDC base units as $\lceil q \cdot I_t / 10^{12} \rceil$, both factors in fixed9. USDC uses 6 decimals, so 1 USDC is 1,000,000 base units. A position's PnL against a mark $I_{mark}$ is

$$\text{PnL}_{long} = q\,(I_{mark} - I_{entry}), \qquad \text{PnL}_{short} = q\,(I_{entry} - I_{mark})$$

rounded down toward the vault. A size of one index unit gains or loses 1 USDC per index point. In the example above, a long of 5,000 index units has a notional of $300,000 at 60 points and gains $3,000 for every rise of 600,000 listeners.

Margin is isolated per position. An opening fill requires margin of at least $N / \lambda$ after fees, with $\lambda$ at most 3 (max_leverage_bps = 30,000). A position's equity is its margin plus PnL, minus accrued funding and borrow charges; a keeper can liquidate it at any print where equity falls below the market's maintenance margin, 2,000 bps of notional at launch.

Fills happen at the index of a print plus a skew premium. With $s = N_{long} - N_{short}$ the market's skew in USDC and $S$ its skew scale, an order that moves the skew from $s_{before}$ to $s_{after}$ fills at

$$P = I_t \left(1 + \frac{s_{before} + s_{after}}{2S}\right)$$

with buys rounded up and sells rounded down. Funding has no spot price to anchor to, so it works as a balancing price: its rate $f$ drifts at a velocity $\dot f$ in proportion to $s / S$, and the side that adds to the vault's net exposure pays the side that reduces it. A borrow fee on open interest rises with the market's utilization of its caps. Chapters 5 and 6 give the full pricing, margin and funding formulas.

A position has no expiry. It stays open until a reduce-only order closes it, a keeper liquidates it, or the market settles. Each owner holds at most one position per market, on one side; an order on the same side adds to it at the new print, and an order on the other side has to wait until the position is closed.

One market per artist

A market account is a PDA seeded by its metric (["market", metric]), so each MetricSpec has exactly one market, and each artist's monthly listeners is one metric. A position is a PDA per owner and market. The vault serves up to 24 markets; the service launches with 20 artists.

A market's caps are proportional to the reference level in its cost dossier (chapter 3). Every market keeps its own skew, funding rate, borrow index and caps, and all of them settle profit and loss against the same vault.

Relative value across markets

A view on one artist against another is two positions: long artist A and short artist B. With notional $N$ in each leg at entry, the legs hold $q_A = N / I_A$ and $q_B = N / I_B$ index units. When the levels change by fractions $r_A$ and $r_B$, the pair returns

$$\text{PnL} = q_A\,r_A I_A - q_B\,r_B I_B = N\,(r_A - r_B)$$

measured from the index at entry, before fees, funding and the skew premium. A rise in listening that lifts both artists alike cancels out; what remains is the difference between the two audiences. Each leg is margined and capped in its own market, and each fills at the next print of its own market.

Rounds and prints

A round is one 15-minute observation window of one metric. open_round opens it once cadence_seconds (900) have passed since the previous round opened, so windows never overlap and a metric runs 96 rounds a day. Within the window, reporters post one signed observation from each root; after both are in, a keeper calls finalize_round. A round that finalizes is a print. Its index, its finalization time and the earliest fetch time of its two observations are what every later step reads.

Prints drive the rest of the system. Pending orders fill at prints. Funding and borrow accrue over the time between consecutive prints. Liquidations, position valuations and NAV generations all reference a print. The oracle keeps the last valid print of each hour in a 168-entry history ring, which supplies the 24-hour reference for the circuit band and the settlement TWAP. When the source has not changed since the previous round, the new print repeats the level; the round still serves as the clock for fills, funding and NAV.

A round that does not print ends in one of three terminal states. DISPUTED means both roots reported but the observations did not agree or were out of order. FAILED means a root was missing when the window closed. OUT_OF_BAND means the roots agreed on a level beyond the circuit band, which waits for confirmation by later rounds. Chapter 4 describes each in full.

Market states

A market moves through a listing pipeline before it trades and through a halt and a settlement if its source stops printing. Two programs record the state: the Proposal and Market accounts in anyperp_perps, and the pause and halt fields of the MetricSpec in anyperp_oracle. Every opening order checks both at the moment it lands and again at the print where it fills.

The shadow gate counts rounds, not days. Approval needs at least shadow_seconds / cadence_seconds evaluated rounds, 1,344 for 14 days of 15-minute rounds, and agreed rounds at or above 9,900 bps of them. Promotion applies the same rule to the rounds evaluated during probation, 2,880 over 30 days. A round counts as agreed when both roots reported, their values matched within tolerance and their times fell inside the window; a round with a missing root or a disagreement counts against the market.

Side pauses and guardian pauses stop new exposure and nothing else. Reporters keep reporting, keepers keep finalizing, closing orders fill, and a pending opening order on a paused side is rejected when a keeper reaches it at a print; cancel_order then returns its margin to the owner's claim balance. A halt stops the rounds themselves: open_round and the observation instructions refuse a halted metric, and the market waits for its settlement price. Pending orders in a halted market can be expired at once, and their margin returns to the owner's claim balance.

A proposal that curators reject returns its bond to the proposer, as does a market that completes probation. A market slashed during probation halts and settles like any other halted market, and its bond goes to the insurance fund.

A listener count can be moved. Fake listeners can be bought, and real listening can be discouraged. A perpetual on the count pays whoever moves it, in proportion to the position they hold. Anyperp sizes each side of each market so that the payment never covers the cost. This chapter derives the cap from the attacker's profit, sets it per side, follows a worked example through the fixed-point arithmetic the programs run, and shows where the cap is enforced.

The attack the cap prices

An attacker opens a long position with notional $N_{long}$ while the level is $L$ and the index $I_t$. Next-print execution decides the order of events: the order fills at the first print whose observations were all fetched after it landed, so the position has to exist before the pushed number is observed. The attacker then buys a move of fraction $x$, raising the count from $L$ to $L(1 + x)$, and holds it until both roots observe it and it prints. The move costs

$$C(x) = c_{up}\, x\, L$$

where $c_{up}$ is the net cost in USDC of adding one listener to the count and keeping it there through the print. The position holds $q = N_{long} / I_t$ index units, and the index rises by $x I_t$, so the position gains $q \cdot x I_t = N_{long}\, x$. The attack's profit is

$$\Pi_{up}(x) = N_{long}\, x - c_{up}\, L\, x = x\,\left(N_{long} - c_{up} L\right)$$

Trading fees are left out. The attacker pays them on the opening fill and again on the closing fill, so they only lower $\Pi_{up}$.

Break-even open interest

The profit is linear in $x$ with slope $N_{long} - c_{up} L$, and its sign does not depend on $x$. If the slope is negative, every push loses money and a larger push loses more. If it is positive, every push makes money and a larger push makes more. There is no optimal push size to defend against, only a threshold on open interest:

$$N^{*}_{long} = c_{up}\, L$$

This is the break-even open interest of the long side. Below it no push of any size pays; above it every push does. The threshold is a property of the market, which is why Anyperp caps open interest rather than limiting how far the index may move.

Two features of the attacker's position leave the threshold unchanged. Leverage changes the margin the attacker posts, at least $N_{long} / 3$, but not the notional that earns the move. Splitting the position across many accounts changes nothing either, because the cap counts every position on the side, whoever holds it.

The short side

An attacker who holds short notional $N_{short}$ and pushes the count down by a fraction $x$ pays $c_{down}$ per listener removed:

$$\Pi_{down}(x) = N_{short}\, x - c_{down}\, L\, x = x\,\left(N_{short} - c_{down} L\right), \qquad N^{*}_{short} = c_{down}\, L$$

Removing listeners is harder than adding them. A fake listener can be bought, while lowering the count means keeping real people from listening to an artist they chose to hear. So $c_{down}$ is larger than $c_{up}$, and the short side of a market carries more open interest than the long side.

A quarter of break-even

Anyperp sets each side's cap at a fraction $\kappa$ of break-even, with $\kappa = 0.25$, stored as kappa_fixed9 = 250,000,000. With $N_{long} \le \kappa\, c_{up} L$, the profit of any upward push is bounded by

$$\Pi_{up}(x) \le x\,(\kappa - 1)\, c_{up} L = -(1 - \kappa)\, C(x) = -0.75\, C(x)$$

The attack loses money at every push size $x > 0$, and the loss is at least three quarters of what the push costs. The same bound holds for the short side with $c_{down}$ in place of $c_{up}$.

The fraction is also the margin for the cost figure. The cap sits at or below break-even whenever the true cost per listener is at least $\kappa$ times the dossier's figure, so the cap holds even if moving the count costs only a quarter of the dossier's price.

Caps per side

Each market carries two caps in USDC:

$$cap_{long} = \kappa\, c_{up}\, L, \qquad cap_{short} = \kappa\, c_{down}\, L$$

Caps are global per side. $N_{long}$ is the notional of every long position in the market at the current index, and $N_{short}$ the same for shorts. Every opening fill on a side is checked against that side's cap. The listing evaluates both caps at the reference level of the market's cost dossier and stores them in USDC, as the following sections show.

The level appears in both caps, so a market listed at a larger audience carries proportionally more open interest. The ratio between the two caps is the ratio of the two costs, $cap_{short} / cap_{long} = c_{down} / c_{up}$, and it does not depend on the level.

Where the costs come from

A proposal carries three inputs to the cap, stored in its Proposal account: cost_up_usdc_per_unit ($c_{up}$, in USDC base units per listener), cost_down_usdc_per_unit ($c_{down}$) and reference_level ($L_0$, in listeners). A dossier_hash commits to the cost dossier that supports them. Sentinel drafts the dossier with cited evidence, the proposer posts it with the bond, and curators review it before they vote.

The dossier prices $c_{up}$ as the net cost of one fake unique listener that survives the platform's filtering and stays in the count through the print. The platform removes artificial streams from the public count, so a bought listener only counts if it is indistinguishable from a real one. The dossier uses the cost to the subject, the artist or the label, because the subject gains visibility from a higher count and so pays the lowest net cost of anyone. $c_{down}$ is the cost of removing one real listener from the count.

The program turns the inputs into caps itself. propose_market requires the proposal's target caps to equal the arithmetic exactly:

$$cap = \left\lfloor \frac{1}{10^4} \left\lfloor \frac{\kappa_9 \cdot c \cdot L_0}{10^9} \right\rfloor \cdot a \right\rfloor$$

where $\kappa_9$ is kappa_fixed9, $c$ is the cost in USDC base units per listener, $L_0$ is the reference level and $a$ is the active multiplier in bps: 10,000 for the target caps. The target is rounded down before the multiplier is applied. The on-chain Rust function and the TypeScript function the services use are checked against the same test vectors.

Curators approve with approve_market(cap_long_usdc, cap_short_usdc, configuration_hash). Each cap must be positive and at or below its target. The first approval fixes the caps, and the second and third must name the same caps and the same configuration_hash, a hash that binds the exchange policy, the full proposal, the market and metric addresses and both caps. Curators can approve smaller caps than the dossier's target, never larger ones.

A worked example

Take an artist at 60,000,000 listeners. The example uses $c_{up}$ = $0.02 per listener and $c_{down} = 3 \times c_{up}$ = $0.06 per listener, with the launch value $\kappa$ = 0.25.

Break-even open interest is

$$N^{*}_{long} = 0.02 \times 60{,}000{,}000 = 1{,}200{,}000 \text{ USDC}, \qquad N^{*}_{short} = 0.06 \times 60{,}000{,}000 = 3{,}600{,}000 \text{ USDC}$$

and the caps are a quarter of each:

$$cap_{long} = 0.25 \times 1{,}200{,}000 = 300{,}000 \text{ USDC}, \qquad cap_{short} = 0.25 \times 3{,}600{,}000 = 900{,}000 \text{ USDC}$$

In the program's units, $c_{up}$ is 20,000 base units and $c_{down}$ 60,000 base units. The long target is $\lfloor 250{,}000{,}000 \times 20{,}000 \times 60{,}000{,}000 / 10^9 \rfloor$ = 300,000,000,000 base units, which is 300,000 USDC, and the short target is 900,000,000,000 base units, 900,000 USDC.

The table carries the long side through four push sizes, for an attacker holding the whole long cap and for one holding the break-even amount.

At every size the attacker at the cap loses three quarters of the cost. The short side follows the same pattern at three times the scale.

In index terms, with the launch index divisor of 1,000,000 the index stands at 60 points. A long at the cap holds 300,000 ÷ 60 = 5,000 index units. A 10 % push lifts the index to 66 points and the position gains 5,000 × 6 = $30,000, the figure in the table.

The circuit band adds a time cost on top. A round whose index lies more than 10 % from the close at or before 24 hours earlier does not print until later rounds confirm the new level, and new positions on the side the move favors are paused meanwhile. A push larger than the band has to be held across the confirming rounds before it prints, and that side takes no new positions until it does.

The launch markets are proposed with lower cost figures than the example: $c_{up}$ = 1,000 base units (0.001 USDC per listener) and $c_{down}$ = 3,000 base units (0.003 USDC), at a reference level of 10,000,000 listeners. Each launch market's target caps are therefore 2,500 USDC long and 7,500 USDC short, and 625 USDC and 1,875 USDC during probation.

Caps and a moving level

The caps are fixed in USDC at listing, from the reference level $L_0$ in the dossier. Open interest is revalued at every print: the programs compute each side's notional as its total size times the current index. As the level moves to $L_t$, the cap's share of break-even becomes

$$\frac{cap_{long}}{c_{up}\, L_t} = \kappa\, \frac{L_0}{L_t}$$

A rising level lowers the share below $\kappa$. The same cap then covers fewer index units, $cap_{long} / I_t$, and the market holds a smaller fraction of what a push would cost. A falling level raises the share, and the cap stays below break-even at every level above $\kappa L_0$. In the example, that is every level above 15,000,000 listeners.

Revaluation also means a side can reach its cap without any new order. When the index rises, the long side's notional rises with it; once it reaches $cap_{long}$, opening longs are rejected while closes and shorts continue. The borrow fee uses the same revalued open interest. Its rate is

$$r_{borrow} = r_{base} + r_{slope} \cdot \max\left(\frac{N_{long}}{cap_{long}}, \frac{N_{short}}{cap_{short}}\right)$$

with utilization measured in bps, so the cost of holding a position rises as either side nears its cap.

Caps change in two steps of the listing lifecycle, and only there. activate_market sets them to 25 % of the approved caps, and promote_market sets them to the approved caps in full.

Probation caps

A market trades its first 30 days in probation. activate_market applies the active multiplier probation_multiplier_bps, which the exchange configuration requires to be exactly 2,500:

$$cap^{prob}_{side} = \left\lfloor \frac{2{,}500 \cdot cap_{side}}{10^4} \right\rfloor$$

During probation a market carries at most $\kappa / 4$ of break-even, 6.25 %. In the example the probation caps are 75,000 USDC long and 225,000 USDC short.

Probation tests the source while little is at stake. promote_market succeeds only after probation_ends_at, with the metric not halted, the market solvent, at least 2,880 rounds evaluated over the 30 days, and the roots agreeing on at least 99 % of them. It then sets the full approved caps and marks the market LIVE, and return_bond credits the bond to the proposer's claim balance. If the metric halts, the market becomes insolvent or probation ends without the required agreement, slash_bond sends the bond to the insurance fund and halts the market.

Enforcement at fill time

The cap is checked when an order fills, not when it lands, because both the open interest and the index it is measured at belong to the print. execute_order first runs sync, which moves the market to the print's index and accrues funding and borrow. For an opening order on a side with total size $q_{side}$, the program then requires

$$\left\lceil \frac{(q_{side} + q_{order}) \cdot I_t}{10^{12}} \right\rceil < cap_{side}$$

with both sizes and the index in fixed9 and the result in USDC base units. The inequality is strict.

The check runs twice. preflight_order evaluates it along with the market state, the side pauses, the acceptable price and the vault's solvency. If any of these fails, the order is marked rejected at that print: it never fills in part, the queue moves on to the next order, and cancel_order returns its margin to the owner's claim balance. If preflight passes, the program checks the cap again before it writes the new position. Closing orders skip the check, since a close only lowers the side's open interest.

Orders fill in the order they landed, one market queue at a time, so headroom under the cap goes to the earliest order. The app's quote shows each side's headroom, the cap minus the current open interest, and the largest order size that fits under it.

anyperp_oracle turns two independent observations of a public count into a price the perps program can trade on. It holds the configuration of the two attestation roots, one spec and one price history per metric, and one account per round. Every check in this chapter runs inside the program. The services that open rounds, report observations and finalize them pay for transactions and hold no authority over what prints.

Accounts

The round clock

open_round(sequence) opens the next round of a metric. Anyone can call it and pays for the new account. It requires a metric that is not halted, a sequence equal to the metric's next_sequence, and at least cadence_seconds since the previous round opened. The round's window is half-open, from opened_at, the time of the call, to closes_at = opened_at + cadence_seconds. In production the cadence is 900 seconds; the perps listing policy accepts no other value. Sequences start at 1, each round is its own PDA, and windows never overlap.

A round starts OPEN and becomes AWAITING_ROOTS with its first observation. It ends in one of four terminal states: FINALIZED (a print), DISPUTED, OUT_OF_BAND or FAILED. Only a FINALIZED round carries an index, and no round leaves a terminal state.

Two attestation roots

Root 1: Reclaim attestors

Root 1 is a set of Reclaim attestors. An attestor witnesses the TLS session in which the artist's public profile page is fetched and signs the value it returned. Each attestor is identified by the Ethereum-style address of its secp256k1 key; root 1's AttestorSet stores these 20-byte addresses, zero-padded to 32 bytes, and the program verifies their signatures through Solana's secp256k1 precompile. The program trusts exactly the addresses in its allowlist and does not call Reclaim's own on-chain verifier, so Anyperp's governance decides which attestors count.

Root 2: an independent notary

Root 2 is a notary service run by an operator independent of root 1. It fetches the same public page itself and signs the value it read with its own Ed25519 key. Its AttestorSet stores 32-byte Ed25519 public keys, and the program verifies its signatures through Solana's Ed25519 precompile.

Neither root prints alone. finalize_round requires an observation from each, and the two values have to agree within tolerance. A root that reports a different number either stays within the 0.5 % tolerance, which moves the median by at most half of it, or turns the round into a dispute with no price.

Reporters carry the observations on chain. Reporting is permissionless: a reporter's key pays for and signs the transaction, and the program checks the attestation inside it, not the reporter.

Attestor sets and timelocked rotation

initialize_oracle_config creates the OracleConfig and both AttestorSet accounts once, signed by the oracle program's upgrade authority as the loader's ProgramData account records it. It names the perps curator PDA (["curator"]) as curator_authority, sets the guardian key and enforces the production policy: an attestor timelock of at least 172,800 s, a guardian pause limit of 86,400 s, hourly history buckets and 86,400 s reference and settlement windows. Each set takes 1 to 8 distinct, nonzero keys; a root-1 key is an address padded with 12 zero bytes.

A set admits a key for an observation according to the observation's fetch time $t_{fetch}$. The key must be in the current set with $t_{fetch}$ in [valid_from, valid_until), or in the previous set with $t_{fetch}$ in [previous_valid_from, previous_valid_until).

Rotation is a two-step change with a public waiting period.

1. schedule_attestor_rotation(root, keys, valid_from, valid_until) queues new keys. Its signer is curator_authority, which the perps program signs for only after three of five curators approve the same action through approve_oracle_policy. Activation is due attestor_timelock_seconds later, 48 hours in production, and a set holds one pending rotation at a time, so a queued change cannot be silently replaced.
2. activate_attestor_rotation(root), open to anyone once the timelock has passed, makes the new keys current and turns the old keys into the previous epoch, whose window closes at the activation time. A claim fetched before activation stays verifiable under the keys valid when it was fetched, and the set's generation increases by one.

cancel_attestor_rotation(root) clears a queued rotation, again through a curator quorum. Scheduling emits AttestorRotationScheduled and activation AttestorRotationActivated, so every key change is public for the full timelock.

Observations

An observation is one root's signed reading of the count in one round. Each root has its own message format and its own instruction, submit_reclaim_observation for root 1 and submit_notary_observation for root 2; both run the same checks and record the observation the same way.

Time bounds

Each observation carries a source timestamp, when the source produced the value, and a fetch timestamp, when the root read it. Both must fall inside the round's window:

$$t_{open} \le t_{source} \le t_{fetch} \le t_{now}, \qquad t_{fetch} < t_{close}, \qquad t_{source} < t_{close}$$

where $t_{open}$ and $t_{close}$ are the round's opened_at and closes_at and $t_{now}$ is the chain clock at submission. In both root formats one attested time serves as both timestamps: a Reclaim claim's timestampS, and a notary message whose two timestamps must be equal. An observation read inside the window can still be submitted after closes_at, until the round reaches a terminal state.

Root 1: the Reclaim claim and its identifier

A Reclaim claim attests to an HTTPS request and what its response contained. It names a provider, the request parameters and a context, and its claim identifier is the Keccak-256 hash of the three. The oracle program builds every part of the claim itself:

The attestor signs the claim as an Ethereum signed message, the prefix \x19Ethereum Signed Message:\n followed by the claim's length and the claim. The secp256k1 precompile hashes that message with Keccak-256 and checks the signature against the attestor's Ethereum address; the 65-byte signature is r, s and a recovery ID of 0 or 1.

A reporter submits only artist_id, value, timestamp_s, owner and epoch. The artist ID must be 22 ASCII letters or digits, and the SHA-256 of the metric's provider name and that ID in a fixed JSON form must equal the metric's metric_id, so a claim about one artist's page cannot be filed in another artist's market. A change to the metric, spec, round, value or timestamp changes the identifier, and a signature over one identifier verifies for no other. The program emits AttestationVerified with the claim identifier, owner and epoch.

Root 2: the notary message

The notary signs a fixed 178-byte message directly with Ed25519, a 64-byte signature:

The program rebuilds the message from its own accounts and the submitted value and timestamps, and accepts a signature only over exactly these bytes, so a notary signature cannot be replayed into another deployment, market or round.

Submitting an observation

An observation arrives as a transaction of two instructions: the precompile instruction that verifies the root's signature, followed by submit_reclaim_observation(artist_id, value, timestamp_s, owner, epoch, verification_instruction_index) or submit_notary_observation(value, fetched_at, source_timestamp, verification_instruction_index). Both take the same accounts: the reporter (signer), the metric's OracleConfig, the metric, the round (a PDA of that metric), the root's AttestorSet (bound to the same config) and the instructions sysvar, checked by address.

The program requires, in order:

1. an AttestorSet of the instruction's root: root 0 (root 1) for a Reclaim claim, root 1 (root 2) for a notary message (UnknownRoot otherwise);
2. a metric that is not halted, and a round in OPEN or AWAITING_ROOTS;
3. no observation yet from that root in this round (ObservationReplay otherwise);
4. a positive value that normalizes to a positive index;
5. both timestamps inside the window and in order, as above (StaleObservation, ObservationOutsideRound, FutureObservation);
6. a verification instruction placed before this one in the transaction (VerificationMustPrecede);
7. a precompile instruction of the exact expected layout, over the exact message the program built;
8. a signer that the root's AttestorSet permits at the observation's fetch time.

The layout check leaves the precompile no room to verify anything else. The instruction must belong to the expected precompile, carry no accounts and exactly one signature, have an exact length and fixed offsets, and refer only to its own data. For secp256k1 that is the address at offset 12, the signature at 32 and the message at 97, with all three instruction indices pointing at the instruction itself; for Ed25519, 290 bytes with the public key at 16, the signature at 48 and the message at 112, and all three indices set to 65535. The runtime verifies the cryptography; the oracle verifies that what was verified is this message, signed by this key.

The round stores the observation with its value, timestamps, submission time, signer and signature, moves to AWAITING_ROOTS and emits ObservationSubmitted. Once both roots are present, it records min_fetched_at, the earlier of the two fetch times.

A third instruction, submit_observation, takes a generic 183-byte claim for either root under the domain tag ANYPERP_LOCAL_CLAIM_V1. The program accepts it only from a configuration created for local testing.

finalize_round

Anyone can call finalize_round with the metric, the round and the metric's PriceHistory; the keeper does so once both observations are in. It requires a metric that is not halted, a round in OPEN or AWAITING_ROOTS, and both observations present (MissingRoot otherwise). With $v_1$, $v_2$ the two raw values and $\tau$ the metric's tolerance_bps (50), the roots agree when

$$|v_1 - v_2| \cdot 10^4 \le \min(v_1, v_2) \cdot \tau$$

that is, when they differ by at most 0.5 % of the smaller value, equality included. The round is DISPUTED if the roots disagree, if either observation's times fall outside the window, if a newer round of the metric has already been evaluated, or if its earliest fetch time is not later than the last print's. Otherwise the program takes the floored median and normalizes it:

$$I_t = \left\lfloor \frac{10^9}{D} \left( \min(v_1, v_2) + \left\lfloor \frac{|v_1 - v_2|}{2} \right\rfloor \right) \right\rfloor$$

A round whose index passes the circuit band, or confirms a level beyond it, finalizes. It stores final_index, finalized_at, min_fetched_at and the previous print's earliest fetch time, and the metric records it as its latest print, resets its count of consecutive rounds without a print, clears both side pauses and writes the close into the price history. Every evaluation emits RoundEvaluated with its outcome.

Every evaluation also updates the metric's agreement counters exactly once: evaluated_rounds always, agreed_rounds when the roots agreed within tolerance and inside the window, failed_rounds otherwise. A round whose roots agree on a level beyond the band counts as agreed. These counters are the shadow-mode and probation statistics of chapter 2.

The circuit band and side pauses

The band compares the new index with the history's most recent close at or before 24 hours earlier, $R$, the close at now − reference_window_seconds (86,400 s). With $\beta$ the metric's band_bps (1,000), the index is in band when

$$|I_t - R| \cdot 10^4 \le R \cdot \beta$$

that is, within 10 % of the close a day earlier. Shadow mode runs for 14 days before a market trades, so its history holds this reference long before the first order arrives.

A round beyond the band stays pending until later rounds confirm the level. A beyond-band round in the same direction as the pending one, whose index agrees with the pending index within $\tau$, adds one to the metric's confirmation count; any other beyond-band round starts a new count at one. While the count is below the metric's confirmation_rounds, at least 2 and 2 at launch, the round ends OUT_OF_BAND. It writes no price and no history, adds to the count of consecutive rounds without a print, and pauses new positions on the side the move favors for side_pause_seconds, 21,600 s: an upward move sets pause_long_until, a downward move pause_short_until. The round that brings the count to confirmation_rounds finalizes at the new level. Later prints that agree with the confirmed level finalize directly while the 24-hour reference catches up, and the pending state clears once a print falls back inside the band.

A side pause stops opening orders on that side, both when they land and when they would fill. Closing orders, the other side, reporting and finalization continue, and any print clears both pause fields.

Disputed and failed rounds

A DISPUTED round has both observations but no price: the roots disagreed, a time fell outside the window, or the round arrived out of order. A FAILED round is missing an observation at the end of its window; anyone can mark it with mark_failed_round once closes_at has passed, while a round with both roots present has to be evaluated instead.

Both outcomes are rounds without a print. If the round is newer than the last evaluated one, the metric's consecutive_failed_rounds increases by one and opening orders on both sides pause for 21,600 s. A late older round still reaches a terminal state, but it cannot rewind or inflate the failure count. No terminal round blocks the next: the next round opens on schedule, and the first print after a dispute or failure resets the failure count and clears the pauses.

Guardian pauses, halts and settlement

guardian_pause_metric(until) lets the guardian pause opening orders in a market until at most guardian_pause_seconds, 86,400 s, after the start of the pause episode; a later call can extend the pause within that limit but never shorten it. curator_pause_metric(until) lets a curator quorum, through approve_oracle_policy, set a longer pause, lift one, or close an episode so the guardian can start another. Reporting, finalization, closing orders and cancellations continue through every pause.

halt_metric stops a metric for good. The guardian or the curator authority can call it once consecutive_failed_rounds has reached the metric's failed_rounds_before_halt, 4 at launch, one hour of rounds; below that count the program rejects the halt. curator_halt_metric is reserved for the curator PDA, which signs it when slash_bond halts a market that failed probation. A halt records halted_at. After it, no round opens and no observation lands.

A halted metric settles at a time-weighted average of its valid closes over the 24 hours before the halt. With $h$ = halted_at, $T$ = settlement_window_seconds = 86,400 s, and $I_k$ the closes in effect over intervals $\Delta t_k$ that tile $[h - T, h)$,

$$I_{settle} = \left\lfloor \frac{1}{T} \sum_k I_k\, \Delta t_k \right\rfloor$$

The average needs a close at or before $h - T$ to cover the start of the window. settlement_twap returns it; settle_metric, callable by anyone, stores it once in settlement_index with settled_at. No caller chooses the value, and a second settlement is rejected.

The price history and what the perps program reads

PriceHistory keeps one close per hour. Each print records its finalized_at and index: a later print in the same hour replaces that hour's close, and a print in a new hour takes the next slot of the 168-entry ring, overwriting the close from seven days earlier. Only FINALIZED rounds enter, in time order. The history supplies the band's 24-hour reference and the settlement TWAP's closes, and the production policy keeps both windows within the ring's 167-hour horizon.

The perps program never writes a price into the oracle. It reads every price from an OracleRound: sync accepts only a FINALIZED round of the market's own metric with a positive index and a sequence no older than the market's last, moves the market to that index and accrues funding and borrow since the previous print. Next-print execution uses the two fetch times each print stores. A print $r$ fills an order that landed at time $\ell$ only when

$$t^{min}_{fetch}(r) > \ell \ge t^{min}_{fetch}(r_{prev})$$

where $t^{min}_{fetch}$ is a print's min_fetched_at and $r_{prev}$ the print before $r$. Every fetch in $r$ happened after the order landed, and at least one fetch of the previous print did not, so $r$ is the first eligible print. The perps program proves this from one round account without reading any other.

From the MetricSpec, every opening order reads halted and the three pause fields, the shadow and probation gates read evaluated_rounds and agreed_rounds, liquidation and settlement check latest_finalized_sequence, and settlement reads settlement_index. The perps program writes to the oracle only as the curator PDA: initialize_metric from propose_market, rotations and curator_pause_metric from approve_oracle_policy, and curator_halt_metric from slash_bond.

Instruction reference

A trader goes long or short a market's index with isolated USDC margin, and the vault takes the other side. A wallet holds at most one position per market, in a Position account derived from the market and the owner (["position", market, owner]), and that position carries at most one pending order at a time. Orders do not fill when they land; they wait for the market's next print. This chapter follows an order from the instruction that places it through the fill, the close and, when margin runs out, the liquidation.

The programs compute every amount in integers. Sizes, prices and indices are fixed9, so 1.0 is stored as 1,000,000,000. USDC amounts are base units with 6 decimals. A position of size $q$ index units has a notional at price $P$ of

$$N(q, P) = \left\lceil \frac{q \cdot P}{10^{12}} \right\rceil$$

USDC base units, the divisor $10^{12}$ bringing the product of two fixed9 numbers back to 6 decimals. The worked examples in this chapter use one example market: an artist at 60 million listeners with an index divisor of 1,000,000, so the index reads 60.000000000 and a position of 500 units has a notional of $30,000.

Placing an order with open_order

open_order takes six arguments.

The instruction moves the margin into the vault and adds it to reserved_margin_usdc, which keeps it out of NAV from the moment it arrives. It writes a PendingOrder account with the order's terms and its arrival: landed_at, the Solana clock time of the transaction, landed_slot, and landed_round_sequence, the latest round the oracle had opened for the metric.

An opening order lands only when the market is in probation or live, the metric is not halted, neither a guardian pause nor a pause on the chosen side is in force, the market is not marked insolvent, the wallet holds no open position on the other side, the margin is positive and the position has no other pending order. A reduce-only order needs an open position on the same side at least as large as the order, zero margin, a metric that is not halted and a market that is not settled. Side pauses and guardian pauses do not apply to it, so a trader can always reduce exposure while the market prints.

The pending order and the next print

A landed order is a request with fixed terms. It fills at exactly one print: the first finalized round whose two observations were both fetched after the order landed. On chain, a round $r$ is eligible for an order when

$$t^{fetch}_{min}(r) > t_{land} \ge t^{fetch}_{min}(r_{prev})$$

Here $t^{fetch}_{min}(r)$ is the round's min_fetched_at, the earlier of its two observations' fetch times, and $t^{fetch}_{min}(r_{prev})$ is the same time for the finalized round before it, which the oracle copies into each print as previous_finalized_min_fetched_at. The left inequality says both roots fetched the source after the order landed. The right one makes $r$ the first such print. The oracle finalizes rounds in strictly increasing fetch time, and a round fetched no later than the previous print ends DISPUTED, so every order has exactly one eligible print. execute_order refuses every other round with IneligibleRound.

Execution waits for that print because the source is public. Monthly listeners appear on a public profile page, and anyone who reads it sees a new count before the oracle prints it. If orders filled at the latest print, a trader who saw the source change could trade at an index already known to be stale. Under next-print execution the fill uses observations fetched after the trader committed size, margin and acceptable price, so the price a trader receives is never older than what the trader could see when the order landed.

The wait is about one round. Rounds open every 15 minutes (cadence_seconds = 900), and each round accepts only observations fetched inside its own window. An order that lands before either root has fetched the current round can fill at that round's print. An order that lands after one root has already fetched it waits for the next round.

The order queue and its barrier

Each market keeps its pending orders in a first-in, first-out queue: a linked list of PendingOrder accounts whose ends sit on the Market as queue_head and queue_tail, with pending_count beside them. open_order appends at the tail. execute_order accepts only the head and refuses any other order with NotQueueHead. Orders therefore fill in landing order, and each one sees the skew left by the orders before it.

The queue also holds the market at the print its orders are owed. When a keeper synchronizes a market to a round that is eligible for the head order, the program records that round as the market's barrier (barrier_sequence, barrier_min_fetched_at). While the barrier stands, the market cannot move to any other print: synchronizing to a later round fails with PendingEligibleOrder, and a margin withdrawal that would read a later print fails the same way. When the head leaves the queue, the barrier stays if the new head landed before the barrier print was fetched, because that print is the new head's eligible print as well. It clears when the queue empties or the next head is owed a later print. Every order eligible at a print is processed at that print, in order, before the market advances to the next one.

Leverage and margin requirements

Leverage is at most 3×: max_leverage_bps is 30,000, and initialize_exchange accepts no value outside 10,000 to 30,000. A position with notional $N$ needs initial margin

$$m_{init}(N) = \left\lceil \frac{N \cdot 10^4}{\lambda_{bps}} \right\rceil$$

with $\lambda_{bps}$ = max_leverage_bps, which is $N/3$ at launch. A trader chooses lower leverage by escrowing more margin; the app's quote sizes the escrow for the chosen leverage and allows for the price of a print that has not happened yet.

Each market sets its maintenance requirement in maintenance_margin_bps ($\mu_{bps}$), at or above the exchange's min_maintenance_margin_bps. The program accepts only values below the initial requirement, maintenance_margin_bps × max_leverage_bps < 100,000,000, and applies the requirement to the notional at the index:

$$m_{maint} = \left\lceil \frac{N(q, I_t) \cdot \mu_{bps}}{10^4} \right\rceil$$

The fill

A keeper fills the head order with execute_order, passing the order's eligible round. The instruction synchronizes the market to that round, which accrues funding and borrow up to the print (chapter 6) and moves the market's index to the print's final_index. For an opening order it then requires every open position in the vault to be valued at its market's current print (unvalued_positions = 0). It runs the whole fill once as a preflight, and only a fill that passes every check is applied.

Fill price

The fill price is the print's index adjusted for skew. With $s$ the market's skew, long minus short open interest in USDC at the index, and $S$ the market's skew scale skew_scale_usdc:

$$P = I_t \cdot \frac{2S + s_{before} + s_{after}}{2S}$$

The order moves the skew by its notional at the index, $N(q, I_t)$: up for a long open or a short close, which are buys and round up, and down for a short open or a long close, which are sells and round down. The adjustment is the average skew over the trade divided by $S$, so an order that adds to the skew trades on the far side of the index and an order that reduces it trades on the near side. A buy fills only if $P$ is at or below acceptable_price, a sell only if $P$ is at or above it.

In the example market, with an example skew scale of $10,000,000 and no skew, a long of 500 units moves the skew from 0 to $30,000 and fills at

$$P = 60 \cdot \frac{20{,}000{,}000 + 0 + 30{,}000}{20{,}000{,}000} = 60.090000000$$

Fees

Each fill pays a trading fee on its notional at the fill price and a flat keeper fee:

$$\phi = \left\lceil \frac{N(q, P) \cdot b_{trade}}{10^4} \right\rceil, \qquad b_{trade} = \texttt{trading\_fee\_bps} = 10$$

The keeper fee keeper_fee_usdc goes to the USDC account of the keeper that signed the fill. The trading fee is split 60 % to the vault, 20 % to the protocol, 10 % to the insurance fund and 10 % to the market's proposer (chapter 7). In the example the fill has a notional of 500 × 60.09 = $30,045 and pays a trading fee of $30.045.

Margin check at the fill price

Fees come out of the escrow, and what remains is the position's margin, $m = m_{escrow} - \phi - k$, with $k$ the keeper fee. A new position fills only if $m \ge m_{init}(N(q, P))$, the initial requirement at the fill price, and its equity at the print, $m + \text{PnL}(q, P, I_t)$, covers $m_{maint}$ at the index. In the example, the initial requirement is $10,015. An escrow of $10,100 with an example keeper fee of $0.01 leaves $10,069.945 of margin; the position opens $45 below water at the index (500 × (60 − 60.09)), and its equity of $10,024.945 clears an example maintenance requirement of 10 %, $3,000.

The fill also has to fit the market's cap on that side: the side's open interest including this order, valued at the index, must stay strictly below cap_long_usdc or cap_short_usdc (chapter 3). After the fill, the vault's cash must still cover every reserve it protects, and its NAV must stay above zero (chapter 7).

A fill that passes writes the position with entry price $P_{entry} = P$ and checkpoints at the market's current funding and borrow indices, grows the market's side size and entry basis, distributes the fee, pays the keeper and marks the order filled with its fill_price and fill_sequence, emitting OrderFilled.

Rejection and refundable escrow

An order that fails any check at its eligible print is rejected there. It is never carried to a later print. The program sets the order's state to rejected, records the print in eligible_sequence, removes the order from the queue, clears the position's pending flag and emits OrderRejected. The checks it can fail are the market's state and pauses at the print, an opposite-side position, the acceptable price, the side cap, the margin requirements at the fill price, the vault's reserves and, for a reduce-only order, equity too small to pay its fees.

The escrow stays in the vault, reserved for the owner, until cancel_order or expire_order returns it to the owner's claim balance (chapter 8) under the rules below. The order account then closes with close_order, which returns its rent to the owner.

Adding to an open position

An opening order on the side of an existing position adds to it. The fill updates the same Position account. The new entry price is the size-weighted average of the old entry and the fill, rounded against the trader (up for a long, down for a short):

$$P'_{entry} = \frac{q_{old}\, P_{entry} + q_{add}\, P}{q_{old} + q_{add}}$$

Charges the position has accrued stay owed. Only the added quantity starts at the current indices: the program moves the funding checkpoint so that the merged size still owes the old quantity's funding,

$$F'_{cp} = F - \frac{q_{old}\,(F - F_{cp})}{q_{old} + q_{add}}$$

with the borrow checkpoint moved the same way and every division rounded so that no accrued charge is forgiven. The margin requirement applies to the whole position. The combined margin after fees must cover the initial requirement at the new entry, and the equity at the print must cover the initial requirement at the index, a stricter test than the maintenance requirement a new position meets. The cap check counts the whole side, existing position included.

If the example position adds 250 units at a later fill of 63.000000000, it becomes 750 units at an entry of (500 × 60.09 + 250 × 63) / 750 = 61.060000000.

Closing at the next print

A close is a reduce-only order. The app's close action prepares an open_order with reduce_only set, zero margin, a size up to the position's size and an acceptable price, and it fills at its eligible print like any other order: a long closes with a sell, a short with a buy, at the skew-adjusted price. A close can take part of a position or all of it.

The closed quantity $q_c$ takes its share of the margin and its share of the accrued charges $c$:

$$e_{close} = \left\lfloor \frac{m \cdot q_c}{q} \right\rfloor + \text{PnL}(q_c, P_{entry}, P) - c(q_c)$$

The close fills only if $e_{close}$ covers the trading fee and the keeper fee, and the rest, $e_{close} - \phi - k$, is credited to the owner's claim balance. The remaining position keeps its entry price, its checkpoints and the rest of its margin. A position closed in full has state closed, and close_position then closes the empty account and returns its rent to the owner.

Closing the example position of 500 units in full, at a later print of 66.000000000 with the position as the market's only open interest, moves the skew from $33,000 to zero and fills at 66 × (20,000,000 + 33,000) / 20,000,000 = 66.108900000, above the index, because the close reduces the skew. The close earns 500 × (66.1089 − 60.09) = $3,009.45 and pays a fee of $33.05445; before funding and borrow, $13,046.33055 reaches the claim balance.

Moving margin with modify_margin

modify_margin adds margin to an open position or takes margin out of it. Adding moves USDC from the wallet into the vault and raises the position's margin and the vault's reserved margin; it works at any time the position is open.

Removing margin requires a market in probation or live and a metric that is not halted, and it reads the metric's latest print. If the market has not synchronized to that print yet, the program projects funding and borrow forward to it without writing anything; a print beyond the barrier of queued orders is refused. The equity left must cover $m_{init}$ at the print, and the equity at the market's recorded state must stay non-negative. The USDC goes straight to the owner's token account.

Cancelling with cancel_order

The owner of a pending or rejected order can cancel it with cancel_order when any of these holds:

A pending order leaves the queue from its head. Cancelling returns the escrow to the owner's claim balance and emits OrderCancelled. While a round is open whose observations could still become the order's fill, the order stays in force, so a trader cannot watch a print form and withdraw ahead of it. expire_order does the same for anyone, without the owner's signature, once the timeout has passed or the metric is halted; keepers use it to clear stale orders.

Equity, maintenance and liquidation

A position's PnL at the index is

$$\text{PnL}(q, P_{entry}, I_t) = \left\lfloor \frac{\sigma \, q \, (I_t - P_{entry})}{10^{12}} \right\rfloor$$

with $\sigma = +1$ for a long and $-1$ for a short, rounded down. Its equity is margin plus PnL minus the funding charge $c_F$ and the borrow charge $c_B$ accrued since its checkpoints (chapter 6):

$$e = m + \text{PnL} - c_F - c_B$$

A position is liquidatable at a print where $e < m_{maint}$.

Liquidation is permissionless: any keeper signs liquidate with the position and a round. The instruction synchronizes the market to the round, which must be the metric's latest print or the barrier print of queued orders, and proceeds only if equity is below maintenance at the market's index (NotLiquidatable otherwise). The whole position closes at the index itself, with no skew adjustment, and pays a liquidation fee on its notional at the index:

$$\phi_{liq} = \left\lceil \frac{N(q, I_t) \cdot b_{liq}}{10^4} \right\rceil, \qquad b_{liq} = \texttt{liquidation\_fee\_bps} = 100$$

which is 1 % of the notional.

What is left of the position's equity pays out in a fixed order. The keeper fee comes first and goes to the liquidating keeper. The liquidation fee comes next, as far as equity reaches, and is split like a trading fee: 60 % to the vault, 20 % to the protocol, 10 % to the insurance fund and 10 % to the proposer. The remaining margin, $\max(e, 0) - k - \phi_{liq}$ where it is positive, is credited to the owner's claim balance. When equity is negative, the insurance fund pays the shortfall into the vault; a shortfall beyond the fund's balance is recorded in bad_debt_usdc, and the market is marked insolvent and takes no new opening orders. The position ends in state liquidated and emits PositionLiquidated.

The liquidation price

Setting equity equal to the maintenance requirement and solving for the index gives the liquidation price, with $\mu = \mu_{bps} / 10^4$ and $c = c_F + c_B$:

$$P_{liq,long} = \frac{P_{entry} - (m - c)/q}{1 - \mu}, \qquad P_{liq,short} = \frac{P_{entry} + (m - c)/q}{1 + \mu}$$

The program computes it from the exact integers, rounding up for a long and down for a short, so a long's reported price is never below the exact threshold and a short's never above it. A long whose margin net of charges exceeds its entry value has no liquidation price. The price moves as funding and borrow accrue, and liquidation itself always checks exact equity at the print.

In the example, the 500-unit long with $10,069.945 of margin, no charges yet and an example maintenance requirement of 10 % has

$$P_{liq} = \frac{60.09 - 10{,}069.945 / 500}{0.9} = 44.389011112$$

At a print of 44.389011112 its equity is $2,219.450556, exactly its maintenance requirement; at any print below it, a keeper can liquidate.

Two charges accrue on every open position between prints. Funding is signed: it moves value between the side that adds to the vault's net exposure and the side that reduces it. The borrow fee is unsigned: both sides pay it, at a rate that rises as the market fills its caps. Each charge accrues into a cumulative index on the Market account, advanced once per print the market consumes, and each position settles its charges against those indices when its quantity closes. Monthly listeners have no spot market, so funding cannot pull a perpetual's price toward a spot price the way it does for a traded asset. It works as the price of the vault's exposure instead, and it keeps moving until traders take that exposure off the vault.

Skew and the skew scale

A market's skew is its long open interest minus its short open interest, both valued at the index:

$$s = N(q_{long}, I_t) - N(q_{short}, I_t)$$

where $q_{long}$ and $q_{short}$ are the market's long_size and short_size. The vault holds the opposite of every trade, so its net exposure in the market is $-s$. A positive skew means traders are net long and the vault is net short.

The skew scale $S$ is the market's skew_scale_usdc, in USDC. It sets how strongly the skew acts on prices. In the fill price of chapter 5 the skew enters as $(s_{before} + s_{after}) / 2S$, and in funding it enters as $s / S$. A market with a larger $S$ moves its fill prices and its funding rate more slowly for the same imbalance.

The parameters of this chapter are set per market in MarketParams. The proposer submits them with the market, and the curators' approval hash binds them, so a market trades with exactly the parameters the curators approved.

Velocity funding

The funding rate $f$ is stored on the market as funding_rate, a signed fixed9 fraction of the index per hour. A positive rate means longs pay and shorts receive; a negative rate means the reverse. The skew does not set the rate directly. It sets the rate's velocity:

$$\dot f = v \cdot \frac{s}{S}$$

While traders are net long, the rate rises, so longs pay more and shorts are paid more, and the incentive to go short or close a long grows for as long as the skew lasts. While traders are net short, the rate falls. When the skew is zero, the rate holds where it is. The rate therefore drifts toward paying whichever side reduces the skew, and its drift changes direction only when the skew changes sign. Under a persistent imbalance the rate keeps moving; in a balanced market it stays at the level it reached.

The discrete update at each print

The program advances funding each time a market synchronizes to a new print, in sync_market and in the synchronization at the start of execute_order and liquidate. The interval is the time between the two prints' finalization, $\Delta t$ = finalized_at of the new round minus the market's last_accrued_at, in seconds. The step uses the state the market held during the interval: the previous print's index $I_{t-1}$ and the skew $s_{t-1}$ at that index. funding_step computes:

$$\Delta f_t = \left\lfloor \frac{v \cdot s_{t-1} \cdot \Delta t}{S \cdot 3600} \right\rfloor$$ $$f_t = f_{t-1} + \Delta f_t$$ $$\bar f_t = \left\lfloor \frac{(f_{t-1} + f_t) \cdot \Delta t}{2 \cdot 3600} \right\rfloor$$ $$\Delta F_t = \left\lfloor \frac{I_{t-1} \cdot \bar f_t}{10^9} \right\rfloor, \qquad F_t = F_{t-1} + \Delta F_t$$

The first line is the velocity applied over the interval. The rate changes linearly between prints, so the third line integrates it by the trapezoid rule: $\bar f_t$ is the fraction of the index that accrues as funding over the interval. The fourth line turns that fraction into index units and adds it to the cumulative funding index $F$, the market's funding_index. Floors are signed and round toward negative infinity. The program also adds $\lvert \Delta F_t \rvert$ to a second index, funding_absolute_index, which the vault uses to reserve cash for funding credits.

An example step, with example parameters: index 60.000000000, skew scale $10,000,000, a long skew of $150,000, a funding velocity of 0.001 per hour per hour (funding_velocity = 1,000,000), a rate of zero before the step and one 15-minute interval of 900 seconds.

If the skew and the index hold, the rate climbs by the same 3,750 at every 15-minute print and reaches 360,000, a rate of 0.00036 per hour, after 96 prints, one day.

The cumulative funding index and position accrual

A position records the funding index when it opens, as funding_checkpoint $F_{cp}$. From then on its accrued funding is

$$c_F = \left\lceil \frac{\sigma \cdot q \cdot (F - F_{cp})}{10^{12}} \right\rceil$$

in USDC base units, with $\sigma = +1$ for a long and $-1$ for a short. A positive $c_F$ is a charge to the trader and a negative one is a credit. Because the index accumulates $I \cdot \bar f$, a position pays its notional times the integrated rate, whatever its entry price.

Nothing moves between accounts at a print. The charge accrues in the index and enters the position's equity at once: every liquidation check, every valuation and every margin withdrawal reads $c_F$ at the current index. It is paid when quantity closes. A close settles the funding of the closed quantity out of that quantity's margin and PnL, a liquidation settles all of it, and a settlement at a halt settles all of it at the last valid print. A position that adds quantity keeps its old funding owed through the merged checkpoint described in chapter 5, so adding never resets what a position owes or is owed.

The borrow fee

The borrow fee charges open interest for the cap capacity it occupies. Its rate follows the market's utilization $u$, in basis points, which is the higher of the two sides' open interest as a share of their caps:

$$u = \max\left(\left\lceil \frac{10^4 \cdot N_{long}}{cap_{long}} \right\rceil, \left\lceil \frac{10^4 \cdot N_{short}}{cap_{short}} \right\rceil\right)$$

The caps are the market's active caps, so during probation utilization is measured against 25 % of the approved caps. The hourly borrow rate is a base plus a slope in utilization:

$$b = b_0 + \left\lceil \frac{b_1 \cdot u}{10^4} \right\rceil$$

At each print the program advances the borrow index $B$, the market's borrow_index, with the same interval and previous index as funding:

$$\Delta B_t = \left\lceil \frac{I_{t-1} \cdot b \cdot \Delta t}{10^9 \cdot 3600} \right\rceil, \qquad B_t = B_{t-1} + \Delta B_t$$

$B$ only increases. A position records it at opening as borrow_checkpoint $B_{cp}$, and its accrued borrow is

$$c_B = \left\lceil \frac{q \cdot (B - B_{cp})}{10^{12}} \right\rceil$$

Both sides pay it, longs and shorts alike. Like funding, it enters equity at once and is collected when quantity closes. At collection the borrow fee is split like every fee the protocol takes: 60 % to the vault, 20 % to the protocol, 10 % to the insurance fund and 10 % to the market's proposer.

Rounding

Each step rounds in a fixed direction. The funding step uses signed floors throughout; every amount charged to a position and every figure in the vault's books rounds in the vault's favor.

How funding and borrow reach the vault

The vault is the counterparty to both charges. Each print adds to three books on the market. The funding receivable basis grows by $(q_{long} - q_{short}) \cdot \Delta F_t$: what longs owe minus what shorts are owed, which is the vault's net funding income. The borrow receivable basis grows by $(q_{long} + q_{short}) \cdot \Delta B_t$, since both sides pay. The funding credit bound grows by $(q_{long} + q_{short}) \cdot \lvert \Delta F_t \rvert$. Position changes remove the bases of the quantity that closes, and a position that adds replaces its bases whole, so the books always describe the open positions exactly.

From the first two books the program computes the outstanding charges it counts in NAV:

$$\Phi = \left\lfloor \frac{\Sigma_F}{10^{12}} \right\rfloor + \left\lfloor \frac{6000}{10^4} \left\lfloor \frac{\Sigma_B}{10^{12}} \right\rfloor \right\rfloor$$

$\Sigma_F$ and $\Sigma_B$ are the funding and borrow receivable bases. The vault counts its net funding receivable in full and only its 60 % share of borrow that has not been collected yet, because 40 % of every borrow fee leaves the vault at collection. The sum across markets is the vault's total_charges_usdc, an asset in its balance sheet (chapter 7).

From the third book the program computes the funding credit reserve $\lceil \Sigma_{\lvert F \rvert} / 10^{12} \rceil$, the vault's reserved_funding_usdc. It bounds every funding credit not yet paid, and the vault keeps at least that much cash in reserve, alongside trader margin and claim balances, before it takes on new exposure or pays out a withdrawal.

Cash moves when quantity closes. A long that paid funding receives a smaller payout, and the difference stays in the vault. A short that earned funding receives a larger payout from vault cash. The vault's net over a skewed market is $(q_{long} - q_{short}) \cdot \Delta F$: positive when the rate charges the side the skew is on, which is where the velocity drives it. The borrow fee collected from the closing quantity leaves the payout, and the 40 % that belongs to the protocol, the insurance fund and the proposer moves to their accounts in the same instruction.

One USDC vault takes the other side of every trade in every market. Liquidity providers deposit USDC into it and receive vault shares, a classic SPL token whose only claim is a pro-rata part of the vault's net asset value. The vault earns what traders lose, the funding the skewed side pays and 60 % of every fee. It pays what traders win and the funding credits of the side that reduces the skew. This chapter describes the vault's accounts and balance sheet, how its NAV is computed and frozen, how deposits and withdrawals are priced against it, and where fees and the insurance fund sit.

One vault behind every market

The Vault account is a single PDA (["vault"]) that serves up to 24 markets. It controls these accounts:

Every market's PnL, funding and fees settle against the same cash. A market's long and short open interest are separate positions to traders, but to the vault they net: in each market the vault holds $-s$, the opposite of that market's skew, and its exposure across the service is the set of those 24 or fewer net positions.

The balance sheet

The vault's NAV is its cash minus everything in that cash that belongs to someone else, minus what it owes traders on open positions, plus what traders owe it in charges:

$$\text{NAV} = C - (M + D + W + K) - \Pi + \Phi$$

Each market keeps the inputs to its share of $\Pi$: its long and short sizes and its long and short entry bases, the sums $V = \sum q_i P_{entry,i}$ over its positions. Its unrealized PnL at the index is

$$\Pi_{market} = \left\lfloor \frac{I_t\,(q_{long} - q_{short}) - (V_{long} - V_{short})}{10^{12}} \right\rfloor$$

and the program refreshes it at every print and every position change. When traders are up, $\Pi$ is positive and NAV is lower by that amount; when they are down, NAV is higher.

Beside NAV, the vault holds two cash reserves that NAV does not subtract. The funding credit reserve $R_F$ (reserved_funding_usdc) bounds the funding credits not yet paid (chapter 6). The exposure reserve $R_X$ (reserved_exposure_usdc) bounds what traders could be owed in gross profit. A long's profit never exceeds its value at the index and a short's profit never exceeds its entry value, so per market

$$R_X = \max\left(\left\lceil \frac{\lvert N_{long} - N_{short} \rvert \cdot r}{10^4} \right\rceil,\; N_{long} + \left\lceil \frac{V_{short}}{10^{12}} \right\rceil\right)$$

with $r$ the exchange's vault_reserve_bps. The protected reserves are $M + D + W + K + R_F + R_X$. An opening fill goes through only if the vault's cash still covers them afterward and NAV stays above zero; a withdrawal executes only if cash covers the withdrawal on top of them; a claim pays out only if cash covers trader margin, pending deposits and all claim balances, the claim included.

For example, a vault with cash of $1,250,000 holds $180,000 of margin and escrow, $50,000 of pending deposits, $20,000 of priced withdrawals and $5,000 of claim balances. Its traders are up $12,000 and owe $1,500 in net charges. Its NAV is

$$1{,}250{,}000 - 255{,}000 - 12{,}000 + 1{,}500 = 984{,}500$$

Shares and NAV per share

The share mint has 9 decimals. initialize_vault takes the vault's seed deposit from the admin and mints initial_shares, 1,000 share base units per USDC base unit, so the first share is worth 1 USDC. Those shares go to the dead shares account. No instruction transfers or burns them, so the share supply never returns to zero, and every later deposit and withdrawal is priced against an existing supply.

With $Z$ the share supply in base units, the price of one share in fixed9 USDC is

$$p = \left\lfloor \frac{\text{NAV} \cdot 10^{12}}{Z} \right\rfloor$$

In the example, with 980,000 shares outstanding, $p$ = 1.004591836.

NAV generations

Deposits and withdrawals are priced at a NAV generation: a cohort in which every market has been valued at a fresh print. The vault numbers generations with valuation_sequence, and every instruction that changes valuation names the generation it works on as its epoch argument. A generation completes in three steps, and LP intents are priced at it in a fourth.

1. Sync markets. sync_market moves a market to its latest print, accruing funding and borrow and refreshing PnL; execute_order and liquidate synchronize the same way. The first synchronization after a completed generation opens the next one. Synchronizing marks every open position in the market as unvalued.
2. Value positions. value_position checks each open position at its market's print and requires its equity to be zero or more. A position with negative equity fails with NegativePositionEquity and has to be liquidated first, so NAV never counts a loss that a trader's margin cannot pay. When a market's last position is valued, the market joins the generation and contributes its print's min_fetched_at; a market without positions joins when it synchronizes. If a market moves to a newer print before the generation completes, its earlier entry is withdrawn and it is valued again at the newer print.
3. Snapshot. The instruction in which the last registered market joins completes the generation's NavSnapshot account (["nav", epoch]). It records nav_usdc, share_supply, the generation's min_fetched_at (the earliest print fetch time among its markets), previous_min_fetched_at (the same time for the previous generation), completed_at and a distressed flag. A completed snapshot never changes. A NavCompleted event announces it.
4. Price LP intents. Keepers price the deposits and withdrawals that are eligible at the snapshot, at its frozen NAV and share supply, in queue order. A new generation cannot open while the completed one has an eligible deposit or withdrawal at the head of its queue still unpriced (PendingLpIntent).

Opening fills wait for valuation as well: an opening order executes only when no position in the vault is unvalued. A newly activated market joins at a completed generation boundary and starts a fresh generation that must include it. Keepers close snapshot accounts more than 24 generations old and return their rent to the keepers that created them.

Deposits

deposit moves USDC from the wallet into the vault and writes a PendingDeposit (["deposit", owner, nonce]) at the tail of the vault's deposit queue. The amount joins pending_deposits_usdc, so it does not count in NAV while it waits. A keeper fills it with execute_deposit at the first complete generation fetched after it landed:

$$t^{fetch}_{min}(g) > t_{land} \ge t^{fetch}_{min}(g_{prev})$$

The deposit receives

$$z = \left\lfloor \frac{a \cdot Z_g}{\text{NAV}_g} \right\rfloor$$

shares, with $a$ the deposit, and $\text{NAV}_g$ and $Z_g$ taken from the snapshot. The shares are minted to the share escrow and credited to the owner's claim balance, from which the owner can claim them to a wallet or queue them straight into a withdrawal. Each generation's NavMintAllocation account counts the shares minted against it, so the frozen quote prices every deposit in its cohort the same way.

The rule mirrors next-print execution. Every market in the generation has a print fetched after the deposit landed, so the NAV that prices the deposit already contains every count the depositor could have seen. A deposit placed after the source moved buys shares at a NAV that includes the move.

Continuing the example, the pending $50,000 deposit fills at a snapshot with NAV $984,500 and 980,000 shares and receives 49,771.457592686 shares. Its USDC leaves $D$ and enters NAV, which rises to $1,034,500, and the price per share stays 1.004591836.

A deposit that no generation has priced can be recovered. cancel_deposit returns it to the owner's claim balance once withdrawal_queue_seconds have passed since it landed, provided no complete generation eligible for it exists.

Withdrawals

A withdrawal runs in three instructions.

1. Request. request_withdraw takes a number of shares, first from the owner's claimable shares and the rest from a share account in the wallet, and moves them into the share escrow. It writes a Withdrawal (["withdraw", owner, nonce]) at the tail of the withdrawal queue with unlocks_at = requested_at + withdrawal_queue_seconds. The queue is 259,200 seconds, 72 hours, and outside local test configuration initialize_exchange refuses anything shorter. Queued shares stay in the supply and keep their share of the vault's gains and losses while they wait.
2. Price. After the unlock, a keeper calls price_withdraw with the first complete generation fetched after unlocks_at, by the same rule as deposits. The withdrawal is worth $\lfloor z \cdot \text{NAV}_g / Z_g \rfloor$ USDC. Its shares are burned, the amount moves into reserved_withdrawals_usdc, and from then on it is a fixed claim outside NAV.
3. Execute. execute_withdraw credits the amount to the owner's claim balance once the vault's current NAV is non-negative and its cash covers the amount on top of the protected reserves.

The queue keeps LPs from leaving ahead of a print they can already see. An LP who reads a move at the source cannot exit at a NAV that has not printed it: the withdrawal is priced only after 72 hours, at a generation every market of which was fetched after the unlock.

Distressed NAV

A snapshot whose raw NAV is zero or below is marked distressed and records a NAV of zero. Nothing is priced against it. A deposit eligible at a distressed snapshot is returned in USDC to the owner's claim balance. A withdrawal eligible at a distressed snapshot is not burned: price_withdraw returns its shares to the owner's claimable shares, closes the request and emits WithdrawalReturned, and the LP holds the shares again and can request a new withdrawal. While NAV is not positive the vault opens no new positions. recapitalize_vault lets any signer add USDC to the vault without receiving shares.

Fees and the fee split

Every one of them is split the same way. initialize_exchange accepts only vault_fee_bps = 6,000, protocol_fee_bps = 2,000, insurance_fee_bps = 1,000 and proposer_fee_bps = 1,000: 60 % to the vault, 20 % to the protocol, 10 % to the insurance fund and 10 % to the market's proposer. The three external shares round down and the vault keeps the remainder:

$$\phi_{vault} = \phi - \left\lfloor \frac{2000\,\phi}{10^4} \right\rfloor - \left\lfloor \frac{1000\,\phi}{10^4} \right\rfloor - \left\lfloor \frac{1000\,\phi}{10^4} \right\rfloor$$

The vault's share stays in vault cash and raises NAV; fees_earned_usdc records it. The protocol's share moves to the protocol treasury's USDC account and the insurance share to the insurance fund; it buys ANYPERP on the market, which is burned (chapter 15). The proposer's share moves to the proposer fee pool and is booked to the market in claimable_proposer_usdc, and the market's proposer withdraws it with claim_market_fees. A FeesPaid event records each split. Keeper fees sit outside the split: keeper_fee_usdc is paid whole to the keeper that runs a fill, liquidation or settlement. A settlement at a halt charges no trading fee.

The insurance fund

The insurance fund is a USDC account owned by the vault PDA and named in Exchange.insurance_token. It is not vault cash and not part of NAV. Two flows fill it: 10 % of every trading, liquidation and borrow fee, and the bonds of proposers whose markets fail during probation, which slash_bond transfers in whole. One flow draws on it. When a close, a liquidation or a settlement finds a position's equity below zero, the program moves the shortfall from the insurance fund into vault cash, up to the fund's balance, so the vault's LPs do not carry it. Any part beyond the fund's balance is recorded in the vault's bad_debt_usdc, and the market is marked insolvent, which stops new opening orders there.

Queue limits

The two vault queue sizes are set in protocol configuration, and initialize_exchange accepts only values in that range. A deposit or withdrawal beyond a limit fails with LpQueueFull, and the wallet places it again once its earlier intent is priced or the queue has room. Both queues are first-in, first-out, priced from the head, and each entry is priced at the one generation its rule selects.

A market stops when its source stops producing prints that the two roots agree on. The oracle counts the rounds that end without a print, the guardian halts the metric once the count reaches the market's threshold, and the market settles at the time-weighted average of its last 24 hours of valid prints. Each position then closes at that price, and what it is owed lands in the owner's claim balance, the protected internal balance that receives the system's payouts and that the owner withdraws with claim_balances.

Failed rounds and the halt threshold

A round that does not print ends in one of three states (chapter 4). It is FAILED when mark_failed_round finds a root's observation missing after the round's closes_at. It is DISPUTED when both roots reported but their values differ by more than the tolerance of 50 bps, a timestamp falls outside the round's window, or the round was fetched no later than the previous print. It is OUT_OF_BAND when the roots agree on a level beyond the circuit band and the level waits for confirmation by later rounds.

Each of these adds one to the metric's consecutive_failed_rounds; a failed round older than the last one evaluated reaches its terminal state without adding to the count. A failed or disputed round also pauses opening orders on both sides for side_pause_seconds, 21,600 seconds (6 hours); an out-of-band round pauses the side in the direction of the move. The next print resets the count to zero and lifts the side pauses.

The threshold is the metric's failed_rounds_before_halt, set in its MetricSpec when the market is proposed. It is part of the configuration the curators' approval hash binds, so every market trades under the halt threshold its curators approved.

The guardian's halt

The guardian is a separate signer with two powers over a metric, both in anyperp_oracle. guardian_pause_metric pauses opening orders until a chosen time, within guardian_pause_seconds of the episode's start; only a curator decision, through curator_pause_metric, clears an episode or starts another. halt_metric halts the metric, and the oracle accepts it, from the guardian or the curator authority, only when consecutive_failed_rounds has reached failed_rounds_before_halt; below the threshold it fails with HaltThresholdNotMet. The guardian writes no price and moves no funds.

The guardian worker checks every metric on each pass and signs halt_metric as soon as a metric reaches its threshold. The halt sets halted and records halted_at, the clock time of the halt, and emits MetricHalted. A market can also halt during probation: when slash_bond finds root agreement below 99 % at the end of probation, the market insolvent or the metric already halted, the curator PDA halts the metric through curator_halt_metric if it is not halted yet, and the proposer's bond goes to the insurance fund.

A halted metric takes no new rounds and no observations. The market accepts no opening or reduce-only orders and no margin withdrawals. Pending orders can be expired at once with expire_order, and their escrow returns to the owners' claim balances. The market then waits for its settlement price.

Settlement at the 24-hour TWAP

settle_metric sets the settlement price. Anyone can call it once the metric is halted. It reads the metric's PriceHistory, the ring of 168 hourly closes, and computes the time-weighted average of the index over the settlement_window_seconds before the halt, 86,400 seconds (24 hours). With $T_h$ the halt time, $W$ the window, $\tau_1 < \dots < \tau_n$ the timestamps of the hourly closes inside the window, $\tau_0 = T_h - W$ and $\tau_{n+1} = T_h$:

$$I_{settle} = \left\lfloor \frac{1}{W} \sum_{k=0}^{n} I_k \, (\tau_{k+1} - \tau_k) \right\rfloor$$

$I_0$ is the latest close at or before the start of the window and $I_k$ the close at $\tau_k$, so the index is a step function that holds each close until the next one. Each hourly close is the last print of its 3,600-second bucket, timed at that print's finalization. Only finalized rounds write history, so failed, disputed and out-of-band rounds contribute nothing, and the last valid close holds through the rounds that failed before the halt. The program requires a close at or before the start of the window and refuses to settle without one (InsufficientHistory). The result is stored as the metric's settlement_index with settled_at, and MetricSettled records it.

For example, if the hourly closes held 60.000000000 for the first 18 hours of the window and 57.000000000 for the last 6, the settlement index is (60 × 18 + 57 × 6) / 24 = 59.250000000.

Settling the market and each position

Three permissionless instructions take a halted market to its end, and the keeper runs them in order.

1. halt_market sets the market's status to HALTED once the metric is halted.
2. settle_market requires a settlement index, an empty order queue and a market synchronized to the metric's last print. It sets the market's index to settlement_index, sets its status to SETTLED, marks every open position unvalued and refreshes the market's PnL at the settlement index. Funding and borrow stop at the last valid print; nothing accrues after the halt.
3. settle_position closes one position in full at the settlement index. It charges no trading fee. It pays the keeper fee, collects the accrued borrow fee and splits it like every fee, and credits the owner's claim balance with

$$\text{payout} = \max\left(0,\; m + \text{PnL}(q, P_{entry}, I_{settle}) - c_F - c_B - k\right)$$

where $c_F$ and $c_B$ are the funding and borrow accrued to the last valid print and $k$ the keeper fee. A position whose equity is negative receives nothing, and the insurance fund covers its shortfall into the vault as in a liquidation.

The vault completes no NAV generation while a settled market still holds open positions. Once the last one has settled, the market joins every later generation with no exposure.

Protected claim balances

Payouts from closes, liquidations, settlements, refunds, withdrawals and bond returns go first to the receiving wallet's OwnerState, as claimable_usdc for USDC and claimable_shares for vault shares. The keepers that run fills, liquidations, settlements and withdrawals never transfer to an owner's token account, so no keeper depends on that account existing or accepting a transfer, and the owner chooses where the funds go.

The USDC behind claim balances stays in the vault's USDC account, and its total is the vault's reserved_claims_usdc. It is excluded from NAV, so LP shares never count it as theirs, and it is part of every reserve check. A close, a liquidation or a settlement credits a payout only if vault cash covers trader margin, pending deposits, the funding credit reserve and all existing claims with the new payout on top. Claimable shares sit in the share escrow; a wallet can claim them or queue them straight into request_withdraw without taking them out.

Claiming with claim_balances

claim_balances takes a USDC amount and a share amount, at least one of them positive and neither above the owner's balance. The owner signs, and the instruction transfers the USDC from the vault's USDC account and the shares from the share escrow to token accounts the owner holds for those mints; any correctly owned account is accepted, not only the wallet's associated token account. Before it pays USDC, the instruction checks that the vault's cash covers trader margin, pending deposits and all claim balances, the claim included. The balances fall by the amounts paid, reserved_claims_usdc falls with them, and BalancesClaimed records the claim.

Every market enters Anyperp through one pipeline, and anyperp_perps enforces each step of it. A proposer describes a metric and posts a USDC bond. The metric runs in shadow mode for 14 days while both attestation roots report on it. Three of the five curators approve caps bound to the full configuration. A 48-hour timelock follows, then 30 days of probation at a quarter of the approved caps. A market that completes probation goes live and its bond returns to the proposer. A market that fails probation halts, settles, and its bond goes to the insurance fund. The program offers no other entry: create_market exists only to return ListingRequired.

The proposal

A proposal starts as a plain-language description of the market: which artist, and the artist's ID on the source. Sentinel turns the description into a draft with two parts, a metric spec and a cost dossier, built from research inputs the proposer supplies.

Both costs are in USDC base units per listener. The spec fixes how the number is read and printed, from endpoint and extraction rule to the 900-second cadence, the 50 bps tolerance and each root's claim encoding. The dossier fixes what moving the number costs, with the target caps of chapter 3:

$$cap_{long} = \lfloor \kappa \, c_{up} \, L \rfloor, \qquad cap_{short} = \lfloor \kappa \, c_{down} \, L \rfloor$$

For an artist at 60,000,000 listeners with $c_{up}$ = $0.02 and $c_{down}$ = $0.06 per listener, an example, the target caps are $300,000 long and $900,000 short.

Sentinel computes every financial and spec field of the draft deterministically from these inputs; its model writes only the dossier's advisory limitations. A draft that lacks an input names it in missingConfiguration, and the API builds no propose_market transaction until that list is empty. Each draft suggests the 5,000 USDC minimum bond, is stored with the SHA-256 of its canonical spec and dossier, and is public.

Sentinel is advisory. It holds no key, signs no price, vote or transfer, and nothing it writes enters a round or a settlement. It also publishes an assessment for every market: flags such as a halted metric or recent failed rounds, and the external markets on the same number.

The bond: propose_market

The proposer signs one transaction carrying the metric arguments, the market parameters, $c_{up}$, $c_{down}$, $L$, the dossier hash, the SHA-256 of the description and the bond. The API fills every market parameter except the caps from protocol configuration.

The program checks the proposal against policy before it creates anything:

• the bond lies between min_bond_usdc and max_bond_usdc, 5,000 and 25,000 USDC at launch;
• the metric uses 900-second rounds, a root tolerance of at most 50 bps, a circuit band of at most 1,000 bps, a side pause of at least 21,600 seconds and at least two confirmation rounds;
• the maintenance margin is at least the exchange minimum and below the initial margin at maximum leverage;
• each target cap equals $\lfloor \kappa c L \rfloor$ exactly, recomputed on chain with kappa_fixed9 = 250,000,000; any other value fails with CapExceeded;
• the root keys in the spec are the first keys of the two active attestor sets.

The same transaction then creates the listing:

1. The curator PDA signs a cross-program call to initialize_metric in anyperp_oracle, which creates the MetricSpec at ["metric", metric_id] and its PriceHistory. The metric ID is the SHA-256 of the provider and the subject ID, so each artist has one metric; the Market derives from the metric, so each metric has one market.
2. The bond moves from the proposer's USDC account into a token account at ["bond", proposal] whose authority is the proposal PDA. Only the program's return and slash paths sign for it.
3. The Proposal at ["proposal", proposer, nonce] records the hashes, costs, level, target caps, bond and shadow_started_at.
4. The Market at ["market", metric] starts in SHADOW with market_index = 255, outside the vault's valuation.

Shadow mode

From that transaction on, the metric runs like any listed metric. Reporters open a round every 900 seconds, both roots observe the source, keepers finalize, and prints enter the price history. The market takes no orders, since open_order accepts only PROBATION and LIVE markets.

The oracle keeps the score. Every round that reaches a terminal state adds one to evaluated_rounds, exactly once. It adds one to agreed_rounds when both roots reported values within tolerance, fetched inside the round's window. Failed and disputed rounds count against the market. Shadow mode is complete when three conditions hold together:

• 1,209,600 seconds (14 days) have passed since shadow_started_at;
• at least shadow_seconds / cadence_seconds = 1,344 rounds are evaluated;
• $agreed \cdot 10{,}000 \ge evaluated \cdot 9{,}900$, so the roots agree on at least 99 % of rounds.

The gate counts rounds as well as time, so a source that missed rounds takes longer to qualify, and a halted metric never qualifies. The listings page in the app shows the running agreement as shadow rounds agreeing.

Curator approval

Five member keys are registered in CuratorConfig, and any three decide. Each curator votes from their own wallet with approve_market(cap_long, cap_short, configuration_hash) or reject_market(reason_hash). A vote sets the member's bit in the proposal's approve_mask or reject_mask, and each member votes once across both.

An approval is bound to the full configuration. The program rebuilds the proposal's arguments from the immutable fields of the proposal, the market and the metric, and hashes them with the policy in force:

$$h = \mathrm{SHA256}\left(D \,\|\, P \,\|\, A \,\|\, \mathrm{ExchangeParams} \,\|\, \mathrm{ProposeMarketArgs} \,\|\, cap_{long} \,\|\, cap_{short}\right)$$

Here $D$ is the domain ANYPERP_LISTING_APPROVAL_V1, $P$ the two program IDs, $A$ the exchange, proposal, proposer, market and metric addresses, and both structs are Borsh-encoded. A vote with any other hash fails with InconsistentVote, so a vote approves exactly one bond, spec, pair of root keys, set of market parameters, dossier, description and exchange policy. The API computes the hash from confirmed accounts and places it in the curator's transaction.

At every vote the program re-checks the policy bounds and the shadow gate. The caps must be positive and at most the target caps. The first approval fixes them, and the second and third must name the same pair, so curators can approve the targets or any lower pair. At the third approval the proposal moves to TIMELOCK with approved_at and timelock_ends_at = approved_at + 172,800 seconds. Three rejections naming the same reason hash move it to REJECTED.

The 48-hour timelock and activation

For 48 hours the approved configuration stands in public and nothing trades. Then anyone can call activate_market, and the keeper does so as soon as the vault allows. Activation requires a metric that is not halted, fewer than 24 registered markets, a complete current NAV generation, and no deposit or withdrawal waiting on that generation.

Activation registers the market in the vault. The market takes the next market_index, market_count rises, and a fresh valuation generation opens that must include the new market before the next NAV exists (chapter 7). The program sets each cap to probation_multiplier_bps = 2,500 of the approved cap, rounded down, marks the market and the proposal PROBATION, starts the 2,592,000-second (30-day) probation, and snapshots the metric's evaluated and agreed counts so probation is scored on its own rounds.

Probation

During probation the market trades at its reduced caps, $75,000 long and $225,000 short in the example. Fees, funding, borrow and the proposer's fee share all run. Objective on-chain state decides the outcome, and any keeper executes it:

• promotion, once probation has ended with full coverage and 99 % agreement;
• slashing, once the metric has halted, the market has become insolvent, or probation has ended with full coverage and agreement below 99 %;
• continued probation, while probation has ended but fewer than 2,880 rounds are evaluated; the market keeps trading at probation caps until coverage is complete.

Promotion to live

promote_market requires PROBATION, the end of probation, a metric that is not halted, a solvent market, and at least 2,880 evaluated probation rounds with the roots agreeing on at least 99 % of them. It sets the caps to the approved caps and marks the market and the proposal LIVE.

Bond return

return_bond runs for a proposal that is LIVE or REJECTED and still holds its bond. The proposal PDA signs the transfer from the bond account into the vault's USDC account, and the program credits the full amount to the proposer's claim balance, claimable_usdc in OwnerState, reserved in the vault's reserved_claims_usdc and outside LP NAV. The proposer moves it to a wallet with claim_balances. The instruction has no signer requirement, and the keeper sends it.

Slashing

slash_bond runs in probation only, and only when one of three conditions holds: the oracle metric is halted; the market is insolvent, its bad debt having exceeded the insurance fund; or probation ended with full coverage and agreement below 99 %. On a healthy probation it fails with ProbationHealthy. If the metric is still running, the slash halts it through curator_halt_metric, signed by the curator PDA. The whole bond goes to the insurance fund's token account, the proposal becomes SLASHED, and the market becomes HALTED and settles at the TWAP of the 24 hours before the halt (chapter 8). The insurance fund holds the slashed bond with the rest of its USDC and pays it out against negative equity when positions settle.

Once a proposal is LIVE, REJECTED or SLASHED with no bond left, the proposer can close it and its empty bond account with close_proposal and recover the rent. The indexer keeps the closed proposal as a read-only receipt.

The proposer's fee share

The proposer earns proposer_fee_bps = 1,000, or 10 %, of every fee the market collects: trading fees on opening and closing fills, liquidation fees and the collected borrow fee. At each fee the program moves the proposer's share into the proposer fee account, a USDC token account owned by the vault PDA, and adds it to claimable_proposer_usdc on the market. For a 10 bps fee on a 10,000 USDC fill, an example, the fee is 10 USDC and 1 USDC of it is the proposer's. The proposer collects with claim_market_fees(amount), signed by the market's recorded proposer, into a USDC account the proposer owns. The share accrues from the first fill in probation for the life of the market, and it is independent of the bond and of the proposal account.

The launch cohort

The 20 launch markets enter through bootstrap_launch_market, a genesis path that closes when the programs pass to governance. Its signer must be the exchange admin and also the current upgrade authority of anyperp_perps, and it runs only before the vault's first NAV generation, while the vault holds no margin, deposits or withdrawals. Each launch market passes the checks of propose_market with a zero bond, is registered in the vault at once and starts LIVE at its target caps.

Protocol configuration sets the launch cohort at $c_{up}$ = 0.001 USDC and $c_{down}$ = 0.003 USDC per listener with a reference level of 10,000,000 listeners per artist, which gives caps of 2,500 USDC long and 7,500 USDC short. Once the upgrade authority passes to the curator PDA (chapter 12), no signer meets the entry check, and every later market takes the full pipeline.

Listing states and transitions

Proposal.status and Market.status share one set of codes. The market keeps SHADOW while its proposal is in TIMELOCK or REJECTED; activation and promotion set both; a slash sets the proposal to SLASHED and the market to HALTED.

Anyperp runs as two Anchor programs on Solana. anyperp_oracle holds the metrics and their prints. anyperp_perps holds the money: the exchange, the vault, markets, orders, positions, the LP queues, NAV snapshots, claim balances, listings and governance. Both build on anyperp_domain, a shared crate of exact integer arithmetic with no floating point, which the off-chain services check against the same test vectors. Every account the two programs own is a PDA with fixed seeds, so any client derives its address from public inputs. Account sizes below are in bytes and include Anchor's 8-byte discriminator.

The two programs

anyperp_oracle owns five account types: one OracleConfig, two AttestorSets, and for every metric a MetricSpec, a PriceHistory and one OracleRound per round. It holds no tokens. It verifies each observation against a signature precompile in the same transaction, secp256k1 for root 1 and Ed25519 for root 2, and writes prices only from rounds in which both roots agree.

anyperp_perps owns every account that moves value. Its token accounts hold USDC and LP shares under the authority of the vault PDA or of a proposal PDA, so only program code signs a transfer out of them.

The oracle names the perps program in one place: initialize_oracle_config requires curator_authority to be the PDA ["curator"] of anyperp_perps. Oracle governance is therefore the perps program's curator quorum, and both programs answer to one set of five curators.

How the perps program reads oracle state

The perps program links the oracle crate and takes MetricSpec and OracleRound as typed Anchor accounts. Anchor checks that each is owned by anyperp_oracle and carries the right discriminator, so an account written by any other program fails to load. Constraints then tie both to the market: the Market names its metric (has_one = metric), and every round must name the same metric or the instruction fails with WrongOracleMetric.

From the round, the perps program reads the print. sync accepts a round only if it is FINALIZED with final_index > 0 and a sequence at or above the market's last_sequence, and copies final_index, finalized_at and min_fetched_at into the market. The round's two fetch-time bounds decide which orders it serves: an order that landed at time $t$ fills only at the round with previous_finalized_min_fetched_at ≤ $t$ < min_fetched_at, the first print whose observations were all fetched after the order landed (chapter 5).

From the metric, it reads the gates: the halt and pause fields for every opening order, latest_finalized_sequence for liquidations and margin removal, the sequence counters for cancellation, evaluated_rounds and agreed_rounds for listing, and settled_at and settlement_index for settlement. A listing vote counts only if the metric's authority is the exchange's curator PDA.

The perps program writes to the oracle only through cross-program calls signed by the curator PDA:

No perps instruction writes a price.

Oracle accounts

OracleConfig holds the roles and the windows every metric inherits: the admin, the curator authority, the guardian, the attestor timelock (172,800 seconds), the guardian pause limit (86,400 seconds), the hourly history bucket and the 86,400-second reference and settlement windows. Outside local test configuration, initialize_oracle_config requires an attestor timelock of at least 172,800 seconds and exactly these pause, bucket and window lengths.

Each AttestorSet lists the keys of one root: up to 8 Ethereum addresses of Reclaim attestors for root 1, padded with 12 zero bytes, and up to 8 Ed25519 keys of the independent notary for root 2. It keeps three generations side by side. The current keys verify observations fetched inside their window; the previous keys verify only observations fetched before the last activation; the pending keys wait for their activation time. generation counts activations.

A MetricSpec holds one artist's metric: the immutable spec fixed at listing, the live state of its rounds, pauses and band confirmation, the shadow and probation score, and the halt and settlement fields. An OracleRound exists per metric and sequence, paid for by whoever opens it, with two observation slots holding each root's value, times, signer and 65-byte signature. PriceHistory is a fixed ring of 168 hourly closes of 16 bytes each; the last print in an hour replaces that hour's close, the circuit band reads its reference from it and settlement its 24-hour TWAP. Its length never changes, so the account never reallocates.

Perps accounts

Exchange holds the admin, the curator PDA, the guardian, the protocol treasury, the USDC mint (6 decimals, checked), the three fee accounts and ExchangeParams, the protocol policy listed in chapter 14. initialize_exchange fixes the fee split at 6,000/2,000/1,000/1,000 bps, bounds leverage between 1× and 3×, requires at least two rounds before cancellation, bounds each LP queue at 1 to 64 entries, enforces the production minimums for the withdrawal queue, shadow mode, timelock, probation and bonds, and requires the guardian and curator authority to match the oracle's configuration.

CuratorConfig at ["curator"] lists the five curator members. Its PDA is the governance signer of the system: the oracle's curator authority, the authority of every MetricSpec, and, after handover, the upgrade authority of both programs.

Vault at ["vault"] backs every market. It carries the reserves of the balance sheet (trader margin, pending deposits, priced withdrawals, claim balances, funding credits and exposure), the trader PnL and charge books, bad debt and fees earned, and the heads and tails of the deposit and withdrawal queues and the valuation state of the current NAV generation, with one fetch-time slot for each of up to 24 markets. Four token accounts sit under its authority: USDC at ["usdc"], the share mint at ["shares"] with 9 decimals, the share escrow at ["share_escrow"], which holds shares owed to claim balances and shares in the withdrawal queue, and ["dead_shares"]. initialize_vault mints the seed's shares, 1,000 share units per USDC base unit, into the dead-share account, where they stay. At the launch seed of 1,000 USDC, one share is worth 1 USDC.

The three fee accounts are USDC token accounts whose addresses Exchange records: the protocol fee account, owned by the protocol treasury, and the insurance fund and the proposer fee account, both owned by the vault PDA. Every fee transfer is constrained to these addresses. The insurance fund receives 10 % of fees and every slashed bond, and covers negative equity when a position settles; what it cannot cover is booked as bad debt and marks the market insolvent.

A Market at ["market", metric] holds one metric's book and its order queue. Each PendingOrder at ["order", owner, nonce] links to the next order in that queue and records its landing time, round and outcome. A Position at ["position", market, owner] is one wallet's isolated position in one market, locked while an order on it is pending.

OwnerState at ["owner", owner] is each wallet's ledger with the program. It keeps the last nonce, the claim balances in USDC and in shares, and pointers to the wallet's one pending deposit and one pending withdrawal. Every account a wallet creates with a nonce takes one strictly above last_nonce, so the address of a closed order, deposit, withdrawal or proposal is never created again (NonceReplay). Claim balances are backed one to one: USDC by reserved_claims_usdc in the vault, shares by the share escrow.

A PendingDeposit at ["deposit", owner, nonce] and a Withdrawal at ["withdraw", owner, nonce] each link to the next entry of their queue; a withdrawal keeps its fixed USDC amount and NAV epoch once priced.

A NavSnapshot at ["nav", epoch] freezes one NAV generation: NAV, share supply, the earliest fetch time across its prints, the previous generation's bound and a distressed flag. Once completed_at is set, nothing changes it. The NavMintAllocation at ["nav_mint", epoch] counts shares already issued against that snapshot, so deposits priced at one epoch take their shares from a fixed quote in queue order, independent of later supply. The keeper whose transaction created either account pays its rent and receives it back when the account is closed.

A Proposal at ["proposal", proposer, nonce] records a listing from bond to outcome, with its bond held at ["bond", proposal] under the proposal PDA's authority (chapter 9). An OraclePolicyApproval at ["oracle_action", action_hash] collects curator votes on one rotation or pause. An UpgradeProposal at ["upgrade", proposal_hash] collects votes on one program upgrade and holds its timelock (chapter 12).

Account reference

The address lookup table

Transactions that touch many accounts compile against one address lookup table, whose authority is the keeper key. At initialization it receives the fixed addresses: Exchange, Vault, the vault's USDC account, share mint and share escrow, the USDC mint, the three fee accounts, the curator PDA, OracleConfig, both AttestorSets, both program IDs, the token program, the system program and the rent sysvar. For every market it adds the Market, MetricSpec and PriceHistory, and the keeper extends it with each new market's three addresses, 20 per extension. The API builds a legacy message when it fits Solana's 1,232-byte packet and a v0 message with the table when it does not, or when the action is known to be large, such as propose_market and settle_position. No prepared transaction exceeds 1,232 bytes.

Oracle instructions

Perps instructions