Mercantile Perpetuals

Introduction

Mercantile is a perpetual futures trading protocol. It lets you take leveraged long or short positions on any ERC20 token, from 2x all the way up to 50x, without borrowing, without margin calls, and without individual liquidations. There are no debt relationships and no dependency on market makers. You deposit tokens, receive shares representing your position, and withdraw tokens when you close. On top of the trading pools, the protocol issues USDMX, a stablecoin backed by the protocol's own counterparty positions, enabling zero-slippage swaps at oracle spot price and generating protocol revenue through funding yield.

Traditional leverage protocols create amplified exposure through borrowing or margin systems. Mercantile takes a fundamentally different approach: it trades volatility for synthetic leverage. The protocol takes the natural price volatility of the underlying asset and restructures how it is distributed across participants. Counterparties surrender their exposure to that volatility by accepting a fixed notional claim, and in exchange they earn funding. That volatility doesn't disappear. It gets redirected into the leveraged tiers, where a weighted distribution system concentrates it. The total volatility in the system is unchanged, but the protocol strips it from one side and amplifies it on the other. The result is leveraged exposure created not through debt, but through a structured reallocation of shared collateral.

Each market on Mercantile consists of two paired pools: a Long pool and a Short pool. Both pools use the same internal mechanics: discrete leverage tiers, a shared reserve of tokens, and a continuous funding rate that keeps supply and demand balanced. The only difference is the direction. Both pools share a Pyth Network oracle and stay synchronized. Every time someone interacts with either pool, both pools update their state to reflect the latest price and funding accrual. This ensures that the entire market is always consistent.

Design Philosophy

Perpetual futures come in two dominant flavors today, and both create leverage through some form of lending, either directly or just in principle.

Centralized exchanges like Binance, Bybit, and OKX use margin-based order books. You post collateral and the exchange extends you a notional position many times larger than your deposit. Leverage is direct: the exchange is effectively lending you the difference. If your margin falls below the maintenance requirement, your individual position is liquidated. This model is fast and liquid, but it concentrates risk in the exchange itself, relies on centralized custody, and subjects traders to cascading liquidations during volatile markets. Liquidation engines, auto-deleveraging systems, and insurance funds exist because the margin model requires constant enforcement to stay solvent.

Decentralized perpetuals like GMX, GNS, and Kwenta take a different approach to matching, but the leverage mechanic is similar in principle. Instead of an order book, traders open positions against a shared liquidity pool. Liquidity providers deposit assets into the pool and passively take the other side of every trade, exposing themselves to informed flow. The pool is effectively lending its liquidity to create leveraged exposure, and individual positions are still liquidated when margin runs out. The liquidation engine's ability to properly handle volatility is susceptible to accrue bad debt. During trending markets they often suffer losses because they are the counterparty to every winning trade. Keeper bots race to liquidate underwater positions, extracting MEV and liquidation penalties from traders at their worst moments.

Mercantile works differently. There is no margin, no individual liquidation, and no passive LP pool. Leverage is not created by letting you control more than you deposited. Instead, the protocol takes the natural price volatility of the underlying asset and redistributes it. Counterparties explicitly opt in as the other side of the trade, receiving a 1x synthetic position in the opposite direction with a stable notional value. The volatility they give up is concentrated into 49 discrete leverage tiers, where it is amplified in proportion to each tier's weight. The result is leveraged exposure built from volatility redistribution rather than debt or margin.

Because there are no margin accounts, there are no individual liquidations. If a tier's total value falls to zero, the entire tier is wiped and resets, but that is a collective event, not a targeted one. There are no keeper bots racing to liquidate you, no liquidation penalties, and no MEV extraction from forced closures. Counterparties are not passive LPs absorbing whatever flow comes in. They choose to enter, they know their exposure is a 1x synthetic position, and their notional value remains constant regardless of price, adjusted only by funding over time.

Permissionless Markets

There is another consequence of this design that goes beyond the trading experience. Because Mercantile does not rely on a liquidation engine, there is no infrastructure that needs to be calibrated per asset. CeFi exchanges choose which markets to list based on whether their liquidation systems, insurance funds, and market makers can handle the asset's volatility. In additiona to these constraints, DeFi perps are also gated by governance and LP pool depth. Both models are inherently permissioned: someone decides which assets get a perpetual market and which do not.

