A perpetual futures system maintains leveraged exposure without a scheduled expiry, using margin, a pricing reference and funding rules to manage ongoing obligations. Its engineering challenge is keeping position accounting, executable liquidity and collateral risk consistent through volatile markets. This resource presents design considerations for derivatives infrastructure, not a description of an available trading service or a claim that proposed FT partner modules are deployed.

Define the position before designing the venue

Specify the economic unit first: underlying reference, contract quantity, settlement asset, position direction and how changes in price become profit or loss. A linear contract settled in a stablecoin differs from an inverse contract settled in the underlying asset. Their units, rounding and collateral sensitivity cannot be interchanged in an implementation.

For a hypothetical linear contract, unrealized P&L can be expressed as signed position quantity multiplied by the difference between the current mark and the entry price. Realized P&L depends on the quantity closed and the accounting convention for entry price. Fees and funding are separate ledger entries. Combining them into an unexplained balance adjustment makes reconciliation and dispute analysis harder.

Document position increases, partial reductions, direction changes and transfers. A trade that crosses from long to short must first close the existing exposure under the chosen accounting rules, then open the residual position. Test those transitions at minimum sizes and decimal boundaries.

Give reference, execution and margin prices distinct roles

The price of the last trade is not automatically a reliable liquidation reference. A thin trade can move a venue price while broader underlying markets remain stable. Conversely, an external reference can remain apparently stable while executable depth on the venue disappears.

Define the index or oracle reference, the price used to value account equity and the price at which a position can actually be reduced. Explain any smoothing, bounds and fallback logic. These choices influence who bears losses during dislocations. Using the most favorable price for each operation creates an exploitable inconsistency.

Feed checks should include freshness, units and acceptable deviation under the intended market conditions. When data is unavailable, specify which operations may continue. Repaying debt or adding collateral can often remain useful, while increasing exposure or withdrawing support may need to stop. A fallback price should have a stated trust model and duration rather than becoming a permanent stale reference.

Treat funding as an obligation with a precise clock

Funding creates recurring transfers intended to influence the relationship between perpetual and reference prices. It is not a promise that the prices will converge immediately. As a concrete implementation reference, dYdX's funding documentation describes premium sampling, periodic funding and configurable limits. A new venue must specify its own mechanism and assumptions.

An accumulator can track funding per unit of position over time. Each account records the last settled accumulator and realizes the difference when its position is updated. Define the sign convention once and use it consistently across the contracts, APIs and interface. A positive displayed rate means little unless users know which direction pays.

Funding affects account equity before a user next trades. Withdrawal and liquidation checks must include accrued obligations rather than rely on the last stored cash balance. Test boundaries around the funding interval, long periods without interaction, position changes between samples and interrupted market operation. Decide how resumption handles missing or stale samples.

Connect margin limits to executable risk

Initial margin determines whether an account can add exposure. Maintenance margin determines when recovery action is required. The gap provides room for execution, fees and adverse movement; it must be calibrated to the market's actual recovery capacity.

A fixed margin percentage alone does not account for position size. Concentrated positions can require larger buffers because closing them consumes more liquidity. Likewise, aggregate open interest and directional imbalance can matter even when each account passes its individual check. A venue should define both account limits and market limits.

Shared collateral adds another dimension. A token that supports lending and perpetual exposure must be evaluated against their combined obligations. A nominal hedge can reduce directional risk while leaving basis, funding and settlement risk. Isolated subaccounts can contain unfamiliar markets, but only if transfers, withdrawals and loss allocation enforce that boundary. The choice between isolation and portfolio margin is a risk-policy decision with consequences throughout the ledger.

Choose execution and liquidation as one design

An order book, automated market maker or RFQ process can each support a perpetual venue, but they expose different liquidity and operational dependencies. The risk engine should know which path can actually reduce an unsafe position and how that path behaves when participation falls.

Partial liquidation can reduce exposure while preserving a remaining position, provided the resulting account meets the defined target or enters another bounded recovery step. The engine must account for fees, funding and execution cost when evaluating improvement. Repeated tiny liquidations should not consume all remaining collateral in overhead.

A no-bid condition needs an explicit response. Position transfer, an auction, a funded reserve or a defined deleveraging process are possible design elements, each with different consequences for other participants. Specify trigger order, authority and accounting effects. A reserve balance is finite, and a deleveraging rule should be observable before it is needed.

Keep the market's operating state observable

A derivatives market can be open, restricted to reductions, paused for an oracle incident or undergoing an orderly close. These are distinct states with different permissions. Integrators need a reliable way to determine the current state and the reason for a rejected action.

ConditionDesign response to define
Unreliable price dataBounds on trading, withdrawals and liquidation
Liquidity disappearsRecovery timing and escalation path
Funding update is delayedAccrual and resumption treatment
Market is retiredClose price, settlement and unclaimed balances
Reserve is depletedRemaining loss-allocation procedure

Operational records should link each balance change to a trade, funding interval, fee, transfer or recovery event. Monitoring should follow both solvency and execution capacity: open interest, concentration, margin deficits, oracle age, liquidation backlog and available reserve assets.

Test solvency across adversarial timelines

Test a reference model against implementation results for long and short positions, partial closes and direction flips. Include funding and fees in the comparison. Check that aggregate transfers reconcile under the chosen counterparty model, with rounding and reserves explicitly accounted for.

Scenario tests should combine failures rather than isolate them: collateral falls while funding is owed; the price feed returns after an outage; a large liquidation consumes depth; or a withdrawal races a position update. The same account state should produce consistent permissions regardless of which API or module initiates the operation.

A proposed deployment should begin with a bounded market set, conservative exposure limits and rehearsed incident procedures. Evidence for expansion includes reliable settlement, explainable funding, adequate recovery liquidity and reproducible reconciliation. Architecture documents can establish how the system is intended to work; only deployment-specific testing and operating evidence establish whether it meets that design.

Common engineering questions

What is the purpose of perpetual funding?

Funding creates recurring transfers intended to encourage alignment between a perpetual market and its reference price. Its calculation, settlement timing and limits are venue-specific, and it does not guarantee immediate convergence.

Can perpetuals use the same collateral as lending?

A proposed architecture can permit this when one risk domain accounts for loans, position P&L, funding, fees and reserved assets together. Whether that is appropriate depends on asset liquidity and the intended loss boundaries.

Why do liquidation and trading design belong together?

A margin threshold is useful only if there is an executable path to reduce the exposure. The matching system, available counterparties and fallback procedures determine how much recovery capacity exists during stress.

References & further reading