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!
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!
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
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!
Should we highlight this matter on Discord and Twitter?
I think itâs important, but there are few people here.
Highlighted in Telegram groups, should be better to announce it in discord & TG announcement channels.
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!
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.
Hey @luca - thank you for your valuable feedback - really appreciate your engagement and commitment to the community.
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
Thanks!
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 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 |
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 )
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
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?)
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).
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.
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.
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.
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!
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
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!
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.
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.
I like this tweaked formula @bluesign, thanks for suggesting this.
A clarification -
Storage fee today = 0.001 FLOW/ 100kB
After change (FLIP66 with tweak)
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,
Also regardless, how does everyone else feel about it? Please chime in
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. )
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?
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.
Thatâs a fair point @bluesign. Waiting for others to jump in and share their feedback on this revised approach!