Soroban Fees & Limits

Mainnet Phases

Goals

• Pick conservative network settings so that we can gradually launch Soroban without putting the greater network at risk.

• Not only validators but also what other nodes like captive core and downstream systems like horizon, Soroban-RPC and other similar systems.
• We expect a percentage of those systems to fail (completely or partially) with every new phase. Goal is to stagger those failures.

• Pick limits for the different phases with an understanding that some of them can only be increased over time (without breaking contracts).

Settings per phase:

Note: Phase 2+ limits will be TBD for a while (likely until Phase 1 is live) until we get some benchmark numbers and better understanding of the metering calibration and overall Soroban impact.

Phase 0 numbers are what we currently have minimum values. The maximum setting values depend on the ledger capacity.

Phase 0/1 per-ledger resource limits are the same as per-transaction limits. So it’s possible to have up to ‘Soroban Txn per ledger’ transactions that all add up to the specified limit, or a single transaction that consumes a maximum amount of every resource, or any combination in-between.

Limits

Important relation: VM instantiation cost = 0.4M + 350 * Contract size (the instruction limit should accommodate for at least the maximum allowed contract size)

Initial fees (protocol 20 upgrade)

Initial fee values are hardcoded as a part of the protocol 20 upgrade. The fees are  used to just introduce some ‘sane’ values to start with and to not make the network vulnerable to spam. These values are documented here for the sake of completeness, but see the following section on phase 1 fees for a more detailed description of the process of coming up with the fees going forward.

Fees (in stroops)

Rent/write fees

Write fees are dependent on the ledger size and have more complex configuration.

Rent payment is a write payment every X ledgers (‘rent period’)

Phase 1 fees

In order to make the fee structure more clear starting from phase 1 we’ll follow a more clear process of determining and describing the ‘bounded’ transaction fees (outside of the rent fees):

• There is a single fee that represents the maximum non-refundable resource fee that can be paid for a transaction (i.e. all the resource fees besides the contract event fees and rent fee). In phase 1 this fee is 0.3 XLM
• Every non-refundable resource has a ledger limit associated with it. Ledger is constrained by every one of these limits, thus initially we use the same fee weight for most of the resource limits. For example, using a ledger-limit worth of instructions (100M instructions in phase 1) would cost the same as using a ledger-limit worth of ledger entry reads (40 ledger entries in phase 1).

• The only two exceptions in phase 1 are the transaction size which is weighted 5 times higher and the base write fee which is weighted 3 times higher. The higher weights reflect the added costs of persisting the data: transactions have to be persisted in the cold history storage and every write persists in the bucket list for some time (even when it does not introduce new data).

Fees (in stroops)

Rent/write fees

The goal of the rent and write fees is to control the ledger growth speed, which is essential for protocol 20 given that the expired persistent entries are not physically removed from the ledger.

Initially, write fees are set up in such a way that 1 year of renting persistent storage for Soroban is equivalent in cost to creating a new entry in ‘classic’ Stellar (which costs 0.5 XLM per ~100 bytes of ledger storage).

The plan is to set up the fees in such a way that the ledger size would get at most 50% growth during a year. The initial “target” size is set based on the 2 month projection of this growth. The values will then be updated if necessary in order to reduce the fees and allow for the further ledger growth as long as the growth rate stays within the projected range.

Rent payment is a write payment every X ledgers (‘rent period’)

When a transaction only updates the entry without extending the rent or increasing the entry size, the write fees will be low and in line with the other resource fees. When a new entry is written to the ledger or the old entry has size and/or TTL increased, the rent fees need to be paid.

Phase 1 Examples

Here are some examples to put things in perspective (the fees are computed at ‘current’ ledger size and would grow as ledger size increases):

Phase 0: when first turning on pubnet (1 week)

This phase is not intended to be publicly usable or useful for any real projects. At this point Testnet should be at high enough capacity for users to continue testing and developing

Goals

• Smoke-test all the systems
• Execute only very basic contracts for the purpose of testing
• Upload network configuration upgrades via contract calls

Phase 1: Useful contracts, 1 “largest” transaction/ledger (~3 weeks)

In this phase users can deploy and test their contracts on the mainnet, but there is no expectation that their dapps can be used ‘in production’ due to low ledger limits.

What we are trying to control for:

• Uncertainty over bespoke deployments

• We don't know and can't test for all combinations of deployments. Uncertainty on CPU/RAM/Disk Space/IOPS
• Unknown spare capacity for core nodes (validators, watcher nodes).
• Unknown spare capacity for Horizon deployments (captive-core, ingestion).
• Unknown spare capacity for other deployments (Horizon alternatives, StellarExpert, etc)

• Uncertainty on metering (if for example the variance for execution time is 10x we could have ledgers ranging from 500 milliseconds to five seconds which is unacceptable)

• As a consequence we probably want to set limits as to target processing about 1 "worst case transaction possible" (so ledger wide limits are equal to transaction level limits)

• Junk or spam transactions or data on ledger

• Resource fees should probably be priced to deter those type of things. In particular we have to make sure that things are several magnitudes more expensive than both classic and (pick a number: 10 years ?) AWS. We may want to take into account some information we got recently that the cost to operate history archives is abnormally high because of bandwidth (so amount of data stored in archives).

• Out of control ledger growth

• Pick a target: 1 extra GB at first on top of the existing ledger
• Ensure that temporary storage is much cheaper then permanent one
• Ensure that policies on pubnet play well with the lack of ESS (probably means requiring longer minPersistentEntryExpiration ?)

• On testnet we may have to do the opposite so that app devs can actually find and debug issues related to state expiration (faster expiration -> more likely to run into issues)

• Amount of data produced

• Number of events and overall metadata size that needs to be processed by downstream systems

Phase 2: Increasing single contract limits (0-3 weeks)

 This is to account for the user needs based on their experience with phase 1.

Goals

• This phase should focus on increasing limits for a single transaction (If needed, as to enable a wider range of scenarios) -- if there is no such need, skip to "phase 3"
• We may also allow for splitting up the ledger capacity among a few transactions (so that we get more than one transaction per ledger, without increasing the overall ledger capacity to be a lot greater than the worst transaction we want to allow)
• Adjust classic capacity as needed
• Adjust market price of resources

Phase 3+: every 3-4 weeks after that

 This where users can start public usage of their dapps (probably still at small scale initially)

Goals

• Increase the overall capacity per ledger (more tps).

• This is the main way we will manage capacity issues in the extended network, so in some cases we may propose to reduce the capacity at the ledger level.

• Adjust classic capacity as needed
• Adjust market price of resources