Omni Progress Update w/ @variational_lvs

The Spaces covered a wide-ranging update on Omni by Variational and market design lessons from a recent Hyperliquid pre-market incident. Lucas explained how thin-liquidity, self-referential pre-markets can be manipulated into cascading liquidations and why circuit breakers, cooldowns, and strict risk limits are essential. He contrasted order books with Omni’s RFQ model that hedges across venues and liquidates on an external index, making manipulation far harder. UI V2 launched to strong trader feedback with denser controls, better TP/SL and liquidation estimates, and more enhancements coming. The headline feature, loss refunds, is backend-complete, in internal staging, with UI polishing before imminent testnet and then mainnet. The mechanism provides instant USDC refunds on losses with a “luck factor,” alongside robust anti-gaming design, capped pools isolated from OLP, multi-phase testing, and planned audits/bug bounties. Metrics show exponential growth: DAU/WAU/MAU rising, inflows spiking on releases, and volumes accelerating even pre-rewards. Near-term roadmap: loss refunds and reward tiers, read API (then invite-only trading API), new order types, and OLP deposits. The team previewed KBW and Token2049 events, upcoming competitions (including loss-refund-themed), and a referral/affiliate system. Operationally, a small, senior team stays laser-focused on core UX, liquidity, zero fees, and saying no to distractions.

Variational Twitter Space: Comprehensive Notes and Key Takeaways

Participants

• Max (Host)
• Lucas (Co-founder; product/market design lead; frequent references to co-founder Edward/“Ed” and teammate Eugenios on quant/mechanism design)

Market Design Post-mortem: Hyperliquid Pre‑market Incident

• What happened
  • A pre‑market listing with thin liquidity experienced a price sweep upward that cascaded into short liquidations, followed by the manipulator selling into the spike on the way down.
  • Pre‑markets lack external reference prices (no spot market, no cross‑venue index), making them self‑referential and easier to swing via the order book.
• Why it was possible
  • Thin liquidity + order book mechanics + liquidation triggers based on last trade/mark prices created a feedback loop: pushing price up squeezed shorts, forced buy-to-close liquidations, and further amplified price moves.
  • Small/self‑referential markets are inherently more manipulable.
• Are order books uniquely vulnerable?
  • Liquidation spirals of this kind are largely an order-book artifact when liquidations hinge on last trade/mark from the same book.
  • RFQ models (like Omni) are more robust: quotes don’t set the global mark; positions/hedges reference a fair index (a moving-average composite across venues), and inventory is hedged externally, making price-pushing costly and ineffective.
• Fixes and best practices
  • Circuit breakers/cool‑off periods for large, rapid moves to allow capital to enter and reprice toward fair value.
  • Strict risk limits and index-based liquidation references (moving averages) rather than raw last trades.
  • Lucas notes Hyperliquid moved to implement safeguards of this nature, and views this as a cautionary tale underscoring careful market design.

Product Update: UI V2 Live

• Reception
  • “Resounding success” with positive feedback from Discord, support tickets, Twitter, and power users.
  • V1 UI underrepresented the sophistication of the infra/OLP; V2 significantly closes that gap.
• Shipped improvements
  • Better TP/SL selection, liquidation price estimate pre‑trade, denser data tables with more in‑table management, full reskin.
• Near‑term additions
  • Editable TP/SL directly on chart and multiple smaller UX refinements.
• Ongoing goal
  • Ensure UI quality matches back‑end/infrastructure quality and day‑trader needs; continue prioritizing community feedback.

Roadmap (Next Quarter Focus)

• Loss refunds and rewards tiers
  • Top priority; design published in docs; internal testing in staging; imminent Testnet, then Mainnet.
• APIs
  • Read API for market data/activity integrations (e.g., data sites and dashboards like CoinMarketCap, CoinGecko, DeFiLlama, Dune; plus user strategies/reporting). Invite‑only trading API (write) to follow later for more sophisticated users, while keeping UI as the primary experience initially.
• Order types
  • Adding stop‑limit and other trigger order types commonly expected on pro platforms.
• OLP deposits
  • Actively in development; no firm timeline, but among the top banner features after refunds and APIs.

Metrics & Growth Trajectory

• User activity
  • DAU/WAU/MAU trend lines are steadily rising; weekly reviews show consistent growth in users returning daily, weekly, and monthly.
• Deposits and inflows
  • Net inflows and new accounts spike around major product announcements (UI V2 was one of the biggest days for inflows).
