FLIP 66 - Revisiting Flow storage minimum account balance

Hey, is there an update you can share?

It was very promising to finally see some quality engagement from Flow with its community, would be great to keep the momentum going!

1 Like

Hi everyone, brief update - we’ll soon be publishing the next FLIP (revisiting transaction fees) so folks could review, discuss and vote on the two FLIPs together. Thanks for your patience, and look forward to your continued participation :slight_smile:

1 Like

Hi everyone, thanks for your critical feedback on this proposal. We are now taking this proposal live for on-chain voting and democratic deliberation by the community. Please cast your vote on CAST between today and 05/22 (until 22.00 UTC). Reach out to me on discord (KshitijChaudhary-FLOW#8777) or here on forum if you have any questions regarding casting a vote. Thanks for helping shape the economics and future of Flow!

1 Like

Should we highlight this matter on Discord and Twitter?
I think it’s important, but there are few people here.

2 Likes

Highlighted in Telegram groups, should be better to announce it in discord & TG announcement channels.

2 Likes

Hi everyone, after careful consideration, we decided to postpone the two Tokenomics proposals. In the interest of ensuring a well-informed and inclusive decision-making process, we believe the community would benefit from additional dialog. I’ll be in touch soon regarding next steps and seek your feedback. Thanks for participating in the economics and future of Flow!

2 Likes

I want to express my concerns about how the FLIPs are being proposed and processed because I feel they are not giving voice at all to what the community expressed here on this forum.

The FLIP has not been changed at all from how it started, and it there is no direct link to this forum post where so many great feedback was given by the community. It feels there is a total disconnect from what is proposed and how the people think it should be handled, and there is no easy way for people to consider all the different opinions before making up their minds before giving a final vote to it.

In this way it will eventually disillusion people and discourage them to even participate in the discussion since it feels that regardless of what people express, the direction and the final decision has already been taken and that we just have to adapt to it in some way or the others.

I could recap the main points highlighted above but I don’t really see the point and it would feel like a broken record playing without being heard by the people taking the decisions.

Please note that I don’t want to force my point of view in any way, but I think that it would be fair to at least acknowledge the concerns and reply to them with some kind of alternative solution maybe, instead of just reiterating the same concept without alteration until it will eventually gets approved when maybe people will not pay enough attention or when they will just not have any more energy to fight for it.

I truly believe in the future of FLOW as a blockchain that should be governed by the whole community, but I feel that we have a really long way to go on that front.

3 Likes

Hey @luca - thank you for your valuable feedback - really appreciate your engagement and commitment to the community.

  1. I apologize for any oversight in cross-linking the FLIP and the forum post – this has been rectified for clarity
  2. I want to clarify that this FLIP has indeed undergone changes. The initial proposal for a 1000x increase was revised to a 100x increase following feedback and discussions within the community consultation call held on Feb-15-2023
  3. Please note that this FLIP is a proposal by me - a community member - and thus nothing is final or set in stone. In view of the diversity of stakeholder feedback, the community had decided on the consultation call that this FLIP will be put to a public vote. I hope to be able to take this to vote next month and members who hold reservations about this FLIP are encouraged and welcome to express their stance by voting against its adoption.
  4. I’d like to highlight that the FLIP process is completely decentralized, transparent and open for all; like me, any community member can propose a FLIP and share a documented alternative strategy to resolving the state bloat issue with the entire community. I’m happy to help with the process should anyone require guidance.
  5. Regarding offering alternative solutions or addressing implementation challenges, I acknowledge that I have not fully covered these aspects. Originally, I viewed this FLIP and its implementation as distinct proposals that should proceed sequentially. Although I maintain this perspective, I recognize the importance of facilitating the community’s decision-making process during the vote. Therefore, before I take this proposal to vote, I will share how we would plan to implement this change if it were to be approved by the community. And if the proposal is passed, of course, I will dive deeper into the implementation details and share them in a separate doc.

I’d encourage everyone to share the specific implementation-related questions that you’d like answers to before you cast a vote on this proposal; feel free to omit those questions already shared in the comments above :slightly_smiling_face:

Thanks!

1 Like

I want to add my concerns about voting, or in particular any voting on any FLIP and FLIP process in general.

First of all voting is a joke; last vote we had ( CAST ) and only one so far I think, had 71 votes only.

  • Total Flow calculated for votes was ~5145 FLOW
  • If we remove ~0.00% votes from the list ( people with tiny balances / just voting to try Cast ) we end up with: 45 votes with total 5143 FLOW
  • From this 45 votes (pasted below)
    – if first 3 agrees on something they have > 50% vote. (with just ~2650 FLOW )
    – if someone has with current FLOW price it is: ~1450 USD**

Total supply of FLOW is 1,450,656,993 and we are getting critical decision based on 2650 FLOW, which is 0.00018268%

Process is far from decentralized unfortunately.

Breakdown of votes (>0.00%)

FLOW Percentage Address Vote
1315.84 25.58 0xc187e81507f1b960 Accept
818.52 15.91 0xc0597793abff95ba Accept
520.51 10.12 0x7c9291ad93155ad7 Accept
403.98 7.85 0x7348427108d74bf1 Accept
306.29 5.95 0xa124ae05d0ce2a6f Accept
211.93 4.12 0x228c770aa47b20d0 Reject
200.55 3.90 0xfcddbc5ac1b0469f Accept
184.56 3.59 0x69e2712cd194cbf2 Accept
183.38 3.56 0x27643308ee0b0dfb Reject
150.00 2.92 0xa8d3fffaa242a20c Accept
120.36 2.34 0xe74bf2893ac8670c Accept
117.48 2.28 0x8ef86aa243189552 Accept
109.37 2.13 0x256827f6bca0296d Accept
69.80 1.36 0x73e4a1094d0bcab6 Accept
69.25 1.35 0x264017edac92fa08 Accept
59.25 1.15 0x886f3aeaf848c535 Accept
44.03 0.86 0xb30a220475c956ad Accept
38.03 0.74 0x6b79fb9b4a394a17 Accept
34.97 0.68 0x11ca36743554b4b0 Accept
33.00 0.64 0x19d2c747e331e55b Accept
30.08 0.58 0x3c629bdf814d1109 Accept
22.70 0.44 0xda15e70dc1552287 Accept
17.42 0.34 0xbf9acaa0b935d9cd Accept
15.57 0.30 0xf155a0f5d826f00d Accept
14.48 0.28 0xbe6b0c85814d652c Accept
12.92 0.25 0xc057f1032aa4713e Accept
7.93 0.15 0x48dc5aed9d1fa9f7 Accept
6.00 0.12 0x6ffeeb03c349714d Accept
3.89 0.08 0xac54bfd0559964e7 Accept
3.28 0.06 0xa86638a220ebd0f2 Accept
3.02 0.06 0x2cc26629902a733f Accept
2.97 0.06 0x39911c57ed3b4084 Accept
1.40 0.03 0x03a176e1cd35144c Accept
1.37 0.03 0x90bd6b4845e310a0 Accept
1.19 0.02 0xf6337be8d00d3950 Accept
1.18 0.02 0x01d63aa89238a559 Accept
1.11 0.02 0x1791697236df7056 Accept
1.00 0.02 0x8971f163d111cfcd Accept
0.94 0.02 0xe80cacd47f14ae13 Accept
0.87 0.02 0x4b19cd7fad04b1b5 Accept
0.79 0.02 0x54f599b469ecc46d Accept
0.78 0.02 0xde1718fa1dcbc8d8 Reject
0.69 0.01 0xccd1db61a9714329 Accept
0.64 0.01 0xb3b38499cc309832 Accept
0.40 0.01 0xd8678a06f1fb5456 Accept
1 Like

About @luca 's concerns:

I totally agree with them, I stated them:

Apr 5, 2021

Jan 31, 2022

and also on this forum post (again) with 2 alternative proposals, both of them didn’t get any attention. ( Tbh I gave up after one of them celebrated 2nd birthday )

Also alternatives are many times proposed; like writer of the resource pays, destroyer of the resource redeems the storage fees

It is not much we can do as community if there is no response from FLOW team on this issues. I mean writing FLIP is not an easy process, and tbh I don’t want to waste my time on this before there is a discussion before, or worse it’s fate will be decided with 1400 USD ( my cost of even writing is FLIP is higher )

1 Like

Hi @kshitij.chaudhary ,

Thanks a lot for your reply and for adding the link to this forum post in the FLIP so that people will be able to get more informations before casting their vote.

I also didn’t notice that the increase was reduced from 1000x to 100x but I think that change is really almost irrelevant considering all the points raised in here and the consequences it will have.
To me it’s not really a discussion about how much it should be increased by (even 1000x could be fine!) but more on how things will be handled once the change is approved.

What is important to me is to discuss and go into more details about some points like the following

  1. Let’s suppose that the vote goes through and the storage limit is increased, how many wallets exactly will be affected and will be blocked until they add more FLOW into it? And what would be the possible ways for them to unlock them and to add more FLOW to their account? Can they swap USDC to FLOW on Increment.fi for example or will any transactions fail until they receive it from some other account? (Would the only solution for them to buy FLOW on some CEX and then send it over to their account?)

  2. I feel there should be some grandfathering plan for the accounts that will be affected, otherwise it would feel like they have been tricked in some way. They spent money to buy NFTs, but now they can’t use them or do anything with them, unless they add more money into it. It wouldn’t be fair and would be like an unilateral change in the terms and conditions that they are forced to accept and pay for it. Since the amount of wallets and FLOW needed to cover for all the existing accounts wouldn’t be too much, it would be much better to automatically send enough FLOW to any account that has exceeded the storage limit (within reasons of course).

  3. What were the original reasoning behind setting the storage fee so low in first place and why are we changing direction now? I know the reasons behind it, but from a user perspective how does it look? Was it just a big mistake in first place, or was just a way to trick users and developers to join the blockchain and then, once they are locked in, to force the change? What was the original plan behind it all? Personally I chose to develop Flovatar on FLOW especially because I could store more data on-chain than other alternatives, so it was deciding factor. If the plan is to keep increasing them to eventually align with every other blockchain (even gradually), it would be important for me to know, so that I can decide if and how to develop the next things I will create for the eco-system.

  4. You are comparing the current storage costs with other blockchains, which is totally reasonable, but I would also consider that those other blockchains, as far as I know, didn’t change their storage fees along the way like you are proposing to do now. This means that their users and developers knew it from the beginning what the rules were and how they should behave in order to have enough storage. In our case we are making a change after the onboarding and for this reason it should be treated differently and for this reason a direct comparison is not possible in my opinion.

  5. I agree with @bluesign that we really need to improve the voting system and involve the community much more both in letting people know about it (participants should be in the thousands and not so few like last time) but also in the development of the next version of CAST. And Ideally everything should be managed in that single place (proposal, discussion and voting). So that people won’t need to go in many different places to follow up all the things related to it. Right now I would have to go to Github, write here on the Forum, check Discord as well (where many great things have been said on this subject and that I fear will just be lost easily) and then finally go to CAST to vote. I think it’s not the right way to handle things and we can improve it considerably by centralizing everything in a single place.

  6. I think it should be a hard requirement for any FLIP to include real-life examples to show how the change should be handled with concrete Cadence code. For example in this case it would be nice to know what and how is the best way to educate people about their storage usage and how certain cases should be handled like sending a simple NFT as a gift to a new wallet. Until now we wouldn’t really have to worry about storage, but with this change we should send before some FLOW and then the NFT so that the storage will be big enough to accept it.

I want to conclude by reiterating that I don’t want to fight this proposal just to defend my position, and I totally agree that to be sustainable on the long run some kind of change is definitely needed, but I just want to make sure that we all think this through properly and consider all the side-effects that it will bring. It is not just about finding the right number (10x, 100x or 1000x), but most importantly how the change will be handled by the Flow Foundations and what the users and developers will be required to do.

Thanks again for your reply and looking forward to continuing the discussion with as many developers and users as possible!

1 Like

Thank you @luca @bluesign for chime in. What would be from your point of view the best way to move forward ? Should we try to find a consensus (through the forum, github, discord ?), and put the proposal for vote, or bring several proposals for voting, and request to reach a quorum before approving a proposal ?

The lack of having a quorum in approving proposals is clearly something we need to put in place imho

1 Like

Hi @Redallica ,

In my opinion we should try first of all to centralize the process as much as possible and have all discussion happen in a single place/platform/website (hopefully the new CAST voting system?), so that people won’t have to jump between many different places (github, discord, forum) to put all the pieces of the puzzle together, or even worse to miss important parts of the conversation all together.

Once we achieve that, we should let people decide what direction they think is the best one to take: a) keeping the storage fees attached to the account or b) change it to being linked to the actual NFT (or resource in general) during the creation process so that it can be returned once the resource is destroyed (or maybe even an option c) that we didn’t think about yet!).

