Assets, Vouchers, And Rights

Z00Z should not use one vague object to mean money, condition, and authority at the same time. The clean model is a triad: assets are final value, vouchers are conditional value, and rights are authority. This split keeps native cash understandable, lets conditional claims exist without poisoning cash, and lets authority move without secretly carrying value.

The triad is both a user-language rule and a settlement-safety rule. Wallets must classify objects correctly. Policies must say what they govern. Checkpoints must preserve accounting. Public docs must not turn every object into “smart money” without explaining which category it belongs to.

Triad Diagram

flowchart LR Asset["Asset\nfinal value"] --> CreateVoucher["create voucher"] CreateVoucher --> Voucher["Voucher\nconditional value"] Right["Right\nauthority"] --> Voucher Voucher --> Redeem["redeem or partial redeem"] Redeem --> AssetOut["Asset\nclean output"] Voucher --> Refund["refund or expire"] Right --> Delegate["delegate or attenuate"] style Asset fill:#E8F5E9,stroke:#43A047,stroke-width:1px,color:#1B5E20 style AssetOut fill:#E8F5E9,stroke:#43A047,stroke-width:1px,color:#1B5E20 style Voucher fill:#FFF3E0,stroke:#FB8C00,stroke-width:1px,color:#E65100 style Right fill:#E3F2FD,stroke:#1E88E5,stroke-width:1px,color:#0D47A1 style CreateVoucher fill:#ECEFF1,stroke:#546E7A,stroke-width:1px,color:#263238 style Redeem fill:#ECEFF1,stroke:#546E7A,stroke-width:1px,color:#263238 style Refund fill:#FFE0E0,stroke:#D32F2F,stroke-width:1px,color:#B71C1C style Delegate fill:#EDE7F6,stroke:#5E35B1,stroke-width:1px,color:#311B92

Asset

An asset is final spendable value. For native Z00Z cash, that means the holder should not have to inspect arbitrary hidden policy before treating the object as money. The asset can be spent, split, merged, transferred, used for fees, or converted into a voucher under explicit rules. It should not carry arbitrary sender restrictions by default.

Keeping cash clean protects receiver clarity. A receiver should know whether they received final value or a conditional claim. If native cash can secretly behave like a contract shell, every payment becomes a policy audit.

Voucher

A voucher is conditional value. It may be backed by reserved or consumed value, scoped to a merchant or service, limited by time or quota, partially redeemable, refundable, or expired. The key point is that it is economically meaningful but not final cash.

Vouchers are useful because they avoid two worse designs. They avoid dirty cash, where restrictions travel invisibly on money. They also avoid rights that secretly carry value. A voucher can hold conditional value while a right authorizes actions over that value.

Right

A right is authority. It answers whether the holder may do something: redeem, view, audit, delegate, operate, refund, or use a bounded capability. A right may be stateless or stateful, but it should not become a value object by hiding backing, remaining amount, or refund state.

Rights are powerful because they let Z00Z model access, machine authority, agent budgets, audit views, and external-control rights without pretending every authority object is money. They also make liability and fee boundaries clearer. The right itself is distinct from the fee envelope and from any bonded liability path.

Lifecycle Mini-Flow

stateDiagram-v2 [*] --> CleanAsset CleanAsset --> VoucherCreated: reserve or consume source value VoucherCreated --> VoucherActive: accept VoucherCreated --> Refunded: reject or expire VoucherActive --> PartRedeemed: partial redeem PartRedeemed --> VoucherActive: remaining value stays conditional VoucherActive --> CleanOutput: redeem full RightGranted --> VoucherActive: authorize redeem, view, or refund RightGranted --> RightDelegated: attenuate CleanOutput --> [*] Refunded --> [*] classDef support fill:#ECEFF1,stroke:#546E7A,stroke-width:1px,color:#263238 class CleanAsset support class VoucherCreated support class VoucherActive support class Refunded support class PartRedeemed support class CleanOutput support class RightGranted support class RightDelegated support

This lifecycle shows why the categories need to remain separate. Final value can become conditional value. Conditional value can become final value again. Authority can act over conditional value. None of those transitions should be hidden.

