[SLP-5] Discussion thread

[dmkozh]

This is to discuss SLP-5 (link to be filled in)

SLP-5 contains the only proposal to increase the per-transaction footprint limit to at least 300 entries. The motivation for the proposal is that certain protocols on mainnet started to hit the entry limit which made them effectively unusable.

[0xhypeJ]

It seems that the reasoning for this proposal is ecosystem maturity and developer UX.

Right now the limit is 200 reads and bumping it up to 300 is the reasonable path forward, as the ecosystem evolves.

The motivation behind the above statement is that the Soroban apps are now running more complex, stateful production workflows than the initial limits were tuned for; as protocols age, it’s becoming common for legitimate transactions to approach per-tx resource ceilings. This creates avoidable friction: extra engineering workarounds, fragmented transaction flows, and poor user experience (especially when simulation succeeds but submission fails due to final resource checks).

Raising the per-transaction footprint limit (and the corresponding disk-read limits in tandem) is a quality-of-life and scalability adjustment that better matches current real-world usage. This proposal simply updates hard ceilings so developers can build naturally composable contracts without unnecessary architectural constraints, improving reliability, composability, and developer productivity as the network matures.

Examples where this could help, focused on DeFi:

• High-state TWAP-aware execution on mature pools (helps Soroswap/Phoenix):
  Today, combining richer on-chain checks with execution can exceed limits. Higher TWAP limits preserve robust checks without forcing off-chain compromises.
• One-click LP maintenance (helps Soroswap/Phoenix):
  Flows like fee collection, range adjustment, re-add liquidity are often forced into multiple transactions, higher limits improve single-tx composability.
• Routed trade reliability at scale (helps Soroswap/Phoenix):
  atomic zaps already exist, but heavier routes and mature pool state can make them brittle under current caps; higher limits improve reliability/headroom for the same feature set.
• Volatility-adjusted collateral management (helps Blend): Lending protocols that dynamically adjust LTV ratios from high-granularity TWAP buffers require more state than current limits allow. LTV governs liquidation risk across large collateral pools — the off-chain keeper model introduces a trust assumption for a parameter of this consequence. Higher limits allow vol estimation to execute atomically and trustlessly alongside the lending operation itself.

All four use cases share a common thread: replacing trusted off-chain computation with verifiable, trustless on-chain logic — a defining characteristic of a maturing blockchain ecosystem.

I would like to see even higher limits in future so that the systems which are off-chain, and could live on-chain, eventually do!