Launching Perpetuals as Your Product Surface: What the Design Ships With
A new venue choosing its product surface makes one decision that flows through every subsequent design choice: perpetual futures, dated futures, or both. For most operators launching today the answer is perpetuals-only, for good structural reasons. There are also specific costs to the decision that need to be understood before the platform ships.
This playbook covers what perpetuals commit an operator to at the platform layer, which flow the decision attracts and which it does not, and what the team has learned across ~30 years of combined experience shipping matching engines, hedging stacks and venue infrastructure about the failure modes that matter.
Why Perpetuals Became the Dominant Crypto Derivative
Perpetuals were first shipped by a crypto derivatives venue in 2016 and every meaningful competitor copied the design within eighteen months. By 2020 perpetual volume was several multiples of spot on most crypto assets, and it has held that ratio since.
The structural reason is simple: retail directional flow does not want a fixed delivery calendar. Under a dated-futures model, participants have to roll positions, pay two spreads, manage the basis. The overhead is small per trade and large in aggregate — enough that most retail flow historically stayed in spot with margin loans rather than touching dated futures at all. Perpetuals removed the calendar and captured that flow at scale.
For an operator, this means the product decision compounds. A venue offering perpetuals inherits the flow gravity of the dominant derivative on the reference asset class. A venue offering dated-only crypto futures is fighting the entire retail market's revealed preference — fine if the target flow is regulated hedgers with fixed delivery calendars, a losing product strategy if the target is directional retail or crypto-native prop.
What the No-Expiry Decision Commits You To
Removing the expiration date sounds like a subtraction. In platform terms it is a substitution — settlement-driven convergence is swapped for continuous funding payments, and the new mechanism is more design-intensive than the old one.
On a dated future, convergence is mechanical. As settlement approaches, any spot-futures divergence gets arbitraged out and by expiry the two prices are the same number. The exchange only has to run settlement correctly on the day.
On a perpetual, the venue has to compute and settle a funding payment between longs and shorts on a fixed cadence, forever. The computation has to reflect the perp-spot premium accurately enough that arbitrageurs will close divergence without over- or under-correcting. And the payment has to clear through the margin engine without cascading liquidations when rates run hot.
That is a permanent operational surface — and the operator's largest tuning lever for the shape of the book. See funding-rate arbitrage flow for the participant side of what those design choices attract.
Funding Mechanism as a Design Tool
Three parameters carry most of the weight in how funding behaves on a venue. All three are operator choices.
- Cadence. 8-hour cycles are the crypto standard, inherited from the original 2016 design. 1-hour and 4-hour cycles exist and compress the arb window — favouring large-capital participants and discouraging small ones. 24-hour cycles suit forex where the underlying settles once per session. Cadence changes ripple through every downstream system: margin recalc, ledger flush, notification cadence, ops surface refresh rate.
- Per-interval cap. A hard cap on the per-cycle payment (0.75% per 8h is a common default) protects both the trader and the venue from runaway rates during euphoria. Without one, extreme rates cascade into liquidations across every hedged book on the platform. This is not optional — a venue without a funding cap turns euphoric markets into a liability event.
- Computation window. The premium index that feeds funding is typically a TWAP over the interval. Window length trades off responsiveness against noise. A window that is too short lets a single upstream spike drive the payment. A window that is too long lets sustained divergence sit uncorrected.
Tuning these is not a one-time decision. Different asset classes want different settings — see per-asset-class funding design — and the operator needs the surface to change them per-symbol without a redeploy.
Mark-Price Feed Engineering
Everything downstream of the perp price feed depends on the price being right. Unrealised P&L, maintenance margin, liquidation triggers, funding computation, and every risk metric on the ops console all read from the same mark. A bad print for 200 milliseconds cascades through all of them.
The pattern that works in production is:
- Blend across at least three independent spot venues. A single upstream reference is a single upstream failure mode.
- Median-filter the constituents. A geometric mean or arithmetic average is dominated by the worst print. A median rejects the outlier automatically.
- Throttle updates to a sub-second cadence with hysteresis. Every tick that moves the mark is a tick that can move a maintenance-margin calculation.
- Reject stale prices at the boundary. A feed that stops arriving is worse than a feed that arrives slightly wrong — the engine has to know when a source has gone dark and stop weighting it.
- Publish a staleness signal on the ops surface. Risk teams need to see mark-price freshness alongside the mark itself.
See matching engine architecture for how the mark feeds into the engine's risk and liquidation paths.
No Expiry Means No Roll Flow, No Calendar Spreads, Indefinite Duration
Traditional futures generate a specific set of platform activity: roll flow at every expiry, calendar-spread order types, term-structure surfaces on the ops dashboard, and positions with a mechanical close date on the risk system. A perpetuals-only venue ships none of that.
What replaces it is a different position lifecycle. Duration is set by participant behaviour, not by the contract, and it varies wildly — sub-minute for HFT market makers, hours for directional swing traders, indefinite for hedged carry positions. Second-order platform implications follow:
- The risk engine has to price and margin positions whose duration is unbounded, not amortise premium over a known time-to-expiry.
- Funding accrual is a permanent line on the position P&L rather than a one-shot cost at settlement.
- Historical data queries for individual positions can span months or years, not just to the next expiry.
- Analytics and reporting have to handle open positions older than the venue's oldest funding-rate change without breaking.
None of this is unmanageable — it is just a different data model than a dated-futures platform runs. A team building a perpetuals venue on top of an inherited dated-futures codebase will discover most of these mismatches the hard way.
What Perpetuals Do Not Attract
The product decision has a shadow side. Perpetuals win directional retail, crypto-native prop, and delta-neutral funding-arb participants. They do not win everything.
- Physical delivery hedgers. A jet-fuel buyer hedging next quarter's physical need requires a contract with a specific delivery date and grade. Perpetuals do not deliver. Any venue courting corporate hedgers with physical exposure needs a dated product alongside.
- Regulated hedge accounting. Corporate treasuries applying hedge accounting under IFRS 9, and CFTC-registered hedgers, need contracts on regulated exchanges with specific characteristics. Most perpetual venues are not that.
- Term-structure strategies. Calendar spreads, butterflies, and cash-and-carry all require an actual curve. Perpetuals collapse the curve into a single price and a funding rate — contango and backwardation are still there, expressed continuously rather than across expiries.
- Section 1256 tax treatment. US-regulated futures get 60/40 long-term/short-term treatment on gains. Perpetuals typically do not. Anyone optimising for after-tax return cares about the gap.
An operator whose target flow includes any of the above needs dated futures in the roadmap. Most launches sensibly defer this — dated futures are strictly more surface area — but the tradeoff should be explicit rather than accidental.
The Component List That Ships With Perpetuals
Choosing perpetuals as the product surface commits the operator to a fixed list of platform components. None of them are optional.
- Continuous margin engine. Mark-to-market runs continuously rather than end-of-day. Every mark update potentially moves maintenance margin. The engine has to compute this fast enough that the risk system stays ahead of price action.
- Funding computation and settlement. Per-interval premium calculation, cap enforcement, per-position accrual, and settlement flush into the ledger on schedule. This is a permanent scheduled workload with no downtime tolerance.
- Active liquidation engine. Positions that breach maintenance margin have to close before they go negative. The liquidation path has to run through the same matching engine as normal flow, with priority handling, and it has to price at the bankruptcy price accurately enough that trader-side losses are bounded to their posted margin.
- Insurance fund. When liquidations clear below bankruptcy price, the residual has to be absorbed somewhere or socialised. The insurance fund is the buffer. See insurance fund mechanics.
- ADL queue. When the insurance fund runs dry in a stress event, auto-deleveraging closes the highest-leverage profitable positions on the other side of the failing liquidations. This is the last line of defence and needs a deterministic, published ranking.
All five are load-bearing. A venue that ships perpetuals without any one of them is running a design that will fail on a bad day.
What Basis Points Ships
Every default in the Basis Points platform reflects the team's ~30 years of combined experience shipping matching engines, hedging stacks and venue infrastructure. The perpetual-futures product surface arrives fully assembled. Funding cadence is 8h on crypto and 24h on forex by default, tunable per-symbol without a redeploy. Per-interval cap sits at 0.75% by default with the same tuning surface. Mark price is blended from at least three independent sources with median filtering, throttled to sub-second cadence, and publishes a staleness signal to the ops dashboard. Liquidations route through the same matching engine as normal flow at bankruptcy price; residuals flow to the insurance fund; ADL queue is deterministic and published.
Operators licensing the platform inherit this stack and tune it per their target-flow strategy. Dated futures are on the roadmap for operators whose flow requires them; perpetuals ship as the default because that is where the addressable derivatives volume actually sits.
The product decision is not just what to list. It is what stack the operator commits to running, forever, once the venue is live. Perpetuals ship with a specific set of load-bearing components — getting them right at the platform layer is a design choice made once, getting them wrong is an incident report published later.
Frequently Asked Questions
Should a new venue launch perpetuals-only, dated-futures-only, or both?
For most operators targeting directional retail, crypto-native prop, or funding-arb flow, perpetuals-only is the right first launch. Dated futures are strictly more surface area — additional expiry management, roll-flow handling, calendar-spread order types — and they capture a materially smaller share of addressable volume. Add dated futures when the target flow requires them (physical hedgers, term-structure strategies, Section 1256 optimisation).
What are the biggest platform-layer decisions when launching perpetuals?
Funding cadence and per-interval cap, mark-price blending and outlier rejection, liquidation-engine bankruptcy pricing, insurance-fund capitalisation and top-up policy, and ADL queue determinism. All of these are set at platform level, not commercial level, and all of them ship with the product decision. Getting any one materially wrong is a bad-day incident.
Why is the mark-price feed treated as load-bearing infrastructure?
Every downstream risk decision — unrealised P&L, maintenance margin, liquidation triggers, funding-premium computation — reads from the same mark. A single bad print for 200ms cascades through all of them, potentially liquidating hedged books across the platform. Blending across at least three independent sources with median filtering, throttling, and staleness rejection is the pattern that survives production.
What flow does a perpetuals-only venue attract, and what does it not?
Attracts: directional retail, crypto-native prop, funding-arb participants, HFT market makers. Does not attract: physical-delivery corporate hedgers, regulated hedge-accounting users under IFRS 9 or CFTC frameworks, term-structure and calendar-spread strategies that need an actual curve, and traders optimising for US Section 1256 tax treatment. The last group needs dated futures on a regulated exchange.
How does funding cadence affect the shape of the book?
Shorter cadences (1h, 4h) compress the arb window and favour large-capital participants who can move on tighter margins; they discourage smaller arb players. 8h is the crypto standard and works well across most participant sizes. 24h suits forex where the underlying settles once per session. Cadence changes ripple through margin recalc, ledger flush, ops-surface refresh cadence, and every downstream system reading funding events — so it is not a lightweight tuning knob.
What ships with the perpetual-futures product decision that operators cannot skip?
A continuous margin engine, funding computation and settlement, an active liquidation engine, an insurance fund, and an ADL queue. All five are load-bearing. Perpetuals cannot rely on expiry-driven convergence or end-of-day mark-to-market, so the platform has to run all of these continuously with no downtime tolerance. Skipping any one of them is a venue that fails on a bad day.
Evaluating the platform?