FIP: Storage Redenomination

[varunsrin]

Title: Storage Redenomination
Type: Implementation FIP
Authors: @v, danromero, sanjayprabhu, dynemyte, horsefacts

Abstract

A proposal to lower fees to get closer to “practically free signups” for Farcaster.

Problem

Farcaster’s growth is being held back because new users have to pay the $2 storage fee. Warpcast sees a ~50% drop off of users on the payment screen. Fees are unfortunately necessary to prevent spam, but ideally they would be much lower.

A good long-term target for storage fees is ~5c. This is roughly the cost of a phone verification and TikTok and other apps have onboarded billions despite having to pay this fee. If we are able to get closer to this price apps can offer “free onboarding” by paying the cost of signup for users who pass some sybil checks.

Fees are high today because hubs have limitations on how many users they can handle. With the move to Snapchain, we should have 2x higher throughput on day one with head room to grow to 10x higher throughput over time. Therefore, we should be able to reduce signup costs and get a lot closer to our 5c target.

Specification

We propose reducing the cost of storage units by 10x. Each unit will cost only $0.20 which is the only fee a user needs to pay to start using Farcaster.

We also propose reducing the size of each unit by ~8x. This gives us further headroom to lower the cost of storage to 10c or maybe even 5c over time. These limits are chosen so that > 90% of new users will not exceed the limits within their first 3 months of usage. These changes only apply to units rented after this proposal goes live.

We also propose adjusting the ratio of different message types to reduce the probability that a user hits their limits soon.

Type	Current Limit	Proposed Limit
Casts	2000	100
Reactions	1000	200
Links	1000	200
UserData	50	25
Verification	25	5
Username Proof	5	2

We also propose reducing the rate limits for newer storage units as well as legacy storage units. The current limits for legacy units are extremely generous and malicious actors could collude to flood the network. Most real users will not exceed these proposed rate limits.

	Rate Limit (msgs/day)
New Units	200 * num_units
Legacy Units	2000 * num_units

As part of this, we're also proposing to extend the existing storage units by 1 year to defer expiry. This will allow users to continue using their existing units without having to re-purchase. Snapchain still has plenty of scaling headroom, so expiry is not required.

Rationale

Why not introduce a “free” tier?

An alternative approach is to charge no fee besides the onchain fee and give users some small unit of storage. The problem with this approach is that the unit is likely too small to be useful to a regular user, but efficient enough for spammers to attack the network.

Release

Release Snapchain version 0.4.0 on or before 2025-07-11 with changes taking effect one week following the release with updated storage denominations for users. The new limits will only apply to storage units rented after 2025-07-16 17:00 UTC and will be valid for one year (31536000 seconds). All older storage units will continue to have the exact same limits as they do today and will be valid according to the rules that were in place when they were originally acquired.

Appendix A: Modeling Impact

We sampled a four month period earlier this year and try to model the impact of fees based on observed behaviors. During this period 118,000 accounts signed up, paid $236,000 in fees and added roughly 17.5GB of storage to each node. It’s worth noting that any such modeling is a rough estimate at best given the dynamic nature of our system, and we should bake in safeguards if the model turns out to be incorrect.

Bandwidth Impact

We did not have a mechanism to measure the amount of bandwidth usage, so the only modeling here is the limit case. Snapchain is expected to support up to 9,000 TPS and each storage unit gives users the ability to submit 200 messages per day or 0.0023 TPS. In the worst case where every user is maxing out their limits we can support 3,000,000 plus accounts. A more realistic case is that we will be able to support 5x to 10x that number.

Storage Impact

One way to model storage is to assume elastic demand — a 10x reducing in price means a 10x increase in signups and usage. So we would add 175GB to the network over a four month period which snapchain could easily sustain.

Another way to model storage is the limit case. Snapchain nodes are expected to grow to approach the largest disk drives available on cloud providers which is roughly 31 TiB. Each storage unit with average utilization approaches 120kB, so this would allow for almost 300 million storage units to be rented.

UX Impact

We estimate that if we reduce the storage limits as proposed only about 7% of users would have reached these limits. In most cases this is reasonable — the accounts are programmatic and outputting a large number of casts and its reasonable to ask them to pay or to prune their oldest messages. In a few cases it may lead to a less ideal user experience as a new user has followed many people on the network and cannot add any more. In such cases, the user will have to pay the fee or the app will need to do it on their behalf.

[netnose]

I still feel like the proportions of casts, reactions and links are not a good fit. What is the actual proportion of currently stored casts vs reactions?

[varunsrin]

What would you want the proportions to be?

[netnose]

I got some data from dune. I don't know how accurate it is, you have better data for sure.

type	fids	count	avg
like	614479	586336669	954
recast	448665	133219358	297
link	795311	185598681	233
cast	631779	248768461	393

In this case reactions are 4x the casts on average.
I also looked on different accounts, reactions storage is often used at 100% way before the others.

[vrypan]

I have a concern about rate limits: Restoring an account state (for example, deleted signer, or user did not pay to renew storage) requires 1000s of messages to be sent. How do rate limits affect this? What can we do?

[sanjayprabhu]

When we move signers to snapchain, we can make it free as well as make deleting messages optional when revoking a signer. That should be a big UX improvement over what we have now and eliminate this problem for most people.

As for restoring account state, we could offer a dedicated api to bulk submit messages one time when you register a storage unit. It hasn't been a problem since we haven't had any storage expire yet.

[vrypan]

I totally agree and looking forward to signers improvements.

Until now, the problem did not exist: I could submit 5k messages to my hub one after the other, and they would propagate on the network. So, I could easily restore a backup created using http://github.com/vrypan/fcp

I would like to be able to do so the same on snapchain. For example: I maintain storage holding 2k casts, but over the years I have posted 10k casts. Then I decide I want the whole history to come online, I pay for 100 storage units (100x100 =10,000), and I want to upload my backed up archive. I should be able to do so.

Actually, based on the rate limits posted, I will be able to post 200x100=20,000/day so it sounds ok. Are these limits enforced be minute too? For example 20,000/24/60/minute? Or are they per 24h window?

[andrei0x309]

I agree that not deleting data when removing a signer is a great UX improvement, probably one of the best that involves signers, and I have pushed for that repeatedly.

I mentioned that it makes sense to move the signer to the network itself instead of the OP chain, mainly for performance, as the network will not need to sync with OP. However, I don't think it is a huge priority.

After all, the cost of creating or removing a signer most of the time is below one cent; it is only higher on Warpcast because people pay in Warps a fixed value that exceeds the cost of doing the transaction on-chain.

[andrei0x309]

I think it's great to reduce the barrier to entry. I know the value in USD is set at the contract level and is currently 2; in case this goes forward, a tx should be made to also change that to 0.2.

Indeed, 20 cents is quite low for an account, and it will be interesting to see how it goes.

While I think that the new values for a storage unit are quite low, I don't see a huge problem with them.

The concern is that most users will roll their storage and create poorer graphs.

I do think the network should just reject people who exceed the storage limit instead of rolling the data, as this alters graphs in an unfortunate way.

People should delete their data themselves or buy more storage to ensure graph data is intentional.

The 200 rate limit is very close to how most traditional networks work, like Instagram, X, etc.

With that being said, I find it quite low.

While I agree that 2000 can be abused, 500 would have seemed more appropriate to ensure you accommodate legitimate edge cases.