Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
VDEX uses 0DTE Perpetual Futures to support non-crypto trading pairs, such as stocks, indexes, commodities, and foreign currencies. Although these traditional markets close during evenings and weekends, VDEX empowers users to hold their positions continuously.
Users can trade traditional markets, such as $AAPL, $XAU, and $EUR with up to 50x leverage. Positions may be cross margined with crypto pairs and other traditional markets for seamless capital efficiency.
If VDEX does not currently offer a particular trading pair, you can request a listing on our Telegram or Discord. With sufficient interest, VDEX can list markets within 24 hours.
VDEX is the only capital exchange that offers universal, anonymous access.
While CEX users contend with identity verification and DEX users face geoblocking, VDEX offers No KYC, No VPN everywhere and to everyone. This includes commonly restricted jurisdictions such as the United States, Türkiye, and the Russian Federation.
Begin trading in seconds regardless of who you are or where you live.
VDEX is powered by Virtual Rollups, a framework built on zero knowledge state channels. Transactions are self-validated and peer-to-peer, eliminating middle men and restoring power to users.
Virtual Rollups segment capital into two layers:
The settlement layer is a blockchain that locks and reassigns escrow according to state
ZK State Channels (ZKSC) are primitives that let users reassign escrow rights through state transitions
Participants lock funds on a settlement layer, like Ethereum, and receive a balance state. This balance state can be exchanged for position states through the ZKSC. At any time, users may submit states onchain to trustlessly unlock funds.
This architecture has distinct advantages:
Privacy
Full Self-Custody
ZeroGas transactions
Sub-millisecond finality
Learn more in the VDEX whitepaper.
VDEX unifies fragmented liquidity through omnichain deposits. Collateral can be supplied on supported chains such as Ethereum, Solana, Arbitrum, Avalanche, and BSC without bridging. Funds arrive within seconds.
Collateral remains on the user's preferred chain until withdrawn, eliminating third-party blockchain risks. Users can also deposit from multiple chains into one VDEX account, unifying collateral into one margin or yield balance. Profit can be withdrawn on any chain.
Assets on VDEX are exchanged through private, peer-to-peer ledgers called zero knowledge state channels. Other market participants are unable to view these transactions. Significantly, TP/SL and liquidation prices are also private, preventing malicious participants from targeting individual users.
User escrow is held in Vaults of Individual Participant Escrow (VIPE) onchain so that
Funds cannot be co-mingled by the exchange
Each user can audit a dedicated proof of reserve
Full Self-Custody of funds is preserved at all times
Pre-signed balance states are maintained by each user's Virtual Node so that funds can be withdraw independently of VDEX and in spite of frontend outages.
Market Execution and Liquidity Engine
Perp contracts never expire and can be opened with fractional margin, supporting leveraged trading.
VDEX supports perps on cryptocurrencies, stocks, commodities, FX, and prediction markets. Assets are listed by community request with leverage ranging from 1x to 50x.
Perpetuals function differently depending on the asset class:
VDEX operates a central limit order book with bids and asks sorted by price. Orders can be placed in integer multiples of the asset tick size. Orders are matched in price-time priority.
The clearing house verifies margin during order creation and matching. If margin is insufficient to cover the full order, it will be reduced until a partial match can be executed.
VDEX orders execute peer-to-peer via Virtual Rollups, not through a centralized backend or blockchain. Transactions are not batched and are executed in the order received. This prevents MEV attack vectors where orders are placed and processed jointly.
Market: An order that executes immediately against the order book
Limit: An order that rests and fills at the specified price or better
Stop Market: A market order that is triggered when a specified price is met or exceeded. The type used in take profit and stop loss orders (TP/SL)
VDEXCore is powered by Virtual Rollups. Virtual Rollups are peer-to-peer channels that allow users to self-lock funds on blockchains and receive an equivalent balance state on VDEXCore. Balance states can be used as margin or redeemed for the respective onchain tokens.
As the user's balance changes through trading, the corresponding balance state is continuously signed by the user and counterparties. At any time, the fresh balance state can be permissionlessly settled onchain for an equal amount of tokens.
Capital deposited into VDEXCore remains on the destination chain in isolated vaults. Corresponding balance states are fungible and independent of the underlying chain.
This enables cross-chain trading, so that an Ethereum depositor can seamlessly trade against an Avalanche depositor without bridging. It further enables users to deposit collateral from multiple chains into one unified balance and withdraw profits on an entirely new chain.
Trades execute entirely between users. First, the user sends their trade request and balance state to the counterparty. If the margin requirements are met, the counterparty signs and transmits the new balance states of both the user and itself. Finally, the user cosigns both balance states and propagates the complete versions back to the counterparty.
If a dishonest or latent participant does not sign balance states during the handshake, then the opposing user may execute their balance state onchain. For convenience, users can trade against a common counterparty which is always assumed to be live.
The process of signing is nearly instant, resulting in sub-millisecond finality in co-geographically located clients. Because users self-validate, VDEXCore execution is trustless and atomic. The peer-to-peer nature of trading creates a darkpool from which external market participants are unable to view transactions.
VDEXCore is presently in beta. This comes with additional limitations and protections for users. All withdrawals undergo a 24 hour dispute period even if they contain an FBS. The protocol team retains the ability to upgrade settlement contracts in case of a discovered exploit. These two beta features enable the protocol team to monitor and prevent exploits before they occur.
VDEX transactions execute directly between market participants, not via a central hub. The elimination of middlemen accelerates trading speeds to the theoretical limit. The removal of wallet pop ups and VPN requirements further hasten settlement time.
The finality benchmark assumes that participants are engaging in co-geographically located clients. Distance to counterparty will proportionally increase settlement latency. As network participation increases, VDEX's intelligent routing will match participants to minimize individual and overall execution time.
Compared against this benchmark, VDEX transactions settle 200x faster than Hyperliquid, 400x faster than Solana, and 12,000 faster than Ethereum. As compared to peer-to-peer direct settlement, excessive blockchain latencies persist in spite of efforts to centralize validator sets.
Trading credits are non-withdrawable margin that allows traders to experience the platform before commiting personal capital.
User accounts with trading credits cannot withdraw balance below the total value of credits received, even if recovered after a drawdown. Realized profits generated from trading credits may be withdrawn like regular funds.
Trading credits on VDEX differ from centralized exchanges. In the event of losses, user equity is deducted before credits. Because VDEX operates without KYC or identity-level controls, this protection is needed to prevent an attacker from creating multiple accounts and extracting risk-free profit.
Because trading credits are primarily issued to onboard new users, they expire after 30 days of inactivity.
Slippage, gas, and MEV derive from blockchain latency, congestion, and surveillance. VDEX participants execute transactions with sub-millisecond finality, unbounded throughput, and private settlement.
Zero Slippage: The interface's expected price will match the executed price due to instant execution
ZeroGas: Transactions settle on the user's device without third-party validation, relinquishing the need for gas payments
MEVZero: Private settlement prevents frontrunning, sandwich attacks, and other exploitations of user trades
The VSHARK Program is a series of initiatives we designed to reward VSHARKs and rising contributors - self-driven, impact-oriented individuals who hunt first, move fast, act without hesitation, and grow the tribe with relentless momentum. They are builders and believers in the long-term vision of VDEX.
VDEX enables the collateralization of Bitcoin and Ethereum at face value. is not converted at deposit, allowing margin and yield accounts to reflect real time changes to underlying asset value.
For example, a user deposits 1 Bitcoin when $BTC = $100,000, so they have $100,000 margin. If $BTC increases to $110,000, then margin updates proportionally to $110,000. Within margin accounts, this enables capital efficient funding arbitrage and delta-neutral hedging.
This applies to equity within the Virtual Market Maker as well. Liquidity providers may deposit Bitcoin and Ethereum and receive yield proportional to the real-time value of their assets. They also enjoy the appreciation or depreciation of the underlying asset.
Margin is the collateral required to open perp contracts.
By default, positions are cross margined and access account equity. In cross margin mode, unrealized PnL is available as initial margin for new positions.
Users can select isolated margin for precise control. Unrealized PnL in isolated positions is used as additional margin for the open contract. At any time, margin can be added or removed from isolated positions within the bounds of the initial margin and account equity. Isolated margin liquidations do not affect other positions.
VRC-3
Vaults of Isolated Participant Escrow (VIPEs) safeguard funds from malicious actors and enable users to audit proof of reserves. Escrow is not stored within a shared pool but within individual vaults tied to the depositor's address. Funds can be moved immediately with universal agreement of the user and counterparty or after the dispute period according to the most recent state.
If the user or counterparty receives a malicious payload, latent response, or for any reason at all, they may submit their latest balance state to their original blockchain. This will trigger a 24 hour dispute period that will release funds in accordance with the balance state that:
Matches the ChainID of the blockchain
Includes signatures from both user and counterparty
Exceeds the nonces of all other submitted balance states
Settlement occurs on a blockchain. The user's will determine if a vault has sufficient liquidity and then request the Final Balance State, FBS, from the counterparty. The FBS executes immediately onchain, bypassing the typical fraud proof delay.
FBS are intended for immediate withdrawal as they lock balance states and expire within five minutes. This prevents double spend as outdated FBS could otherwise immediately withdraw funds without the possibility of dispute. The user can create unlimited FBS after expiration of the last.
If the counterparty refuses to create the FBS, then the user may submit their latest nonfinal balance state as a fraud proof.
VDEX smart contracts were audited by Halborn, a leading blockchain security firm.
Audit Type: Smart Contract Audit
Auditor: Halborn
Date of Engagement: December 5–6, 2024
VRC-7
The Virtual Wallet displays user balances according to the Virtual Node. The Virtual Wallet does not have a unique private key and is entirely governed by the user's connect blockchain address. If a user holds multiple collaterals, the Virtual Wallet aggregates value into one USD-denominated balance. This unified balance is referenced for margin and yield accounts.
Leverage can be set by a user between 1 and the max leverage. Max leverage depends on the asset. The leverage of an existing position can be increased without closing the position, decreasing the initial margin requirement (IMR).
The margin required to open a position or create an order is the dollarized position size divided by the leverage. Margin supporting open orders cannot be withdrawn.
Positions will be liquidated when isolated margin or account equity is less than the maintenance margin requirement (MMR).
Account equity is the sum of collateral value, PnL, and net funding. Users can add margin by depositing supported collateral, including USDC, USDT, WETH, and WBTC. All collateral adds margin at face value. Volatile Asset Collateral, such as WETH and WBTC, is dynamic according to the mark price.
For example, a user deposits 1 Bitcoin when $BTC = $100,000, so they have $100,000 margin. If $BTC increases to $110,000, then margin updates proportionally to $110,000. Within margin accounts, this enables capital efficient funding arbitrage and delta-neutral hedging.
In cases of profit and positive yield, USD-denominated state is added. In cases of loss, USD-denominated state is subtracted, but the underlying VAC is not converted until withdrawal or liquidation. This means that if losses are reversed, the principle VAC is untouched.
Proof of Reserve
MEVZero
ZeroGas Fees
Private Execution
Borderless Settlement
Sub-Millisecond Finality
Trustless State Transitions
Status: 100% of all reported findings have been addressed.
Click here to view the full audit report
Unified margin balance
Omnichain deposits
Chain abstraction