Once we decide which direction is the best one, we should then move forward with it and have a discussion in more details about how much the storage fee should be increased (10x, 100x, 1000x) and more especially about the strategy and general plan on how to execute it so that it will affect the existing users and developers the least (grandfathering current accounts, communication channels to educate people about it, Cadence code examples, etc.).

I know that there is a ton of work behind it, but I feel that if we manage to handle it properly it will benefit greatly the Flow Foundation and will serve as an example to make all future proposals more transparent, solid and something we should be really proud of having achieved!

1 Like

Hi all - Based on the questions and feedback on the 100x storage fee FLIP received over the past few months, gathered from forum, Discord, and the community consultation call, I’ve compiled a list of FAQs and integrated them into the FLIP document itself. Please take some time to review them and share your thoughts.

1 Like

Crossposting here a new formula:

My formula is a bit simple:

Account cost is same as FLIP 66 ( 0.01 FLOW as part of the account-creation transaction (1) ) but instead of giving 10kb, we give 100kb.

so technically we give 90kb bonus to each account: storage_available = 90kb + FLIP66 formula

This way we guarantee that we almost don’t affect any current accounts ( %99.9 instead of %95 ) and avoid high account-creation cost.

as I mentioned before: Top 20 accounts with 75GB storage counts for 35% of the state ( which is around 205GB ) Considering there are approx 20M accounts , they are like %0.0001

