FLIP 66 - Revisiting Flow storage minimum account balance

Governance FLIPs
#1

Revisiting Flow storage minimum account balance

Status Proposed
FLIP # 66
Author(s) Kshitij Chaudhary ([email protected])
Sponsor Kshitij Chaudhary ([email protected])
FLIP Document https://github.com/onflow/flips/blob/main/governance/FLIP-revisiting-storage-fee.md

While Flow storage pricing was kept low in its early days to promote network trial-ability without financial concerns, as the chain matures and usage-patterns evolve, it is important to revisit the pricing from time to time. This FLIP aims at gathering community feedback on revisiting storage pricing such that it reduces attack surfaces, promotes sustainable state growth, and steers mass adoption and scalability.

#2

Hi everyone, I’m a Senior Product Manager in Flow protocol team, leading all Tokenomics and Governance work required to scale Flow to greater security and decentralization, mass adoption, and long-term sustainability. I come with a decade-long experience in economics, pricing, product development and Web3, and am thrilled to be a part of the Flow core R&D team. I look forward to your critical feedback on this proposal, and others that I’ll publish soon. Thank you!

3 Likes
#3

A good proposal, which can greatly improve the utility of $FLOW !

Have two questions:

  1. What about an old account that have only 0.001 FLOW? Need additional deposit to match minimum FLOW token balance?
  2. Is the account that has exceeded the usage also need additional deposit before it can be used again?
2 Likes
#4

I feel like this deserves a very long comment @kshitij.chaudhary ( my initial reaction is in insane category ) But in general I like bold moves.

Few comments: I would be happy if you mark them as agreed/not agreed to better understand the position.

  • This needs to be considered seriously; and we shouldn’t change account minimum balance unless something major happens again ( it should be predictable for people building )

  • with new 0.1 FLOW, it is like 10 usd cents right? this is pretty high, as comparison, I have mobile games acquiring users from ad networks for less than this price. (which they have similar LTVs with little profit margin ) So basically if I want to integrate my mobile games, I should invest more to Flow then my UA ? I think this is an adaptation blocker.

  • can you confirm as you said 0.1 FLOW, you don’t predict Flow price going to 10$ ranges anytime soon ? You are the only person in the flow team, that should be able to discuss and speculate on flow price, otherwise you cannot do your job I guess.

  • what is the cost of the running network ? Which percentage cost is storage ? I feel like you are trying to prevent account creation ( and leeching ) but I want to learn more about details and numbers here, if you can share some.

  • I think changes should be made in synergy with transaction fees ( preferably at the same time ) super cheap transactions ( and market network as cheap ) but support with extra expensive storage fees is not a good solution. It is like buying from Amazon something cheap with extra expensive shipping. ( we call then scams )

Thanks for your time and answers in advance, and good luck

3 Likes
#5

Also one more thing; If I will pay this amount of money to store stuff, I would track for every byte, are we ready for that accountability? Currently storing something on Flow and checking how much storage its using is the best random number generator on chain.

#6

Hello @kshitij.chaudhary In the FLIP you claim that 95% of accounts only store 10k. I would claim that there are a lot of vacant accounts then. Can we base this number on active users that are using the chain?

I have a medium sized collection of NFTs in my storage and i would require to hold 32 flow in order to keep them.

I created this script in flowrunner to calculate the required storage of a .find name or address.

3 Likes
#7

Cant resist:

From twitter:

The Flow mainnet spork is just a few days away and we’re gearing up for unprecedented scaling. We will be laying the foundation down to scale Flow to Petabytes of data, a feat not achieved by any other blockchain :chart_with_upwards_trend:

Considering 1 flow is 100kb with new scheme
10 flow is megabyte
10K flow is gigabyte
10M flow is terabyte
10B flow is petabyte

Total flow supply is around 1B…

Wait a minute….

#8

One of .finds enterprise customers OneFootball is preminting things and putting them in packs. At the moment they do not have that many things in treasury storage but they would still need to hold over 3000 flow to store what they have.

#9

minimum 80-90% of the accounts are joyride accounts anyway. ( in which users doesn’t even know about flow ) Popular Flow Blockchain Projects It is not surprising they don’t consume much storage.

#10

As the creator of Flovatar that heavily relies on blockchain storage for the SVG of each NFT, I have to say that this is a bit of a shocker and will create so much confusion and troubles among our users, especially the Dapper ones since they can’t manage storage themselves and have to rely on the bot to refill it all the time.
Such a huge change (1000x!) should at least be planned ahead of time and maybe with a more phased approach (10x three times) instead of all at once. In this way I think that a better balance can be found in between and that will have less disruptive effect.

I totally agree with everything that @bluesign and @bjartek said so I won’t repeat it again to avoid adding noise to the conversation.

Finally I think that the network should focus much more on increasing gas fees instead of the storage because it would definitely be a big deterrent for mass adoption of new wallets if everyone has to pay $1 or more to open it (making it also unsustainable to be subsidized).

I really hope that this change won’t go into effect and that you will at least consider making it a 10x increase instead of 1000x.

2 Likes
#11

Chiming in to say I agree with all the sentiment above that @bluesign, @bjartek, and @luca have said, and I wanted to ask an additional question as well:

How does the flow team plan to address the possibility of attacking someone’s account if it becomes so much more expensive? Any resource that can have things put in it is suddenly a much easier (100x easier) avenue to bricking that account. It would be great to see considerations like that also clearly addressed so we know what all has been thought of

1 Like
#12