Mercantile removes that constraint entirely. At the pool level, a new perpetual market can be created for any ERC20 token that has a Pyth price feed. No governance vote, no risk committee, no liquidity bootstrapping. The protocol handles volatility naturally through tier wipeouts rather than requiring bespoke liquidation tuning. This makes Mercantile the first fully permissionless perpetual futures protocol, in the same way that Uniswap allowed anyone to create a spot trading pair for any token.

The implications extend beyond crypto native assets. As tokenized real world securities continue to grow, with on-chain representations of stocks like NVIDIA, Tesla, and Apple, or commodities like Gold already trading on multiple networks, Mercantile is positioned to provide decentralized leveraged derivatives on these assets from day one. Any tokenized asset with a price feed can have a perpetual market without waiting for an exchange to list it. The same applies to commodities, forex pairs, and any other asset class that makes its way on-chain.

While the underlying pool contracts are permissionless, the protocol's decision to actively support a market through the USDMX Comptroller is not. For the Comptroller to take a counterparty position on a market, the protocol evaluates the asset's suitability: the depth of secondary market liquidity available for the Comptroller to unload reserves, the funding yield the market generates relative to the exposure the Comptroller assumes, and the conditions under which the Comptroller should exit and convert to stables. These parameters ensure the protocol only commits capital where it can manage risk responsibly. Anyone can deploy pools for any asset, but the protocol's backing through USDMX and Comptroller revenue is reserved for markets that meet its quality standards.

How It Works

Paired Pools

A Mercantile market is made up of two contracts that mirror each other. The Long pool holds the volatile asset as its reserve, for example WETH or stETH in an ETH market. The Short pool holds a stable asset as its reserve, in this case USDMX. Each pool is a self-contained system with its own leverage tiers, its own counterparty side, and its own funding rate. They are linked together as siblings so that a price update in one automatically propagates to the other.

Inside each pool, there are two roles. The leveraged side deposits tokens into one of 49 tiers and receives amplified exposure to price movements. The counterparty side provides the other side of the trade as a 1x synthetic position in the opposite direction. In the Long pool, the counterparty holds a 1x synthetic short: they deposit volatile tokens, receive a stable-denominated notional claim, and withdraw the equivalent stable value in reserve tokens regardless of how the price moves. In the Short pool, the counterparty holds a 1x synthetic long: they deposit stable tokens, receive a volatile-denominated notional claim, and withdraw the equivalent volatile value in USDMX reserve tokens.

The Reserve and the Residual

Every deposit goes into the pool's shared reserve. The total reserve is then split between two claims. The counterparty side holds a notional claim denominated in a different unit: stable value in the Long pool, volatile asset value in the Short pool. Whatever remains in the reserve after satisfying that counterparty claim is the residual, and it belongs to the leveraged side.

When the price moves favorably for the leveraged side, the counterparty's claim in reserve token terms shrinks relative to the total reserve, and the residual grows. When the price moves against the leveraged side, the counterparty's claim in reserve token terms grows and the residual shrinks. This is how profit and loss flow to the leveraged side without any borrowing or debt. The counterparty's notional value stays constant in its own denomination, adjusted only by funding.

Weighted Gain Distribution

The residual is not split equally among all leveraged positions. Each of the 49 tiers has a weight that determines its share. Tier 0 (the 2x tier) has weight 1. Tier 1 (the 3x tier) has weight 2. This continues linearly up to Tier 48 (the 50x tier) with weight 49. When the residual changes, the protocol distributes that change to each tier in proportion to its deposit base multiplied by its weight.

A position in the 10x tier receives five times the gain or loss per deposited token compared to a position in the 2x tier. That proportional amplification is what creates leverage. It is not borrowing and it is not margin. It is a structured allocation of shared collateral where higher tiers claim a larger slice of every move.

New deposits only participate in gains and losses that occur after they enter. The protocol snapshots the global state at the moment of your deposit, so you cannot inherit gains or losses from before your entry. Your position starts at face value and moves from there.

