Dynamic/Programmatic Rent

[brooksprumo]

Placeholder issue for designing and implementing dynamic rent

Rent prices need to be changeable (up and/or down), but that's not easy right now. We need a mechanism to allow rent to be computed dynamically/programmatically.

Considerations:

• Rent cost too cheap: scale rent costs up as total storage in accounts increases (i.e. new accounts cost more)
• Rent cost too expensive: onboarding new users is harder with higher rent costs
• Handling collecting rent correctly with skipped slots
• Handling collecting rent to be more performant
• Handling collecting rent to ideally limit re-writing accounts unnecessarily
• Feature-gating this
• Any scenario where rent can be replaced with another economic incentive model?
• What should happen to accounts that transition between rent-exempt <-> rent-paying due to a rent change

Related to:

• Proposals for long-running rewards computations #20384
• Writing account state on every slot inefficient and reduces incremental snapshot efficiency #17178

Previous work done elsewhere

• https://docs.ethhub.io/ethereum-roadmap/ethereum-1.x/#state-rent
• https://github.com/ledgerwatch/eth_state/blob/master/State_size_growth_management.pdf
• https://github.com/ledgerwatch/eth_state/blob/master/State_Rent_2.pdf
• https://github.com/ledgerwatch/eth_state/blob/master/State_Fees_3.pdf

[t-nelson]

I think the first step here is to be able to raise rent without rugging currently rent-exempt accounts. Without that nothing else can be implemented.

[askibin]

what is the business case for non-exempt accounts? I always use either rent exempt or flash accounts that are created and destroyed within transaction.
the only reason for a periodic rent collection I see is to prevent the account from sudden destruction if its balance goes below rent-exempt. but this is easily fixable: 1. don't allow spendings that would reduce balance below threshold, 2. if user wants to recover funds provide him with close account instruction

[brooksprumo]

what is the business case for non-exempt accounts? I always use either rent exempt or flash accounts that are created and destroyed within transaction. the only reason for a periodic rent collection I see is to prevent the account from sudden destruction if its balance goes below rent-exempt. but this is easily fixable: 1. don't allow spendings that would reduce balance below threshold, 2. if user wants to recover funds provide him with close account instruction

I've been looking into Rent to try and answer these questions also (discord). I haven't come across a use-case for rent-paying accounts; I believe your point makes sense, and I feel the two changes would fix that. I'd love to remove Rent entirely, as it's a source negative performance impact in a few places (computation and on-disk storage). I'll run this by other folks to get feedback.

Then, if Rent is removed, we'll be left with the concept of Minimum Account Balance. That will need a way to change over time, so the dynamic/programmatic issue still remains.

[askibin]

it might be not necessary to deal with min account balance:

• user pays one-time rent upon account creation (if he wants the account to persist)
• that amount gets recorded in a separate field
• balance shows zero (or whatever was deposited minus rent)
• everything works as it is now just no periodic rent
• when user wants to recover funds he calls close account and gets balance + stored rent amount

[brooksprumo]

it might be not necessary to deal with min account balance:

* user pays one-time rent upon account creation (if he wants the account to persist)

* that amount gets recorded in a separate field

* balance shows zero (or whatever was deposited minus rent)

* everything works as it is now just no periodic rent

* when user wants to recover funds he calls close account and gets balance + stored rent amount

Yeah, that could work too. So then as the rent-exempt amount/minimum account balance needs to change, it would only affect new accounts being created, not existing accounts. This would then effectively transition into a "new account cost". And then you're rewarded that amount when closing the account.

[justindoody]

what is the business case for non-exempt accounts? I always use either rent exempt or flash accounts that are created and destroyed within transaction. the only reason for a periodic rent collection I see is to prevent the account from sudden destruction if its balance goes below rent-exempt. but this is easily fixable: 1. don't allow spendings that would reduce balance below threshold, 2. if user wants to recover funds provide him with close account instruction

I've been looking into Rent to try and answer these questions also (discord). I haven't come across a use-case for rent-paying accounts; I believe your point makes sense, and I feel the two changes would fix that. I'd love to remove Rent entirely, as it's a source negative performance impact in a few places (computation and on-disk storage). I'll run this by other folks to get feedback.

Then, if Rent is removed, we'll be left with the concept of Minimum Account Balance. That will need a way to change over time, so the dynamic/programmatic issue still remains.

Hi, i'm new to Solana development but have been digging into rent related topics all day for a project i'm speccing out and stumbled upon this issue. I have a business case for non-exempt accounts. Basically i'm working on an option for very low cost self expiring NFT's that could be minted for costs in the low cents / sub cent usd price area and accounts initially seeded with only a few epochs worth of rent.

Note: There are currently other things blocking this due to the SPL Token Program not allowing rent exempt accounts but that was due to at the time "we've failed to discover a compelling reason to permit non-rent-exempt token accounts." so perhaps that's open to change.

I think ultra low costs nft's unlock a whole new area of exploration within the Solana ecosystem so unless minimum account balance can be massively reduced to at least within an order of magnitude of transaction fees at least retaining the potential for low cost rent paying accounts seems important.

[Henry-E]

This really doesn't change anything. Instead of trying to make a cheap NFT, just make a rent exempt account and retrieve the rent after X epochs. Then you have a zero cost NFT

[justindoody]

This really doesn't change anything. Instead of trying to make a cheap NFT, just make a rent exempt account and retrieve the rent after X epochs. Then you have a zero cost NFT

That still introduces an upfront cost and if the account is user controlled i can't collect the rent anyway. I need near zero upfront cost and user controlled.

[Arrowana]

This really doesn't change anything. Instead of trying to make a cheap NFT, just make a rent exempt account and retrieve the rent after X epochs. Then you have a zero cost NFT

