The Problem
When infrastructure becomes a business decision
Firms trading on decentralized exchanges (DEXes) have two contradictory requirements: wallets holding millions of dollars must be protected to institutional standards, and trading strategies must execute within milliseconds to keep up with markets. Historically, firms have had to compromise on one to achieve the other. One of DeFi's highest-volume algorithmic trading firms was unwilling to make that tradeoff. This case study examines how they used an on-premise deployment of the Cubist platform to hit their latency targets and move profitable new strategies into production without compromising on security.
The firm had already invested heavily in a key management system based on multi-party computation (MPC). Their MPC provider met the firm's security requirements and was trusted in production.
But security alone wasn't the problem; security at speed was.
The MPC provider’s signing latency regularly exceeded 600 ms per request, which made latency-sensitive trading strategies impossible to implement or put them at a severe competitive disadvantage and, as a result, left millions of dollars on the table. While 600 ms is perfectly acceptable for manual custody workflows, it is far too slow for DEX trading, which has unique challenges compared to trading on centralized exchanges because the trading wallet must generate a unique cryptographic signature for every transaction. On DEXes, signing is on the critical path between identifying an opportunity and finalizing a transaction on-chain, and one of the few latency components traders directly control. Not only can the added latency destroy profitability (e.g., prices move, arbitrageurs react, liquidity disappears, priority lost in the mempool, etc.), but it renders some strategies infeasible.
Some of the firm's most promising trading strategies required sub-100 ms end-to-end execution, but their MPC provider was consuming several times that budget on its own. This is a fundamental limitation of MPC technology: generating a signature requires several network round trips between parties holding key shares, introducing latency that is difficult to eliminate.
The common alternative, hot wallets, can achieve extremely low latency because signing happens directly within the application infrastructure, by, for example, storing keys in memory. Hot wallets may be acceptable for smaller balances or less sophisticated operations, but for a firm managing significant capital and running automated strategies around the clock, they concentrate too much risk in systems that are exposed to the Internet and routinely process untrusted inputs. Managing hot wallets is a security operations nightmare because every person or system with access to a private key becomes a potential vector for catastrophic asset loss, and continuously managing, auditing, and enforcing that access is difficult and error-prone. Hot wallets were not an option for this firm; they take security seriously—e.g., we can't even disclose who they are since this would be disclosing details of their internal systems.
What had initially been a security-focused decision was now impacting the firm's ability to execute novel trading strategies. They had effectively been forced to choose between the security model they needed and the latency their strategies required. No vendor they’d previously evaluated could give them both.
“We knew where the opportunities were, but our signing infrastructure prevented us from acting on them. We weren't looking for a marginal latency improvement. We were looking for a way to unlock entire classes of new trading opportunities.”
Head of Trading · Leading Trading Firm