• Volumes (organic; no points)
  • Despite day‑to‑day chop, aggregate growth is exponential when plotted: 0→$100M took ~4 months; $100M→$1B took weeks; now nearing $2B in a similarly short window.
  • Frequent $50M days, approaching $100M/day as the new normal; expectations rising quickly without turning on heavy growth levers yet.
  • Loss refunds is the final “blocker” before stepping on the gas (e.g., broader invites, more campaigns).

Loss Refunds: Status, Mechanics, and Testing

• Implementation status
  • Core back‑end logic complete and running in internal staging; UI polish in progress (rewards tab with refund history, notifications, etc.).
  • Testnet release “very soon,” followed by a short public testing period, then Mainnet.
  • Refunds are instant: on closing a losing trade, a USDC refund (0% to 100% of the loss) credits immediately to the user’s portfolio balance—early internal testing reports this feels “crazy good.”
• Observed/expected refund levels (from internal test datasets)
  • Many users averaged 5%+ back on losses; some individual refunds reached five figures (tens of thousands of dollars) in test simulations.
• Mechanism design highlights
  • At the moment of a realized loss, a probabilistic refund is drawn between 0 and the loss amount.
  • A “luck” factor increases odds if a user hasn’t received refunds recently, smoothing the experience over time.
  • A dedicated loss‑refund pool caps the system’s exposure and is separated from OLP revenues to avoid harming OLP performance.
• User behavior considerations
  • Closing one large loss vs. multiple partial closes: no guaranteed EV advantage; preference trade‑off between a single low‑probability large refund versus multiple higher‑probability smaller refunds. Lucas and Max personally favor “one big roll of the dice.”
• Anti‑gaming & safety
  • Micro‑loss farming scenario (community question): design and monitoring aim to make this unprofitable in expectation due to trading costs, difficulty ensuring steady losses, and the pool cap. Worst case, someone might extract slightly above-average refunds relative to peers; monitoring allows parameter adjustments.
  • Audits/bug bounties: platform audits include off‑chain logic and business logic, not only smart contracts. Considering a bug bounty (e.g., Immunefi) that would include mechanism-level exploits. Quantitative validation is primarily handled internally by the quant team.
• Testing methodology
  • Phase 1: Research/quant design—backtests on real production data; validate pool solvency, OLP drag, exploitability, and reward rates.
  • Phase 2: Internal staging—end‑to‑end load with a “bot army” simulating heavy usage and edge cases; instrumentation and metric checks.
  • Phase 3: Public Testnet—UI/UX validation and quasi‑real usage with test USDC on Arbitrum; fix issues prior to Mainnet.
  • Launch: careful, metered rollout with extensive monitoring.

Conferences & Community Events

• Korea Blockchain Week (KBW)
  • Live perps trading event/competition with other protocols; mixers and targeted dinners with community, partners, investors. Some co‑hosting with Arbitrum and other backers.
• Token 2049 (Singapore)
  • Lucas speaking at multiple events, more institutional tilt (options, pro derivatives, future of the protocol). Additional partner co‑hosted events; some open to community.
• Call to action
  • If attending KBW or Token 2049, DM the main account or open a Discord support ticket to coordinate invites/meetups.

Growth Campaigns & Community Activation

• Competitions and campaigns
  • More PnL and trading competitions; considering a “loss refunds” themed competition after launch.
  • Community AMAs, occasional giveaways; unique, brand‑specific contests (e.g., custom merch) rather than generic trading comps.
• Affiliates & referrals
  • Incoming referral rewards and a refreshed affiliate system; higher tiers for high‑impact community members who drive volume and onboard users.
• Expect acceleration
  • “Gloves off” once UI V2 and loss refunds are live; broaden invites and scale outreach.

Operating Model & Prioritization (Small, Senior Team)

• Team philosophy
  • Keep the team small, senior, and focused (currently <10; likely ≤15 by year‑end). Background in HFT influences a bias for elite, compact teams.
• Focus areas
  • Core: Variational protocol, Omni trading experience, OLP market‑making, and rewards. Maintain zero fees, deep/liquid quotes, responsive UI.
• Saying “no”
  • Ruthless prioritization is essential: defer multi‑chain, numerous protocol integrations, and new collateral expansions (USDC remains primary) unless there’s a clear 10x product impact. Ship excellence for the core user first, then expand.

Closing Calls to Action

• Watch for the Testnet announcement for loss refunds and help test; share feedback just as with UI V2.
• After Mainnet loss refunds, expect Omni to be the most compelling retail perps venue; the team will ramp marketing and asks the community to amplify.
• Stay active in Discord; the team still reads nearly every message and uses community input to prioritize.

Additional Mentions

• Media coverage was briefly noted at the outset (an article about the project); details not discussed further during the session.