Effective Leverage

The leverage you actually experience depends on two things: the tier's weight and how much of the pool is being utilized by the counterparty. The protocol defines coverage as the ratio of the counterparty's token claim to the total weighted value of all leveraged tiers. When coverage is 100%, effective leverage matches the tier name. A position in the 10x tier delivers 10x exposure to price movement.

The protocol targets 80% utilization and enforces a maximum average weight of 4 across all leveraged deposits. These two constraints work together so that at the target state, effective leverage matches what you see in the tier name. If utilization drops below 80% or the weight composition shifts, leverage compresses toward 1x. This system design decision is a safety property that reduces risk during low-demand periods.

Leveraged Positions

Leveraged positions are the core of the protocol. Whether you are trading in the Long pool or the Short pool, the experience is the same: choose a tier, deposit your tokens, and receive shares.

To open a position, you pick a tier corresponding to 2x through 50x nominal leverage, and deposit the pool's reserve token. In the Long pool, you deposit the volatile asset and profit when its price rises. In the Short pool, you deposit the stable asset and profit when the tracked asset's price falls. The protocol converts your deposit into shares for that tier based on the current NAV per share. If the tier is empty, you receive one share per token deposited. If other positions already exist in that tier, your shares are calculated proportionally so that your entry does not dilute anyone.

You can close your position at any time, partially or in full, by burning shares. The protocol calculates your share of the tier's current value and transfers that amount of reserve tokens back to you. Both opening and closing support slippage protection: you specify a minimum acceptable output, and the transaction reverts if the price moves against you before execution.

The protocol tracks your weighted average entry price and cost basis on-chain, so you can always see your unrealized PnL, your current position value, and your entry price. These values reflect the live Pyth price and accrued funding without requiring a transaction.

Weight Cap

For a tier's effective leverage to match its name, the counterparty side needs to be large enough to fully back the weighted value of all leveraged deposits. At 80% utilization, the counterparty claim works out to roughly 4 times the total leveraged deposit base. This means the system can support an average tier weight of up to 4 before coverage starts to fall short and effective leverage begins to compress.

The protocol enforces this directly. If a deposit would push the average weight above 4, it is rejected. Lower-leverage tiers (2x through 5x) can always accept deposits because their weights are 4 or below. Higher-leverage tiers are limited based on how much room remains. If the pool is heavily concentrated in high tiers, new high-leverage deposits are blocked until enough lower-leverage positions enter to bring the average down. The UI shows the maximum deposit available for each tier at any given moment.

Counterparty Positions

Every pool has a counterparty side that provides the other side of the trade for the leveraged tiers. Counterparty depositors do not pick a tier and do not receive leverage. They deposit reserve tokens and receive shares in the counterparty pool.

The counterparty is a 1x synthetic position in the opposite direction from the leveraged side. In the Long pool, the counterparty is a 1x synthetic short. You deposit volatile tokens, and the protocol records a stable-denominated notional claim based on the current price. If the price doubles, your notional claim is still worth the same in stable terms, so you receive fewer reserve tokens when you withdraw. If the price halves, your notional value is unchanged, so you receive more reserve tokens. Your stable-denominated value stays constant, adjusted only by funding over time.

In the Short pool, the counterparty is a 1x synthetic long. You deposit stable tokens, and the protocol records a volatile-denominated notional claim. If the tracked asset's price rises, your volatile-denominated claim is worth more in stable terms, so you receive more reserve tokens when you withdraw. If the price falls, you receive less. Your volatile-denominated value stays constant, again adjusted only by funding.

Counterparty NAV per share starts at 1.0 in the pool's notional denomination and adjusts based on funding accrual. Opening a counterparty position is constrained by utilization. The protocol will not allow a deposit that would push utilization above 80%. The UI shows the maximum available deposit. Closing burns your shares and returns reserve tokens at the current NAV.

The USDMX Comptroller is itself a counterparty in the Long pool. When users mint USDMX, the Comptroller opens a counterparty position on their behalf. This means the protocol's own reserves sit alongside regular counterparty depositors, earning the same funding yield and subject to the same mechanics. The Comptroller has no privileged access to the pool. It interacts as any external caller would.

