Enum VerificationContext 

pub enum VerificationContext {
    ClientPut,
    Replication,
}

The situation a payment proof is being verified in.

A proof-of-payment is a receipt: it records a sale that closed at some earlier moment, at that moment’s prices, between the client and the close group of that moment. Two very different callers present receipts:

• ClientPut — the node is the storer being paid right now. Every check applies, including the ones that interrogate the present: “is the price on this receipt still fair for my current fullness?” (own-quote freshness) and “am I actually one of the paid recipients?” (local recipient / merkle candidate closeness).
• Replication — a neighbour is handing over an already-paid record (fresh-write fan-out, paid-notify, repair). The sale closed long ago; the network’s job now is to keep the record at target redundancy for the rest of its life. Re-asking the present-tense questions of a receipt is a category error with a guaranteed failure mode: record counts only grow, so every receipt’s quoted price eventually drops below the verifier’s live floor, and close groups churn, so the receiving node eventually isn’t a quoted recipient at all. On DEV-01 (2026-06-05) this rejected nearly 100% of replication proof-of-payment transfers within an hour of launch (4M+ rejections at ~300k/hour), pinned records below target redundancy, and drove a permanent ~500 MB/s fleet-wide re-offer storm.

Under Replication the verifier therefore skips only the storer-being-paid-now checks. Everything that makes the receipt a receipt still runs: quote structure, content binding to this exact address, peer-ID/pub-key bindings, ML-DSA signatures, and the on-chain settlement lookup. A record cannot be admitted via replication without an authentic, settled payment for that record.

The verified-XorName cache is context-aware to match: an entry inserted by a Replication verification satisfies later replication lookups but NOT a later ClientPut fast-path, so a replication receipt can never let a client PUT bypass the checks this enum gates.

Trade-off (deliberate, documented): skipping the recipient/closeness checks for replication means a payer who self-deals — minting a quote pool from peers they control and settling the median payment to their own wallet on-chain — can present that receipt to honest nodes via the replication protocol, paying only gas plus a recycled self-payment instead of paying real storers. The client-PUT path still rejects such pools, and replication admission still requires the receiving node to be responsible for the key, so the abuse costs a settled on-chain payment per chunk and buys only what storage already costs; closing it properly belongs in quote issuance / payment policy, not in the replication hot path, where the equivalent defence provably destroys the network’s ability to heal.

Variants

ClientPut

The node is the storer being paid right now: all checks apply.

Replication

An already-settled receipt presented during replication/repair: skip the storer-being-paid-now checks (own-quote price freshness, local recipient, merkle candidate closeness); keep all receipt-authenticity checks.

Trait Implementations

impl Clone for VerificationContext

fn clone(&self) -> VerificationContext

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Copy for VerificationContext

impl Debug for VerificationContext

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Eq for VerificationContext

impl PartialEq for VerificationContext

fn eq(&self, other: &VerificationContext) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl StructuralPartialEq for VerificationContext