Perpetual DEX (Futures Trading Platform): model and chain selection through to a fast, high-volume launch.
The client wanted to build a perpetual futures trading platform but came in with no Web3 background. They didn't know which trading model would suit a perpetual DEX, and had no way to evaluate which Layer 2 network to deploy on. Every downstream decision - including architecture, liquidity design, and integration effort - depended on getting those two foundational choices right, and getting them right fast.
As a team with zero Web3 background, the client's biggest fear wasn't the build. It was picking the wrong foundation and finding out six months in. They chose us because we brought a structured, criteria-based way to evaluate both the trading model and the L2, and because we were willing to slow down the first two weeks to get that decision right instead of rushing straight into development.
A dedicated team with a structured evaluation sprint before a single line of production code was written.
1 Product Manager, 1 Business Analyst, 1 Tech Lead, 3 smart contract engineers, 2 backend engineers (oracle/liquidation systems), 2 frontend engineers, 1 DevOps/Infra Engineer, 1 QA engineer.
A structured 2-week evaluation sprint before development began, with the client’s non-technical founders sitting in on every model/chain review.
Weekly technical reviews once building started, translating engineering trade-offs into plain business terms throughout.
We advised the client toward a vault-based perpetual model, where traders take positions against a shared liquidity vault rather than a peer-to-peer order book, because it offered deeper effective liquidity from day one without needing to bootstrap a deep order book first. For the network, we evaluated candidate L2s against sustainability, fee levels, incentive programs, and integration complexity - not just raw TPS.
Solidity vault and position contracts on the selected L2 rollup, handling margin, funding rate, and settlement. Chainlink price feeds with a secondary redundant oracle path to reduce single-oracle risk on liquidation triggers.
An off-chain keeper bot (Go) monitoring positions in real time and submitting liquidations on-chain within seconds of threshold breach.
Subgraph-based indexing layer for positions, trade history, and vault performance. React/Next.js frontend with wagmi/viem for wallet connections and real-time position/PnL tracking.
Tech stack: Solidity · Layer 2 rollup · Chainlink oracles · Go (keeper bots) · The Graph · React/Next.js · wagmi/viem
Model and chain selection were treated as a structured evaluation with weighted criteria - not a quick recommendation - so the client understood and owned the trade-offs before a single line of production code was written.
The highest-risk component got the most engineering attention: the liquidation engine was stress-tested against simulated flash-crash scenarios and sudden volume spikes to confirm it could clear at-risk positions before the vault took on bad debt.
That upfront clarity and targeted stress-testing is what let the three-month build proceed without the model, chain, or risk engine being questioned midway through.
Model evaluation, Layer 2 selection, architecture design, oracle strategy.
Core build: vault contracts, matching/position logic, liquidation engine.
Stress testing, security audit, incentive program integration, launch.
With the right model and Layer 2 chosen upfront, the client launched fast and the platform scaled quickly - reaching $10M in TVL, $200M in cumulative trading volume, and over 80,000 users, with the liquidation engine clearing at-risk positions in under 10 seconds on average and zero instances of vault bad debt in the months following launch.
Read the full category overview, market data and outlook.