There is a cost to running a business right? These 3000 flows will still stay in your account and they will not be burned. They might need to revise their strategy by not pre-minting so many things. Maybe 3000 flows for them is a slightly high number at this stage but the storage minimum account balance at the current setting is definitely too low. In the flip document, we can see the storage cost happened on solana and near which are 14,000x and 2100x higher than us.

1 Like
#13

Thanks @kshitij.chaudhary for the proposal.
I see a lot of valid points in what @bluesign @bjartek and @luca stated above, and I believe that finding the right pricing model should use a kind of competitive analysis as you did for Solana and Near, but also try in someway to see what is the model proposed for account storage in the web2 world, because at the end of the day users will compare what they pay for whatever storage product/service.
To make it simple, if I look into Dropox pricing model here: https://www.dropbox.com/plans, what I can see is:

  1. There is no linear model between different Tiers
  2. Each tier is coming with additional benefits on top of the storage itself. I I can think here about what @bjartek has said about OneFootball packs and how we could imagine including packs in the pricing model

There are certainly other aspects to look into where we could enrich the storage pricing model

1 Like
#14

Hi, thanks for your comment.

  1. Yes, in this case an additional deposit of 0.099 FLOW would be required
  2. If an account exceeds the storage-usage vis-à-vis the FLOW reserve in their accounts today, I believe the transaction simply fails. So, the rules on this should remain the same. Lmk if I’ve misunderstood your question though.
1 Like
#15

Hi, thanks for your feedback.

  1. I agree, we need to keep prices predictable for builders. We would thus make these changes after enough deliberation, and only change if there’s a strong reason to do so (such as substantial change in FLOW price, txn volume, Flow state etc.)

  2. Yes, 10 $cents would be the approx. fee for a new account. I share the competitiveness with other blockchains (NEAR and SOL) in the doc. Additionally, in the instance of a game wanting to integrate with Flow, yes, this would add slightly to their CAC. Generally, I believe for most successful games the average CAC is several US$ per user (90-100x higher if we consider transacting/ paying users), so the addition 10c shouldn’t be a very high proportion of the total acquisition cost per user

  3. (A) You make a great point on “what happens when Flow bounces back to the double-digit $/Flow price”. I believe this is related to what you said in point (1) - “unless something major happens again”. Based on the markets and exogenous factors, my job would be to continuously analyze the community’s experience and the inflection points that could make adoption challenging for folks, and accordingly propose changes.

(B) On discussing the FLOW price being my job – what I am working on is improving the intrinsic value of Flow – that’s my primary responsibility imo. I could build a model next that helps evaluate the price range based on supply, velocity, transaction volume and other factors, but I strongly believe that the delta in the observed and the projected price (speculation) is a market-based random walk that cannot be conclusively determined. Nevertheless, I’ll soon open up conversations on FLOW price and inflation.

4, 5– Agreed, storage fee changes should happen in synergy with txn fee changes. Proposal to changing the txn fee is coming soon too (drafting stage). As you are aware, we made execution fee variable last year, based on the execution costs to the network (https://github.com/onflow/flow/blob/c05d847adf2f6fb509e42c17020484d7dd3e89bd/flips/20220111-execution-effort.md) – will share more numbers on this, thanks.

1 Like
#16

Hi, thanks for your comment. So we don’t have too many “vacant” accounts – here’s the distribution (StorageUsed is in bytes) -
quantile, StorageUsed
0.10000, 1.345000e+03
0.20000, 2.119000e+03
0.30000, 2.165000e+03
0.40000, 2.165000e+03
0.50000, 3.159000e+03
0.60000, 3.744000e+03
0.70000, 4.640000e+03
0.80000, 6.171000e+03
0.90000, 8.000000e+03
0.95000, 1.080800e+04
0.99000, 2.676200e+04
0.99900, 2.091000e+05
0.99990, 8.918132e+05
0.99999, 5.439810e+06
You’re right though, we could have non-vacant-but-inactive accounts. We need an account-staleness analysis – even amongst non-vacant accounts, how many are inactive, based on different definitions of “active”… Will pick this up, thanks.

1 Like
#17

Hi!
This was to say that we are preparing for a future when a billion accounts on Flow (storing an average of 1MB+ data) each would require 1 petabyte of storage. This would however be achieved by a mix of technical solutions (such as eventually moving current state from memory to disc to allow for such large state) and equally crucial economic solutions (like this one) to encourage users to economize on storage space.

#18

Hi, thanks for sharing your concerns.

  1. First, clarification - The account opening balance would be 0.1 FLOW (providing 10kB of data), which is closer to 0.1 US$ (at the current exchange rate), rather than $1
  2. I agree that txn fee should be increased too, and we are working on a proposal to implement that
  3. The idea behind the proposed change is to incentivize thoughtful data storage decisions, prevent state-exhaustion, and make Flow more secure by increasing the cost of attacks. I understand the 1000x increase in this proposal would impact some large accounts like yours (and like @bjartek pointed out previously), but I want to assure you that we are aware of this and would ensure the transition happens smoothly for everyone
#19

Hi, thanks for your comment.
+1, the current prices (and the cost to exhaust storage) are very low and non-competitive today, which was the key motivation behind this proposal.

#20

Hi, thanks for your comment.

I agree, there are many more things we need to do with our storage pricing model in the medium/long-term. Examples to consider include introducing cold storage vs hot storage and charging different prices for each, deploying Solana-type rent model, price discrimination to discourage mass storage or storage of useless data, or introducing a market-based pricing model where price is a convex function of capacity-utilization. In view of the research and engineering costs behind these mature solutions however, a linear pricing based on byte-size has been upheld and an increase in the price per data-unit has been proposed