Wallet Rules

Wallets should show assets, vouchers, and rights differently. Assets can appear as spendable value after settlement. Vouchers should appear as conditional claims with policy status, expiry, partial-redemption state, and refund expectations. Rights should appear as authority with scope, action, expiry, delegation, and disclosure rules.

Unknown policy objects should be quarantined. A wallet should not silently convert an unknown voucher into spendable cash or count an authority right as balance. This is user safety, not extra polish.

Policy And Action Boundaries

Policy belongs where the object category says it belongs. Cash policy should stay fixed and narrow. Voucher policy can govern redemption, refund, expiry, merchant scope, and partial use. Right policy can govern action scope, delegation, attenuation, revocation, and disclosure. Action pools should be explicit, bounded, and not smuggled into native cash.

This prevents object-model inflation. Instead of inventing many bespoke money types, the protocol can classify the object correctly and keep settlement accounting coherent.

Receiver And Quarantine Rules

The receiver wallet is where the triad becomes concrete. A wallet should not present a voucher as clean cash, a right as balance, or an unknown policy object as ordinary value. Unknown policy should be quarantined until the wallet can explain the object family, source, authority, refund behavior, and settlement status.

This protects both safety and privacy. If a user accepts a policy object they do not understand, they may expose themselves to unexpected refund paths, expiry, issuer conditions, or support workflows. If the wallet logs or exports the object too broadly while trying to explain it, it may leak more than public settlement would have revealed.

Accounting Implications

The triad also constrains accounting. Assets count as final value after settlement. Vouchers count as conditional value until redeemed or refunded. Rights count as authority and should not inflate value totals. Fee envelopes and liability bonds are support surfaces, not silent expansions of the object itself.

This prevents double counting. A voucher backed by reserved value should not be counted as both the original cash and the conditional claim. A right that authorizes redemption should not be counted as the redeemable value unless the voucher or asset backing exists separately. These rules are necessary for wallet UX, issuer accounting, and future audit packages.

Service And External Boundaries

External-asset rights add another layer. Z00Z can settle an internal right privately, but custody, reserves, redemption, and issuer promises remain external unless the specific integration proves otherwise. A wallet should therefore display source family, issuer domain, and redemption posture instead of flattening every private object into one generic token.

The same rule applies to local economies, aid vouchers, subscriptions, and machine rights. Z00Z can provide the private object and settlement boundary. The service context still owns its own business promise.

Naming Discipline

Names should preserve category. Use cash or asset language only for final value. Use voucher language for conditional value. Use right language for authority. Use claim language when a pre-authorized condition materializes an output. Use locker or external-right language when an outside custody or issuer surface remains part of the story.

This naming discipline is not pedantry. It keeps users from treating authority as money, conditional claims as settled value, or external promises as protocol guarantees.

Closeout Review Notes

Use this page to catch category drift across the rest of the docs. A page about vouchers should not quietly promise final cash. A page about rights should not turn authority into balance. A page about external assets should not imply that Z00Z has taken over reserve, issuer, redemption, or compliance duties. The object category determines what the wallet can display, what the protocol can settle, what evidence can be produced, and which actor still owns a real-world promise.

This also matters for examples. Offline private cash, policy-shaped money, community distribution, and machine-agent rights all sound like money stories, but they are not the same object family. Some are final value, some are conditional claims, some are delegated authority, and some depend on an external service. A clean page keeps those differences visible so future use-case copy does not collapse them into one impressive but inaccurate product claim.

Closeout review should therefore scan for category shortcuts in every downstream page. If the object is conditional, delegated, redeemable, or externally backed, the wording should say so before it describes user value.

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.

Assets, Rights, And Vouchers Whitepaper sections 3-11 define the asset, voucher, right triad, cross-object bindings, voucher lifecycle, rights, settlement implications, and open design questions.
Smart Cash section 7 defines right, fee, and liability boundaries that must remain separate.
Main Whitepaper section 3 defines the canonical object-first protocol core that this page uses.

Z00ZBlockchain