Developers / Smart contract

Resource limits and costs

What AXIS operations consume under Soroban's per-transaction limits, which limit binds first, and what each operation costs in fees and rent.

Network limits#

Per ledger the network allows 1,000 written entries and 286,720 written bytes. Persistent entries are created with a minimum TTL of 2,073,600 ledgers (about 120 days) on mainnet and 120,960 ledgers (7 days) on Testnet, and no entry can live more than 3,110,400 ledgers (about 180 days) ahead.

Reading live state is free. A key declared read-write pays the write-entry fee even if the call never writes it, so the read-write declarations the JS client adds cost something for unmatched orders too.

Measured operation shapes#

The contract's resource tests (src/tests/lib/resources.rs) measure one call per shape in the test host. Instructions are a lower bound (no Wasm overhead), makers are contract addresses (no classic disk reads), and writes include the 72-byte authorization nonce. "Created" is the size of new persistent entries, the basis of rent.

Buy trades and swaps measure like their Sell rows, except that a Buy swap needs fewer instructions because it skips the forward planning pass (2.22M for 2 hops of 1 order). The created bytes of fills are first-time token balances of the test accounts. They include the contract's own balance of each asset a trade buys, an entry that only the first trade buying that asset creates.

Per-fill formulas#

With N fills from distinct makers:

A fill against a distinct maker writes 4 entries: the maker's order, both of the maker's balances and the maker's allowance. Its 792 event bytes are one trade event (about 320 B) and the two transfer events of the legs (about 236 B each). One maker's orders share one transfer per leg, hence 320 B per extra fill in the single-maker row. On top of the fills, every trade forwards what the makers delivered from the contract to the trader in one transfer (236 B), which also writes the contract's balance of the bought asset. Every swap hop writes the contract's balance of the asset it buys, and the swap ends with the same forward plus its own swap event. Other events: new 268 B, mod 148 B, skip 84 B, refresh 152 B, swap 236 B. A crossfill pays the taker order's owner instead of forwarding, and a surplus adds one transfer event to its row.

Which cap binds first#

Event bytes bind first, by a factor of about 2.4. The constants routers must respect:

• MAX_FILLS = 20 per trade. The resource tests pin it: 20 fills from distinct makers fit, 21 do not.
• The skip budget. 20 fills use 16,076 B, leaving room for 3 skip events (252 B), not 4, so routers budget listed orders, not only fills. Silent skips cost no event bytes.
• About 110 orders per update, changed or removed. AxisAccount sends batches of 90, while AxisContractClient.update and cancel send the whole list in one transaction.
• 20 fills per swap across all hops, since the swap event and the forward to the trader add 472 B.
• 19 maker fills per crossfill, derived from its formula: the taker order's own trade event and the payouts add up to 792 B with a surplus.

The two transfer events per fill (472 B) are 60% of a fill's event budget and come from the token, so the AXIS contract cannot lower them.

Fee estimates#

Execution fees at the snapshot rates, without rent and transaction size:

"New balances" is the rent of first-time token balances, if the call creates any. About two thirds of a multi-fill trade's fee is the write-entry fee (4 entries per maker at 2,500 stroops), and about a quarter the event fee. Not included: transaction size (several KB for a 20-fill envelope), read-write entries declared for orders that end up unmatched, resource safety margins and the inclusion fee, which the JS client bids up to 100,000 stroops by default (see Contract client).

Rent at the floor rate is about 1,667 stroops per byte for 120 days: about 0.041 XLM for an order entry, and about 0.037 XLM for the first token balance of a contract address. Order lifecycle and rent covers who pays which rent.

Requote economics#

Only new entries pay rent. A maker who refreshes quotes by removing orders and creating new ones pays about 0.042 XLM per order each time. update rewrites the same entries in place and pays the execution fee, plus a small TTL extension proportional to the time since the last update.

A 40-order update stays well within the event cap and keeps its orders from archiving. See Market making.

Adapting to limit changes#

The contract stores no caps: every loop it runs is bounded by a list the client passes. When an SLP changes a limit, nothing changes on-chain, and clients adapt:

• Read live limits. Take the per-transaction limits from the network configuration over RPC instead of hard-coding MAX_FILLS, and derive the fill budget from the event cap, the 792 B per fill and the 236 B forward per trade.
• Chunk large sweeps into several transactions, each racing the book on its own.
• Expect the effects. A higher event cap raises fills per transaction until the read-write cap takes over near 48, while a higher read-write cap alone changes nothing. A higher rent rate makes new orders dearer but barely affects update, which pays only a small extension.

Concurrency#

Since protocol 23, transactions that write no common ledger entry can execute in parallel.

• A trade writes the orders it fills, each maker's balances and allowance, the taker's balances and allowance, the taker's authorization nonce, and the AXIS contract's own balance of the asset it buys. It writes no instance entry or counter. Trades that buy the same asset share that contract balance entry and serialize, whatever their pair or makers. Trades that buy different assets from disjoint makers are independent.
• An update writes only the owner's orders, plus the owner's allowances when it grants approvals.
• swap and crossfill route tokens through the AXIS contract's own balance in every hop asset or the bought asset, the same entry the trades buying that asset write.
• requote and subsidize write the market and the price cache only when something changed, so a refresh with nothing new does not serialize with the trades and updates that read them.