Mercantile Perpetuals

Introduction

Mercantile is a perpetual futures trading protocol; derivatives that track an asset's price without an expiration date, allowing positions to be held indefinitely. 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 (trades from participants with superior price information). 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 addition 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, a fixed face value denominated in a different unit from the reserve token: stable value (USD) in the Long pool, volatile asset value (ETH) 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.

For example, consider an ETH Long pool with 200 ETH in total reserve and a counterparty notional of $200,000:

The counterparty's dollar claim is always $200,000. But when ETH rises, that claim costs fewer tokens to satisfy, so the residual grows by 20 ETH, a gain for the leveraged side. When ETH falls, the claim costs more tokens, and the residual shrinks by 25 ETH, a loss for the leveraged side. The total reserve never changed. Only the split between the two claims shifted.

In the Short pool the mechanics are identical but the directions are mirrored. The reserve is a stable asset (USDMX), and the counterparty's notional is denominated in the volatile asset. Consider a Short pool with $400,000 USDMX in total reserve and a counterparty notional of 100 ETH:

The counterparty's claim is always 100 ETH, but satisfying that claim in USDMX costs more when ETH rises and less when ETH falls. The leveraged side profits when the price falls (they are short) and loses when the price rises. Same zero-sum structure, opposite direction.

This reserve/residual structure is the concrete mechanism behind what Mercantile calls volatility redistribution. Every asset has natural price volatility. In a traditional market, everyone holding the asset is exposed to it equally. Mercantile restructures that exposure: the counterparty's fixed notional claim absorbs none of the asset's price movement , their volatility exposure has been entirely stripped away. That volatility does not vanish. It concentrates in the residual, which belongs to the leveraged side. The weighted tier system then takes that concentrated volatility and amplifies it further, delivering leveraged exposure without any borrowing. No new volatility is created and none is destroyed, it is stripped from one side and redirected to the other.

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.

Continuing the example above, suppose the residual grows by 10 ETH and the pool has three active tiers:

Per deposited token, the 10x tier receives 9 times the gain of the 2x tier and about 2.25 times the gain of the 5x tier, matching the weight ratios exactly. The 10x tier captures a smaller absolute share than the 5x tier (because fewer tokens are deposited), but each individual token in the 10x tier benefits far more.

At full coverage, the effective leverage of each tier matches its name: a position in the 2x tier experiences twice the gain or loss of the underlying asset per deposited token, the 10x tier ten times, and the 50x tier fifty times. The tier name directly tells you the amplification factor relative to the raw asset at the protocol's target state. This amplification 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 well the counterparty side backs the leveraged deposits. Two related but distinct metrics govern this.

Utilization is the ratio of the counterparty's total notional claim to the total collateral value of the pool, both measured in the counterparty's denomination (USD for Long pools, volatile asset units for Short pools). Utilization determines the funding rate direction and magnitude: below 80% the leveraged side pays the counterparty, above 80% the counterparty pays the leveraged side.

Coverage is the ratio of the counterparty's token claim (the notional converted to reserve tokens at the current price) to the total weighted value of all leveraged tiers. Coverage determines how much leverage each tier actually delivers. 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, coverage reaches 100% and effective leverage matches the tier name. If utilization drops below 80% or the weight composition shifts, coverage falls and leverage compresses toward 1x. This is a safety property that reduces risk during low-demand periods.

For example, consider a position in the 10x tier (weight 9). At full coverage, effective leverage = 1 + (9 × 1.0) = 10x, so the tier delivers what its name promises. If counterparty capital exits and coverage drops to 50%, effective leverage falls to 1 + (9 × 0.5) = 5.5x. At 25% coverage, it compresses further to 1 + (9 × 0.25) = 3.25x. The same compression applies to all tiers: a 2x position (weight 1) at 50% coverage delivers only 1 + (1 × 0.5) = 1.5x. The protocol never delivers more leverage than the counterparty side can support.

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. Shares represent proportional ownership of a tier's total value. If you hold 10% of a tier's shares, you are entitled to 10% of that tier's value when you withdraw.

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 (net asset value) per share, the tier's total value divided by its total shares outstanding. 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, a safeguard against the price moving between when you submit a transaction and when it executes. You specify a minimum acceptable output, and the transaction reverts if the result falls below it.

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.

