Skip to content
Temporal Docs← Back to the app

10 · Risks & security

Risks & security

What this venue depends on that it does not control, what can happen to you if that dependency fails, and how the contracts are checked. Read this before you trade or quote.

Price data and what happens if it fails#

Every price on this venue starts from data we read from other markets. We do not produce it, we do not control it, and we accept the risk that it can fail. We tell you here, openly, instead of hoping you never find out.

Where the prices come from#

Option prices are set from a listed options market for each asset, fitted by the venue's model. The market named below is the one the venue is using right now, read live from the venue. Perp marks and the spot reference come from Hyperliquid for every asset.

AssetOption prices come fromPerp mark and spot from
BTCDeribit (reading…)Hyperliquid
HYPEDerive (reading…)Hyperliquid

What can go wrong#

A source can fail, go stale, change what it publishes, or withdraw our access. If that happens:

  • Option prices may stop updating. The last good prices can stay on screen while the market moves on.
  • Trading may be halted. The venue may stop trading in that asset (opens and closes) until its prices are fresh again.
  • Marks used for margin may be stale. Margin, equity and liquidation levels are computed from marks; a stale mark can make an account look safer or riskier than it is.
  • Nothing settles on stale data. How long prices can be stale before the venue steps in, and what it does then, is set out in the next section. A position is never settled automatically on stale data.
No licence, no backup. The venue does not hold a licence from the markets it reads, and they may object to its use of their data or block it. There is no second source yet: when the one named above stops, nothing takes its place automatically.

When prices go stale#

The venue watches two clocks for each asset, separately: how old its options data is, and how old its spot price is. Each asset is judged on its own, so a problem with one asset does not stop another. There are two states, and the line between them is one test: can the venue still sign a fresh price for a trade in that asset?

  • Normal. Options data is at most 15 minutes old and the spot price at most 60 seconds old, so every trade carries a freshly signed price. Everything works.
  • Frozen. Options data is more than 15 minutes old, or the spot price more than 60 seconds old: the venue can no longer sign a fresh price. Trading is paused: opens and closes are both refused (“Prices are stale — trading is paused.”). No one is liquidated on stale data, and funding accrual on open options stops for the frozen time. Withdrawals are paused and go through once prices are fresh again; this lifts by itself. Nothing is ever settled automatically.

Prices coming back moves the asset back to normal without anyone acting. The state of each asset, how old its two clocks are and since when are published on the venue's health page. These limits are the venue's own rule and it may change them; the page will say so when it does.

Do this from your agent

Check that prices are fresh before you act

The venue publishes each asset's state and how old its two clocks are. An agent should read this before it trades, and stop when an asset is frozen: every act in that asset is refused.

Per-asset price state
curl -s https://protect.temporal.exchange/api/venue/health
Response (shortened)
{"ok":true,"ready":true,"phase":"testnet",
 "oracleTier":{"BTC":{"tier":"normal","surfaceAgeMs":2424,"spotAgeMs":535,"since":"…"},
               "HYPE":{"tier":"normal","surfaceAgeMs":2842,"spotAgeMs":299,"since":"…"}}, ...}
Paste this to your agent

Before you do anything on the Temporal testnet venue, read https://protect.temporal.exchange/api/venue/health. If any asset I am about to trade has a tier other than "normal", stop and tell me. Otherwise say the options-data age and spot age for that asset.

Check the result yourself: the fresh-prices check.

