Mars Attack(ed)! - A deep dive into the latest exploit in cosmos

On December 14th, 2025, Mars Protocol’s deployment on Neutron suffered a critical exploit on its Perpetuals (perp) Markets. Mars is one of the most used and robust DeFi applications in the cosmos ecosystem with its primary use-case being lending markets with its innovative credit account system enabling more capital efficiency. In February 2025, they added perp markets to their platform, functionality that was exploited just 10 months after launch.

In part 1 of our investigation , we traced how the attacker behind the $973K Mars Protocol exploit funded their contracts, executed the attack, and bridged the stolen USDC off Neutron - all without using mixers, privacy tools, or DEX swaps. But while the exit path was clean and fast, the real story lies in how the attacker was able to extract that value in the first place.

This post unpacks the exploit from a technical perspective. Unlike previous oracle-based perp attacks, such as the GMX AVAX/USD incident, the Mars attacker didn’t manipulate price feeds. Instead, they leveraged the protocol's design, exploiting how skew-based pricing, intra-block funding rules, and lending pool mechanics interact under specific conditions.

What follows is a step-by-step breakdown of the attack loop, the smart contracts used, and the critical design assumptions that made this exploit both repeatable and highly profitable.

How do Mars Protocol’s perps work?

Perpetual contracts (or “perps”) are a type of derivative product in crypto that lets users trade assets with leverage - without owning the underlying token and without any expiry date. Unlike spot markets, perps use mechanisms like funding rates and price oracles to keep their price aligned with the real market. They’re widely used in DeFi to offer synthetic exposure to assets like BTC, ETH, or SOL, but their design complexity introduces unique risks around liquidation logic, oracle updates, and economic incentives.

Perpetual protocols are situated in two broad categories:

1. Orderbook based
2. Oracle based

Popular protocols such as Hyperliquid, Lighter and dYdX are all in the first category of orderbook based. Mars lives in the second category of oracle-based protocols, alongside GMX and Levana.

So what is the difference?

Well, in both cases, there are two types of price discovery. The first is where prices are determined directly in the market as buyers and sellers post bids and asks; the second is where an oracle provides a price based on one or more external price sources.

These second types of protocol have proven popular - as running an orderbook is both a computationally intensive and latency sensitive activity. Thus prior to the explosion of CLOB-chains (Central Limit Order Book) the most realistic way to have decentralised-perpetuals has been using the oracle-based method.

Note from the editor: some cynical people would say price-based perps are infact not perpetuals but something more closely representing a CFD (contract for difference) but let's not get bogged down.

The problem with the Oracle-based perps, unlike CLOB, is that there isn't a native matching of buyers and sellers. This means that, depending on market sentiment, the number of longs can far outstrip the shorts, and vice versa. This leads to a problem where the protocol can be insolvent if there are too many winners. Therefore in order to mitigate this Mars uses two mechanisms: price premium and funding rates.

Price premium

To calculate the price premium Mars uses the skew - simply the difference between long and short open interest. When you open or close a position, you don't trade at the oracle price - you trade at an execution price that is derived from a premium based on market skew.

If the market is heavily long (positive skew), longs get worse entry prices and shorts get better ones. The opposite applies when skew is negative. This naturally incentivises traders to take the other side of a crowded trade.

Funding rates

Funding rates work alongside pricing to keep the market balanced. The rate is proportional to skew and accrues continuously over time - the longer you hold a position on the crowded side, the more you pay to holders on the other side.

Worth noting: funding doesn't jump instantly. It has a velocity that accumulates, meaning short-duration trades experience minimal funding costs.

Fees

Opening and closing positions incur small fees (typically 0.1-0.5%). These act as a baseline cost for any trade regardless of direction.

The arbitrage loop

Together these mechanisms create a neat incentive structure: if the market becomes imbalanced, contrarian traders can enter at favorable prices and get paid via funding to hold their position. This should, in theory, attract arbitrageurs who restore balance.

Conclusion

Mars perps are designed around a simple principle: make it expensive to pile onto the popular side, and make it profitable to take the other side. Skew-based pricing provides immediate incentives, funding rates provide ongoing ones, and fees ensure some baseline cost to trading.

The combination should keep markets balanced and the protocol solvent - at least in theory.

The Dec 14 Exploit!

On December 14th utilization rates started skyrocketing on Mars's deployment on Neutron, reaching as high as 213% for the USDC pool - a sign that something was wrong!

What happened?

Unlike other attacks performed against oracle-based perp protocols this hack did not try to outsmart the price oracle as happened with GMX. The exploiter simply attacked the core mechanism design:

• Slippage calculation through the OI skew
• Funding not being applied on an intra-block basis
• Bad debt being funded by the lending markets

Let's break down each of these.

Exploiting skew-based pricing

Recall that execution price depends on market skew. The key insight is that this creates a profitable loop:

1. Open a position in the direction of existing skew (making it worse)
2. In the same transaction, push skew even further via additional positions
3. Close the original position at a now-favorable price

The attacker pockets the difference between entry and exit execution prices - profit extracted purely from the skew mechanism, independent of any oracle price movement.

Zero funding on intra-block trades

Funding accrues based on time elapsed between blocks. If you open and close within the same block, time_elapsed = 0, meaning funding paid = 0.

This is critical. Normally, holding a position on the wrong side of skew bleeds money via funding. But same-block trades sidestep this entirely. The attacker could take massively skewed positions without paying the ongoing cost designed to discourage exactly that behavior.