The main reasoning here is: we don’t actually want developers to keep less data on NFT, we want to just punish developers for excessive pre-minting ( in one case it is like 100 million pre-minted NFTs )

As you stated (2) , 95% of accounts anyway using <10KB storage anyway, where they have 100kb limit now, they will keep using 10kb anyway.

I think ideal solution is the one that makes developers to change behaviour than make regular user to take some action.

2 Likes

I like this tweaked formula @bluesign, thanks for suggesting this.

A clarification -

Storage fee today = 0.001 FLOW/ 100kB

After change (FLIP66 with tweak)

  • Minimum requirement = 0.01 FLOW, but gives 100kB (instead of 10kB that’s current proposed)
  • Thereafter, charge @ 0.1 FLOW/100kB or 1FLOW/MB

What’s confusing to me is “90kb bonus to each account”. Should this bonus apply only to accounts with storage <=100kB; and for accounts that already have >100kB, there should be no bonus? Or do you think this should apply to everyone - so someone who has 1 FLOW in their account has storageAvailable = 1MB + 90kB?

For example,

  • If I have 50kB stored, I’ll pay the minimum requirement, i.e. 0.01 FLOW, that gives me storageAvailable up to 100kB. Understood
  • But if I have 200kB stored, will I be required to have 0.01 FLOW + 0.1 FLOW = 0.11 FLOW, or just 0.01 FLOW (for the first 100kB) + 0.01 FLOW (for the last 10kB after 90kB bonus) = 0.02 FLOW

