In Z00Z the receiver is not just a public address waiting for a balance update. A receiver flow can include signed receiver material, a payment request, local acceptance checks, imported package handling, later publication, and post-settlement reconciliation. That makes receiving an active wallet boundary rather than a passive account row.

This matters because the receiver is where privacy, safety, and object semantics meet. The receiver must know whether the incoming object is final cash, a voucher, a right, a claim, an external-asset right, or an unknown policy object that should be quarantined. It must also know whether local acceptance is enough for a low-risk handoff or whether the user should wait for checkpoint settlement.

Receiver-Native Flow

The flow separates local acceptance from final settlement. A receiver can decide that a package is good enough for a bounded local workflow, but only checkpoint validation makes the transition canonical.

Receiver Material

Receiver material should be bounded and explicit. A signed receiver card may identify how the sender should build a receive package. A payment request may add amount hints, expiry, memo discipline, policy context, or one-time workflow identity. The receiver should avoid reusing broad receiver surfaces in ways that rebuild a public graph through operational behavior.

The point is not to eliminate routing artifacts. The point is to avoid turning them into a permanent public ownership primitive. The receiver artifact helps a sender create the right package for this workflow. It does not become a universal account address.

Local Acceptance

Local acceptance is a policy decision. The receiver wallet checks structure, object family, expiry, amount expectations, proof-bearing fields, receiver binding, voucher conditions, refund terms, or unknown policy markers. A merchant may accept a low-value package before publication. A corporate wallet may require stronger evidence before recording the item as final. A privacy wallet may warn when receiver reuse or exact timing narrows privacy.

Local acceptance should therefore expose state clearly:

This language helps users avoid confusing possession, publication, and finality.

Vouchers And Refunds

Vouchers make receiver flow more important because the receiver is not receiving final cash yet. A voucher may require acceptance, partial redemption, expiry handling, merchant scope, refund rules, or a future right. The wallet should show that distinction. Counting a voucher as ordinary spendable cash before redemption is a category error.

Refund boundaries should be explicit. If a voucher is rejected, expires, or cannot be redeemed, the refund should follow the declared policy and source context. A refund should not become a hidden operator conversion path or a way to strip restrictions from value. If the object was created from a bounded source such as a grant, allowance, issuer, or service program, the refund path should preserve that source meaning.

Unknown Policy Quarantine

Receiver safety depends on refusing objects the wallet cannot classify. Unknown policy objects, unsupported voucher actions, suspicious issuer families, malformed request material, or externally backed claims without clear redemption context should enter quarantine rather than appearing as normal money.

Quarantine is not censorship by the base protocol. It is local wallet discipline. The user may decide what to do next, but the wallet should not silently convert an unknown object into spendable balance or hide the reason for caution.

Publication And Dispute

After local acceptance, the package still needs publication and checkpoint validation. If publication succeeds and roots line up, the object becomes settled. If a replay, conflict, expiry, or fraud path appears, the receiver may need a refund, dispute, liability case, or support workflow.

For offline or delayed use, this staged design is the point. It lets local possession be useful before global finality while preserving a strict later authority boundary.

Builder Checklist

A receiver implementation should not treat every inbound object as balance. It should classify the object, display the maturity state, preserve the source or policy label, and keep local acceptance separate from settlement. The minimum checklist is direct:

• verify receiver material and request binding before import;
• classify the object as asset, voucher, right, claim, or unknown;
• show whether the object is locally accepted, published, settled, rejected, or refunded;
• quarantine unsupported policies and externally backed claims with unclear issuer context;
• retain enough local evidence for later reconciliation without exporting unrelated wallet history.

This checklist is especially important for builders who are used to address-based chains. A receive address can hide policy questions behind the ledger. A receiver-native Z00Z flow cannot. The wallet has to help the user understand what was received and what still needs to happen.

Privacy Notes

Receiver flow is a privacy surface. Reusing the same request material across many senders, accepting exact-value payments from one narrow source, or exporting broad support logs can weaken privacy even if the public chain never sees a reusable address. The wallet should warn when receiver behavior starts recreating a stable operational graph.

The safest default is fresh or tightly scoped receiver material, explicit expiry where useful, narrow memos, redacted logs, and clear separation between counterparty-visible request data and wallet-local inventory.

Receivers should also avoid treating “private” as “context-free.” A private package can still arrive from a known merchant, employer, bridge, issuer, or support workflow. That context may matter for safety, refunds, and later disclosure even when it should not become public settlement meaning.

Closeout Review Notes

Receiver flow is where technical precision becomes user safety. A page can describe a sophisticated private-object model, but the user eventually sees a receive prompt, imported package, voucher, right, or claim. If the wallet does not explain the object class and maturity state, the user may treat an unsafe object as ordinary value. If support asks for too much receiver evidence, the user may reveal more context than public settlement would have exposed.

For closeout review, check that receiver copy names the source of trust. A receiver card, payment request, merchant context, issuer domain, policy hash, expiry, refund rule, and checkpoint state all answer different questions. The docs should not compress them into one “received” label. Good receiver wording tells the user what is locally known, what is still pending, what could be disputed, and what must not be shared publicly.

This is also where examples should stay careful. A friendly receive flow can still produce privacy leakage if it encourages repeated identifiers, oversized screenshots, or broad support exports.

Read Next

• Wallet-Local Possession for the possession model behind receiver flows.
• Object Lifecycle for package, settlement, dispute, and redemption states.
• Assets, Vouchers, And Rights for final value versus conditional value and authority.

Evidence and Further Reading

Use the source bullets below as an audit checklist, not decoration: when reusing this page, preserve the named section scope, the responsible actor, and the split between live repository evidence, target architecture, and open design work.

• Main Whitepaper sections 3-5 define canonical objects, wallet-local possession, receiver-card and payment-request surfaces, offline handling, and reconciliation.
• Assets, Rights, And Vouchers Whitepaper section 8 defines wallet safety, quarantine, acceptance, and policy-bound object handling for vouchers and rights.
• Smart Cash sections 4-8 define bounded smart-cash objects, client-side state-machine behavior, public settlement limits, and supported state-machine families.