• SP posts a refundable data set deposit on createDataSet, currently 0.1 FIL. This replaces the old client-paid sybil fee (0.1 USDFC, burned).
• Client pays SP a one-time create data set fee of $0.00112, designed to cover gas (base measured gas x10).
• Deposit is locked until the data set is cleaned up, then the SP gets it back.
• Cleanup can't happen until the rail finalises, at least 30 days. So even if the SP terminates the day it's created, the deposit is locked for 30+ days.

Client griefs SP

Under this model there's a cheap griefing method: a client spends very little to make the SP lock a lot of FIL into PDPVerifier for 30+ days. FIL balances are visible on chain, so this is a simple DoS to drain an SP's wallet and deny anyone service by that SP. Requiring an addPieces alongside createDataSet (proposed as part of the pricing plan) only adds another $0.002, so the SP gets paid $0.00312 to lock up 0.1 FIL. A $100 client spend could lock ~3,205 FIL for 30+ days, if the SP holds that much, which they should for ordinary PDP operations. It gets worse as FIL rises: the locked FIL and the client's USDFC cost are both fixed, so the dollar leverage scales with the FIL price.

This isn't necessarily a rate of return problem. The SP gets the deposit back and the fee works out to roughly 38% annualised on the locked capital, which is fine in isolation. The problem is forced illiquidity: the SP can't use the locked FIL for operations (gas for proving), and the attacker controls the timing and scale. A good yield doesn't help an SP that's run out of spendable FIL.

If SPs experience this, the rational response is to get restrictive: require existing relationships, minimum spends, per-client or global rate limiting. That undermines a core goal of the pricing system, that being an FWSS SP should be a good deal most of the time.

Lowering the deposit is probably not the lever to pull: the lower it is, the weaker the incentive to clean up large data sets (where cleanup gas can exceed the deposit). Per-piece or per-byte deposits change the accounting but not the leverage; byte size also disconnects the deposit from its clean-up purpose.

SP griefs client

The reverse vector exists if the create fee is paid to the SP. A bad-actor SP collects the upfront fees, never provides service, and the client's only recourse is to terminateService and walk away. Per client it's small (create + addPieces + the terminate fee the client pays on user-initiated termination + maybe gas for terminate submission), but farmed across many duped clients it could add up.

It's weak on its own: the SP locks their own 0.1 FIL per data set and needs a real client signature each time, so the return on their locked capital is poor and it doesn't scale without lots of victims and reputation cost. Requiring addPieces atomically with createDataSet also removes the "take fee, refuse to add pieces" variant. But it sharpens the design question below.

Burn a client deterrent, pay only the gas-related fee?

The two vectors pull the same way. Client griefing wants the client's cost high; SP griefing wants the SP's revenue low. The client pays the cost either way, so client griefing is deterred whether the charge is burned or paid onward. The deciding factor is the SP side: paying a raised create fee to the SP creates the fee-farming incentive, burning it removes it.

So split the charge by purpose:

• Gas reimbursement to the SP: stays paid to the SP, kept small and matched to gas. Not farmable, the deposit lockup dwarfs the x10 padding.
• Anti-griefing surcharge: burned. Sized to make client capital-locking uneconomic. Pure deterrent, neither side profits.

Same logic applies to the terminate fee: cleaner burned than SP-paid when the client is the terminator, since escaping a bad SP shouldn't pay them.

Bonus: the original pricing design still has the client-paid Sybil fee, that was removed late in the design phase, so we can just keep it with a cost of $0.10112 to create a data set.