[SLP-7] - Discussion thread

[drebelsky]

This is a discussion thread for SLP-7. This SLP proposes increasing some of the ledger-wide Soroban limits and decreasing many of the resource fees by ~2x.

[orbitlens]

Great initiative! Is it possible to increase the txMaxContractEventsSizeBytes as well?
I'm working on a smart contract that performs a lot of transfers (settlements) in one transaction and for this model it's a major limiting factor because each token transfer raises its own transfer event. I hit the events limit ceiling even if my contract doesn't emit a lot of them, simply because SAC and other contracts always write events on transfers, burns, allowance changes, etc.

Its current value (16KiB) was set back in January 2025. Since then ledgerMaxWriteLedgerEntries was updated twice, from 250 to 1000, and this SLP is the third proposed update (8x from Jan 2025 value). The txMaxWriteLedgerEntries grew from 50 to 200 (4x since Jan 2025). So can we increase txMaxContractEventsSizeBytes to match the write throughput gain? Ideally, 4x to mirror the txMaxWriteLedgerEntries.

I understand that events may potentially clog the history, but unlike the contract state entries they do not stay on-chain, only in transaction archives. From my perspective, it's a good tradeoff to support adequate multiparty settlement in smart contracts.

[tupui]

+1 there. I was also limited to do something like 40-ish payments at the same time IIRC and I had to find another solution. I was taking a collateral and wanted to repay all parties atomically.

(Slightly out of scope for that discussion. Alternatives could be having a batch payment option, which in some ecosystems you do have. Or to allow an aggregation of events if they come from the same function or if coming from repeated cross-contract calls.)

[drebelsky]

It's probably not possible to increase txMaxContractEventsSizeBytes in this SLP given some concerns about worst-case growth with RPC, but it is something we're looking into.

[orbitlens]

Could you please provide any details regarding the aforementioned concerns? Doubling allowed events size can potentially lead to increase of the average RPC database size by 10-20% percent in the worst case scenario, and probably some performance degradation of the index lookup for events. But it shouldn't be the end of the world, right?

[tamirms]

@orbitlens we should be able to support your use case but we need to have other limits in place first so we can cap number of events per ledger, cumulative size of all events per ledger, and max event size. Otherwise we can get into worst case scenarios where there is over 32 mb of just events in the LedgerCloseMeta payload.

It would be helpful to know how many settlements per transaction you'd like to do in your smart contract so when we do bump the limits it can support your use case. Could you share those details?

[Oaksuprem]

While discussing this, can we also address Minimum Reserves. I feel they have been a huge headache and cost for developer deploying on stellar whether through sponsoring reserves, starting balances or requiring users to acquire XLM from exchanges.

[tupui]

This is not really related to Soroban limits though. Might want to make a new proposal for that purpose with some motivations on that. I personally don't agree with the statement. The core features there are quite nice for that purpose. You now also have the route to give C accounts to users which do not require acquiring any XLM even.

[fazzatti]

I agree with @tupui here. I understand how these can be frustrating at times and perhaps there could be improvements to consider but it would be best to have a separate thread only for that topic so it doesn't mix with the SLP topic.

[Oaksuprem]

Understood. Thank you for the patience in understanding and explain. I'm a new contributor from Kenya.

[Galmanus]

Question on the SAC scenario: the 1,000 transfers per ledger justification checks entries and tx size, but for that case write bytes looks like the binding limit.

A G-to-G transfer writes both trustlines, and on mainnet most USDC trustlines are sponsored, which makes them 160 B instead of 116 B. In a sample of 200 USDC trustlines the median was 160 B, and simulating 12 transfers between real holders gave 276 to 320 write bytes each (mean 307.7). At that size 297,000 fits about 965 transfers. Unsponsored trustlines (232 B per transfer) would fit all 1,000.

Write bytes is also the limit that's maxed out today. Summing the declared resources of Soroban txs over two recent windows (60 and 25 ledgers), write bytes averaged 94.1% and 99.9% of the 286,720 limit, while write entries peaked at 927 and read entries at 363, out of 1,000.

Is 297,000 deliberately kept close to the current value, for ledger growth reasons, with 1,000 SAC as an approximate target? Happy to share the scripts.