Also regardless, how does everyone else feel about it? Please chime in :slight_smile:

1 Like

It should apply to everyone. ( someone who has 1 FLOW in their account has storageAvailable = 1MB + 90kB? )

  • If I have 50kB stored, I’ll pay the minimum requirement, i.e. 0.01 FLOW, that gives me storageAvailable up to 100kB.

0.01 FLOW = 10kB + 90kB = 100kB correct

But if I have 200kB stored, will I be required to have 0.01 FLOW + 0.1 FLOW = 0.11 FLOW, or just 0.01 FLOW (for the first 100kB) + 0.01 FLOW (for the last 10kB after 90kB bonus) = 0.02 FLOW

200kB - 90kB = 110kb → 0.11 FLOW

btw I think we can also relax that you can have less than 0.01 FLOW for legacy accounts. or we can just top up accounts < 0.01 to 0.01 for better user experience. but this is another topic.

( Ticketmaster has like 10M accounts, joyride 5M. I think those will hit hard with the change. 100k flow 50k flow respectively. even monetary effect is small, I think operational load to send tokens to this many accounts still a challenge. )

1 Like

Got it, thanks for the clarification. This does create a loophole though where if I want to store 1MB i can create 10 accounts, shard the data, and pay 0.1 FLOW total instead of paying 1 FLOW to have everything in a single account… Wdyt?

1 Like

I think we need to think not like people abusing for 1MB, but maybe 1GB-10GB or something. Then management burden will be much more than the gains. 100kb is actually really small when we think about one account using almost 100GB.

1 Like

That’s a fair point @bluesign. Waiting for others to jump in and share their feedback on this revised approach!

1 Like