For example, in an ETH Long pool you deposit 10 ETH as counterparty when ETH is $2,000. The protocol records your notional claim as $20,000.

When ETH rises, you withdraw fewer tokens, but those tokens are worth more, so your dollar value is unchanged. When ETH falls, you withdraw more tokens, but they are worth less, again preserving your dollar value. You gave up exposure to ETH's price movement in exchange for a stable-denominated claim. That is the synthetic short: you are dollar-neutral regardless of where ETH goes, adjusted only by funding over time.

In the Short pool, the counterparty is the mirror image: a synthetic long. You deposit $20,000 USDMX as counterparty when ETH is $2,000. The protocol records your notional claim as 10 ETH.

Your ETH-denominated exposure stays constant at 10 ETH. When ETH rises, that claim is worth more in USDMX terms, so you withdraw more. When ETH falls, it is worth less, and you withdraw less. You are ETH-neutral regardless of dollar price, the opposite of the Long pool counterparty. That is the synthetic long.

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.

For example, you want to sell 100 ETH when ETH is at $2,000. On an AMM, price impact pushes your average execution price to around $1,950, netting roughly $195,000 on what should have been a $200,000 trade. On Mercantile, you deposit 100 ETH and receive exactly 200,000 USDMX, the full oracle spot value with zero slippage. The maximum mintable amount is bounded by the pool's remaining counterparty capacity before utilization reaches 80%, so large mints may be constrained by how much room the pool has available. The same applies in reverse: burning 200,000 USDMX returns exactly 100 ETH at oracle spot, limited only by the Comptroller's counterparty position size.

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 (the reserve tokens remaining after the counterparty's claim, as described in The Reserve and 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.

For example, suppose a pool sits at 40% utilization for 3 months with no price movement. The funding rate at 40% utilization is 50% APY (linearly interpolated: (80 - 40) / 80 × 100% = 50%). If the residual is 100 ETH, the leveraged side transfers approximately 12.5 ETH to the counterparty over that quarter (50% × 0.25 years × 100 ETH). The residual shrinks from 100 to 87.5 ETH, a 12.5% decline, even though ETH's price did not move. Every leveraged position in the pool sees its value reduced proportionally to its tier weight, with higher tiers absorbing more of the funding cost per deposited token.

The counterparty yield (also referred to as funding rate) is the annualized rate at which funding payments grow the counterparty's notional claim. It is a function of the current funding rate and the size of the residual relative to the counterparty's position. When utilization is low, the funding rate is high and the residual is large, so the counterparty yield is at its highest. As utilization approaches 80%, the rate drops to zero and the yield disappears. Above 80%, the yield turns negative and the counterparty's notional claim shrinks.

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, a generation counter that isolates each lifetime of a tier, so that positions from before the wipeout are permanently separated from any new deposits after it.

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.

For example, consider an ETH Long pool where ETH drops sharply and the leveraged side has positions across multiple tiers:

1. The 50x tier has 5 ETH of total value. The drop drives its value below zero. The tier is wiped and all its positions are permanently lost. The 2 ETH of excess loss beyond the tier's value is redistributed across the remaining tiers proportionally by weighted value.
2. The 49x tier had 3 ETH of value. After absorbing its weighted share of the redistributed loss, its value is pushed below zero. It is wiped as well, and its excess loss cascades further.
3. The 48x tier had 15 ETH of value. It absorbs the remaining cascade, losing roughly 1 ETH, and survives at approximately 14 ETH.

Every position in the 50x and 49x tiers is permanently zeroed out. The 48x tier and all tiers below it continue operating at reduced values. The cascade always starts at the highest leverage tier and works downward, so lower tiers are the last to be affected.

In the Short pool, the same cascade mechanics apply but in the opposite direction. A sharp price rise hurts the leveraged shorts, so a sudden ETH spike would trigger wipeouts starting from the 50x short tier downward. The mechanics (processing order, excess loss redistribution, epoch reset) are identical.

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.