Increase per-transaction memory limit for Soroban

[misty-forest]

Increase per-transaction memory limit for Soroban

Motivation

As Soroban DeFi protocols mature, multi-hop swap operations are hitting the current 40 MB per-transaction memory limit. This is a fundamental consequence of the cross-contract call model where each invocation instantiates a fresh VM, combined with the growing adoption of feature-rich custom token contracts.

We operate an AMM on Stellar with multiple pool types and a router that composes them into multi-hop swap paths. After exhausting all meaningful on-chain optimizations, we are unable to fit a 4-hop strict_receive swap when custom (non-SAC) tokens are involved.

How multi-hop swaps consume memory

A chained swap routes through N liquidity pools. There are two modes:

• strict_send (exact input): single forward pass — N pool VM instantiations.
• strict_receive (exact output): reverse estimate pass + forward swap pass — 2N pool VM instantiations. This two-pass design is architecturally unavoidable since Soroban does not support reentrancy.

For a 4-hop strict_receive swap, this means 8 pool contract invocations. Each pool is a 55-65 KB WASM with swap logic, rewards, gauges, governance, and upgrade mechanics — all actively used in production.

On top of pool calls, each hop involves token operations (balance checks, transfers, refunds). SAC tokens are free here, but custom WASM tokens are not — each call instantiates the token VM.

A typical 4-hop strict_receive with 2 custom tokens in the path results in roughly 8 pool + 12 token + 4 utility = ~24 VM instantiations. Cross-contract calls have been optimized as far as practically possible — this is the minimum required to execute the operation.

The custom token problem

SAC tokens execute natively with zero VM overhead. Custom tokens require VM instantiation on every call.

The OpenZeppelin/Stellar token template produces WASM binaries of ~60 KB vs ~7 KB for a minimal soroban-token. In a 4-hop path with 2 custom tokens, ~12 token VM instantiations alone consume an estimated 8-10 MB of the 40 MB budget.

As more projects adopt the OpenZeppelin template, this gap will affect every protocol that composes token operations across multiple contracts.

Current memory consumption (testnet measurements)

Scenario	Hops	Token types	Memory	Source	Status
strict_send	4	2 custom + SAC	~32 MB	measured	fits
strict_receive	3	2 custom + SAC	~38 MB	measured	barely fits
strict_receive	4	SAC only	~28 MB	measured	comfortable
strict_receive	4	2 custom + SAC	~42 MB	estimated	exceeds limit
strict_receive	4	all custom (~60 KB each)	~51 MB	estimated	exceeds limit

What we need

4-hop swaps in both directions is a reasonable maximum for our pool graph — normal users (not just arbitrageurs) regularly use paths of this depth.

With a memory limit of 60 MB, 4-hop strict_receive would work comfortably even with multiple custom tokens, providing headroom for ecosystem growth.

Scenario	40 MB (current)	50 MB	60 MB
4-hop strict_receive, all SAC (~28 MB)	12 MB headroom	22 MB headroom	32 MB headroom
4-hop strict_receive, 2 custom tokens (~42 MB)	exceeds limit	~8 MB headroom	~18 MB headroom
4-hop strict_receive, all custom tokens (~51 MB)	exceeds limit	exceeds limit	~9 MB headroom

Summary

The 40 MB limit was set when Soroban contracts were simpler and token interactions were primarily SAC-based. As the ecosystem matures — with richer contracts, multi-hop DeFi composition, and heavier custom token WASMs becoming the norm — this limit increasingly constrains legitimate production workloads. A moderate increase to 60 MB would provide the necessary headroom without fundamentally changing the resource model.

[tupui]

The OpenZeppelin/Stellar token template produces WASM binaries of ~60 KB vs ~7 KB for a minimal soroban-token

This is a problem on its own to me. IMHO we should be focusing on that part first and see why these contracts are so large and if something can be done. I saw that spec shaking got into the SDK last week. Maybe that already changes a bit these numbers in the right direction? or are these numbers already leveraging this?

[willemneal]

Adding more context about the OZ contracts, a lot of their size comes from extra types in the generate spec that soon should be removed when building via the stellar CLI using the new tree shaking @tupui mentioned. Here is an experiment I did that shows the results of it: OpenZeppelin/stellar-contracts#574 . For what it's worth it drops to around 10-30kb per FT contract.

I do think it is still worth looking into higher limits though. I haven't yet but would like to do some wasm verification on chain. Which would require higher memory limits. Would be nice for spec validations and attestations.