Other risks#

  • Contract risk. The ledger, the front and the margin run in contracts on a young chain. A bug can lose money. The next section says how they are checked, and what that does not prove.
  • Custody. Your deposits sit in a HyperCore wallet the venue controls, and the ledger records whose money is whose. If that wallet or its key failed, withdrawals would fail with it. Daily withdrawal limits bound how much can leave in a day, and a continuous check compares what the ledger says with what the wallet holds.
  • Sold options need margin, set per asset. Each asset takes its own price source's numbers, as those venues do: BTC Deribit's 15 % of spot to open (never under 10 %) and 7.5 % to hold, HYPE Derive's 30 % / 25 % / 18 % (stricter), each plus the option's price. A put's opening floor counts on its strike and its holding margin on the lower of spot and strike, so a far out-of-the-money put needs a little less.
  • A liquidation closes only what it needs. When an account falls to its maintenance margin, the ledger contract itself sizes each round of closing so that it stops once the account is back to 15 % above maintenance (Derive's rule), and it sells bought options last; the venue's keeper only sends the closes the contract accepts. An account with $100 or less at risk, and every PROTECT account, closes in full. On a TRADE or EARN account the fee is 1.5 % of what is closed.
  • A loss the insurance fund cannot cover. A trader's loss is never collected from later money, so if an account goes below zero the fund pays. If the fund runs short, the rest is counted as a shared loss among the makers who were paid. A thin fund is a real risk for a maker (section 6).
  • Admin powers. The venue's admin can pause withdrawals, change fee settings inside fixed contract ceilings, and upgrade the contracts. Moving these behind a multisig and a delay, so any upgrade is public before it takes effect, is under way; until it is done, treat the admin as trusted.
  • It is a testnet. No real money moves. The venue may be reset, paused or upgraded, and the numbers on screen are for testing the mechanism.

What this means for you#

Only trade or quote with money you can afford to have stuck, closed late, or marked off stale prices. If a price on screen looks frozen, treat it as frozen.

How the contracts are checked#

There is no paid third-party audit. Security rests on automated and open checking instead, in four layers. Each is designed to be run by anyone, and none of them is a guarantee.

1. Rules that must hold after every step#

A fuzzer runs long random programmes against the real compiled contracts in a local copy of the chain: deposits, withdrawals, opens, partial closes, funding, liquidations, price moves, fee changes, and calls by strangers. After every single step it checks more than twenty rules, and it prints the seed, the step and the shortest trace of any rule that breaks. In plain words the rules say:

  • Money is conserved. What the cells hold equals what came in from custody, less what went out, plus the perp results the venue posted, to the cent. Nothing is created or lost by a fill, a fee, a funding payment or a liquidation.
  • A refused action changes nothing. If a transaction reverts, no balance, position, mark or flag moved.
  • Closing is never blocked. A close that reduces risk is never refused for margin.
  • Funding is charged once. Each stretch of time is charged exactly once, never twice and never skipped silently.
  • No recourse. No account but the insurance fund ever carries a debt, and your wallet's cash only falls by your own signed act.
  • A flagged account takes no new risk, and an open leaves an account above its initial requirement.
  • PROTECT is all or nothing: the perp and its options open together or neither does.
  • A round trip never profits, fees and spreads stay inside their fixed ceilings, and privileged calls need their role.

A rule set that has never failed proves little, so the suite is also run against ten deliberately broken copies of the contracts (the fund pays but books nothing, a fee credited twice, a withdraw that skips the margin test, and so on). Each one is caught.

2. Proofs of the model#

The arithmetic of the venue's money operations is also written as a model in the Lean language, and every statement about it is proved by a theorem prover: in every operation money is neither created nor destroyed; an option payment goes down a fixed order (the payer, then the insurance fund, then a haircut on the other side of the trade) and never becomes anyone's debt; fees, funding, liquidation and margin follow their stated formulas; and no maker is filled past its size. A proof is about the model, not the deployed code. The model is tied to the contracts by checks that replay it on the contracts' own recorded transactions, which is evidence and not a verification of the deployed bytecode. Pricing, the oracle, the keeper, the HyperCore bridge, access control and upgrades are outside the model.

3. Attacker agents#

Agent attackers are given the contracts and the venue and told to take money, lock others' money, or break an invariant. Round 1 ran on 7 October 2026 and found real problems, some of them serious. Each is being fixed, and each fix is re-run against the attack that found it. The rounds repeat, and their reports are published.

4. Open to anyone#

The rules, the proofs and the harnesses are written to be read and extended: anyone can add a rule or an attack, and it runs on every change. If you find something, send it through the FEEDBACK tab (section 9).

Kept in lockstep with the code: a check fails if this page drifts.

Everything above is the short form. The canon — every ruling, every rejected alternative with the reason it was rejected, and the measurements behind each number — is the design spec, and the corroboration procedure is the audit protocol. Both live in the repository this venue is built from.