-
A bad perpetuals launch does not degrade, it cascades: one mispriced funding rate empties the insurance fund and socializes losses to your best traders.
-
This checklist covers 27 items across four phases: Pre-Build, Build, Validation, and Post-Launch.
-
It includes a self-assessment readiness score, clear 7.5 / 10 before you go live.
The cost of a bad perpetuals launch is not measured in downtime, it is measured in trust you never get back. When the funding rate is miscalibrated and the insurance fund drains, the platform does not slow down; it socializes losses onto the exact traders you most needed to keep. That is the failure mode unique to derivatives: the system can be technically up and economically insolvent at the same time. The work below is about the parameters that decide solvency under stress, the ones you cannot copy from a competitor running ten times your volume. Finish it and you will know your risk engine holds before the market tests it for you.
| Phase | Timing | Items | What breaks if you skip it |
|---|---|---|---|
| 1Pre-Build Foundation | 12–16 weeks out | 6 | Wrong collateral model, wrong funding mechanism, unrecoverable risk parameters |
| 2Infrastructure Build | 4–8 weeks out | 8 | Liquidation cascade risk, insurance fund under-capitalized, funding rate mispriced |
| 3Pre-Launch Validation | 1–3 weeks out | 7 | Day 1 insolvency, liquidation engine failure, regulatory rejection |
| 4Post-Launch Monitoring | Week 1–4 after live | 5 | Insurance-fund drain, trader exodus, socialized-loss event |
Pre-Build Foundation
The single most expensive Perpetual Trading Platform mistake is made here — the decisions that are cheapest to fix now and most expensive once build has started.
Pick the jurisdiction before anything else it determines your banking partners, your AML configuration, and which licenses you even need. Get a regulatory counsel opinion in writing for the UAE, not a forum thread.
Shortlist two Liquidity + Market Making APIs providers and run a real integration spike against your stack before you commit. Validate latency, failover, and the actual data shape not the sales deck.
Decide your compliance posture now and choose AML + Identity Verification APIs to match it. Map every flow that touches a user identity or a transaction so the pipeline is designed for AML, not retrofitted.
Model your unit economics at expected volume. Put Liquidity + Market Making APIs cost, compliance cost, and infrastructure cost in one sheet against your fee structure. If the math only works at 10× your launch volume, you do not have a model yet.
Decide custodial vs non-custodial vs MPC, and document the key-management model your auditor will sign off on. This is the most expensive decision to reverse.
Define cross vs isolated margin and your funding-rate formula in Phase 1, calibrated to your own open-interest baseline. Do not inherit a competitor’s parameters, their liquidity is not yours.
Infrastructure Build
This is where most platforms that fail, fail. Each item below is something that is far harder to add after beta than before it.
The funding rate that emptied the insurance fund
A perpetual exchange launched with a funding-rate mechanism copied from a competitor’s whitepaper, without adjusting for its own lower open-interest baseline. On Day 4 a coordinated long position drove the rate to 0.8% per 8 hours. The insurance fund was depleted within 18 hours and socialized losses hit every profitable trader. The platform never recovered.
Stand up Low-latency Matching + Risk Engine for scale from day one. Configure auto-scaling, partitioning, and back-pressure handling and load the config into version control so it is reproducible, not tribal knowledge.
Connect Liquidity + Market Making APIs and set per-pair depth targets before beta. Validate each pair independently a healthy BTC book tells you nothing about your thin pairs.
Wire AML + Identity Verification APIs into live transaction monitoring and run a real suspicious-transaction-report dry run end to end. A configured-but-untested AML stack is not a compliant one.
Build the KYC flow and instrument every step. Run it with real external testers and record the drop-off. The number you get is the number you launch with unless you fix it now.
Build the liquidation engine and capitalize the insurance fund, then stress it against coordinated-position and gap-move scenarios. Confirm partial liquidations fire before the fund is ever touched.
Build the reporting pipeline and submit a test file in VARA's required format before you need to. Format rejections are discovered at the deadline by everyone who skips this.
Configure matching, mark-price, and auto-deleveraging logic together, they are one system under stress. Replay a volatility spike and confirm ADL ranks and fires the way your docs promise traders.
Define circuit breakers, rate limits, and a written incident-response runbook with named owners. Rehearse the first 15 minutes of an incident before you have one.
From Troniex’s implementation work with Perpetual Trading Platform operators
Across derivatives builds, the parameter teams get wrong is not the headline leverage cap, it is the mark-price source under thin liquidity. A mark price that follows a manipulable index lets a modestly funded attacker trigger liquidations on solvent accounts. We see it most often on newly listed pairs, where index depth is thin and nobody re-checked the oracle config after launch.
Pre-Launch Validation
The last gate before a real user touches it. Everything here is about discovering the failure in a drill instead of in production.
| What to validate | Pass threshold | Fail signal | Resolution |
|---|---|---|---|
| Liquidation latency under load | < 50 ms | Queues behind order flow | Isolate liquidation lane |
| Insurance-fund coverage | > 99.5% scenarios | Shortfall in stress test | Recapitalize before launch |
| Funding-rate bounds | Calibrated to OI | Copied from competitor | Re-derive on own baseline |
| Mark-price manipulation | Multi-source index | Single thin source | Add index redundancy |
| ADL ranking correctness | Matches spec | Wrong accounts ranked | Fix ADL ordering |
| Uptime under 3× load | > 99.9% | Risk engine lag | Infrastructure config review |
Run a sustained load test at 3× projected peak, not average. Watch the matching queue, the database, and the auto-scaler under pressure and capture where the first thing bends.
Commission a third-party audit with an explicit scope document, then remediate every critical and high finding before launch. Get the scope in writing before you get the report.
Run your compliance stack against VARA's published test scenarios and tune thresholds against the results not against defaults shipped by the vendor.
Re-run the onboarding flow with a fresh external cohort and confirm completion clears your benchmark. Fix the friction point you find before, not after, you spend on acquisition.
Confirm depth on every launch pair at peak volume, pair by pair. Add a market maker before go-live for any pair that cannot hold its spread target.
Run a real failover drill: kill the primary, time the recovery, verify data integrity on the other side. An untested BCP is a document, not a plan.
Simulate a coordinated attack: a large position driving funding, a gap move triggering liquidations, the insurance fund absorbing the shortfall, all at once. This is the only test that matters for a perp.
The liquidation that fired too late
During validation a team tested liquidations in isolation and they worked cleanly. What they never tested was a gap move with the matching engine already under load. In the combined drill, liquidations queued behind ordinary order flow and fired 4 seconds late, long enough for three positions to go underwater past their margin.
Post-Launch Monitoring
The first 30 days decide whether the launch holds. Item 26 is the retention mechanic unique to this platform.
Review execution quality and per-pair liquidity every day for the first two weeks. The early signal of a failing launch shows here first.
Watch the live onboarding funnel and isolate the real drop-off step within the first 72 hours, while you can still act on it.
Review the AML queue weekly. A false-positive rate creeping up is an early compliance-cost problem you want to catch before it buries the team.
Submit the first regulatory report on time, in the validated format. The first one sets your standing with VARA.
Turn on the retention loop perps run on: funding-rate optimization for makers and a public PnL leaderboard for volume. Seed the leaderboard Week 1 to build the competitive flywheel.
Is your Perpetual Trading Platform ready to launch?
Each category fills in automatically as you tick the checklist above — and the verdict updates live. Drag any slider to model a what-if before you commit.
Score your readiness
Tick the checklist above — categories fill in automatically and the verdict updates live.
Get the Perpetual Trading Platform Launch Readiness Report
A documented PDF — your scores, gap analysis, go/no-go decision, and full checklist record.
Where Perpetual Trading Platform launches actually fail
1Funding parameters borrowed from a bigger venue
A formula tuned for a venue with deep open interest behaves violently on a thin book. The first coordinated position finds the gap, and the insurance fund pays for the borrowed assumption.
2Liquidations tested in isolation
A liquidation engine that works alone and an engine that works under matching load are two different systems. The cascade is born in the interaction nobody simulated.
3The narrative one
The mark price followed a single index that looked deep enough in testing. On launch week a newly listed pair had a fraction of that depth, and someone noticed. A few hundred thousand dollars of pressure on the index moved the mark enough to trigger liquidations on accounts that were never actually underwater. The accounts liquidated were solvent; the index was not. The team spent the next month explaining to liquidated traders why the system did exactly what it was configured to do.
4An under-capitalized insurance fund
A fund sized for the average day is decoration on the bad one. The shortfall does not stay the platform’s problem, it becomes a socialized loss on the traders you most wanted to keep.
5No coordinated-stress drill
Funding, liquidation, and insurance are one system under stress and three systems in the test plan. Teams that never drill them together discover the coupling live.
Frequently asked questions
Let’s Get in Touch.
Unsure whether your Perpetual Trading Platform is ready to go live? Our infrastructure team will pressure-test your readiness and map the gaps with honest, practical advice — ABSOLUTELY FREE.
Book Your Free Consultation
