Date: 2026-02-28 Status: Proposed (canonical Tier 2 draft) Scope: Defines the recommended receipt, aggregation, epoch accounting, reputation, and optional payout model for storage, indexing, review, and FLora reward accounting in Verse communities. Related:

• design_docs/verse_docs/implementation_strategy/flora_submission_checkpoint_spec.md
• design_docs/verse_docs/implementation_strategy/community_governance_spec.md
• design_docs/verse_docs/implementation_strategy/2026-03-28_decentralized_storage_bank_spec.md
• design_docs/verse_docs/technical_architecture/2026-02-23_verse_tier2_architecture.md

Adopted standards (see 2026-03-04_standards_alignment_report.md §§3.1, 3.2, 3.10, 3.11)):

• RFC 4122 UUID v7 — receipt_id and entry_id are UUID v7 (time-ordered for append-only ledger ordering)
• W3C DID Core 1.0 — provider and requester identity fields use did:key; PeerId must be a DID
• IPFS CIDv1 — receipts_root and settlements_root are CIDv1 content addresses

Proof of Access is the Verse accounting layer for:

• storage service
• retrieval service
• indexing service
• review/moderation work
• FLora contribution rewards

It should support:

• reputation-only operation
• off-chain ledger accounting
• optional token settlement later

The default recommendation is off-chain-first, payout-second.

1. Receipts are evidence, not money Receipts prove service claims. They do not settle funds directly.

2. Epoch batching Aggregate and settle in epochs rather than per-request.

3. Off-chain default Keep v1 accounting in signed append-only ledgers, not live chain transactions.

4. Payment channels over per-action settlement If token payouts are enabled, use escrowed channel-style settlement rather than on-chain transfer per event.

5. Reputation always exists Even if financial payout is disabled, the ledger still computes reputation.

enum AccessWorkType {
    BlobServed,
    IndexServed,
    FloraSubmissionAccepted,
    FloraCheckpointIncluded,
    ReviewCompleted,
    ModerationCompleted,
    BlobAvailabilityEpochHeld,  // storage bank: base credit for passing availability challenge
    BlobRetrievalServed,        // storage bank: usage bonus with hold-duration weighting
    BlobRepairCompleted,        // storage bank: repair credit for re-hosting under-replicated blob
}

struct AccessReceipt {
    receipt_id: Uuid,          // UUID v7 (time-ordered, RFC 4122) — ledger ordering
    community_id: CommunityId,
    work_type: AccessWorkType,

    subject_ref: String,       // blob cid, submission id, checkpoint id, review id
    provider: Did,             // did:key (W3C DID Core 1.0)
    requester: Option<Did>,    // did:key (W3C DID Core 1.0)

    declared_units: u64,      // bytes, points, or policy-defined work units
    hold_duration_epochs: Option<u64>,  // epochs held before serving (storage bank receipts)
    epoch_hint: u64,
    created_at_ms: u64,

    signature: Signature,
}

• BlobServed: bytes transferred
• IndexServed: bytes or query-weighted points
• FloraSubmissionAccepted: policy-weighted points
• FloraCheckpointIncluded: higher policy-weighted points
• ReviewCompleted: review points
• ModerationCompleted: moderation points
• BlobAvailabilityEpochHeld: byte-epochs (blob_size × 1 epoch); base credit for storage bank availability
• BlobRetrievalServed: bytes transferred × hold-duration multiplier; usage-validated storage credit (see storage bank spec §3.2)
• BlobRepairCompleted: bytes re-hosted; repair credit for re-hosting under-replicated blobs

Each community defines the exact weighting schedule, but the receipt shape stays stable.

For BlobRetrievalServed and BlobRepairCompleted receipts, the optional hold_duration_epochs field records how many epochs the provider held the blob before the retrieval or repair event. This enables the "usage validates storage time" credit model: longer holds produce higher credit on retrieval.

hold_duration_epochs is None for all other work types and for BlobAvailabilityEpochHeld (where duration is implicitly 1 epoch).

See 2026-03-28_decentralized_storage_bank_spec.md for the full credit mechanics, challenge protocol, and bonus formula.

struct LedgerEpoch {
    community_id: CommunityId,
    epoch_id: u64,
    opens_at_ms: u64,
    closes_at_ms: u64,

    receipts_root: Cid,
    settlements_root: Option<Cid>,
    finalized: bool,
}

struct LedgerEntry {
    entry_id: Uuid,      // UUID v7 (time-ordered, RFC 4122)
    epoch_id: u64,
    beneficiary: Did,    // did:key (W3C DID Core 1.0)
    work_type: AccessWorkType,
    weighted_units: u64,
    reputation_delta: i64,
    payout_delta: Option<u64>,
}

• small/private communities: daily or weekly
• active public communities: hourly to daily

Short enough for responsive accounting, long enough to avoid hot-path settlement.

Reputation should be computed from weighted, policy-filtered receipts.

Recommended factors:

• validated unique requesters
• successful service volume
• freshness (recent activity weighted more)
• dispute / invalid receipt rate
• moderator overrides for fraud or abuse

Use mild rolling decay rather than permanent accumulation.

Rationale:

• reduces stale oligarchies
• rewards recent useful participation
• aligns with community quality and responsiveness

• Keep payout disabled by default
• Keep full receipt and reputation accounting active
• Allow communities to enable explicit bounty or budget pools later

If payout is enabled:

• community treasury escrows a fixed budget
• epoch finalization computes payout allocations
• beneficiaries claim against an escrowed channel or batched settlement record

This mirrors established decentralized-storage practice: negotiate and account off-chain, settle in coarse batches.

For Filecoin-oriented communities:

• use Filecoin-backed treasury accounting as the budget source
• prefer payment-channel-like claim semantics instead of direct chain transactions per contribution
• treat on-chain interaction as settlement/audit, not live service coordination

Required protections:

• duplicate receipt suppression
• nonce / unique receipt IDs
• signed requester acknowledgment where applicable
• epoch cutoffs
• claim dispute window
• per-peer rate limiting

Recommended anti-gaming rules:

• cap repeated receipts from the same requester in a short window
• weight unique requesters more heavily than repeated self-loop traffic
• allow communities to mark peers as colluding or low-trust
• separate “receipt accepted” from “payout eligible”

Communities should allow work that does not generate economic receipts.

Examples:

• private peer exchange
• anonymous public caching
• reputation-disabled communities

enum ReceiptPolicy {
    RequiredForPayout,
    OptionalReputationOnly,
    Disabled,
}

This keeps the economic layer optional and prevents money logic from becoming mandatory for basic network use.

The ledger should support post-hoc correction without rewriting history.

enum LedgerDisputeOutcome {
    ConfirmedValid,
    Invalidated,
    ReducedWeight,
    Reassigned,
}

Rules:

• never delete original receipts
• append dispute and correction records
• future epochs may claw back reputation or payouts if policy allows

• Signed append-only off-chain ledger
• Epoch-based aggregation
• Reputation on by default
• Token payout off by default
• Payment-channel-style settlement if payouts are enabled
• Fraud controls and dispute windows mandatory

These defaults keep the economic layer useful without dragging the Verse protocol into premature chain complexity.