What is Virtual Labs?
Virtual Labs is a cryptography company with the firm belief that user experience is the single largest issue holding back web3 adoption. The Virtual team identifies these problems to specifically include latency, gas, and wallet frictions. Virtual's solution is Virtual Rollups, the first deployable omnichain rollups with sub-millisecond finality. DApps built on Virtual Rollups accomplish web2-style UX through:
Zero latency
ZeroGas
Zero wallet clicks
Full chain abstraction
This feature set is not entirely new as other blockchains have approximated seamless user experiences before. The innovation of Virtual Rollup is specifically what all other previously solutions have lacked: trustlessness.
Virtual Rollup achieves N of N Byzantine Fault-Tolerance through zero knowledge state channels. ZK state channels are similar to the Lightning Network's state channel. With both, they key advantage is self-verification.
With Virtual Rollups, the user is the node, sequencer, and validator of their own transactions. If a user sends a token, makes a bet, or trades an asset, all parties within the ZK state channel sign every message, ensuring full self-custody and the verification of their capital themselves.
Virtual Rollup's premier DApp is VDEX. VDEX is the first omnichain perpDEX with no slippage and sustainable Bitcoin yield. Virtual Rollup DApps inherits all of the features of the underlying tech, meaning VDEX is the first truly self-custodial and self-verified perpetual exchange.
VRC-6
The Virtual Market Maker (VMM) has a triple mandate as the common ZKSC counterparty, default LP vault, and exchange market maker. Due to liveness constraints mandated by ZKSCs, participants self-validate states with the VMM. Furthermore, the VMM intakes escrow from liquidity providers which it utilizes to ensure liquid markets and stable liquidations. It distributes all excess state proportionally to liquidity providers.
Solvency
Sustainable Yield
Continuous network uptime
The Virtual Vision is to live in a truly decentralized world. A world of self-custody, self-verification, and self-control. A vision of ZeroGas, zero latency, and zero friction. An onchain internet where users never need to worry about buying a new gas token, tracking bridged funds, or knowing which chain they are on. They are simply onchain, seamlessly connected, as if they were online.
The decision to move onchain will not be driven by fanaticism or loyalty to a particular ecosystem based on community, culture, or cult-like mentality. Companies and users will choose onchain solutions because of the superior security and protection they offer.
The future is onchain, but blockchain will win when people do not even realize they are interacting with it. This is the very reason why Virtual Labs carries its name: blockchain infrastructure should feel seamless and simple, creating a virtual experience where the underlying complexity is invisible to the end user. When the user experience is truly frictionless, adoption will naturally follow.
True adoption will be measured by real users engaging with decentralized applications, not by speculative tokens or airdrop hunters. Mass adoption will be achieved when people of all generations, across all regions, use decentralized applications as part of their everyday lives.
VRC-8
Volatile Asset Collateral (VAC) is a VDEX asset standard that supports the collateralization of crypto majors at face value. Bitcoin and Ethereum deposits receive margin or yield equity equal to the present value of those assets. As the values of collateralized assets change, margin is added or subtracted proportionally. In cases of profit and positive yield, USD-denominated state is added. In cases of loss, USD-denominated state is subtracted, but the underlying VAC is not converted until withdrawal or liquidation. This means that if losses are reversed, the principle VAC is untouched.
Funding arbitrage
Delta-neutral hedging
Sustainable Bitcoin Yield
VRC-4
The Virtual Insurance Pool (VIP) enables participants to instantly unlock and transfer escrowed value in excess of their initial VIPE contribution. The VIP represents unclaimed escrow that, unlike VIPE funds, are not subject to a dispute period. Participants can thus immediately settle states reflecting realized profits with the VIP instead of against their counterparty's VIPE.
Permissionless Capital Flows
Fees are based on your rolling 14 day volume. Referral and membership discounts apply after tier is determined. Maker rebates are directly credited to accounts after each trade. There are no additional gas or liquidation fees.
Crypto Tiers
1
Less than $1M
0.025%
0.015%
2
Traditional Market Tiers
The VDEX liquidation engine will close positions once account equity falls below the maintenance margin. The maintenance margin is half of the initial margin at maximum leverage. A detailed list can be found in contract specifications.
If account equity or isolated margin falls below the maintenance margin, the liquidation engine executes a market order to close the full position. During liquidations, any remaining collateral remains with the trader. VDEX does not charge clearance fees.
Backstop liquidations occur if equity falls below two-thirds of the maintenance margin before successful liquidation. During backstop liquidations, the Virtual Market Maker acquires unliquidated positions and remaining margin. This ensures that VDEX remains solvent when volatility and clustered liquidation prices cause liquidation cascades.
Within the margin mode that is backstop liquidated, the user ends up with zero account equity. Backstop liquidations in isolated margined positions do not affect other positions.
Liquidations are based on the mark price, which combines the VDEX order book with external exchanges for maximum stability. During times of high volatility, the mark price may diverge significantly from the VDEX order book. Users may observe the trading chart, reflecting the mid price, exceed liquidation prices without liquidation and vice versa.
To avoid liquidations and backstop liquidations, traders are encouraged to set stop loss orders and actively monitor open positions. Higher leverage factors increase the risk of liquidation.
For positions larger than $10,000, only 20% of the position will be liquidated at a time. If a position is partially liquidated twice within 30 seconds, the entire position will be closed and equity is retained by the user.
VDEX uniquely supports at face value for account margining. VAC is denominated in their original form without swapping.
For example, a user deposits 1 Bitcoin when $BTC = $100,000, so they have $100,000 margin. If $BTC increases to $110,000, then margin updates proportionally to $110,000.
To support maximum flexibility—including delta-neutral hedging and funding arbitrage—PnL is denominated in USDT and losses are not immediately deducted from VAC.
Consider that the user accumulates losses of $11,000. Collateral is stored as (1 BTC, -11,000 USDT). If the user withdraws immediately, 0.1 BTC is swapped for 11,000 USDT, releasing 0.9 BTC. However, if $11,000 was regained through trading or USDT deposits, collateral becomes (1 BTC) not (0.9 BTC, 11,000 USDT).
This introduces the possibility that VAC value may fall below USDT-denominated losses. Account liquidations trigger automatic swapping from VAC to USDT once account equity falls below this threshold.
VDEX executes an account liquidation if 1.1*losses > VAC or when BTC declines from $110,000 to $12,100.
Pricing an asset is subtly complex. VDEX measures the price of perpetuals through robust price indices and displays cosmetic values for client-side monitoring.
VDEX utilizes various price types to minimize the risk of market manipulation.
pOracle: the oracle price is an external data feed used in calculating the funding rate and in pMark. The data source depends on the asset class.
Crypto - Binance, updates every second
Stocks, Commodities, and Foreign Exchange - TwelveData, updates every 5 seconds
Prediction Markets - Seda, updates every 200ms
pMark: the mark price is designed to be a fair approximation of the perp price. It is used in calculating unrealized PnL and margin requirements, as well as for TP/SL and liquidation triggers. pMark updates every 5 seconds and is the median value of:
pOracle plus a 150 second exponential moving average (EMA) of the difference between pMid and pOracle
The median of the best bid, best ask, and pLast on VDEX
pOracle
pImpact: the impact price measures market depth at pMid. Bid and ask orders of size $1,000 are simulated against the order book. The median of the average execution prices is pImpact. pImpact is used exclusively in calculating the funding rate.
pMid: the mid price is the average price between the best bid price and best ask price. pMid is used in calculating pMark and is displayed on trading charts.
pLast: the last price is the most recent price at which an order was executed. pLast is used in calculating pMark and appears in the token dashboard.
The protocol's fundamental state is based solely on margin. The following prices are inferred from margin and displayed for convenient monitoring:
Entry price is updated to the average of the former entry price and successive trade prices, weighted by size
Exit price is the executed price of an order.
Expected price is the simulated execution price based on position size and the current state of the order book
Unrealized PnL is the difference between entry price and pMark, scaled by position size
Crypto Liquidity Without the Hassle
Bitcoin and Ethereum hold the largest liquidity pools in crypto, yet their potential as trading collateral is often untapped. Traders must traditionally go through lending markets to convert their holdings into stable coins before accessing perpetual trading. VDEX changes this by allowing Bitcoin, Ethereum, and other major volatile assets to be used directly as collateral eliminating unnecessary steps, reducing trust assumptions, and improving security.
Learn to trade on VDEX in four easy steps
An EVM wallet
If you do not have a supported wallet (e.g., Rabby, MetaMask, WalletConnect, Ledger), you can easily create one at .
After downloading the extension and creating a wallet, you must store your seed phrase in a private and secure location. If anyone else knows your seed phrase, they will be able to steal your funds.
Unlike other derivatives, perpetual futures never expire. To tether the price of the perp to the spot asset, traders pay hourly funding based on the deviation.
The payment amount is determined by the funding rate. If the perp price is higher than the spot price, then the funding rate is positive and longs pay shorts; if the perp price is lower than the spot price, then the funding rate is negative and shorts pay longs. Significant deviations in either direction cause proportionally higher funding rates.
Funding is entirely peer-to-peer, VDEX does not charge a funding fee.
For assistance or to engage with the community, reach out via:
Telegram
VRC-11
0DTE Perpetual Futures accommodates trading for pairs that lack a continuous spot market. VRC-10 cannot support markets with evening or weekend closes. VRC-11 handles asset downtime by halting trading activity and rolling over positions until the next open time. Users perceive contracts as continuing perpetually, however VRC-11 closes and reopens positions each day to ensure stable funding rates and liquidations. There are no additional fees for this service.
VRC-10
Perpetual futures markets are officially supported on VDEX with the introduction of VRC-10. Perpetual contracts trade independently from spot markets and are tethered to the oracle price via an hourly funding rate. The margin required to open a position is discounted on a pair's maximum leverage factor. VDEX will close a position on behalf of the user should their equity decrease below the requirement.
Detailed Overview of Platform Design
The whitepaper is a comprehensive document outlining the foundation and architecture of VDEX . It covers the Virtual Rollup technology, the separation of state and escrow, gasless trading, and how VDEX achieves sub-millisecond finality while ensuring full self-custody. This document is essential for anyone looking to understand the deeper workings of the platform. View VDEX Whitepaper :
Realized PnL measures the absolute change in margin from a position. It excludes funding payments and fees.
Liquidation price reflects the point at which account equity falls below the maintenance margin requirement
This formulation applies a decay factor over a 2.5-minute window, giving more weight to recent values while smoothing out short-term noise.
Broad accessibility: Use different assets for collateral without impacting your final profit payouts.
With Volatile Asset Collateral on VDEX, traders gain flexibility, efficiency, and security, all while keeping their profits stable in USDT.
Processes state transitions
VRC-2: Virtual Node
Handles communication between settlement layer and ZKSC
Ensures self-verification
Stores states
VRC-3: VIPE
Guarantees state is backed 1:1 against escrow
VRC-4: VIP
Supports permissionless capital flows
Together, Virtual Rollups solve double-spend and counterparty risk. Double-spend is resolved through a common counterparty that interfaces with user. Full Self-Custody is guaranteed in spite of a malicious counterparty because users store state locally which can be redeemed for escrow on the immutable settlement layer. Consider the following attack scenario:
The common counterparty cannot profitably collude with a fictitious user to withdraw escrow because VIPE funds require either:
universal consent of all relevant participants for immediate withdrawals
an onchain dispute process
To attack the onchain dispute process, states must be
Valid: signed by both the participant and counterparty in the ZKSC
Exploitable: the Escrow-State difference reflected in a stale state exceeds the Escrow-State difference of the live state
This scenario can occur when a participant’s balance genuinely decreased from its initial level before later recovering back to that same amount.
Once the onchain dispute process is triggered, the participant's Virtual Node will automatically override with the valid, live state. If the participant is offline, another Virtual Node may execute the state proof on their behalf, earning the slashing reward.
Therefore, VIPE funds are inaccessible to malicious counterparties. The VIP is not protected by an onchain dispute process and therefore could be drained by a malicious actor. But because the VIP definitionally represents unclaimed funds, it is already considered profit of the counterparty.
Trustless
Permissionless
Full Self-Custody
Stocks
Commodities
Foreign exchange
Crypto derivatives without expiration
Isolated and cross margin
Maker and taker orders
Funding rate
Liquidation
Leverage
p = entry price
MMF = maintenance margin fraction
MMR_o = MMR for other positions
p' = liquidation price
Formulas
Isolated Liquidation Price p' = (e - s * p) / (|s| * MMF - s)
Cross Liquiation Price p' = (e - s * p - MMR_o) / (|s| * MMF - s)
XAU MMF = 0.01
SOL MMF = 0.025
MMR_o = 10 * 175 * 0.025 = 43.75
p' = (1000 - (-1.5 * 3000) - 43.75) / (1.5 * 0.01 + 1.5) = 3601.49
The liquidation price of the XAU position is $3,601.49
Virtual Labs was founded by José Betancourt in his dorm at Yale University. The original idea was a protocol for self-verified data called Ontropy. Ontropy was a self-verified oracle that would enable users themselves to verify price data for trading and randomness for gaming. Ontropy was accepted into Binance Labs' Season 5 Incubator in October of 2022.
On April 20th, 2023 Virtual Labs closed its pre-seed round and pivoted to the idea of self-verified transactions, utilizing the existing architecture of the self-verified data protocol. Nine months later, Virtual Rollup V1 (henceforth VR1.0) was created and brought into the world with an initial cohort of a dozen gaming projects.
VR1.0 worked perfectly in theory, eliminating latency, gas fees, and wallet frictions and allowing the user to forget the game was decentralized. Demand for seamless UX was also proven, with over 25 orders for VR1.0. However, the vast majority of these orders could not be completed because integrating DApps to work with VR1.0 essentially required recoding the applications from the ground up.
Armed with this feedback, the Virtual team created VR1.1 which can support orderbook transactions as opposed to game moves, and VR1.2, which offers full chain abstraction. These updates did not make Virtual Rollup universally scalable for all blockchain transactions, but enabled support for all perpetual exchanges due to the lack of technical variety between orderbook designs.
To demonstrate VR1.2, Virtual Labs built VDEX. VDEX will be the first perpDEX with no slippage, full-self-custody, and will even be able to accept volatile assets as collateral, such as Bitcoin and Ethereum.
Virtual Labs now employs 17 engineers and business developers across 6 countries.
4
$25M or more
0.03%
0.01%
5
$100M or more
0.015%
0.005%
$1M or more
0.02%
0.01%
3
$5M or more
0.015%
0.005%
4
$25M or more
0.01%
0.000%
5
$100M or more
0.005%
-0.002%
1
Less than $1M
0.05%
0.03%
2
$1M or more
0.045%
0.025%
3
$5M or more
0.04%
0.02%
Collateral
Supported assets such as USDT, USDC, WETH or WBTC
Gas tokens on a supported chain (ETH on Ethereum or Arbitrum, BNB on BSC, or AVAX on Avalanche)
Open VDEX
Click “Connect Wallet” in the top-right corner
Select a supported wallet
Sign the connection request
Variables
pOracle = spot price
pImpact = order book impact price
s = position size
d = premium deviation
Formulas
d = (max(pImpactBid - pOracle, 0) - max(pOracle - pImpactAsk, 0))/pOracle
8-Hour Funding Rate (F) = dAverage + clamp (0.0001 - dAverage, -0.0005, 0.0005)
Funding Payment = s * pOracle * F
Methodology
The deviation between the perp price and spot price is measured through d. This is done through the impact and oracle prices respectively. The impact price is like the mid price, but incorporates order book depth.
d is sampled every 5 seconds and averaged over the hour, creating dAverage. This value represents the relative difference between the perp price and spot price, so a dAverage of -0.01 means the perp trades 1% below spot.
The funding rate tracks dAverage while filtering out small deviations. The clamp applies an interest rate of 0.0001 and bounds of ±0.0005, producing a baseline funding rate of 0.01% when dAverage remains within ±0.05%. The interest rate represents the difference in cost to borrow USD versus spot crypto, defaulting to longs paying shorts. The clamp ensures that the funding rate is predictable and stable under normal market conditions.
Due to precedent, the 8-hour funding rate is calculated. However, funding is paid and displayed hourly. The results in a baseline rate of 0.00125%.
Optimizing Liquidity Through Smart Capital Deployment
The VDEX Fund Strategy is designed to ensure deep liquidity, efficient capital utilization, and sustainable trading conditions for all market participants. Unlike traditional perpetual exchanges that rely on fragmented liquidity pools or external market makers, VDEX integrates an advanced Virtual Market Maker (VMM) system to dynamically adjust capital flows and maintain a robust trading environment.
The Virtual Market Maker (VMM) is a decentralized liquidity vault designed to facilitate trading while giving liquidity providers (LPs) the opportunity to share in the trading profits. Instead of relying on external market makers, VMM allows the community to supply liquidity and collectively benefit from market-making activities.
Unlike traditional market makers who profit from spreads and fees in exclusive systems, VMM operates transparently and does not extract additional fees. Profits and losses are distributed proportionally among depositors based on their share of the vault, creating an open and fair trading environment.
Answers to Frequently Asked Questions
VDEX perpetual contracts can be opened with fractional margin, supporting leveraged trading. Perps mirror spot asset prices and denomination—the perp contract and the spot asset have similar values. Convergence is tethered through peer-to-peer hourly funding.
Perps are quoted against USDT. The margin required to open a contract is determined by the leverage factor. The collateral required to maintain the position is half of the initial margin fraction at maximum leverage.
Clear and detailed bug reports are essential for maintaining a fast, secure, and reliable trading platform. Feedback from the community helps identify and resolve issues efficiently, ensuring smooth trading for all participants.
When encountering a bug or unexpected platform behavior, reports should include:
A concise description of the issue observed.
Steps taken before the issue occurred.
Any relevant screenshots or error messages.
VRC-2
Virtual Nodes validate and store balance states within the ZKSC. First, a participant’s Virtual Node produces an unsigned balance state reflecting user actions. Then, the counterparty’s Virtual Node signs valid updates and returns them to the participant. The participant’s Virtual Node then issues the final signature, completing the state and disseminating it back to the counterparty.
Participant Virtual Nodes are programmed to assume counterparty liveness. If the participant's balance state is not immediately returned, the Virtual Node will execute its state on the settlement layer, ensuring network service in all scenarios. If the counterparty does not receive the finalized state from the participant, it will execute the partially signed state on the settlement layer.
If a Virtual Node observes that a stale state has been submitted to the settlement layer, it will automatically override the ledger with its most recent finalized state.
Capital Optimization: This structure allows traders to use their existing holdings efficiently without additional conversion costs.
No Bad Debt Exposure: The system ensures that all trades are backed by sufficient collateral, preventing bad debt accumulation.
By combining Virtual Market Making, Volatile Asset Collateral, and Automated Risk Management, the VDEX Fund Strategy ensures a balanced ecosystem where liquidity remains accessible, risks are managed, and capital efficiency is maximized.
The VMM operates as an automated liquidity provider on the decentralized limit order book (DLOB). It continuously posts both bid and ask orders across supported markets to facilitate trading. Its strategy focuses on:
Maintaining competitive spreads to attract takers.
Adjusting order sizes and prices dynamically based on market conditions.
Managing inventory risk to ensure sustainable operations over time.
The VMM earns returns by capturing the bid-ask spread and earning rebates or fees from trades executed against its orders. Profitability depends on order flow, market volatility, and competition from other market makers.
Users providing capital to the VMM can contribute using supported assets such as WETH, WBTC, USDC, and USDT. Contributions are pooled and managed by the VMM strategy.
Participating in the VMM strategy involves several risks:
Market Risk: Adverse price movements can cause losses to the pooled capital.
Competition Risk: Increased competition from external market makers can reduce VMM's trade volume and profitability.
Liquidity Risk: In periods of low activity, the VMM may struggle to capture spreads effectively.
Interested participants can allocate funds to the VMM pool via the VDEX interface. Allocated funds are used to support the VMM's liquidity provisioning strategy. Contributions and withdrawals are subject to the platform's standard rules and conditions.
The device, browser, or wallet used at the time of the issue.
Thorough reporting allows the development team to diagnose problems faster, implement fixes, and continuously improve the trading experience on VDEX.
Security Disclosure.
Security-related findings should be reported privately through the designated secure channels and must not be shared publicly to prevent potential exploitation.
Contributions that significantly enhance platform security may receive acknowledgment or a reward under the VDEX community incentive program.
Every report plays an important role in strengthening the platform’s safety and reliability.
Self-Verification
clamped difference = min(max(0.01% - dAverage, -0.05%), 0.05%)clamped difference = min(max(0.01% - (-0.5%), -0.05%), 0.05%)
clamped difference = min(max(0.51%, -0.05%), 0.05%)
clamped difference = min(0.51%, 0.05%) = 0.05%
Calculate the Funding Rate, f
8-Hour Funding Rate (F) = dAverage + clamp (0.01% - dAverage, -0.05%, 0.05%)
8-Hour Funding Rate (F) = -0.5% + 0.05%
8-Hour Funding Rate (F) = -0.45%
1-Hour Funding Rate = -0.05625%









