FLIP 66 - Revisiting Flow storage minimum account balance

Governance FLIPs
#63

In all cases, someone would need to pay/deposit for the account storage fees.
This first question to answer imo is: do we need to keep sponsoring the storage fees ?
1- if the decision is to sponsor the storage fees, then it needs to be the case for all the Flow wallets in the ecosystem, not only Dapper Wallet. (and no, “we don’t want a world like that”). In that case, the best way to do it would be to use the ‘Ecosystem Development’ Flow treasury (32% of the Genesis Block) or Dapper Labs treasury if it makes sense
2 - if the decision is not to sponsor the account storage fees anymore, who then needs to pay/deposit for it ? users, dApps ?

What is sure is as @kshitij.chaudhary highlighted, the current account storage pricing is not competitive and is currently undermining the value it’s bringing (account storage doesn’t need to be free, and I believe anyone can understand that). Does it need to be x10/x100/x1000 ? probably the x1000 is too much for a price increase and this needs to be made in different steps.

After that came the question of what we should do with the payment/deposit for account storage, and here I believe that @TraderFlow and @luca bring some good ideas with the burning mechanism

1 Like
#64

@bluesign good points.

There is a contradiction between wanting to give ownership with Flow and trying to take it away with the Dapper wallet and it seems like Dapper is doing everything it can to monopolize users on their wallet. Old-web habits die hard.

The odds are against you if you try to compete with Dapper on their own chain. They would win whether the fees were high or low.

The FLOW token is currently just used to annoy new users. There isn’t a lot of stuff to purchase or sell in FLOW, but you do need 0.0001 to cover transaction costs. With the price increase it would at least feel that there is a use case for the token.

2 Likes
#65

Agree with that.

  1. The first thing to do is review Dapper Wallet. In this unfair scenario to the other wallet service provider together with Dapper’s web2 mindset, Flow will not succeed.
  2. if the decision is not to sponsor the account storage fees anymore, who then needs to pay/deposit for it ? users, dApps ?
  3. Discuss the increment of account storage fees and strategy.