Bad debt spills into lending markets

Mars's architecture connects the perps system to its lending markets. When the perps vault becomes undercollateralized - because traders extracted more profit than the vault could cover - the bad debt doesn't stay contained. It propagates to the lending pools, which is why USDC utilization spiked to 213%.

The lending pool depositors effectively became the exit liquidity for the exploit.

The attack in summary

What made this exploit work wasn't any single flaw - it was how three design choices interacted:

Skew pricing created the profit opportunity. The mechanism that was supposed to discourage imbalanced positions actually created arbitrage-like profits for anyone who could manipulate skew and exit quickly enough.

Intra-block funding removed the cost. The funding rate - designed specifically to make holding skewed positions expensive - simply didn't apply when trades happened within the same block. This turned what should have been a losing trade into a risk-free extraction.

Shared liquidity with lending provided the exit. When the perps vault couldn't cover the attacker's profits, the debt didn't cause a localized failure - it flowed into the lending markets. USDC depositors who thought they were simply earning yield became the unwitting counterparty to a perps trade gone wrong.

Individually, each of these might have been manageable. Skew pricing without the funding loophole would have been unprofitable to exploit over time. The funding loophole without deep liquidity would have had limited impact. But together, they formed a perfect extraction mechanism: generate artificial profits via skew manipulation, pay nothing to hold the position, and pull the winnings from an entirely different pool of users who had no idea they were exposed.

The lesson here is subtle: mechanism design isn't just about getting individual incentives right - it's about how those incentives behave at the edges, especially when time assumptions break down.

Attack Infrastructure

The attacker deployed two identical smart contracts with purpose-built functions for the exploit:

Contract Functions

The looping Parameters

The attacker called looping with explicit configuration for the attack:

{
  "looping": {
    "params": {
      "main_amount_usdc": "40000000000",
      "main_amount_token": "6500000000000",
      "sub_amount_usdc": "8400000000",
      "sub_amount_token": "1900000000000",
      "partner": "neutron123pa8s...",
      "times": 15,
      "reset": true
    }
  }
}

Key insight: The attack was fully parameterized and automated. The attacker could tune position sizes and run multiple iterations in a single transaction. With times: 15, they extracted profits across 15 loops before the lending pool was drained.

How Primary and Partner Work Together

1. Primary opens and closes the profitable short positions
2. Primary creates throwaway accounts each loop that take the losing side
3. Partner liquidates the underwater throwaway accounts
4. Liquidation is necessary to "close out" the bad debt and allow the loop to continue
5. happy_ending is called at the end to withdraw all accumulated profits

The two-contract setup was necessary because an account cannot liquidate itself - the Partner exists solely to perform the liquidation step.

The Exploit Step-by-Step (Single Loop)

Phase 1: Setup

Phase 2: Push Skew Negative (Primary shorts)

Phase 3: Push Skew Even Worse (Throwaway piles on)

Phase 4: Extract Profit (Primary exits)

Phase 5: Throwaway Takes the Loss

Phase 6: Partner Cleans Up

Phase 7: Repeat or Exit

Why this is repeatable

Each iteration:

1. Primary profits ~15k from skew manipulation
2. Throwaway loses ~15k (but only had ~8k collateral)
3. Red Bank covers the ~7k shortfall
4. Partner liquidates the throwaway, clearing the bad debt
5. Fresh throwaway created
6. Repeat

With times: 15, the attacker ran this loop 15 times in succession, extracting profits while the lending pool absorbed the bad debt.

The Numbers (Single Loop)

The attacker profits. The throwaway is sacrificed. The lending pool bleeds. Repeat.

A mechanism design failure?

This exploit was fundamentally a mechanism design failure - but executing it required deep understanding of exactly how Mars's entry and exit pricing worked at the implementation level.

Individually, the three components made sense:

• Skew-based pricing discouraged imbalanced positions
• Funding rates charged ongoing costs to the crowded side
• Lending pool backstop provided a bad debt solution

But within a single block, they cancelled each other out. Funding didn't accrue. Skew manipulation became free. And the lending pool became an infinite well to draw from.

Mars clearly invested significant effort in designing a perps mechanism for a generalized appchain. The broader challenge they faced, how do you stay solvent when there are too many winners, is unsolved across the industry.

Hyperliquid's October 10th ADL event showed another answer: forcibly close winning positions, leaving traders unhedged. That socialized losses across many winners. The key difference here is what got socialized and to whom. ADL spreads pain across winning traders who understood they were in a perps market. This exploit drained funds from lending depositors who thought their exposure was isolated - socializing supposedly ring-fenced capital to the benefit of a single attacker.

That's not a funding rate problem or a pricing problem. It's an architecture problem.

For further reading, we recommend reading the post-mortem from the Mars team, the response plan from the Mars Foundation, as well as part 1 of our investigation tracing the money flow.

Range continues to support post-mortems like this by offering real-time observability, risk analytics, and forensics tooling across ecosystems:

• Range Trail lets teams trace funds, actors, and flows across hundreds of chains and bridges
• Risk API helps protocols assess wallet behavior before execution - not after
• Faraday powers all stablecoin payment operations - from swaps and cross-chain routing, to real-time risk analysis and multi-jurisdictional compliance - all in a single API

If you're building lending, perps, or stablecoin infrastructure, and want to avoid becoming the next case study - talk to us. We’re here to help secure what’s next.

Appendix

Below are the addresses pertinent to the attack on Mars Protocol on Neutron. See more related addresses in our investigation into the money flow.