1%
XAU
0.1
50x
2%
1%
ETH
0.1
40x
2.5%
1.25%
SOL
0.01
40x
2.5%
1.25%
XRP
0.0001
40x
2.5%
1.25%
MSTR
0.1
40x
2.5%
1.25%
AVAX
0.001
20x
5%
2.5%
TRY
0.00001
20x
5%
2.5%
LINK
0.01
20x
5%
2.5%
BNB
0.1
20x
5%
2.5%
HYPE
0.001
20x
5%
2.5%
SUI
0.0001
10x
10%
5%
CRO
0.00001
10x
10%
5%
PENGU
0.000001
10x
10%
5%
DOGE
0.00001
10x
10%
5%
1000PEPE
0.000001
10x
10%
5%
ZEC
0.01
10x
10%
5%
BTC
0.1
50x
2%
A state channel involves locking funds into a smart contract then trading the rights to this escrow over a P2P (peer-to-peer) gossip network. Because the funds are already locked and the signature exchanges occur directly between users, it’s trustless while being gas and latency-free.
The catch is that the costs associated with locking and unlocking funds (i.e., opening and closing the state channel) means users must perform at least three zero-gas P2P transactions to receive a cost-benefit. The addresses of the transacting users must also be predefined in the smart contract.
Necessitating a predefined relationship limits utility. After all, most DeFi transactions are between two strangers who transact once.
The advent and incorporation of zero knowledge into state channels (ZKSC) by Virtual Labs brings three innovations that exponentially increase their use cases: unlimited participants with a fixed cost; dynamic channels overcoming rigid and predefined user flows; and self-validated, easy-to-verify proofs for trustless cross-chain access. Most importantly, ZK state channels are Turing-complete whereas state channels are not. So, any DApp, not just payment channels, can be supported with ZeroGas and sub-millisecond finality.
To understand the difference and power of a ZK State Channel, first consider poker powered by a traditional state channel:
Alice and Bob can deposit 100 USDC into a smart contract, and play an unlimited amount of hands. Here, the state channel is beneficial because every previous fold, check, and raise would have needed to be an onchain transaction to maintain trustlessness. Alice and Bob benefit from saving 3 wallet interactions, 20 seconds, and a dollar in gas fees per game action.
However, if their friend Carol wants to play as well, Alice and Bob need to close the state channel with an expensive onchain transaction, and immediately reopen one including Carol. The closing fees scale linearly with the amount of participants which is why traditional state channels are best suited for only two users at a time.
If Carol, now part of the state channel, wants to leave the game before Alice and Bob, all three must close the channel and Alice and Bob must reopen a new one. Finally, if Carol or any other user wanted to join from a different chain, they would need to wait to bridge funds first.
Now consider poker powered by a ZKSC, like the Virtual Rollup:
Alice and Bob deposit 100 USDC into a smart contract, and can play an unbounded amount of hands. Now if Carol wants to join, she must deposit 100 USDC into the same smart contract. Crucially, Alice and Bob do not need to close the channel nor perform an onchain transaction for Caroland to join. Underlying complexity is abstracted away from them.
If Dylan, Evelyn, and Frank also want to join, they all must perform their opening transaction onchain, but they join the existing ZKSC so the current users are not affected. This is why ZKSCs are dynamic. The Virtual Rollup uses the deposit timestamp as immutable proof that all previous transactions do not include the new user's signature, but all subsequent interactions must. With 5, 50, or 500 users, the signature size has a constant amount of data, resulting in decreasing marginal cost.
Finally, if Grace has funds locked in the Virtual Rollup contract on a different chain, she will be able to use these funds to immediately begin playing the poker game on the original chain. No bridging necessary! We’ll dive into more detail later, but in short, this is possible because her already locked funds are resistant to reorgs, so she can send a publicly-verifiable proof to the poker dApp (and other users), and trade against her escrow the same way Alice, Bob, and others are. Because users communicate P2P, the location of escrow is not important, so long as you trust the underlying chains themselves. To close the channel when funds are on different chains, users will balance what they owe to each other by performing an atomic swap.
To clarify one point, the Virtual Rollup does not overcome reorg attacks on cross-chain transactions. But because the behavior of ZKSCs involves depositing funds up front and leaving it there, these same reorg-resistant funds can be utilized to overcome the traditional chain 1+chain 2 finality bridging wait period.
ZK State Channels are dynamic and can support N users, as compared to 2 users. But perhaps the biggest innovation is that their versatility allows them to power Turing-complete computers, so that DApps can be run on top of them. This computation network is called the Virtual Rollup. Here is our full paper that detail how this computation network can support orderbook applications.
ZK State Channel (Virtual Rollup)
Traditional State Channel
Unlimited users
Two users
Dynamic entering and exiting
Predefined addresses (new users force channels to close down and re-open)
Chain Abstraction
Single chain
Seamless ephemeral creation
Difficult to set up
ZeroGas
ZeroGas
Sub-Millisecond Finality
Sub-Millisecond Finality
ZK State Channel (Virtual Rollup)
Traditional State Channel
• Batch transactions, like the Lightning Network
• Batch transactions, like the Lightning Network
• Establish recurring transactions, like those between merchants and vendors
• Establish recurring transactions, like those between merchants and vendors
Turing-complete computation network (Virtual Rollup) can support any DApp: - Sub-millisecond finality perpDEXes - Fully onchain gaming - Censorship-resistant SocialFi
Turing-Complete computation network support (Virtual Rollup)
State channels, such as the Lightning Network, have long been considered an alternative scaling solution to layer 2 networks but have not achieved large-scale adoption due to high costs, rigid predefined user flows, and limited utility. Powered by ZK Accumulators, Virtual Rollups represent a next-generation ZK state channel architecture, enabling unlimited participants to process unlimited transactions on any chain. This innovation unlocks new state channel applications, including capital-efficient ZeroGas decentralized exchange (DEX) day trading, federated social networks, and fully onchain gaming.
Zero-Knowledge State Channels (ZKSCs) deliver a trading experience with ZeroGas, zero latency, and zero friction.
A key use case is perpetual exchanges. With Virtual Rollups, traders can open sessions to exchange assets such as ETH for BTC, BTC for USDC, or USDC for SOL without paying fees or facing execution delay while maintaining full self-custody. This technology allows traders to capture opportunities faster and more efficiently.
The experience rivals centralized exchanges, offering sub-millisecond finality, orderbook-based capital efficiency, and seamless deposits and withdrawals across multiple chains.
Another significant use case is fully onchain gaming enabled by Autonomous Worlds. Some argue that only in-game assets need to be recorded onchain, while the gameplay itself can remain external. However, if assets, tournament prize pools, and wagers are tied to determining a winner, that outcome must be verified in a trustless manner; otherwise, maintaining assets onchain loses its purpose.
Traditionally, winner determination and prize distribution have relied on centralized systems, as executing real-time gameplay directly on blockchain networks has been prohibitively expensive and slow.
Virtual Rollups solve this challenge by allowing players themselves to validate and finalize game outcomes through self-verified state updates. This approach ensures results are fast, cost-efficient, and fully decentralized, creating a truly trustless onchain gaming experience.
Another use case is decentralizing federated social platforms like Mastodon, Bluesky, and FriendTech. Currently, frames incur gas costs, and posts, likes, and comments are processed centrally. ZK state channels enable censorship resistance without compromising a seamless user experience.
It is important to note that ZK state channels are not designed to replace Layer 2 solutions. Instead, they complement them. ZK state channels require a P2P network and an onchain escrow agent. Virtual Rollups is built on top of blockchains, allowing them to focus on what they do best: global settlement. State transitions for trades, game moves, and social interactions are handled through P2P local consensus rather than relying on the blockchain for every update.
Users complete an action, which reaches finality when every user completes a handshake, exchanging their proofs of agreement
Users maintain their own updated state through the public deposit history as the first state, followed by updates they approve
Instead of storing N (users) *S (states) proofs, users instead continuously reaggregate proofs using a ZK Accumulator
So, a user can prove the final state and cash out with a lightweight proof that agrees with their final balance
State Updates:
If the user wishes to purchase an asset, the user, they will sign the state update, which includes the position, balance data, and time stamp, and send it it to VDEX. VDEX will check the available balance and the market maker's orders, and sign the trade, sending it back. VDEX will store the user's signature. The user will store VDEX's signature.
Finality is achieved at the moment both parties complete the handshake. This is not dissimilar to a multisig. As further trades are made, both parties store complete ledgers of their counterparty's acknowledgement. If a dispute were to arise, the user can prove that VDEX signed off on the trade, and vice-versa.
When the user wishes to withdraw, they will request to flip the Boolean "isSessionFinished" with a final state update.
Distribute Withdrawal:
If the user's state update contains "isSessionFinished==true" then the contract will read the balance within and distribute it to the depositor's original address, as defined in the contract and state update, immediately.
Process Dispute:
If both parties cannot agree on a final state update, perhaps because one has gone offline or is acting maliciously, then "isSessionFinished" will not be true and they have entered into a dispute. Note that this cannot happen is both parties are acting honestly and properly. Because both parties record all transactions, it is not possible for this to occur during normal circumstances. Perhaps the user has gone offline when VDEX is attempting to liquidate or a user is attempting to submit an old state update when their balance was higher.
If this situation does occur, the previously recorded state updates are used. One of the parties will submit a state update onto the contract. Of course, the contract has no way of knowing the private date of the peer-to-peer channel, so this could be an old state update. So, in cases of dispute, the contract will function optimistically within a 24-hour window. If the user submits an old state update, VDEX will have the opportunity to submit a more recent one. The contract will evaluate that the second state update is indeed signed by the user and has a more recent UTC timestamp. The balance in this state update will thus be observed.
2. ZK State Channel state root updates:
Action: In-game click, akin to Web2 UX
Cost: $0.00
Time: 1ms proof generation + 2*K (user with highest ping), ~110ms for an average American mobile user
3. Closing:
Action: Aggregate proofs submitted via traditional wallet, or for a sequencer to process
Cost: 1.30 times EOA or SC transaction cost ($1.64 EOA, $7.8 AA) but can be bundled with other exits for decreasing marginal cost
Time: 20 seconds
The lightweight MuSig2/Blind Schnorr signatures only represent a portion of total gas. Because the majority of an EVM transaction data load is made up of boilerplate metadata, a sequencer can combine multiple exit proofs from a closing channel to exponentially lower user costs. Just three proofs would result in a total transaction cost of 39,000, split across three users is 13,000, or $0.78 EOA and $3.72 AA.
Whereas traditional state channels allow users to break even above three transactions, this theoretic ZKSC model achieves it at less than two!
Next up on the latter is BLS, that’s Boneh, Lynn, and Shacham, not Barreto, Lynn, and Scott, although we’ll be discussing the BLS12-381 curve as well. BLS is well known for its pairing capabilities and is the signature scheme for Ethereum PoS. BLS signatures do allow the verifier to discern the individual agreements and disagreements from the aggregate key pairs, which is useful in several scenarios (ETH Research).
According to 0xParc, “Verifying a BLS signature involves a pairing check that two elliptic curve pairings are equal and is thus directly enabled by zkPairing. This unlocks potential scaling applications like signature aggregation for light clients and bridges.” This means that BLS can be recursively verified and compiled inside SNARKs. This is useful for both of BLS’ two main drawbacks: limited blockchain support and quantum attacks.
Despite numerous proposals, pushes, and promises by the core devs, BLS verification is expensive on mainnet and simply cannot be done on other chains, like Polygon. Bundling BLS inside Plonky2 (or Halo2), SNARKS would decrease marginal costs without a substantial increase in latency. The other main disadvantage of BLS is that they are not quantum secure, which zero knowledge proofs also solve.
Finally, Plonky2 is the last scheme Virtual is employing for ZK Accumulators. There are three ways Plonky2 powers ZKSCs. First, these SNARKs can bundle existing BLS signatures. Because BLS aggregation is instant and SNARK bundling is cheap at scale, this combination works well. Second, Plonky2 can form a light client to prove that a user is running the correct version of a game or trading application, providing anti-cheat measures. If users are able to attain these proofs up-front, it could rule out future disputes. Finally, this SNARK can directly form the ZK Accumulator itself. An advantage here is that a Plonky2-powered Accumulator could allow efficient state updates for multiple Virtual Rollups and for all users within them. This means that users would not need to cash out, as one user signing out and proving their own state would necessitate proving onchain the balances of all other users.
Virtual Labs is employing all three options across this spectrum of ZK Accumulators. Native MuSig2s validation is common across most chains, and is therefore the version running in the current Virtual Rollup by our partner protocols. The BLS version has been up and running for some time, but verification remains prohibitively expensive or impossible across Polygon, BNB, Ethereum, and Arbitrum, which represent 90% of our users. The team has achieved working Plonky2 Accumulators internally and is excited for them to pass security checks before wider deployment.
The deployed smart contracts are identical except for one variable: chainID—the blockchain knows which chain they are in relation to other chains. Say Ethereum is chainID:0 and Bitlayer is chainID:1. When the withdrawal signature is generated, its chainID is set to a specific value: 0,1,2... If this signature is submitted onto a chain that does not match the chain ID, it will reject the signature.
So, ZK state channels enable chain abstraction. This, of course be used to bridge funds into and out of different blockchains as well. It also has the side effect of bypassing reorg latency if the user trades for some time. For example, if a user deposits on Ethereum, trades for 10 minutes, and withdraws to Bitlayer, the funds will reach the user's EOA within one block time. This is because the reorg attack window on Ethereum has already passed when the user traded, so withdrawals are now instant.




