Pre-GA review: Sybil fee cost burden and abuse vector

[rvagg]

I'm putting this in an issue because it's come up again. I don't really want to open old arguments, but I'd like to record this so we're all clear about the behaviour (it turns out we're not all clear) and maybe just have a discussion before GA and agree that this is OK for now, or we might need to apply some mitigation.

The PDPVerifier contract charges a 0.1 FIL sybil fee on dataset creation, which is burned to prevent spam and protect the contract's state from bloat. This fee was introduced as an anti-spam mechanism, modelled on concerns around Filecoin miner actor creation spam (and the new creation fee there).

However, the fee creates an economic disparity in the current architecture. The storage provider pays this fee when calling createDataSet, but dataset creation is initiated by a client signature sent to the SP's HTTP API—essentially free for the client. The SP has no direct way to recover this cost since the sybil fee exists at the protocol layer (PDPVerifier), which has no awareness of payments or client relationships. FWSS does validate that the client has sufficient funds and operator approval during the createDataSet callback, but this check is not binding if the client never adds pieces to the dataset.

The minimum storage fee floor of 0.06 USDFC per month (introduced in PR #320 to ensure small datasets remain economically viable) provides some mitigation. At current FIL prices, the sybil fee is recoverable in a few months from a floor-paying dataset. However, the sybil fee is denominated in FIL while storage revenue is denominated in USDFC, creating exchange rate risk. If FIL appreciates significantly, the payback period extends proportionally - at $5/FIL it would take 8+ months, at $10/FIL over 16 months.

There is also a potential abuse vector where a malicious or careless client could cause an SP to create many datasets, each costing the SP 0.1 FIL upfront. The floor price validation in FWSS ensures clients have funds to cover storage costs, but the sybil fee is already burned at the PDPVerifier layer before FWSS callbacks run. Empty datasets generate no revenue at all since they require no proving, though closing the empty dataset creation path could mitigate this—meaning that clients would have to pay at least one month of floor price. Recall that we have a createDataSet+addPieces combined flow that we use via the SDK by default now, but we left open the createDataSet(only) functionality so you have something similar to S3's bucket creation where a bucket exists but can be empty.

The concern is that this dynamic may push SPs toward being selective about which clients they onboard, particularly if FIL price increases or if they anticipate high client churn or we see a pattern of client abuse or just wasteful behaviour because the client doesn't feel the impact. The sybil fee serves a legitimate purpose in preventing state spam, but the current setup places the cost burden on the party who has the least control over whether a dataset is created.