Fleetmesh fleetmesh

design note · storage settlement · § Grants & receipts

Retrieval-Based Storage Settlement

Analysis of storage settlement: why fees apply to discrete retrieval requests rather than ongoing retention.

Verdict

Storage settlement is deferred on the same terms as transit. Discrete retrieval is the only operation in the storage plane that carries a fee.

The reserved settlement tag remains none, and blob_bytes remains a flow limit defaulting to zero. Alpha telemetry measures actual storage usage to inform future revisions.

The structural argument

Storage economics compared to transit and compute

In § Grants & receipts, transit settlement is deferred because it represents continuous, fungible traffic. Compute functions effectively because it is discrete, specified in advance, and concludes at a defined moment of completion.

Storage represents a stock rather than a flow. Byte-months are countable across hardware, yet storage obligations lack a natural moment of completion.

A compute job completes upon output delivery. Storage requires ongoing retention over time.

TRANSIT continuous · fungible · no natural boundary COMPUTE payment reveals k discrete · priced in fuel · terminates STORAGE bytes accepted no right-hand edge continuing obligation · nothing to settle against time
The compute market settles at a point. Transit has no point, which is why it was deferred. Storage has a start and no point at all — the obligation runs off the edge of the diagram, and that missing right-hand edge is the whole problem.
The three economic objects, against the criteria the spec already uses
Property Transit Compute Storage
Shape Flow Discrete act Stock — a held position
Natural unit weak bytes, but priced against an unmeasured curve yes fuel yes byte-months
Moment of completion none yes none, by definition
What a buyer is buying Headroom An output hash A promise about the future
Obligation after payment Ends with the window Ends on delivery Never ends
Verifiable without trust receipts subject-signed, hash-chained re-run it needs proof-of-retrievability
Status Deferred Shipped Deferred — harder

Applying the existing rules

The three invariants already answer this

§ Grants & receipts constrains any future settlement mechanism in advance. Point each rule at storage and it fails — the first one fatally.

RULE 1

Payment may raise a ceiling, never establish a floor.

Apply it literally and paid storage self-destructs. What would a paying peer receive? A higher blob_bytes ceiling — the right to push more bytes at them. That is a transit product with extra steps. The entire value of a storage purchase is the floor: you will still have this in six months. The one thing forbidden is the only thing anyone would be buying.

Fatal — nothing coherent left to sell

RULE 2

The severity ladder is never suspended.

Under transit, revoking a peer stops traffic without residual cost. Under storage, an S4 deletes the grant while data remains on the disk of the revoked peer. The ladder operates independently of commercial positions.

Remedies operate independently of payment

RULE 3

Obligations do not require issuer arbitration.

Continuous retention over time creates an ongoing dispute surface regarding retention duration. Atomic wire settlements cannot prove future retention at the time funds transfer.

Dispute surfaces remain bounded

Verification and dispute boundaries

Coverage is verified by sampling: missing event IDs provide evidence for an S2 report. Reputation proofs tolerate false negatives because withholding is detected over successive windows. Commercial storage contracts require deterministic proofs, creating unnecessary arbitration complexity.

The economic argument

Reciprocal coverage benefits both peers

A peer asserting completeness: asserted over a shared shard serves local queries from it, earns standing, and advertises it in kind 30803 to attract peers. Shard replication provides mutual benefit to both participating nodes.

Charging ongoing retention fees for data both parties choose to hold creates artificial overhead. Mutual replication balances naturally upon shard declaration.

Asymmetric cases

Non-reciprocal storage scenarios

Three specific scenarios exhibit asymmetric storage requirements:

Default settings

The sample grant sets ["limit", "blob_bytes", "0"] by default, and blob_bytes does not appear in the tier ceiling table. Carrying binary blobs remains optional for all node tiers.

Text event storage requires minimal disk capacity: a community shard for a year consumes megabytes of space. Pricing text storage introduces unnecessary protocol complexity.

The constructive shape

Retrieval pricing provides discrete settlement

A retrieval request is discrete, has a defined moment of completion, and reuses the escrow-free construction from § Compute market. The payload is sealed under a payment hash, and payment reveals the decryption key.

01 Request names a CIDContent-addressed query ensures the buyer specifies the exact payload before transfer begins.
02 Holder quotes a priceRate quoted per byte served. Objective and comparable across holders.
03 Payload sealed under a payment hashEncrypted to key k; the invoice payment hash is SHA256(k). Equivalent to the sealed result in the compute market.
04 Payment reveals kDelivery and settlement conclude in one step without escrow intermediaries. The buyer verifies payload bytes against the CID.

This model requires no continuous proof of space-time. Proof is verified by producing bytes on demand. A node that discards data cannot fulfill retrieval requests or earn retrieval fees.

Retrieval settlement keeps compute and storage payments separate from standing. An operator with disk and CPU provides services without purchasing reputation.

Second-order risk

Impact of retention fees on coverage signals

Coverage declarations under completeness: asserted indicate local store completeness. Commercializing retention incentives over-claiming to attract fees, complicating verification sampling.

Coverage claims function as reputational signals. Coupling claims with commercial storage fees distorts reliability metrics across the network.

Recommendation

Telemetry and measurement

Transit settlement records whether grants bind and which limit binds first. Storage telemetry tracks four metrics during the alpha period to inform future specifications:

{
  "kind": 21802,
  "tags": [
    ["metric", "shard_bytes_held",   "p50:8388608", "p95:134217728"],
    ["metric", "coverage_declined",  "capacity:0", "policy:3"],
    ["metric", "shard_dropped",      "age:2", "capacity:0"],
    ["metric", "blob_ceiling_raised", "false"]
  ]
}

These metrics evaluate operational capacity:

Specification status

The settlement tag remains reserved at none. blob_bytes remains a flow limit defaulting to zero.

A design note on § Grants & receipts and § Replication. The specification defines normative rules, and this document records supporting design rationale.