FIP-12: Pricing schedule for flexible storage #126
Replies: 9 comments 2 replies
-
|
"This is no longer the cast" --> "This is no longer the case" |
Beta Was this translation helpful? Give feedback.
-
|
Is there any discussion on how the paid rent funds will be distributed? Will they be used for Hub operator incentives or a general fund for all ecosystem development? |
Beta Was this translation helpful? Give feedback.
-
|
Find the fee was once mentioned in the doc.
Any changes since then? |
Beta Was this translation helpful? Give feedback.
-
|
Are we sure we want storage units to have an expiration date? I can see the argument that if you run a hub on rented cloud infrastructure, the cost of storage is a function of time. But it would be interesting to consider that storage units without an expiration date will incentivise hubs to run on owned infrastructure (which in my opinion is good for decentralisation at a higher level). An alternative (not sure its a good one, just bringing it to the table) is storage units that never expire, but provide lower quotas. |
Beta Was this translation helpful? Give feedback.
-
|
I obviously have in mind that at some point in the future, hubs may be able to get some revenue, which may not be the case. However, if we get there at some point in the very distant future, it would be good if we have set user expectations right from the beginning. |
Beta Was this translation helpful? Give feedback.
-
I like this |
Beta Was this translation helpful? Give feedback.
-
|
i'm a fan :) (also would be super super cool if warpcast throws in some free warps when we buy farcaster storage ❤️) |
Beta Was this translation helpful? Give feedback.
-
|
I'm always a fan of cheaper prices, and the proposal was informative and compelling! |
Beta Was this translation helpful? Give feedback.
-
|
💯 (this is a low effort reply) |
Beta Was this translation helpful? Give feedback.
-
Title: Flexible pricing for flexible storage
Type: Implementation FIP
Author: Varun Srinivasan (@varunsrin)
Abstract
We propose a simple system for adjusting the price of storage to strike a balance between making onboarding easy and reducing the amount of spam on the network.
Problem
Flexible storage (FIP-6) mitigates the problem of finite hub storage by adding a fee to store messages and limit to how many messages hubs must be able to store. The fee prevents users from broadcasting infinite amounts of junk data. The limit gives hub operators a predictable amount of space to allocate to hubs.
The limit is 200k storage units or ~ 20GB of disk space and the fee is $5/year per unit. As of today, 40k storage units are being rented. Our goal is to balance the limits and fees over time so that:
Specification
A protocol release must specify the new storage limit and corresponding disk space requirements for hubs. It must also specify a pricing schedule that raises the price of storage as supply dwindles to ensure that we never run out of storage before the next release.
The prices are also chosen to minimize the number of low quality users while maximizing the number of high quality users. This is more art than science so some trial and error may be necessary to arrive at the right values. Since changes must be triggered manually, they may happen slightly before or after these thresholds and they are rough guidelines.
Finally, we propose that the pricing schedules be updated in this document when they are finalized for each protocol release so that they are accessible in one place. The FIP will constantly be updated with the latest proposals at the time of each release and discussion can happen in the thread below.
Pricing Schedule for 2024.06.12 "Kangaroo" release
Currently we have 580k consumed storage units and an available unit limit of 600k. We made a mid-release adjustment to the storage unit limit on May 24, to 600k units. Storage growth has been sustainable, so we propose a larger limit increase. We propose:
Pricing Schedule for 2024.05.01 "Jaguar" release
No proposed changes to price or unit limit. If necessary, we will make a mid-release adjustment to the unit limit.
Pricing Schedule for 2024.03.20 "Iguana" release
Currently we have 258k consumed storage units and an available unit limit of 300k. We propose:
Pricing Schedule for 2024.02.07 "Horse" release
We propose reducing registration fees from $5 to $3:
Currently we have 82k consumed storage units and an available unit limit of 200k. We propose:
Pricing Schedule for 2023.12.27 “Giraffe” release
We propose reducing registration fees from $7 to $5:
Currently we have 65k consumed storage units and an available unit limit of 200k. We propose:
Pricing Schedule for 2023.11.15 “Fennec” release
Given a consistent usage rate of ~100 units/day we propose a more conservative increases in prices than the previous release.
Pricing Schedule for 2023.10.04 “Elephant” release
We don't understand usage patterns and propose an aggressive increase schedule to prevent the network from being flooded.
Rationale
Who is a low quality user?
Low quality users generate many messages which receive little engagement, except from other low quality users. The goal is to either qualify for a perceived airdrop or to sell their engagement as a service to others. Such users often add unrelated content into public discussions, frustrating well intentioned users by sending unnecessary notifications or taking up screen real estate.
Why worry about low quality users?
Our initial “request an invite” form received over 250k submissions and we estimate that over 95% of these are airdrop farmers.
Why are the prices multiples of $7?
Warpcast is the only app ready to onboard users today and requires in-app purchases with a 30% tax to apple. A $7 price translates to a round price of $10 which is psychologically significant. Making Warpcast pricing optimal for now will maximize users on the network, which benefits everyone. Users and other apps are always free to directly register with the contracts and pay $7. When other clients start onboarding users, optimizing for Warpcast will become a lower priority.
Why don’t we use a bonding curve or other mechanism to determine price?
Long term, we believe such an approach is ideal. The initial version of the storage contract was designed to be as simple and flexible, so that we can iterate quickly instead of being locked into a specific pricing model.
Release
These limits will kick in on the first date of permissionless (~ Oct - Nov) and not on 2023.10.04.
Appendix A: Disk footprint of a storage unit
A storage unit takes up an average of 40 kB on disk today. Most of this data was generated when we had time-based expiry, and older messages were automatically purged. This is no longer the case as of FIP-6 which was a recent change, so we expect the average size to increase.
The theoretical upper bound, assuming every possible bit of a message is filled, is 7MB for a storage unit. A more realistic upper bound, assuming normal usage patterns for an extremely active user, is closer to 2MB. Our best guesstimate is about 100kb per storage unit on average, though this is a very imprecise model and might change as the network grows.
Therefore we expect that hubs with 20 GB of storage will able to service 200,000 units. See Storage Math for more details on the calculations.
Beta Was this translation helpful? Give feedback.
All reactions