Smart cash is the middle path between plain bearer cash and generic hidden smart contracts. Z00Z objects can carry bounded economic meaning, move privately, support wallet-local state, and later settle through public evidence. That is already more expressive than a public balance row. It is not the same as arbitrary hidden program execution.

The page exists to prevent overclaiming. If Z00Z is described too narrowly, readers miss why vouchers, rights, claims, machine budgets, and external-asset rights belong to the same architecture. If it is described too broadly, readers expect a private world computer that the corpus does not prove.

State-Machine Boundary

The dashed edge is the non-claim. Wallets and services may run local state machines. The chain verifies typed transition evidence. That does not automatically create a universal private VM.

Supported State-Machine Families

These families fit because they can be expressed as bounded object transitions. They do not require the base chain to execute an arbitrary hidden application state machine.

What The Chain Verifies

The checkpoint path verifies public settlement evidence: package structure, authorization surfaces, replay inputs, roots, created and consumed objects, proof payloads, and canonical links. It can accept or reject the typed transition. It does not generically verify every local business rule, every external issuer promise, every service-side branch, or every hidden workflow decision that preceded publication.

That distinction is enough for strong smart cash. Many useful workflows need local policy plus final settlement, not a public contract VM. A voucher can be partially redeemed. A machine right can be presented locally. An access right can be consumed. Later, the public layer checks the resulting transition.

Proof Boundary

Simple commitments, signatures, range proofs, canonical encodings, replay artifacts, and checkpoint proofs can enforce many bounded policies. They are well suited to object identity, ownership authority, amount discipline, expiry, scope, and replay safety. General hidden branching over large private state requires stronger proof machinery and should remain future-facing unless explicitly implemented.

This proof boundary is the main reason the docs avoid generic “private smart contracts” language. It is safer and more accurate to say “bounded smart cash and rights.”

Fee And Liability Separation

The right itself is not the fee path. A FeeEnvelope or fee support object answers how publication, relay, verification, or execution costs are paid. It should not be hidden inside the right as if authority and payment support were one thing.

Liability is separate as well. A delayed or offline right may carry a hidden liability commitment, bond reference, and penalty policy. Those surfaces answer for abuse. They should not turn ordinary smart-cash use into public surveillance, and they should not be omitted when local acceptance creates real risk.

Unsupported Claims

Do not claim that Z00Z already provides arbitrary private smart contracts, a universal hidden VM, complete service-side correctness, automatic external reserve proof, or full production enforcement for every future right family. Those may be research or target directions. They are not safe present-tense protocol claims in this lane.

The safe present claim is narrower: Z00Z is a privacy-preserving settlement architecture for bounded private objects whose local policy can be richer than public balance accounting while final acceptance remains checkpoint-bound.

Builder Fit Test

Before calling a feature smart cash, ask six questions:

If the answer is no, the feature may still be interesting, but it is not yet safe to describe as current smart cash.

Examples That Fit

A merchant voucher fits because the object carries conditional value and later redemption can produce clean output. A machine access right fits because the local service can check bounded authority and later reconcile evidence. An external locker right fits if external custody remains labeled as service responsibility. A useful-work claim fits when external evaluation creates a bounded claim that Z00Z can settle privately.

Each example keeps the same structure: local meaning, bounded policy, typed package, checkpoint settlement, and explicit service boundaries.

Roadmap Discipline

Future smart-cash work should advance by evidence gates, not by labels. A richer right family should show object shape, wallet UX, package fields, replay boundaries, proof requirements, fee support, liability posture, and checkpoint interpretation before it is described as live. A wider private execution model should show the proof system and verifier path before it is called a VM.

This is how the docs can stay ambitious without becoming misleading.

Closeout Review Notes

Smart-cash language is attractive because it compresses many ideas into one phrase. That makes it risky. During review, split every smart-cash claim into object family, local rule, public proof, settlement effect, external service duty, and maturity. If any part is missing, the page should use target or research language instead of present-tense product language.

The same discipline protects user expectations. A policy-shaped voucher can be useful without being a general-purpose smart contract. A machine right can authorize a bounded action without becoming a universal agent economy. A liability bond can deter abuse without making all users publicly accountable by default. A fee envelope can pay for support work without becoming hidden monetary policy. These are powerful features because they are bounded. The page should preserve that boundedness every time it explains why smart cash matters.

Closeout review should flag any phrase that turns bounded state machines into an unrestricted VM claim. Z00Z can be more expressive than cash without pretending every application rule belongs in the base layer.

Read Next

• Assets, Vouchers, And Rights for the object categories smart cash relies on.
• Settlement Model for what the chain verifies.
• Linked Liability for conflict-triggered accountability around delayed rights.

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.

• Smart Cash sections 3-10 define the smart-cash problem, live protocol boundary, chain verification surface, proof boundary, right/fee/liability separation, supported FSM families, unsupported claims, and roadmap consequences.
• Assets, Rights, And Vouchers Whitepaper section 7 defines right policy, stateful rights, fee envelopes, and action-boundary discipline.
• Use Cases Whitepaper section 6 supports bounded consumer and service workflows that fit smart cash without implying a universal VM.