Decentralized perpetuals exchanges operate in a difficult design space. Traders want the speed and convenience of centralized platforms, but without the custody risk that has caused some of the largest failures in crypto history. At the same time, many protocols described as decentralized still rely on trust-heavy components such as centralized price relayers, single-operator infrastructure, or privileged admin controls.
Exolane, a leveraged perpetuals exchange on Arbitrum One, makes several architectural choices intended to reduce those trust assumptions. This review looks at those design choices, what they appear to achieve, where the limitations remain, and how readers can independently verify the main claims.
It is important to state this upfront: Exolane is not risk-free. Exolane may be safer than many decentralized exchanges, but smart contract risk and liquidity risk still apply. The purpose of this article is not to imply that any DeFi protocol is without risk, but to document what is observable and verifiable.
Collateral Custody Model
When a user deposits USDC into Exolane, the funds are held in smart contracts on Arbitrum One rather than in a custodial wallet or team-controlled treasury wallet. The MarketFactory contract (0x02d46F54c986e298854cD0Ea110E9f0fA87a6702) manages market creation and configuration.
Based on a review of the contract’s public interface, there does not appear to be an admin function specifically designed to transfer user collateral to an arbitrary external address. In normal operation, funds leave a user’s collateral account through user-initiated withdrawal flows or through liquidation logic that returns remaining collateral after losses are accounted for.
This is a meaningful design property, but it comes with an important caveat. The contracts are upgradeable via proxy patterns, which means the implementation behind the proxy can change. Those upgrades are gated by a seven-day timelock, which gives users time to react, but the upgrade path itself remains a trust assumption that should not be ignored.
How to verify: review the MarketFactory contract on Arbiscan (https://arbiscan.io/address/0x02d46F54c986e298854cD0Ea110E9f0fA87a6702) and inspect the public and external functions. Then inspect the ProxyAdmin and timelock-related contracts to see whether upgrade actions are queued or executed.
Security Audit History
Exolane’s core smart contract stack is based on a codebase that has gone through seven security audit rounds conducted by Sherlock and Zellic between August 2023 and February 2025.
Round | Auditor | Date | Focus
Core Review | Sherlock | August 2023 | Full protocol
Core Review | Zellic | August 2023 | Deep manual review
Fix Review | Sherlock | September 2023 | Remediation verification
V2.1 Update | Sherlock | October 2023 | Protocol changes
V2.2 Update | Sherlock | March 2024 | Protocol changes
V2.3 Update | Sherlock | August 2024 | Protocol changes
V2.4 Update | Sherlock | February 2025 | Full protocol update
What this covers includes market contracts, oracle integration, collateral systems, liquidation logic, funding rate calculations, position management, access controls, and vault contracts.
Sherlock’s competitive audit model increases coverage by creating incentives for independent researchers to search for issues. Zellic’s methodology adds a different adversarial lens. That broader review history is useful, but no audit process guarantees the absence of undiscovered vulnerabilities.
Oracle System and Staleness Protection
Oracle architecture is one of the most important risk factors in any perpetuals protocol. Exolane uses Pyth Network for price data.
Pyth aggregates signed price submissions from a large number of data publishers, including exchanges, market makers, and trading firms. Those submissions are combined into an on-chain price feed intended to reduce dependence on any single source.
Exolane also enforces a forty-second staleness threshold on price feeds. If a feed is too old, trading and liquidation activity for that market pauses until fresh data becomes available. That is an important safety feature because it reduces the risk of liquidations or trade execution on stale data.
Still, staleness protection is not the same thing as eliminating oracle risk. If an oracle network were manipulated at the source or if enough publishers were compromised, staleness checks alone would not solve that problem. The design reduces one category of failure, but not all of them.
How to verify: inspect OracleFactory configuration and associated Pyth feed settings on Arbiscan (https://arbiscan.io/address/0x2Da923DD3c647d956B3e0D131E2350fF2495ecDD).
Settlement Model and MEV Resistance
Exolane uses an oracle-settled execution model. In simple terms, a user submits an order, the order enters a pending state, an oracle keeper commits a fresh price update, and pending orders in that batch settle at the same oracle price.
This reduces some common on-chain execution issues. Because all orders in the same settlement window receive the same price, traditional ordering advantages and certain sandwich-style attack vectors become less effective inside that settlement design.
There is, however, an obvious trade-off. Settlement is not instant. There is usually a delay of roughly one to five seconds between submission and execution. That makes the model more suitable for position trading and less ideal for very latency-sensitive strategies.
There is also residual risk at the chain level. This design reduces certain MEV vectors within settlement itself, but it does not fully remove sequencer-layer ordering risk on Arbitrum.
Liquidation Mechanics
Exolane currently sets liquidation penalty at zero percent. When a position falls below maintenance requirements, it closes at the oracle price, the keeper receives gas reimbursement, and remaining collateral is returned to the user after losses are accounted for.
Current parameters described in the system include eight percent maintenance margin for BTC and ETH, sixteen percent for many altcoin markets, ten times maximum leverage on BTC and ETH, and five times on altcoins.
The advantage of this model is that it avoids adding a punitive liquidation fee on top of an already losing position. The trade-off is that keeper incentives are lower. In periods of congestion or operational stress, reimbursement-only incentives may be weaker than penalty-based liquidation models.
That makes liquidation design one of the more interesting trade-offs in Exolane’s architecture: it appears more trader-friendly, but potentially less aggressive in incentivizing keepers under extreme conditions.
How to verify: inspect market-level maintenance margin and liquidation parameters directly on-chain.
Governance Structure
Governance remains one of the key trust vectors for any protocol.
Exolane uses a three-tier structure:
Timelock Controller — protocol-level changes require a seven-day delay between proposal and execution. That delay gives users time to review changes and exit if needed.
Multisig — the multisig is limited to emergency pause functions and is not supposed to be able to access user funds or arbitrarily rewrite the protocol without the timelock path.
Coordinator — the coordinator manages per-market risk parameters such as margin requirements, fee rates, and funding caps. These changes can happen faster than protocol-wide changes, which is worth paying attention to.
All of these governance actions are on-chain and reviewable. That is a positive trust signal. But governance is still team-operated rather than community-controlled, and that distinction matters. Exolane appears more constrained than a typical opaque admin-controlled platform, but it is not governance-minimized in the same way as a fully ossified system.
Funding Rate Design
One of Exolane’s clearest differentiators is its hard funding rate cap of plus or minus fifteen percent APR per market.
The system uses a skew-based controller for funding. In practical terms, when one side of the market becomes too crowded, funding adjusts, but it cannot exceed the predefined cap.
The main advantage is predictability. Traders can estimate a maximum carrying cost before opening a position. For longer-duration positions, that is a meaningful difference from uncapped systems where funding can spike much higher, sometimes up to 150% during imbalanced conditions.
The trade-off is that capped funding also weakens the market’s ability to rapidly self-correct through extreme incentives. If skew becomes severe, a hard cap can leave the market imbalanced for longer than an uncapped design might.
Another notable point is that funding payments flow between counterparties rather than being diverted to the protocol as direct revenue.
Fee Schedule
Exolane’s published fee structure includes:
Fee Type | Rate | Recipient
Taker fee | 0.02% | Protocol
Maker fee | 0.00% | —
Liquidation penalty | 0.00% | —
Withdrawal fee | 0.00% | —
Deposit fee | 0.00% | —
Funding rate | Variable, capped at ±15% APR | Counterparty traders
Keeper gas | Small per-action cost | Keeper operators
On a one hundred thousand dollar position, a 0.02 percent taker fee equals twenty dollars to open. That is competitive in the on-chain perpetuals segment, although any real fee comparison should include total carrying cost, gas, and execution model differences rather than headline fee alone.
All fee parameters are on-chain and subject to governance updates.
Fee parameters are documented in Exolane’s protocol fee documentation: https://docs.exolane.com/protocol/fees
Collateral Architecture
Exolane uses an internal accounting token called EXU, or ExoUnit, for position management. EXU is designed to maintain a one-to-one relationship with USDC through ExoReserve.
Deposits convert USDC into EXU internally, and withdrawals reverse the process. The point of this design is accounting precision rather than creating an additional economic token.
ExoReserve also includes rate limits on mint and redeem operations, which appear intended to reduce flash-loan-style manipulation risk.
Known Limitations and Open Risks
An honest review should not stop at strengths.
The main open risks include:
- smart contract risk despite audits
- dependence on Pyth oracle integrity
- conservative leverage that narrows the protocol’s addressable audience
- one to five second settlement latency
These are not small details. They are part of the actual trust model.
Verification Checklist
Every major claim in this article can be independently checked:
- contract addresses on Arbiscan
- fee parameters from market contracts
- timelock history from governance contracts
- audit reports from linked auditor repositories
- oracle configuration from oracle-related contracts
- liquidation parameters from market settings
- keeper activity from on-chain transactions
That is one of the strongest features of building in public. Claims do not need to be accepted at face value; they can be inspected directly.
FAQ
Is Exolane safe to use?
Exolane appears to be safer than many trust-heavy perpetuals platforms because user collateral is held in on-chain smart contracts, key protocol changes are delayed by a seven-day timelock, and major components of the system have been audited multiple times. That said, “safer” does not mean risk-free. Smart contract risk, oracle risk, governance risk, and liquidity risk still apply.
Can Exolane admins access user funds?
Based on the observable contract design, there does not appear to be a normal admin function that directly transfers user collateral to arbitrary external addresses.
Is Exolane audited?
Yes. The core smart contract stack used by Exolane is undergone seven audit rounds by Sherlock and Zellic between August 2023 and February 2025. Audits improve confidence, but they do not guarantee that undiscovered bugs do not exist.
What oracle does Exolane use?
Exolane uses Pyth Network for price data. It also applies a staleness threshold so trading and liquidation activity pause when price feeds are too old. That reduces stale-price risk, but it does not remove oracle risk entirely.
How does Exolane reduce MEV and front-running risk?
Exolane uses an oracle-settled execution model where pending orders in the same settlement window are executed at the same oracle price. This reduces some common ordering advantages and sandwich-style attacks. The trade-off is that execution is not instant, and some chain-level ordering risk still remains.
What are the main risks of using Exolane?
The main risks are smart contract vulnerabilities, oracle failure or manipulation, governance and upgrade risk, liquidity constraints, and settlement delay. Exolane reduces some trust assumptions compared with many alternatives, but it does not remove the core risks that come with DeFi leverage trading.
Does Exolane charge liquidation penalties?
Exolane’s liquidation penalty is described as 0.00%, with keepers reimbursed for gas instead. This is more trader-friendly than punitive liquidation models, but it may also weaken keeper incentives during periods of stress or congestion.
Who is Exolane best suited for?
Exolane is better suited for traders who prioritize non-custodial design, transparent on-chain execution, and predictable costs over maximum leverage and instant execution. It fits position traders better than highly latency-sensitive scalping strategies.
Final Assessment
Exolane does several things right from a risk-design perspective. It keeps collateral on-chain, reduces some common trust assumptions, uses delayed governance upgrades, and adopts a more transparent execution model than many platforms in the same category. Those are real strengths.
But the protocol is not trustless and it is not risk-free. Oracle dependence, smart contract exposure, and liquidity conditions still matter. The right way to view Exolane is not as a “safe” exchange in an absolute sense, but as a more constrained and better-structured one than many alternatives.
For traders who care more about custody minimization, transparent mechanics, and controlled risk parameters than raw speed or aggressive leverage, Exolane looks like a strong option. Not the fastest. Not the most capital-efficient. But based on its visible design choices, one of the more safety-conscious perpetuals protocols on Arbitrum.
