Refresh mainnet() resource limits and fees

[leighmcculloch]

What

Refresh the InvocationResourceLimits::mainnet() limits and the fee-rate snapshot used by CostEstimate::fee() to the Stellar Mainnet settings as of 2026-07-10, and update their rustdocs (including the duplicated limits table in the v25 resource-limits migration guide) to point readers to stellar network settings --network mainnet and Stellar Lab as the live source of truth.

Why

InvocationResourceLimits::mainnet() has been enforced by Env::default() on every test invocation since v25 but still carried the values from when resource-limit enforcement was first introduced, which had drifted from Mainnet in both directions: the instruction ceiling was too high (600,000,000 vs 400,000,000), letting a contract pass tests yet exceed Mainnet's per-transaction limit in production and defeating the early-warning purpose of the enforcement, while the entry ceilings were too low (disk read entries 100 vs 200, write entries 50 vs 200, ledger entries 100 vs 400).

Known limitations

The values remain a hardcoded snapshot rather than being pulled dynamically, so they will drift again.

On the one hand this is bad, but also, if they kept moving tests could become flakey, so timing this update with new major releases on some cadence is probably a good idea.

Follow up to introduce CI to help us keep it updated:

• Automate detecting drift of the hardcoded Mainnet resource limits and fee snapshot #1948

[leighmcculloch]

CI note: the test-example (import_ark_bn254, false) and (…, true) jobs fail, and this is the change working as intended rather than a regression to paper over. That example's test_running_contract_as_wasm consumes 404,552,943 instructions, which now trips the refreshed Mainnet ceiling of 400,000,000 (it fit under the previous, too-high 600,000,000). Surfacing exactly this kind of over-limit contract — one that passes today but would exceed Mainnet's per-transaction instruction limit — is the point of #1931.

The example lives in stellar/soroban-examples (pulled in by .github/workflows/test-with-soroban-examples.yml, which checks out that repo's main), so it can't be fixed from this PR. Resolving the job needs a decision there — e.g. calling disable_resource_limits() or setting a custom higher limit in that heavy-pairing example's test, or accepting that a single bn254 pairing at ~404M isn't meant to fit within a Mainnet transaction. Other heavy-crypto examples could hit the same ceiling. Flagging for a maintainer call rather than lowering the SDK value back toward 600M, which would defeat the purpose of the change.

---

Generated by Claude Code

[leighmcculloch]

I'm opening to merging this in a patch release given an experience of this is that it is surprising. But also, it could break peoples tests as it does for the soroban-examples, in which case it would be better to hold this for the v28 release and merge it just prior.

[Copilot]

Pull request overview

Refreshes hardcoded Mainnet resource limits and fee estimates to the 2026-07-10 network settings.

Changes:

• Updates invocation limits and fee/rent parameters.
• Refreshes fee expectation snapshots and rustdocs.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
soroban-sdk/src/testutils/cost_estimate.rs	Updates Mainnet limits, fees, and documentation.
soroban-sdk/src/tests/cost_estimate.rs	Updates expected fee calculations.

[leighmcculloch]

The soroban-example failures are being fixed in:

• Disable resource limits in bn254 wasm test soroban-examples#410

[mootz12]

Good catch on this drift.

Should we cache this for the user during test runs or something instead of requiring a release? We can expire it on some window.

This value changes unrelated to protocol upgrades, so I don't think tying it to SDK releases is the best.

[leighmcculloch]

Should we cache this for the user during test runs or something instead of requiring a release?

This is an interesting idea. There would need to be some built in defaults to apply when used offline. And test reproducibility is really important so it would be important that once a test ran once with limits that it ran every future time with the same values until a user took action to update it. I guess we could have built in defaults and write them to a .json file that gets committed with the project.

Is that what you had in mind?

[leighmcculloch]

This value changes unrelated to protocol upgrades, so I don't think tying it to SDK releases is the best.

For this reason I don't think it should be tied to major releases, and so we can release it with a patch release as a bug fix / tweak.

[leighmcculloch]

If there was a way to get the limits at a ledger number, then it could be convenience to cache a past limit in, but then you could get the limit for a given ledger number in your test that would be cached. That makes the values less arbitrary.