You still have to pay for a few things that cannot be returned ever:

• rent of the mint
• rent of the metadata
• rent on whatever storage: arweave, ipfs...

[t-nelson]

@justindoody @Henry-E @Arrowana mind taking this to another issue? It's a bit off topic for the goals of this one

[hann228]

Rent-exemption generally

Thoughts here is that it's important to note that all SPL token accounts must be created rent exempt. Anecdotally, 'rent-paying' accounts seem to only be a very limited sub-set of accounts in the Solana ecosystem which do not have SPL tokens. I agree with @askibin that periodic rent paying accounts seems to have a trivial use case.

Handling collecting rent to ideally limit re-writing accounts unnecessarily

Add storage to each account to save the epoch number of the epoch in which the account was created (that could be generally useful for a number of things, but would allow grandfathering rules too).
When a dynamic fee increase/decrease 'occurs', the change in cost will apply from the current epoch going forwards to all new accounts (rather than re-write/reset all accounts within the Solana ecosystem).

(This would appear to address @t-nelson's concern of a rug pull, I would question if that would really occur anyway - with a total fee decrease today - we are talking about 40c per account x the number of rent-exempt accounts on Solana - the aggregate total is still likely less than half a single day's trading volume of Sol <$500M in Sol)).

Practically, this means pre-existing accounts would have a different rent-exempt minimums to new accounts after the fee adjustment. However there are number of justifications for this, (1) different rent-exempt minimums already exist today depending on program size (2) the app developer has already incurred the costs of pre-existing wallets so the financial burden has already been incurred for those wallets (3) the app developer's remedy for high cost pre-existing accounts is to close them and recover the rent-exemption.

What should happen to accounts that transition between rent-exempt <-> rent-paying due to a rent change

Under the above grandfathering rules, this scenario would not occur. In any event, I think it could make sense where an account is created 'rent-exempt', that it cannot be withdrawn past the rent-exempt minimum rather the account must be closed to recover this amount to avoid transitional status changes.

[ruuda]

Right now, rent is a major complication for developing on Solana, and it interacts with almost everything.

Analogy

I haven't come across a use-case for rent-paying accounts

Imagine a file system where in addition to the rwx bits, there was a “k” bit, for “keep”.

• When the k bit is 0, the OS can delete the file at any time. Sometimes it does so immediately, sometimes it only happens later.
• The k bit is 0 by default when you create a new file, although you can turn it on if you create the file in a special way, and you can turn it on after creation.
• Some file operations set the k bit to 0 in some cases as a side effect.
• Some file operations set the k bit to 1 in some cases as a side effect.

For such a file system, you would expect:

• Many applications to have bugs where files disappear.
• Review to be ineffective at catching such bugs, because they are very difficult to notice in the source code. Setting the k bit is something that you actively need to do; it’s the absence of that which creates the bug. Code that looks entirely correct if you are unaware of k bits, can be buggy.
• Sometimes it’s an unrelated operation that unintendedly zeroed the k bit. Reviewers need to be aware of operations that might do this and learn to be suspicious of them. Code that looks fine can be buggy.
• Most of these bugs don’t get caught in testing, because usually the file still exists when testing ends, even if the k bit is 0.

That would be a pretty awful file system, right? This is how accounts and rent work in Solana.

Solutions

Disallowing rent-paying accounts at the end of a transaction, is enforcing that the k bit is 1 at the end of the transaction. It’s a step forward for sure, because now you get an error instead of a silent bug, and it’s easier to catch in testing. But it doesn’t make it any easier to avoid introducing bugs in the first place. The better fix is to remove the k bit entirely.

I believe the above proposal by @askibin is the right way to do that.

If rent goes away, let’s call the rent-exempt balance of an account its “rest balance” (like rest energy). The rest balance is the amount of SOL that you pay to create the account, and that you would reclaim by closing the account.

There is still some subtlety in dealing with balances: should you count the rest balance as part of the balance or not? (I.e. does it move the problem? Do you now need to remember to write account.lamports + account.rest_lamports where you previously wrote account.lamports?) I think it depends, it needs to be decided on a case-by-case basis, but in all cases that I have encountered so far, you don’t want to count the rest balance as part of the balance. (E.g. in a wallet, if you can spend 0 SOL but you do have a few SPL token accounts, it would be surprising to show a nonzero SOL balance. And the stake program has bugs that can be blamed on rent being part of the balance.) I think this subtlety is inevitable, but having rest balance not be part of the normal balance is the right default, so that’s another point in favor of moving the rent to a different field, as @askibin suggests.

Backwards-compatibility

If we want to convert the current rent-exempt share of an account’s balance into rest balance going forward, that would suddenly decrease the balances of accounts, and that would break things, so that’s not an option. That means we have to set the rest balance of existing accounts to 0. But what about existing accounts that are not rent-exempt? Well, as we still haven’t found a valid use case for those, there shouldn’t be many of them either way (but I haven’t confirmed this), so maybe it’s fine that they become immortal. If not, @asparagusm’s proposal above to also add the creation epoch (or maybe even the slot?) would help to tell these accounts apart. (And the rest balance could be computed from the creation epoch as long as accounts can’t be resized, so that saves some disk space.)

One more issue is that changing the memory layout of AccountInfo in the entry point would break all existing programs, so if we want to expose the rest balance to programs, it can’t go in AccountInfo. Maybe there could be a new syscall to query it? It would be unfortunate if AccountInfo is no longer a full description of an account, but I don’t see a backwards-compatible way around that if accounts have to gain fields.

Creating an account doesn’t have to break API-wise, if the fee payer pays for it, although it might break applications that expect to pay a certain fee and now they need to start paying more.