USDMX

USDMX is a stablecoin issued by the Mercantile Comptroller. It is backed by the Comptroller's counterparty position in Long pools, which holds a stable-denominated notional claim on the pool's volatile reserves. The Comptroller contract is the USDMX token itself.

Zero-Slippage Swaps

When you mint USDMX, you deposit volatile tokens at the current Pyth oracle spot price and receive USDMX equal to the stable value of your deposit. The Comptroller takes your tokens and opens a counterparty position in the Long pool. This is effectively a zero-slippage sell of the volatile asset. There is no price impact, no AMM curve, and no order book spread. You receive exactly the oracle price regardless of trade size, limited only by the pool's available capacity.

When you sell USDMX back to the Comptroller for a portion of its reserves, the Comptroller closes part of its counterparty position and returns volatile tokens to you at oracle spot. This is a zero-slippage buy. You burn USDMX and receive the exact oracle value in volatile tokens. If the Comptroller's position cannot cover the full redemption, a partial fill is executed and the remaining USDMX stays in your wallet.

Backing and Collateralization

USDMX is backed by two sources. The primary backing is the Comptroller's active counterparty position in the Long pool, which holds a stable-denominated notional claim. The secondary backing is any reserves the Comptroller has withdrawn from the pool during rebalancing events and sold for USDC or frxUSD. The collateralization ratio is the total backing divided by the USDMX supply, and it is visible on-chain at all times.

Rebalancing

When the Long pool's counterparty yield falls below a designated minimum threshold, anyone can trigger a rebalance, which withdraws the minimum amount of the Comptroller's position needed to bring utilization back to the given target. The withdrawn volatile tokens are then sold for dollar backed stablecoins. This is permissionless: no admin action is required, and the protocol incentivizes it by design since high utilization lowers the counterparty yield, thus removing Comptroller positions lowers utilization which in turn increases counterparty yield again.

Protocol Revenue

The protocol generates revenue through the Comptroller's counterparty position. When the Long pool's utilization is below 80%, leveraged traders pay funding to the counterparty side. The Comptroller's position is part of that counterparty pool, so it earns a proportional share of all funding payments. This funding yield accrues continuously and compounds into the Comptroller's notional claim.

The funding yield the Comptroller earns is highest when utilization is low, since the rate scales from 100% APY at 0% utilization down to 0% at the 80% target. This creates a natural incentive for the protocol to provide counterparty liquidity to markets that need it most. As more counterparty capital enters and utilization rises toward 80%, the yield compresses toward zero, self-regulating the Comptroller's appetite. If utilization exceeds 80%, funding flips negative and the Comptroller begins paying the leveraged side, at which point the rebalancing mechanism kicks in and the Comptroller reduces its exposure.

The protocol evaluates each market it supports through the Comptroller based on the funding yield the market generates, the depth of secondary market liquidity available to convert withdrawn reserves to stables, and the risk profile of the volatile asset. Markets where the expected funding yield does not justify the exposure, or where secondary liquidity is too thin for the Comptroller to safely exit, are not actively supported. This curation ensures the protocol's capital is deployed where it can generate sustainable revenue while managing downside risk.

The Funding Rate

The funding rate is the mechanism that keeps the leveraged side and the counterparty side in balance. It is a continuous rate that transfers value between the two sides based on current utilization. When utilization is below 80%, the funding rate is positive, meaning the leveraged side pays the counterparty. This incentivizes more counterparty deposits to bring utilization up toward the target. The rate scales linearly from 100% APY at 0% utilization down to 0% at exactly 80%.

When utilization exceeds 80%, the funding rate flips negative, meaning the counterparty pays the leveraged side. This incentivizes counterparty withdrawals or new leveraged deposits, pushing utilization back down. The rate scales from 0% at 80% to -100% APY at 100% utilization. At exactly 80% utilization, the funding rate is zero and neither side pays the other. The system is in equilibrium.

