feat: floor price set to the 0.06 USDFC/month

[rvagg]

Edit: This got switched to having 0.06 USDFC as the floor, not the bytes; so now the bytes works out as ~24.576 GiB and we get to talk about it in terms of cents per month.

(PR on top of #316, that should be merged first)

Amounts below this pay as if they are storing 24 GiB, which is 0.05859375 USDFC / month.

Closes: #319

---

• 24 GiB = 24/1024 TiB = 0.0234375 TiB
• At 2.5 USDFC/TiB/month, price = 0.0234375 * 2.5 = 0.05859375 USDFC/month

Are we OK with 0.05859375? I have an option here of either setting 24GiB as the floor size or 0.06 as the floor price.

If we go with 0.06 as the floor then we're working with 24.576 GiB floor size.

---

I also had to change the mock token from 6 decimal places to 18, cause there's already a floor rounding bit of code in here and it was getting stuck on a higher floor due to not enough decimal places, so everything came out wrong.

[lucaniz]

So,
the calculator shows that over 23 GiB size we turn profit positive, so that's what I was taking as the reference, and then took the rounded value for price.

Either way is fine tbh. We should pick the easiest route.

Maybe the easiest way to do so is setting the min price to 0.57 which is 23.35 GiB, which is also fine....

[lucaniz]

We can also set 0.5 and be covered againt a slightly smaller basefee max value (at the end of the day we picked the march 2025 avg because there were some oscillation back then, but it is better to come up with a fixed value, I think it won't make a huge difference)

[Kubuxu]

Is it feasible to add a check that the floor price rate is available to be paid when doing createDataSet? It would solve one of the problems causing: filecoin-project/curio#726

[timfong888]

My take away: if it's a minimum from which storage providers are paid as thing as used, this "top up" model is understandable and much better in $ units. I think it's probably better and clearer if it were a larger amount than a couple of cents. $1-5 is not unusual for top-up based usaged pricing models.

[rvagg]

Is it feasible to add a check that the floor price rate is available to be paid when doing createDataSet?

Oh, this is a really good idea, and yes it is possible! We have a getAccountInfoIfSettled on FilecoinPay that we can use to check their balance (if they were fully settled) so we can compare that with what would be needed for initial lockup and reject early. With create+add this is nice and clean. With create, then add, it's a little more messy and we lose guarantees but you'd just get rejected at add if you used up funds in between the two calls. If nextProvingPeriod gets done immediately after create+add then Curio should have a pretty solid guarantee that there is at least 0.06 on the table if they prove for a month, with a slight window for a possible race.

See latest commit in here for that feature.

[Kubuxu]

Does that also cover OperatorRateAllowanceExceeded?

[rvagg]

Figured out how to add additional checks in there. I'm of two minds about this, mostly it's great UX, we catch errors early and can be descriptive about it - good for SPs and good for users. But it also adds complexity and gets FWSS more deeply involved in something that it feels like should be something should be able to ask Filecoin Pay to figure out for us. But it's probably fine.

• InsufficientFundsForMinimumRate - not enough deposit
• OperatorNotApproved - need to approve FWSS
• InsufficientRateAllowance - not enough approval for the minimum rate (0.06/month)
• InsufficientLockupAllowance - not enough lockup approval for minimum rate @ 30 days
• InsufficientMaxLockupPeriod - not enough lockup period approval for the 30 day lockup

[Kubuxu]

But it's probably fine.

We will be able to remove it when we combine createDataSet and initial nextProvePeriod.

[Kubuxu]

SGTM

[Kubuxu]

I'm going to merge it as is, if we want to improve stuff just a bit, let's open a new PR.