[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.

[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?

[mihaieremia]

+1 I just hit the same txMaxContractEventsSizeBytes for XOXNO swap aggregator complex optimizations of routes for higher inputs

Such example of swap https://stellar.expert/explorer/public/tx/7148357b7ea266b7778ed915ccae051e2c2e2187b48e9a3b3e8ed4dcb6443b63

[orbitlens]

@tamirms We are building a CLOB based on allowances and pure on-chain settlement: https://axis.markets/docs/learn/how-axis-works/. Since all the settlements between makers and taker happen in the contract, we have to send funds as maker -> contract -> taker + taker -> contract -> maker, which generates calls try_transfer_from a lot under the hood. It's not possible to send directly maker -> taker + taker -> maker because the transfer can fail for numerous reasons that is impossible to know in advance (insufficient balance, no auth, full trustline, etc). We also cannot simply panic and revert the entire transaction because this way rogue makers can effectively block all trading on the contract with a few orders. So a contract need to have a possibility to skip "bad" fills (when the transfer fails) and continue execution + settlement with other orders. This means that right now we are limited to about 20 fills per transaction. And mostly because of events generated by token transfers. I have this resource limits table for the reference (it's updated by AI on each build, so some numbers might be slightly off, but it is correct in general): https://axis.markets/docs/developers/contract/resources/

The bottom line: would be nice to have x2 at least txMaxContractEventsSizeBytes (this will double fills per transaction in our case), but of course, I don't see the entire picture. E.g. "32 MB of events in the LedgerCloseMeta payload" doesn't seem like something terrible to me (it already can be up to 16 MB with current settings if I understand it right).

[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.

[anupsdf]

Thanks for looking at this proposal and posting your questions @Galmanus !

Unsponsored trustlines (232 B per transfer) would fit all 1,000.

Yeah, and that's the current motivation and we are trying to see if we can fit 1000 of those non-sponsored G-G transfers.

Write bytes is also the limit that's maxed out today.

You are right but most traffic is from Kale contract and any ledger limit increase would be easily taken up by more Kale traffic. We would love to hear if any other contracts/protocols are blocked by current limits that would require us to re-assess the new threshold.

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

That's right. One major consideration is to look at the impact to ledger close time as we increase this limit. If you look at the benchmark results, the ledger close time is barely under 300ms for the test cases. This is the threshold that was established in SLP-004. We do plan to optimize and speed up ledger close time in the near future, at which point we would be able to increase the limits again.

[Galmanus]

Thanks @anupsdf, that clears it up. Makes sense to hold write bytes until close time comes down.

On whether anything else is blocked: I split write bytes by contract over 160 ledgers spread across the last week (8 windows of 20). The KALE farm contract plus three helper contracts that call into it (batch plant/work, harvest) accounted for 97.6% of declared write bytes. Everything else averaged 2.0% of the limit (p90 3.4%, max 59.2%). KALE txs also bid the 100 stroop minimum inclusion fee per op (all 1,687 in a 10-ledger sample), so anything bidding more should get in ahead of them. So outside KALE, I don't see signs of anything being blocked by write bytes right now.

[drebelsky]

Just noting here that in ledger 64857535, ~84% of ALPHANUM4 trustlines fit in the proposed limit.