Funding accrues continuously. Every time someone interacts with a pool, the protocol calculates the elapsed time since the last update, applies the current rate to the residual, and adjusts the counterparty's notional claim. When the leveraged side pays the counterparty, the counterparty claim grows and the residual shrinks. When the counterparty pays the leveraged side, the opposite happens.

Each pool has its own independent funding rate. The Long pool's rate depends on its own utilization, and the Short pool's rate depends on its own. They are not linked. A market can have high utilization on the long side and low utilization on the short side, or vice versa. This allows the funding rates to independently incentivize balance within each direction.

Tier Liquidation

Mercantile does not liquidate individual positions. Instead, liquidation happens at the tier level. When a tier's net asset value falls to zero, the entire tier is wiped out. Every position in that tier is lost, and the tier resets with a new epoch.

The protocol processes wipeouts from the highest leverage tier downward, since those are the most exposed. If a large adverse price move wipes the 50x tier, the excess loss beyond that tier's value cascades and is absorbed proportionally by the remaining tiers. This can trigger sequential wipeouts: a severe enough move might wipe the 50x tier, then the 49x, and so on down the line.

After a wipeout, the tier starts fresh. New deposits enter at a new epoch, completely isolated from the previous epoch's losses. Old positions from the wiped epoch are permanently zeroed out. Anyone depositing into a previously-wiped tier gets a clean start with no inherited baggage. Liquidation prices are available for each active tier in the UI. In the Long pool, the liquidation price is a floor: the price the asset must not fall below. In the Short pool, it is a ceiling: the price the asset must not rise above.

Sibling Pools

The Long pool and Short pool in a market are connected as siblings. After both are deployed, they are linked together permanently. Once linked, every user action on either pool triggers a sync on both. If you open a leveraged long, the Short pool also updates its state to reflect the latest price and funding. If someone closes a counterparty position on the Short pool, the Long pool syncs too. This ensures that both sides of the market always operate on the same price and the same timestamp. Without sibling syncing, one pool could drift ahead of the other during periods where only one side sees activity. The linked sync eliminates that risk.

Oracle and Price Feeds

Mercantile uses Pyth Network for pricing. Each market's price feed is specified at deployment and cannot be changed. Pyth price updates are passed with every transaction, allowing the protocol to incorporate the freshest available price on each operation. When you check position values, NAVs, funding rates, or liquidation prices, the data you see reflects the latest oracle price and all accrued funding, even if no transaction has been sent recently. There is no need to wait for an on-chain update to get accurate numbers.

Protocol Parameters

Each pool is deployed with four immutable parameters: the reserve token, the Pyth oracle address, the price feed ID, and the pool direction (Long or Short). Beyond that, the protocol's behavior is governed by constants hardcoded in the contract. There are 49 leverage tiers. The target utilization is 80%. The maximum annualized funding rate is 100% in either direction. The minimum deposit is 0.001 tokens. The maximum average weight across all leveraged deposits is 4. These parameters are currently not configurable after deployment.

Risk Considerations

Leverage amplifies losses as much as it amplifies gains. A position in the 50x tier can be completely wiped out by a small adverse price movement. Even lower-leverage tiers carry meaningful risk of total loss during severe market conditions. The higher the tier, the faster it moves toward zero when the market goes against you. Tier liquidation is permanent. When a tier is wiped, all positions in it are gone. There is no partial liquidation, no grace period, and no recovery mechanism for positions in the wiped epoch.

The funding rate can erode your position over time. If utilization stays persistently below 80%, the leveraged side continuously pays the counterparty. Over weeks or months, this drain can meaningfully reduce the value of leveraged positions even if the underlying price hasn't moved.

Counterparty positions carry funding risk. While their notional value is stable in its own denomination, persistent funding transfers can erode that value over time. A counterparty in a pool where utilization remains above 80% will see their notional claim decrease as they pay the leveraged side. Additionally, in extreme scenarios where the leveraged side has consumed most of the reserve, counterparty withdrawals are capped at the pro-rata share of remaining tokens, which may be less than the notional value of the claim.

The protocol depends on Pyth Network for pricing. If the oracle provides stale, incorrect, or manipulated prices, positions may be opened, closed, or liquidated at incorrect valuations.