`

#66

I agree with @bluesign that the various types of fees are confusing to most people, and that combining them into a single transaction fee would be preferable.

The transaction fee could be calculated based on the number of bytes written and the total number of bytes locked by an account.

@luca’s proposal to burn the tokens instead of recovering them when space is freed makes sense too.
The FLOW token price would more accurately reflect chain usage.

If we move forward with a single unified fee, per transaction, would that fee be burned?

#67

Disclaimer: I’m on the Flow team, but I wasn’t involved in creating this proposal and I am just sharing my personal opinions. These are also just my intuitions, so I may be completely wrong. :laughing:

Remember that this is still just a proposal, so nothing is set in stone! Everything is still up for discussion, so don’t think that the Flow team has already made this decision. We make decisions like this as a community. :slight_smile:

I agree that storage fees are not the best UX in the world, but the proposal to just add storage fee costs to transaction fees to pay when a resource is created for the first time is basically already how Ethereum does things, and that has clearly not stopped people from creating insane amounts of data. That is probably an argument for increasing the creation fees for resources, but I don’t think it is an argument for getting rid of storage fees. I believe Ethereum suffers from state bloat partly because there is no incentive to free up storage. If users can get FLOW back by freeing up storage in their account, then that encourages them to get rid of any useless data that they might be storing, which helps prevent state bloat.

Another comment in regards to the complaint about forcing the owner to pay for storage instead of the creator. In Flow, an account isn’t able to store an object unless it either explicitly stores it itself or has indicated that it is willing to store it by creating a public capability to deposit a specific type of object in their account. This is already different from every other ledger-based blockchain where all data related to a contracts are stored in the contract’s account, so it is hard to compare it to other chains anyway. I think having the storage deposit opens up more possibilities for wallet pricing and account management. Think of it kind of like using gmail or another hosted email service. When you sign up, you pay up front for a specific storage limit or you don’t and get the free limit, and you can’t go over that limit unless you either free up space on your phone or pay more for a higher limit. There are a bunch of really useful tools to help users free up space in their emails without thinking much about it. Presumably, there could be something like that for Flow accounts in the future that wallets can integrate. Users seem to be fine with this model for a lot of web2 services because they’re easy to use. I don’t see why we can’t have something similar for web3.

We would just need to get wallets, especially Dapper Wallet, to only pay for the account minimum balance for their users and make any further increases a paid option, but that’ll be difficult, but still possible! :wink:

Please be nice when telling me that everything I just said is wrong. :slight_smile:

1 Like
#68

Hi @all, can we meet at one of the following times for a further discussion on this? I can share the invite once we agree on a time. Thanks

  • 12 noon PST (3PM ET) on 2/14, Tuesday - React with :+1:
  • 9 am PST (12PM ET) on 2/15, Wednesday - React with :heart:
  • If none of these work but you’d really like to attend react with :frowning_face:
1 Like
#69

the problem is “state bloat” is “never” caused by active user. @kshitij.chaudhary shared storage sizes above, almost 90% of total storage is used by either empty/puppet/non-active accounts. Those users will never ‘pay’ for upgrade you mentioned, and they will never empty those accounts ( as they cannot get the minimum storage fee back ). But we are now suggesting to punish active users.

#70

Thanks @flowjosh for the great reply and for pointing out the Ethereum example when applying the creation fees for resources.

While thinking more about it, what if the creation fee wouldn’t be burned, but instead would be put somewhere in a special general vault?
Then if people will decide to free up some of their space by burning some old NFT, they would automatically receive the amount paid for the creation back to their wallet.
In this way, it could almost incentivize people or small projects to be “garbage collector” that would perhaps turn some profit out of it, while benefiting the whole blockchain with their service.

Moreover, it could be treated as a net zero-sum (amount paid for creation = amount paid back on destroy), but it could also keep a certain amount and burn it forever, as a general fee for using the network.

I think from a user point of view is fundamental to know that if he has 1.2FLOW in his wallet, he can spend 1.2FLOW on anything he wants. Having this uncertainty on how much extra will someone have to pay to use the things he buys will lead to terrible user experiences and to lots of confusion (1.2 FLOW + 0.1 FLOW for storage = 1.3 FLOW => TX failed).

It would make much more sense to still apply the concept of “staking” the FLOW for storage (instead of burning it), but I would just associate and tie it to the actual resource that generates that storage, and not the wallet that holds it.

Anyway, just throwing ideas around and I am happy that the discussion is bringing a lot of interesting point of views to the table.

Unfortunately I won’t be able on Wednesday, but in case it will be done on Tuesday I will be happy to join! @kshitij.chaudhary

#71

In the preceding scenario:

The transaction fee could be calculated based on the number of bytes written and the total number of bytes locked by an account.

A user will be penalised for bloating the chain.
The more data he stores, the higher the cost of his future transactions.
Because the FLOW token is decoupled from the storage cost, it can still be burned per @Luca 's suggestion.

Another method for removing unused data is to assign a TTL (time to live) to data stored.
When minted, tokens would have a predetermined TTL.
The initial fee for the TTL could be included in the transaction that creates the token.
Users would need to send periodic touch (as in unix touch) transactions to keep (some of) their data alive.

#72

Hi team, here are the meeting details. Hope to see you all there!

Community Discussion - FLIP 66 Storage Fees
Wednesday, February 15 · 12:00 – 12:45pm (ET) // 9:00 – 9.45am (PST)
Google Meet joining info
Video call link: https://meet.google.com/qtf-mkfp-oay
Or dial: ‪(US) +1 484-746-4248‬ PIN: ‪479 482 861‬#
More phone numbers: https://tel.meet/qtf-mkfp-oay?pin=9213308814584

#73

@kshitij.chaudhary isnn’t the timeslot supposed to be at 9:00 A.M PST ?

#74

Hey, yes. The time shown is in ET. Updated the post to reflect both time zones. Thanks and see you!

#75

@kshitij.chaudhary Can you post a recap from the meeting on wednesday? I wasn’t able to attend because I was giving a presentation for the hackathon

#76

Hi everyone. Here’s a brief summary of yesterday’s community discussion.

  1. Generally participants agreed that the fee must be increased; “it’s a no brainer”. Today, Flow storage fees are too low to prevent attacks and also superbly low compared to competitors. 1000x however might be too steep, and a phased/ staggered increase was proposed.
  2. The question of “who’s going to pay?” was raised. Between the four key entities, ie., Dapper Labs vs Wallets vs dApps vs End-users, Dapper Labs continuing to sponsor the fees forever is an unsustainable option. Account creation should be paid for by wallets, while dApps are likely to bear any additional storage charges beyond the minimum, or pass partial incidence to users eventually. However, it was agreed that this discussion can be kept open for now.
  3. The question of “what could be done with the fees” was raised. A burn-on mechanism was proposed, but given that Flow network does not (yet) “collect” the fee and simply ensures a certain number of tokens are kept out of circulation (controlling liquidity), the a burn might not be game-changing. Additionally, if the fees is in fact collected and/or burnt, how do we ensure a future where users could delete the data to unlock tokens?
  4. As next steps >
    a. FLIP 66 would be updated (by @Kshitij), recommending a phase-wise implementation, like a 100x increase instead of a straight 1000x increase. This would settle some concerns around the storage fees being a large proportion of a dApp’s customer acquisition cost (CAC) given that with the new proposal, the cost of creating an account would be about ~$0.01.
    b. A token-based voting mechanism on this FLIP and other econ/governance FLIPs was proposed - perhaps something similar to last year’s community voting on variable transaction fee on cast.fyi. This will be discussed further.
#77

@kshitij.chaudhary all great points but I think currently we dont suffer any attack, and we have long road to have this attacks causing any threat to system.

Maybe let’s not rush things, we wait for you to finish all economics model, including tx fee increase, storage fees final proposal, inflation percentage, flow token price prediction etc.

Maybe you give us a estimated time to model this economical system, we wait and evaluate as a whole?

Because I believe without having a bird eye view of a complicated economical system, we will not be able to see effects of the parts. I think there is a saying about blindfolded people describing elephant, I feel our situation is a bit like this.

There are a lot of topics waiting almost a year, like inflation rate, staking rewards adjustment etc. Rushing stuff doesn’t benefit anyone here. Storage fees comparing to inflation rate and tx fees very minor.

Btw I personally feel like you do what you decide, but you keep other stuff open for discussion always, but it never discussed.

we were supposed to discuss inflation rate at august 2022 , after flip on july 2022 decided to keep it at same percentage. But that conversation died out.

Tx fees after variable transaction fees are introduced would be discussed to increased and modeled, but it died out

1 Like
#78

That’s a good point, and actually, this is something we touched on a bit during our discussion on Wednesday, but no further action has been decided.
It would be great to have a broader view of the FLIPs related to protocol economics to understand the overall impact on the Flow ecosystem participants (wallets, dApps, users, …) before taking any final decision.

1 Like
#79

the discussion stopped here?

#80

Hi everyone, based on the feedback received and discussions over the last few weeks, the FLIP has been updated (same link) to recommend a 100x increase in storage fee instead of a 1000x increase. We plan to take this proposal to voting, but meanwhile, look forward to your thoughts and continued engagement.

#81

Very interesting discussion.

When will this be put to vote?

#82

When will the txn fee discussion be brought up?

1 Like