When bumping we add a ledgerbump { key, min_ledgers } to the contract's ledger bumps, does it mean that if the current expiration is 100 ledgers away and I bump by 130 the expiration happens in 130 ledgers and I only get charged for a bump of 30 ledgers (as I believe it was about last month)? Or I am extending the expiration by another 130 ledgers (so the entry expires in 230 ledgers)?
#Are ledger bumps cumulative?
simple grotto
summer hinge
the bump means 'the entry must stay alive for at least N ledgers from now' (hopefully this is documented)
the decision on the fees will be made based on the actual expiration ledger increase, as well as size increase (FWIW fees aren't implemented in p10)
so if the entry will expire at ledger curr + 1000 and you do bump(100), this will be effectively a no-op
simple grotto
makes sense, what happens when the min_ledgers_to_live value is less than the current expiration? is it overwritten?
just read the last message nvm
summer hinge
yeah, no overwrites or anything
so it's basically a good idea to just bump important entries for some reasonable amount (depending on the contract). the lower is amount, the more 'distributed' will be the bumps among the contract users, the higher the amount, the higher the risk of someone paying for the most of the rent, but also the less is risk of entries actually expiring due to low usage of the entry
simple grotto
yeah my approach currently is to bump instance storage by n ledgers with n being smaller than the bump amount for account-specific entries (varying also on if the account-specific entry needs to be read by other contracts).
summer hinge
yeah, there are no good numbers yet. for SAC we used 2 days instance bump (so your token will stay alive automatically as long as someone uses it once per 2 days) and 30 days for balances on every access (probably still to low... but really this should probably be a wallet responsibility to top it up)
simple grotto
Nice, I believe I'm a fan of smaller bumps and keeping things as "shorter" term as possible (and tries that last about a year before creating a new one) without impacting too much usability since it seems that it may optimize costs more hoping that recovering an entry that hasn't expired a long time ago isn't a significantly high cost
summer hinge
recovering entry is at least a signficant latency cost (at least in v2). also the bump cost should be reasonably small (nothing is decided yet, but I don't think we'd want something bigger than a couple XLM per year per maxed-out entry at maximum bucket list capacity)
so e.g. for a tiny entry like balance the cost of bumping even for a couple of months will probably be tiny. again, you can probably come back to number tuning when the fees are out on mainnet
simple grotto
yep probably better to leave bump amounts as TBD for now and leave a reasonable placeholder
it'd be interesting to come up with a scientific method to fine-tune the bump amounts depending on the expected entry usage frequency
summer hinge
I'm not sure it's really possible
unless you have a super narrowly used contract
like for token balances, the token usage frequency might wildly vary and even within a single instance the per-address balance usage may wildly vary. so I'd bump for a maximum possible amount that still can be considered 'cheap' (say, a fraction of other costs of using the contract)
like if your contract invocation costs 1% more, but will self-sustain 80% of the time, I'd say the increase is worth it
simple grotto
you're probably correct. I'm thinking that there could be oracles that measure the activity of an entry over time and provide bump amounts as oracles. But the cost of running these would be much higher than simply bumping by a very conservative amount