A balance answers a narrow question: how much value can this owner spend? Many useful agreements need a richer answer. How much may a delegate spend during the current period? When may a beneficiary claim the next payment? Which authority can recover the remainder after a deadline?
These are statements about rights that still exist. Their validity depends on earlier actions, but a future participant should not have to inherit every earlier action merely to check them.
In Decentralization Across Time, I described the possibility of extending proof-carrying State from money to rights and obligations. Parano1d v2 implements a concrete first core for that model. A live output can commit to a program, its authorities and its current counters. Every accepted change to that object is proved inside the shared recursive block relation.
The current right carries the validity of the path that produced it.
The practical consequence is substantial. A contract can remain independently verifiable after its old interaction bodies have been pruned. Applications gain programmable rules without making every completed interaction a permanent storage obligation for every future node.
These contracts also inherit Parano1d's post-quantum authorization and proof system. The same construction protects who may act and which state changes are admissible, for both templates and custom programs. The cryptographic basis and its published assumptions are set out below.
The contract rules apply from mainnet block 210,537. They are available through the official wallet, CLI and public RPC interface. The implementation is a bounded integer core with six templates and custom programs; its exact capabilities are described below.
What a live right is
An ordinary output binds value to an owner. Spending it requires valid authorization for the exact transaction. A contract output adds a committed rule for how that value may change hands and how the contract's own state may advance.
Here, “right” has a precise protocol meaning: permission to consume a particular live output under particular conditions. The conditions may restrict the authority, recipient, amount, inclusion height or the next counter values. Consensus enforces those conditions on native value. Any interpretation as access to a service or fulfilment of an external obligation belongs to the application using that right.
Three things then become distinct: the value that exists now, the rules for its next permitted transition, and evidence of an earlier transition. V2 gives each an explicit representation.
A small live record, exact public terms
The global live record contains an amount, an owner commitment and its creation identity. For a contract, that owner commitment binds immutable program and policy together with two persistent counters. The public opening supplies the data behind the commitment.
The ABI 3 opening is 699 bytes. It includes 16 instructions, the counter pair, claim and recovery authorities, their closing recipients, a deadline and spending limits. Domain-separated commitments bind the program, policy and live object state. There is no separate globally registered contract account whose history must be preserved.
A continuing call keeps the program and policy fixed and may change the counters. A changed counter pair produces a changed commitment and therefore a new contract address. The wallet groups related states under the same immutable terms so a person can work with one contract in the interface. Consensus still authenticates the exact current commitment.
The slot is also an exact object, not just a location. Its creation_id distinguishes the live instance from a previous occupant of a reused slot. A call identifies both the slot and its incarnation.
Define, fund, call
Creating terms is local. Anyone can construct, inspect, save or share a program and policy without broadcasting a deployment transaction. Saving those terms is free.
Funding is a separate ordinary payment to the contract commitment. It creates a live instance with value. A shared term file alone does not establish that funds were deposited; the wallet checks verified State, and a funding receipt can preserve evidence of the payment.
Every deposit creates an independent instance. Two deposits to the same opening do not become one shared counter or budget. Each instance has its own value and state, and one call consumes one instance. This is an essential design choice when building an application around allowances.
At the inclusion height, the committed deadline selects the authority branch. Before the deadline, the claim branch applies. At the deadline and afterward, the recovery branch applies. Each branch separately permits continuation, closing, both or neither.
| Operation | Result |
|---|---|
| Continue without a payment | One successor contract output; the fee is paid from the consumed value |
| Continue with a payment | A successor contract output and a permitted payment output |
| Close | The remainder goes to the branch's committed closing recipient, after the fee |
The selected authority proves knowledge of its spending secret through a fresh capsule bound to the complete transaction. Possessing that authority does not let it bypass the program or alter the committed policy. There is no implicit administrator.
Every live output must retain positive value. A zero-balance contract cannot remain as a free standalone storage record.
Where execution is proved
The wallet reviews a concrete proposed call. The mempool checks admission and conflicts. The miner then constructs a block whose recursive relation checks the contract execution itself.
The relation binds the supplied opening to the consumed commitment, checks the selected authority, executes the integer program, enforces the permitted output shape and proves the exact State changes. Value is conserved across the retained amount, payout and fee. The new HistoryStep also carries the validity of its predecessor.
Contract execution therefore belongs to the same proof that makes the block's State transition valid. Mempool acceptance is not a substitute for that proof. A producer cannot introduce a different result merely by claiming that it ran the program correctly.
All applications use the same interpreter and frozen block matrices. A new program that fits the existing core needs no application-specific matrix and no separate execution proof for each contract. Ordinary transaction authorization still supplies its own fresh wallet proof.
After confirmation and eventual pruning, the network retains the current State and authenticated recursive continuity. A joining node checks that continuity rather than replaying the contract's lifetime of calls. It still downloads live State and validates chain ordering; the proof does not make the live data or proof of work disappear.
Post-quantum protection for live rights
A vault may remain locked for years. A recovery authority may stay unused until a deadline. A beneficiary may collect value in many successive tranches. Each arrangement depends on the continuing security of both its authorization and its rules. This is where the post-quantum design becomes part of the contract itself.
Authorization uses Parano1d's signatureless ownership. An authority address commits through Poseidon2b to a 256-bit secret. The active authority produces a freshly randomized zero-knowledge proof of knowing that secret, bound to the exact transaction. The secret is not disclosed, and changing the recipient, amount, fee or input set invalidates the authorization. Claim and recovery use this mechanism without an elliptic-curve spending signature.
The block proof then enforces the committed policy and program. Forging an authority and proving a forbidden transition are both within the scope of the security analysis. Contract execution adds deterministic constraints to the shared recursive relation; it does not introduce a separate cryptographic protocol for every application. A custom program within this core uses the same analyzed authorization and execution construction as a built-in template.
The published v2 security model gives a conditional NIST PQC Category 1 resource assessment. Its premises cover composition across proof roots, the ideal compiler, the fixed Poseidon2b instance, quantum resource accounting and honest preprocessing of the authenticated legacy matrices. The derivation includes wallet authorization, recursive ancestry and the reductions that permit old matrices to be retired. Pruning old data does not remove its cryptographic obligations from that analysis.
For an application builder, the result is a common post-quantum foundation for funded rights: a spending allowance, a delayed claim or a recovery path can be expressed directly in the proved state transition. The proof enforces the program that was committed. The author still has to choose the intended policy, participants must protect their secrets, and the public terms and receipts remain necessary for the recovery flows described below.
A budget that survives its history
Consider an automated client allowed to spend from a funded instance of 100 NOID. Its policy caps each payment at 3 NOID, sets a fee ceiling, preserves a reserve and assigns a separate recovery authority. Its program permits a total of 10 NOID, including fees, per height-based period.
The two persistent counters hold the remaining budget and the next period boundary. Suppose the client requests a payment of 2 NOID with a fee of 0.01 NOID during the current period. A successful call leaves 97.99 NOID in the instance and 7.99 NOID in the period budget. Those are different quantities, proved by the same transition.
A second call cannot pretend the remaining budget is still 10. Its opening must match the live commitment produced by the first call. A payment over the per-call ceiling fails. Spending the same incarnation twice fails. Supplying a different program fails.
At or after the saved period boundary, the next successful call resets the budget and sets a new boundary at that call's inclusion height plus the period. Unused allowance does not accumulate. The template uses a call-started height window; an application should describe it that way rather than promise a calendar-day reset.
Now remove the old call bodies from ordinary node storage. The current 7.99 budget is still authenticated through the current commitment and recursive proof. A future verifier can establish that the present is valid without retrieving the first payment from an archival provider.
The example applies to one funded instance. Funding two instances creates two independently usable budgets. An application requiring one aggregate budget must account for that explicitly.
The integer core
The execution budget is fixed: 16 ordered instructions, two persistent unsigned 64-bit counters and two scratch registers. Scratch registers begin at zero on every call. Later instructions observe earlier writes.
The operations include copying, checked addition and subtraction, minimum and maximum, comparisons and assertions. Operands can read the registers, integer constants, inclusion height, amounts and fee, branch flags, output recipient words and exact instance or slot identifiers. Predicates select whether an instruction runs.
Arithmetic overflow, underflow, a false assertion or a non-Boolean predicate rejects the call. The core has no loops, unbounded storage or network access. Those bounds make the execution cost part of the block relation's defined budget.
One detail matters for custom programs: context operands refer to physical output positions. On continuation, output 0 is the retained contract and output 1 is the payment. On close, output 0 pays the closing recipient and output 1 is absent. A program handling both forms must use the terminal flag correctly; the semantic “payout” shown by an API is not the same thing as the program's physical output-1 operand on close.
Closing still executes the program and respects the fee ceiling. The policy's continuing-payment cap and minimum retained amount do not themselves limit a closing withdrawal. A custom policy must review every permitted branch, especially recovery and close.
Six usable forms of the same model
The templates are wallet conveniences compiled to the common core. Their names are not a consensus whitelist.
| Template | What it enforces | Application use |
|---|---|---|
| Payment with refund | Payee collects before expiry; payer recovers from expiry | Payments with a defined collection window |
| Timelocked vault | No permitted spend before the height, including by the owner | Delayed access to saved value |
| Allowance wallet | Capped continuing payments, reserve and a recovery path | A limited spending key for a person, service or device |
| Period budget | A fee-inclusive budget tracked across calls | Bounded automated operating expenditure |
| Recurring payment | One exact payment when due; next due height follows the successful call | A funded recurring claim |
| Gradual unlock | One fixed tranche per due step, then closing at maturity | Staged release to a beneficiary |
A per-call allowance does not enforce a period budget. A recurring payment does not accumulate missed periods; its next due height is the successful claim's inclusion height plus the period. Gradual unlock advances from the previously scheduled due height, so missed tranches can be claimed one call at a time.
Every scheduled operation still needs an authorized transaction. A bot, wallet or service can submit it. Consensus has no background timer that wakes up and pays somebody. A fee ceiling of 1 NOID permits a fee up to that amount; it is not a 1 NOID charge for creating terms.
Current rights and portable evidence
Three questions require three different answers:
| Question | Evidence |
|---|---|
| Can this known instance be spent now? | Authenticated current State and its public opening |
| Did this earlier call occur on the selected chain? | A verified contract receipt and canonical inclusion |
| What interactions does this wallet know about? | Its retained and imported local journal |
A receipt proves a past call. It does not establish that the resulting output remains unspent today. Conversely, current State can reveal whether a known commitment has funds without supplying every historical interaction that produced it.
This separation allows the network to prune old bodies while participants retain evidence useful to them. An application can verify a receipt with its own node before granting access to an external service. That application-level workflow does not imply that the v2 integer program can ingest arbitrary historical receipts, call another contract or consult an oracle. Those operations are outside the current core.
Two parties and an offline wallet
Alice creates terms, funds an instance and sends its public contract file to Bob. Bob opens it, checks his authority and current balance, and saves it. An online wallet watching those terms can retain relevant calls authorized by either party.
Alice then goes offline. Bob makes a permitted call that changes a counter and keeps the receipt. When Alice returns after the body-retention window, her node still verifies current State. But the old commitment alone cannot reveal the unknown successor opening. A hash authenticates data supplied to it; it cannot recreate data nobody retained.
Bob can send a contract receipt or a shared file carrying the update. Alice verifies it, imports the successor terms or closing evidence, then checks current State again. Import merges verified evidence, deduplicates repeated transaction IDs and preserves her own records and local name. An older opening does not overwrite a newer known live state.
A shared contract file carries terms and at most one matching receipt. It does not synchronize an entire journal. Additional relevant receipts can be exported and imported individually. Ordinary payment receipts, including deposits, use the ordinary receipt interface; contract interaction receipts use the contract workflow.
Backups therefore include both the wallet secret and public contract data. The secret restores authority. Terms and receipts restore the information needed to exercise and explain that authority. If every holder loses an opening and no retained body or receipt can supply it, the commitment cannot reconstruct the program.
From a proved core to a usable product
The official GUI exposes F7 Contracts. Create prepares a template or custom program and reviews funding. My Contracts opens saved instances, balances, actions, rules and the operations journal. Open File accepts shared terms, updates and contract receipts. Settings moves to F8.
Applications use the same operations through CLI and RPC. The useful integration boundary is the reviewed call: previewObjectCall returns the concrete input, fee, outputs and successor, together with guards for submission. A changed chain tip can change the inclusion height, authority branch, availability or output allocation. The caller refreshes and reviews that changed transaction before authorizing it.
Submission is not confirmation. A conflicting call may win, and a permitted reorganization may replace a recent confirmation. The wallet checks canonical headers and live State instead of treating a saved status label as final evidence. The network keeps its 18-block finality boundary and 17-block maximum rollback.
Developers can begin with the GUI walkthrough, the API guide and the exact core and ABI. Creating another application within that core does not require permission from a registry or a new network matrix.
Capacity and boundaries
Both v2 classes allow 63 contract calls and 504 live inputs. Small has 63 user pages; Large has 206. Each call uses one page and one input, so Large can carry the same 63 calls alongside up to 143 ordinary one-page payments, subject to the shared input limit. An additional mandatory system page consumes a position when required.
At the 30-second target, the call ceiling is 2.1 per second. This is a concrete bounded execution budget. Programs have no cross-contract calls, arbitrary state database or in-place upgrade mechanism. A permitted transfer can move value into new terms. New instruction semantics would require new consensus work.
The strongest immediate applications fit that shape: funded agreements with a small state, clear authorities, explicit limits and participants who keep their evidence. More elaborate services can coordinate several such rights outside the core, while treating each one's on-chain authorization and value limits as independently enforced.
The extension
The important change is what the present can mean. It can now represent a remaining allowance, a recovery path, a next due payment or a beneficiary's unclaimed tranche, with proof that the rules leading to that state were followed.
That opens a practical route from proof-carrying money to proof-carrying applications. Their active obligations occupy live State. Their fulfilled obligations need not become a permanent execution archive for every future participant. People and services preserve the evidence they need, and new nodes can still establish the validity of the current network for themselves.
Live value was the starting point. Live rights make that same independently verifiable present programmable.