The VSHARK Referral Program is a program designed to reward members for introducing new traders to VDEX. By sharing your referral codes, you can earn direct and indirect referral points, gain a share of a reward pool starting at $1,000, and contribute to the growth of the VDEX ecosystem. Your share of points and cash (USDT) are distributed EVERY Friday.
The more referral points you accumulate, the bigger reward share you earn during each distribution period.
We are giving back ~100% of revenue share through the referral points mechanism:
For every $10,000 in trading volume, VDEX adds $1 and 1 point to the reward pool.
The pool has a minimum of $1,000 per period.
Your points = your points (from your trading activities) + 50% of your referees’ direct points + 25% of your referees’ indirect points.
The more referral points you earn, the greater your share of the pool.
To join the Referral Program, you must have a minimum of $100 in trading volume on VDEX.
Log in to your VDEX and go to the Refer section
Claim up to 3 referral codes per week.
Admins may increase the code limit for KOLs and Trading Community Builders.
To request more codes, email:
10% trading fee discount on their first $100M in trading volume
A free $500 trading credits bonus (see details at VSHARK Deposit Matching Program)
Reward Currency
Based on your point, your reward share will be issued in the USDT currency and credited to the relevant accounts.
Distribution Timeline
Points are counted weekly from 00:00 UTC every Thursday to 23:59 UTC the following Wednesday.
Reward shares are issued automatically every Friday on VDEX.
Fair Play and Cheating Prevention
Accounts involved in any form of abuse or cheating behavior (including but not limited to fraudulent registrations, self-referrals using secondary accounts, or forged identity documents) will be disqualified from the VSHARK Referral Program.
Any gains obtained through such activities will be revoked.
Right to Adjust
Due to market conditions and fraud risk management, VDEX reserves the right to adjust the rules of the VSHARK Referral Program at any time.
Updated rules and terms will prevail upon publication.