Using AXIS

Features and limitations

A summary of what AXIS does well and where its current limits are.

Features#

Convenient DEX#

AXIS combines the best from both worlds: CEX trading experience + DEX trustless self-custody model. It is based on the off-chain matching approach with further on-chain settlement. AXIS interface will be familiar to anyone who used exchange or trading terminal before. It's here to reduce friction for end-users and provide a fully-functional orderbook DEX for Stellar smart contracts platform.

Non-custodial immutable contract#

Security is our primary focus. That's why AXIS works with allowances instead of a classic deposit/withdraw model. Your tokens stay in your wallet until an order is filled. The contract holds tokens only inside a trade and pays out everything it receives before the call ends, so there is no exchange wallet or vault that could be drained. The contract is non-upgradeable - nobody can change the rules mid-flight.

All profits are yours, settlement is instant#

AXIS charges no trading fees and no settlement commissions. Makers receive exactly their price, and takers pay exactly the maker's price. The contract has no fee switch, and because its code cannot be upgraded, no fee can be added later. Traders pay only a small transaction fee to put the order on the blockchain. When your order fills, the tokens arrive in your wallet within the taker's transaction. There is no claim or withdraw step, and makers do not need to be online to receive funds or pay transaction fees for withdrawal.

Reliable and transparent execution#

Trader's signature covers their own call, not payments to specific makers. If the book changes before your transaction lands, the trade stays valid and fills what is still available. An order that is gone, expired, priced out of your limit, or whose maker cannot deliver, is skipped and the rest of the trade continues. Multi-hop swaps can trade through several markets in one transaction, for example XLM to EURC through USDC. A routing engine searches for an optimal path across liquidity from several markets to execute a quote atomically.

Tools for professional market-makers#

Allowance-based model enables an exceptional capital efficiency management. Funds backing active orders stay absolutely liquid and can be easily re-deployed without the need to cancel orders and withdraw money from the contract. This provides an opportunity to reuse the same inventory to quote RFQs with immediate settlement or generate yield using funds that otherwise would be locked in the trading contract. In-place order updates are cheap - makers can change the price, amount or expiration of multiple orders in one transaction without paying a blockchain rent fee.

Modular architecture + open-source tooling#

The Indexer and the JS client are MIT-licensed and provide a solid scaffolding for custom integrations. The protocol is fully open and introduces an extendable framework for advanced trading features like stop-loss or take-profit orders. It also can serve as a base layer for third-party protocols implementing market-making vaults, index baskets, RFQ/OTC trading, etc.

Permissionless pairs with spam protection#

Anyone can create a market for a trading pair where the Reflector oracle quotes at least one asset. Prices are set by traders' orders, oracle only helps with the protection from dust attacks. Dust orders clogging the orderbook pose a standard problem for any decentralized trading protocol. Stellar native DEX itself requires a 0.5XLM locked reserve per each active offer. AXIS deals with it by imposing a minimum trade size requirement. The estimated order volume is calculated based on reference prices pulled from the oracle.

Fortified trade settlement#

The DEX smart contract holds no user funds and consequently cannot be directly drained by an attacker. Since the contract is non-upgradeable, nobody can replace the smart contract code the matches orders, and therefore nobody can steal funds from standing orders by deploying a malicious contract update. So the potential attack surface shrinks to only a few functions that actually execute the trade. It's way easier to audit them than trying to protect the entire contract codebase.

Integrated kill-switch#

If something goes wrong with the protocol, a safety admin can freeze all trading activity on the contract. But the users do not lose access to their funds on frozen orders since the tokens actually never leave their accounts. In the worst-case scenario, the new DEX contract can be deployed on-chain and users can simply start using it right away, they will just have to recreate their orders. Any potential future protocol updates will be carried out only through the new contract deployment.

Open arbitrage opportunities#

When the book is crossed, anyone can call crossfill to match and cross-execute several on-chain orders without the need to supply any funds. Both makers get at least their own price, and the caller keeps the difference. This also means that a trader can put a high-volume order on the book and arbitragers can compete to execute it in chunks using all liquidity available on the orderbook.

Limitations#

Open orders are not guaranteed fillable#

The tokens are not locked in the open order, so if a trader spends them or balance allowance expires, the order stays listed, but it won't be executed in full. The AXIS API counts only the backed part of each order.

Network limits order execution#

Stellar restrains the size of events one transaction can publish, so one trade can fill at most 20 orders from different makers at the moment. A larger sweep needs several transactions. This ceiling depends only on the network limits and will likely increase in the future.

Storage rent order#

Every new order in the book pays a small non-refundable blockchain storage rent fee imposed by Stellar network. Updating existing orders avoids this cost.

Archival without updates#

An order lives in the blockchain active storage set for about 120 days on Stellar Pubnet (7 days on Testnet) unless it is updated. After that it is archived and must be restored by the next transaction before it can be filled or canceled. Stellar automatically restores archived state entries, but it means that a trader would pay additional fee for trading with an archived order.

Allowance expiry#

Allowances expire after at most about 180 days. All trader's orders selling that token stop filling until it is renewed. So a trader needs to revisit AXIS at least twice a year to make sure that long-lasting orders stay active.

Limit orders need an open market with a fresh oracle price#

A limit order needs an open market whose cached oracle price is less than 72 hours old to guarantee that it meets the minimum order value requirement. When nobody refreshes prices for a long period of time, new limit orders and updates pause. Market orders, swaps and cancels keep working.

No on-chain price-time priority#

The contract fills the orders a router lists, in the order listed. Routers such will pick the best prices, but nothing on-chain forces the best or oldest order to fill first.

The book can be temporarily crossed#

A new order can be created at a price that crosses an existing one. The book stays crossed until a new trade takes the orders or someone cross-fills it.

The safety admin can freeze trading#

The safety admin can pause trading in an emergency. Cancels and allowance changes still work, and the admin cannot move funds or touch orders.

Keeper dependence#

Normal market functioning relies on keepers who provision oracle access. Otherwise, new limit orders and updates pause. Existing orders can still be filled and canceled.

Preauthorized assets#

Settlements on AXIS pass through the AXIS contract, so a regulated asset with the preauthorization can be bought only after the issuer has authorized the AXIS contract too.

Self-trades are allowed#

A trade against your own order goes through and spends your allowance like any other fill. This is a deliberate choice to allow self-trades as traders can decide whether they want to include their own orders into the matching list on trade or not.

Non-upgradeable contract#

A potential protocol upgrade in the future will require full contract redeployment and transferring trading activity from the old contract to a new one. This it the price of enhanced security.