Paying rent with deposits



Thinking about storage rent - what about requiring a deposit for all storage used, instead of a rental fee? The deposit can be refunded in its entirety when storage is freed up, and provides a direct financial incentive to free up unused storage, without any of the complexity of tracking rent balances over time, and deleting state for contracts ‘in arrears’. With Casper, there’ll be a very real opportunity cost of locking up your ether, and so a direct financial incentive to design contracts to be conservative with the storage they use.


I’m not yet convinced that the opportunity of staking in Casper will outweigh the risk of having your ETH controlled by a hot wallet. With storage, your ETH can be secured by a cold wallet, thus is significantly lower risk.

As a user, I’ll need pretty solid returns from staking to convince me to bring my ETH out of cold storage. However, having my ETH locked up in a contract that is recoverable by my cold wallet is not really a different risk profile from storing in my cold wallet directly.


You still incur the opportunity cost of not being able to use those funds for anything as long as they’re locked up paying for storage.


The main point of my argument wasn’t that your proposed solution was bad, just that that particular piece of the argument doesn’t hold water IMO since it is yet to be seen whether or not the yield of staking even fully offsets the risk of holding your assets in a hot wallet.


In the most recent Casper FFG implementation, a compromise of your hot wallet will only cost a large portion of your funds in the case that very many other users get compromised (or attack) at the same time. So it’s a much smaller risk than actually putting all of your funds in the hot wallet.


I like the idea, as it’s simpler to make people “pay” by inflation than to actually remove some ETH.
It’s also a better incentive than gas refund as gas refund can only be used to, at best, divide the cost of a transaction by two, providing really little incentive for cleanup.

On a precedent, you can see that Augur switched from making inactive token holder loose funds, to increasing the total supply and rewarding active token holders (see:

However the disadvantage of requiring a deposit, is that the capital lockup costs decreases with inflation making it tends toward 0 (but quite slowly).


Is it more like a hot key that votes on behalf of some funds instead of a key that directly controls the funds?


Yeah, that how I see it. It does not need to be implemented in casper, but people would use staking smart contracts requiring different keys for different actions.


It turns out this was a mistake and the system is very likely switching to “use-it-or-lose-it” sometime after launch. :cry:


Ah, clever. So the contract may limit “withdraw funds” action to a cold key or multisig, while “vote for block” would be done with a hot key? And since the damage that can be done via voting wrong is limited, this limits the risk of the staker.


I’m not sure it’s a mistake, but they may increase the inflation rate (5% everytime there is a fork is really low, I think something like 50-100% when there is a fork is reasonable).

Yeah, that’s how I’d do it.


I don’t want to hijack this thread any more than I already have, but if you want to discuss this more in depth feel free to hop into Augur Discord server or DM me here (assuming DMs here are a thing)!


The point of rent is that accounts that use more storage space time need to pay more, and accounts that use less storage space time need to pay less. Simply relying on inflation for the cost would mean that accounts that have more tokens would be paying more, not accounts that use more storage. Rent also allows unused dust accounts to be cleaned up, and relying on inflation or even a deposit does not solve that.


Right; I’m not suggesting using inflation, but rather opportunity cost. Locking up funds always imposes an opportunity cost, and the ability to recover those unused funds provides an integrated incentive to free up storage.