Smart contracts on Platform: decisions and implementation plan for 5.0

[QuantumExplorer]

Complete planning reference: all 160 tasks, prerequisites and dependents · Complete dependency register, reasons and tracking · Complete task details 1 — R03-01 through R07-06 · Complete task details 2 — R07-07 through R10-04 · Complete task details 3 — R10-05 through R12-08 · Complete task details 4 — R12-09 through CAP-11 · Complete task details 5 — CAP-12 through INT-RNG · Current capability rules and external primitives. This issue contains all 234 dependency links with reasons/evidence, complete task acceptance and scope, capability declarations/rules/costs, module/file/caller maps, all 18 storage areas, decisions and open engineering work. Timing remains unset. The site is an interactive view; it is not required to recover these planning records.

Proposed release allocation: 6 task targets in 4.3-dev, 5 in 4.4-dev and 149 in 5.0-dev. Earlier preparation is explicitly separated from full task completion; smart-contract activation remains 5.0. Dates and durations remain unset.

DIP drafts and implementation: 12 drafts and all 160 task mappings · 25 workstreams · Shared allocation register.

Development architecture: module ownership and call flows · all task-to-module mappings. The guide covers 63 module groups, nine reusable new crates and one example, all 160 tasks, all 110 capability families and all 18 storage areas. Shared native validators, existing Drive indexes/fees/proofs and one ABCI commit are explicit. Unimplemented interfaces remain labeled engineering proposals.

Implementation layout supplements: new crates and existing-package changes · ownership of all 160 tasks and 110 capabilities · 18 Drive storage areas and GroveDB mapping. Engineering proposals published 11 September 2026; implementation and final numeric storage allocations remain open.

Recent owner choices, reconciled 11 September 2026:

• Several named WASM modules per immutable contract-version bundle; unchanged modules can be reused and the whole bundle activates together.

• Data-only contracts contain only local keys 0/1. Smart contracts add 2=EXEC, 3=COLLECTIONS and 4=RUNTIME.

• Create the 0/1 tree first, then add 2/3/4 as a distinct Merk application within the same atomic transaction, preserving documents key 1 as root. Authorized data-to-smart conversion follows the same required final shape.

• Scheduled jobs use consensus-time triggers and one jobs_due_time queue.

• Reuse the existing prefunded ledger at 40/128/balance_id for job removal, with purpose-aware native validation and preserved legacy voting behavior; no separate DashVM reserve subtree.

• Keep rs-drive-contracts separate from Drive and DashVM. Use rs-dash-sdk-contract / dash-sdk-contract / dash_sdk_contract for the contract-author SDK.

• Keep two VM crates: rs-dashvm-validation for deterministic WASM validation and required instrumentation; rs-dashvm for Wasmtime/Cranelift compilation, caching and execution.

Engineering recommendation updated: ordinary SumTree for contract-credit root/per-contract totals. This corrects the earlier blanket provable-sum proposal; it is distinguished from owner-confirmed policy. Exact remaining codecs, limits and identifiers still need implementation validation.

Complete storage mapping, rationale and task acceptance. All 160 tasks remain open and timing remains unset.

Owner follow-up incorporated, 11 September 2026 — revision 11. DashVM is confirmed: pinned upstream Wasmtime/Cranelift, upstream fixes and deterministic scalar floating point. Current-state reads remain in force. All 160 tasks are owned by QuantumExplorer; dates and durations remain unset. Confirmed policy answers and provisional engineering limits. Production work remains open.

Revision 10: owner responses, DashVM, Rust API and native capabilities. Updated 11 September 2026. Fable findings and proposed resolutions · Developer API, Rust example and primitive dependencies.

The current MPM and unscheduled Gantt contain 160 open work items: the previous 120 reviewed tasks and 18 capability work packages, plus 20 refinements and 2 external primitive deliveries. Related work is implemented once. The catalogue contains 108 inspected native capability families plus 2 planned external primitives. ACL and randomness have separate interface/stub, external delivery and production-integration tasks. Only their interface prototypes and unavailable adapters are implemented in this planning work; the native primitives and production integrations remain open. Required consumers cannot activate using a stub. QuantumExplorer owns all work; dates and durations remain unset.

The Rust proposal uses persistent document structs, native index/rule declarations, exported methods and free functions, ordinary helpers and explicit transaction staging. It includes a complete API sketch; these macros are proposed, not a released SDK. Fable's findings have proposed engineering resolutions or an explicit policy disposition. The owner selected normal protocol upgrades only, declining an emergency pause; a reproducible scheduled host fault can therefore still require existing coordinated recovery. Upstream Wasmtime/Cranelift maintenance is confirmed; the exact release/configuration remains engineering work. Other new implementation recommendations are marked for review rather than silently added to the 56 approved-direction register.

Latest GroveDB develop was rechecked at c401b504. Capability A, capability B, and capability C retain the native source inventory and 18 work packages. All 213 original-row dispositions are retained. Planning coverage is not evidence that production execution or a full source-line audit is complete.

---

Smart contracts on Platform: decisions and implementation plan for 5.0

Rust contracts compile to WebAssembly and run through a Dash-owned host and guest SDK. The first full smart-contract scope targets Platform 5.0, including calls between contracts. Contract data uses Platform documents and GroveDB; contract credit balances use a separate sum balance tree, with credit and token buckets governed by contract rules.

Revision 7 : 11 September 2026. This revision incorporates the owner's 56-decision review and subsequent decisions on proofs, receipts, wipes, contract versions, call routing, and compilation readiness. These selected directions supersede revisions 1–6. Wasmtime/Cranelift and upstream maintenance are confirmed; exact release/configuration remains engineering work. This issue records design and implementation work; updating it does not mean the implementation is complete.

Release direction

Protocol version	Release target
PV15	4.3
PV16	4.4
PV17	5.0

Build toward 5.0 first. Identify features suitable for earlier release and make the final allocation after implementation. Use at most these three protocol activations. The work groups below describe dependencies, not one protocol version per group. The old PV18/PV19 schedule and its derived wire/table allocations are superseded. Project dates, effort estimates, task durations, and the exact development branch are unset.

Selected architecture

• Identities and ordinary contracts remain separate. Account for the ACL work planned for 4.3; introduce no keyless contract identity model. Contract credits use a new sum balance tree; credit/token buckets carry spending rules.
• Contracts can hold credits, documents, and tokens. Receiving contracts decide whether to accept credit deposits. Contract rules authorize identities or groups to move assets, including payouts to multiple identities and transfers to other contracts when both permit them. No direct contract-to-Core unlocks.
• Contract state uses documents, with an internal document type for exposed queryability. Reuse existing GroveDB indexes, validation, and atomic writes. Preserve all-or-nothing contract effects through that integration.
• Each transition reads the current execution state at its position in the agreed block order, including accepted effects of earlier transitions and its own earlier operations. Later transitions and unvalidated speculative writes are never visible.
• Include cross-contract calls in the first release. Resolve methods on the latest target version visible under those rules; callers cannot pin or fall back to an older version.
• Keep every canonical contract code version permanently in state, including after a wipe. Deprecation is a warning period; explicit unsupported/inactivity rules determine when a version can no longer run. Compiled copies of inactive versions may be discarded and reconstructed for historical replay.
• Store execution receipts by default; each contract may disable receipt storage. Provide current-state proofs using GroveDB. Serving arbitrary past-state proofs is outside the requirement; historical execution replay remains required.
• Check full execution affordability against the live balance before entering guest code. Charge consumed work once, including failed execution. Direct-call signers pay processing and storage; storage refunds follow the owner recorded on the data.
• Limit the new compute budget to smart-contract computation. Keep existing non-contract/block-event budgeting and the proposer timer. Recurring execution need not be fully prepaid: drop a loop on its first failure to pay, with the drop cost prepaid.
• Test on testnet, then allow open deployment. Contract rules support freeze, unfreeze, and temporary freeze. Freeze, wipe, unfreeze and foreign-token vestige recovery require strictly more than two-thirds of all active eligible evonodes, one vote each. Votes have a one-week window and approve early after rechecking eligibility against agreed current membership. Require N > 0 and 3yes > 2N, equivalently floor(2*N/3)+1 yes votes. Exactly two-thirds fails. Compilation readiness remains at least 80% with its existing adaptive wait and no automatic expiry. Wiped credits go to the current processing pool; its own issued tokens cease to exist; other contracts' tokens it holds move to a deleted-contract identity vestige.

Execution engine and activation

Wasmtime with Cranelift is confirmed. Upstream maintenance and scalar floating point with NaN canonicalization are confirmed; the exact release/configuration remains engineering work. The earlier requirement to use wasmi and defer JIT compilation is superseded. DashVM is the confirmed name for the execution system, using upstream Wasmtime/Cranelift.

The activation policy is selected: an evonode reports ready only after compiling the contract, and at least 80% of the entire active evonode set, counted once each, starts the waiting period. This is not a vote over only the current validator quorum.

Let T be the time from deployment to the first committed 80% readiness threshold:

additional_wait = min(max(T, 2 minutes), 1 hour)
activation_time = threshold_time + additional_wait

Normally activation takes 2T in total, not 3T. The limits apply to the additional wait. They do not impose a deadline for reaching 80%. The accepted-deployment timestamp convention, active-set snapshot/churn rules, activation block boundary, and recovery details remain to be specified in section 8. No extra current-quorum gate or below-threshold automatic activation has been approved.

Scope and decision status

Rust/WASM, current-state proofs, SDK/tooling, scheduling, and cross-contract calls are in the first scope. Oracle feeds move to a later 5.x release. Escrow, allowances, and native auctions are not current priorities and have no assigned release. Preflight is excluded from 5.0; zero-knowledge work is for a future version. EVM/Solidity compatibility and external-asset bridges are outside this plan. Contract-held group membership and DPNS names are deferred; groups may still authorize contract actions.

The audit/sign-off and SDK funding gates from the original proposal are removed. Ordinary implementation checks and the explicitly agreed engine comparison/adoption tests remain. Hardware publication and the final proposer-timer policy are deferred. Existing recovery is retained, with failing state transitions removed from the proposer.

Decision status: the original 56-entry mapping is preserved for traceability. All 42 review directions and the five follow-up policy topics now have recorded answers; numerical allocations remain engineering work. Wasmtime/Cranelift and upstream maintenance are settled; provisional engineering details are not additional approvals.

Reading the task lists: all implementation tasks remain unchecked. Sxx-yy references preserve traceability to original checklist rows; tasks may combine or replace those rows. New tasks have no old reference. Described implementation approaches are proposals to realize the selected decisions, not additional owner approvals. Exact ABI identifiers, limits, thresholds not chosen above, and version-table generations must be specified and checked against the implementation tree before use.

Contents

1. Summary, goals, non-goals, and design principles
2. Current state of Platform: what exists, what is missing
3. Options considered and runtime direction
4. Target architecture
5. Decisions, DIPs, and groundwork
6. VM-independent infrastructure
7. Bounded expression guards
8. WASM execution, compilation, and activation
9. Reads, visibility, and current-state proofs
10. Entry points, cross-contract calls, and scheduled execution
11. Determinism, lifecycle, freeze/wipe, and engine governance
12. Fees and economics
13. Developer experience, SDK, and tooling
14. Delivery, validation, deferred work, and remaining decisions
15. Crate layout, responsibilities and dependencies
16. Task and capability ownership by crate
17. Drive storage areas and GroveDB mapping
18. Architecture overview and call flows
19. New-crate module and file catalog
20. Native Drive, DPP and ABCI module catalog
21. Client, wallet and supporting module catalog
22. Native reuse, capabilities and storage ownership
23. Complete tasks, dependencies and module ownership
24. Complete dependency register, reasons and tracking
25. Complete task details 1 — R03-01 through R07-06
26. Complete task details 2 — R07-07 through R10-04
27. Complete task details 3 — R10-05 through R12-08
28. Complete task details 4 — R12-09 through CAP-11
29. Complete task details 5 — CAP-12 through INT-RNG
30. Current capability rules and external primitives
31. Release allocation: 4.3-dev, 4.4-dev and 5.0-dev
32. DIP drafts and complete implementation tracking
33. DIP shared allocation register and provisional values

---

Revision 10 incorporates the returned owner review. Unresolved policies and provisional engineering values are labelled; implementation tasks remain open.

Owner review outcome

DashVM uses upstream Wasmtime/Cranelift and scalar floating point with NaN canonicalization. Current-state reads, explicit delegated rights, no active-contract reentry and whole-call rollback are selected.

Direct users can target supported old code; schedules and cross-contract calls use latest. No universal warning delay; contract-promised notice remains binding. Preserve existing native index-update validation.

Readiness checks prune ineligible votes at a potential 80% crossing. Replacement cancels the previous pending round/timer; no automatic expiry. Nodes pay their compilation; deployers pay bounded protocol verification.

Freeze, wipe, unfreeze and specific-transfer vestige recovery use strictly more than two-thirds of all active eligible evonodes, one-week windows and early approval after eligibility recheck. Frozen code can be updated but stays frozen; native inbound funds remain permitted under receiving rules.

Scheduled routines declare Drop/Retry/Skip. Receipt ownership, paid-failure storage, contract-defined retention, explicit Rust persistence and canonical typed declarations are confirmed. Cancellation authority, prepaid removal and recorded-owner refunds are confirmed.

All 160 tasks are assigned to QuantumExplorer, including external native ACL/randomness delivery; dates and durations remain unset. The MPM/Gantt keeps all task IDs and dependency endpoints. Native award behavior and governance are selected; resource and price values remain provisional engineering estimates.

Read all remaining choices and proposed limits.

Final five policy answers

Contracts may parameterize contested indexes only through supported native declarations. Native rules select and award the winner; guest code and custom guards cannot veto, delay, redirect or retry the award. No blocked-award or guest retry workflow. Make rule scopes explicit; enforce native validation, internal award authority, atomicity and lifecycle rules.

Freeze, wipe, unfreeze and foreign-token vestige recovery require strictly more than two-thirds of all active eligible evonodes, one vote each. Votes have a one-week window and approve early after rechecking eligibility against agreed current membership. Require N > 0 and 3yes > 2N, equivalently floor(2*N/3)+1 yes votes. Exactly two-thirds fails. Compilation readiness remains at least 80% with its existing adaptive wait and no automatic expiry.

Foreign tokens remain in the deleted-contract identity vestige until a separate network vote approves specific token IDs, amounts and a recipient. Require strictly more than two-thirds of all active eligible evonodes, one vote each, with a one-week window and early approval after eligibility recheck. Enforce native transfer validation and conservation; no unrestricted permanent recovery authority.

Each scheduled job declares its cancellation authority and reserves removal costs. Charge removal and return unused reserves to their recorded owner, or the current processing pool if that owner is a wiped contract. Preserve funded removal across fee upgrades or settle affected old jobs first.

All five follow-up policy topics are settled. Resource/price estimates and exact engine/configuration remain engineering work; production implementation tasks remain open.

[QuantumExplorer]

Owner follow-up incorporated, 11 September 2026 — revision 11. DashVM is confirmed: pinned upstream Wasmtime/Cranelift, upstream fixes and deterministic scalar floating point. Current-state reads remain in force. All 160 tasks are owned by QuantumExplorer; dates and durations remain unset. Confirmed policy answers and provisional engineering limits. Production work remains open.

Part 2 of 14 · Revision 11 · 11 September 2026 · Parent plan · Decision register

Revision 8 capability coverage: Appendix A · Appendix B · Appendix C. This section's implementation includes the corresponding capability requirements and CAP-01–CAP-18 acceptance work. The reviewed product decisions below are unchanged; GroveDB review baseline is develop at c401b504.

2. Current state of Platform: what exists, what is missing

Baseline and reuse

The original source inventory was inspected at v4.2-dev, commit a3c36f39a3, on 7 September 2026. Those branch names, line numbers, counts, and table generations are historical observations, not the new development target. Recheck the relevant code before implementing; this issue update does not claim new code or passing tests.

Existing area	Integration work under the selected decisions
packages/rs-dpp: data contracts, documents, tokens, identities, groups, state transitions	Extend contract schemas, calls, authorization, serialization, and lifecycle without turning ordinary contracts into identities. Coordinate the 4.3 ACL work.
packages/rs-drive: GroveDB operations, indexes, validation, atomic writes, fee/refund storage flags	Reuse these capabilities. Add separate contract credit sum storage and credit/token buckets; extend conservation and current-state proofs.
packages/rs-drive-abci: validation, proposal execution, fee charging, block events, recovery	Insert bounded guest execution after live affordability checks; preserve CheckTx's no-execution rule and existing recovery. Add compilation-readiness activation and recurring-call integration.
packages/rs-platform-version: protocol dispatch, serialization and fee tables	Limit release allocation to PV15/4.3, PV16/4.4, PV17/5.0. Record engine behavior per protocol version and preserve replay.
rs-drive-proof-verifier, DAPI, Rust/WASM/JS and mobile SDKs	Extend ordinary contract balance/data proofs and call/lifecycle surfaces. No contract-identity compatibility gate or past-state proof service.

Gaps to address

Code deployment needs a substantially larger state-transition size allowance; the exact cap and optional chunking are undecided. Compiled artifacts need preparation, persistent caching, recovery, and activation coordination. Canonical code remains permanently stored even when an executable cache entry is removed.

The new computation budget covers smart-contract work only. Existing fees, non-contract execution, block events, and the proposer timer retain their established handling; integration must not double-charge or omit smart-contract computation in scheduled calls.

Repair fee-version numbering and historical refund lookup before infrastructure merges. Reuse current GroveDB validation and atomicity rather than treating a new index algorithm or separate savepoint layer as a prerequisite. Measure and test integration boundaries instead of assuming existing coverage proves every new behavior.

Prior review findings that still matter

The earlier review identified assumptions not fully pinned by tests: stored-document size after updates, transfers and price changes; serializer growth and the larger guest wire representation; and exactly which CheckTx/RecheckTx paths can enter contract execution. Preserve these as implementation checks. Do not reuse the old 20 KiB cap as a proven document or guest-wire bound after changing upload limits.

Current-state proofs attest state under the relevant committed root. Execution-result text alone is not a state proof. Receipt storage being enabled does not create a requirement to retain proofs for arbitrary historical heights, and disabled receipts must not be represented as stored proof of execution.

Public documentation must be aligned to the 5.0 target and actual SDK capabilities after checking the current tree. Historical source links may remain useful, but stale product promises and invented release dates should not.

---

Revision 10 incorporates the returned owner review. Unresolved policies and provisional engineering values are labelled; implementation tasks remain open.

Owner review answers applying to this section

Q39 — Confirmed direction. Substantially extend contract create and update state transitions to carry large code/declarations. Apply larger bounded limits consistently on every ingress path; do not merely introduce an unrelated upload route. Initial single-transition form and exact sizes are engineering proposals.

Q40 — Confirmed delegation. Maintain one protocol-versioned allocation register. Supply provisional numeric limits and prices now, then measure and revise before activation. Allocate wire/storage/ABI IDs from actual registries; keep engine/profile pin and unmeasured native costs explicitly unresolved.

[QuantumExplorer]

Owner follow-up incorporated, 11 September 2026 — revision 11. DashVM is confirmed: pinned upstream Wasmtime/Cranelift, upstream fixes and deterministic scalar floating point. Current-state reads remain in force. All 160 tasks are owned by QuantumExplorer; dates and durations remain unset. Confirmed policy answers and provisional engineering limits. Production work remains open.

Part 3 of 14 · Revision 11 · 11 September 2026 · Parent plan · Decision register

3. Options considered and runtime direction

What is selected

Rust-to-WASM is the contract language/toolchain direction. Dash owns its host integration, protocol semantics, and guest SDK. The choice is driven by long-term execution speed and maintainability as well as delivery effort. The old argument that throughput is not a discriminator, the mandated wasmi interpreter, and the blanket JIT deferral are superseded.

Engine and maintenance choices still open (review entries 34–36)

Option	Position in the current discussion	Tradeoff to validate
Wasmtime + Cranelift	Working direction, with compilation before activation	Optimized execution and compilation moved ahead of use; compilation cost, adversarial modules, deterministic metering/stack limits, cache size, and upgrade preparation still need evidence.
Wasmtime + Winch	Alternative baseline compiler	A possible faster-preparation path; compare runtime speed and supported deterministic configuration against Cranelift on Dash workloads. No dual-engine deployment has been selected.
Winch plus Cranelift	Alternative compilation tiers	Could balance preparation and optimized execution, but introduces a second backend and requires consensus-equivalence testing of results, fees, traps, and resource boundaries. Not an approved requirement.
wasmi/interpreter	Comparison or reference candidate	May be useful in differential testing. It is no longer the mandated first production engine.
Pinned upstream integration versus maintained fork	Maintenance decision reopened	Compare a small Dash integration with upstreamable patches against the continuing cost of carrying a fork. No fork-and-freeze policy is approved.

Select an exact revision only after comparison tests and an agreed test period. Neither that revision nor the period has been chosen. Historical engine behavior must remain replayable; software-only hotfixes require identical execution and fees, while behavior changes require a protocol upgrade. An engine comparison can expose differences; only candidates intended to implement the same Dash protocol rules must match. Historical versions may deliberately differ and must replay under their own rules.

Lessons carried forward from the NEAR/NearVM review

These are engineering considerations from the research, not a decision to fork NearVM: bound compiler work for adversarial modules; prepare code ahead of execution; keep cache state from changing consensus results; tie artifact compatibility to code, compiler/engine configuration and target architecture; retain old execution behavior; test metering and resource boundaries across compiler changes. Readiness votes establish reported preparation, not proof that a compiler is correct.

Other options and scope

EVM/Solidity compatibility is outside the plan. Importing CosmWasm, Move, SVM, or another chain's complete account/state/ABI model is not selected. Their designs may inform bounded module validation, capabilities, metering, and SDK ergonomics without importing those systems. Native primitives are deferred as described in section 6; zero-knowledge execution and its study move to a future version rather than a parallel current workstream.

Naming

DashVM is proposed for the complete Dash execution system: protocol rules, host API, storage integration, metering, activation, and replay. Wasmtime would be its underlying runtime and Cranelift its compiler if selected. The name remains open; use neutral contract-runtime package placeholders until naming and package availability are settled.

Implementation tasks

• Build a deterministic comparison corpus covering module validation, output, protocol-metered cost, traps, and resource boundaries on x86_64 and aarch64. Test candidate engine/compiler configurations and exact revisions; distinguish expected historical differences from forbidden differences under identical protocol rules. Source: S03-01.
• Replay recorded blocks under their original protocol/engine behavior using later node binaries; compare application hashes and per-transition fees after engine changes and backports. Source: S03-02.
• Benchmark the confirmed Cranelift backend against Winch and a reference interpreter for diagnostic evidence; select a pinned upstream release/profile after representative and adversarial tests. Comparison does not reopen the chosen engine. Source: S03-03.
• Define and implement bounded registration validation: admitted WASM features, import/export and capability rules, ABI version, code size, memories/tables, function/parameter/local counts, nesting, and compilation complexity. Specify the exact caps rather than reusing old allocated constants. Source: S03-04.
• Version required host-capability declarations and reject unsupported capabilities consistently. Track advisories for the dependencies actually selected; external subscriptions or communications remain separate operational actions. Source: S03-05.
• Validate ABI and target protocol compatibility at registration and upgrades; preserve execution of accepted historical code. Define upgrade preparation explicitly instead of silently freezing contracts or charging first-use recompilation under the old proposal. Source: S03-06.
• Define protocol-versioned computation and memory metering with golden vectors and paid limit failures; verify it is independent of local cache state and compiler optimization choices. Source: S03-07.

---

Revision 10 incorporates the returned owner review. Unresolved policies and provisional engineering values are labelled; implementation tasks remain open.

Owner review answers applying to this section

Q01 — Confirmed. Use pinned upstream Wasmtime with Cranelift and a small Dash integration layer; contribute fixes upstream. A necessary temporary patch is an exception, not a standing engine fork.

Q02 — Confirmed direction. Coordinate engine behavior changes through normal protocol upgrades and preserve historical replay. Select the exact release, locked dependencies, Cranelift configuration and adoption evidence through engineering tests.

Q03 — Confirmed. Call the complete execution system DashVM. Wasmtime is its runtime and Cranelift its compiler; exact crate and command names remain engineering allocations.

Q04 — Confirmed. Allow f32/f64 with explicit Cranelift NaN canonicalization and deterministic host/profile tests. SIMD and relaxed SIMD are separate profile choices; proposed initial profile disables both.

Named modules — owner direction recorded 11 September 2026

Support several named WASM modules in one contract version in 5.0; a single-module bundle remains valid. Pin exact modules and interfaces in one immutable manifest, reuse unchanged canonical modules across versions, and activate the whole bundle under the existing readiness rule. Detailed linking, initialization and fee rules remain engineering proposals.

Detailed storage, linking, initialization, accounting and 16 expanded task acceptances. References above to a module/code archive now allow the complete named-module bundle. Canonical blobs and immutable manifests remain permanent; public methods map to module exports. Readiness covers every module, internal calls share one authority/budget/atomic scope, and cross-contract/scheduled latest-version routing is unchanged. Proposed ABI/linker/initializer specifics require engineering validation; this amendment does not claim implementation or measured limits.

[QuantumExplorer]

Owner follow-up incorporated, 11 September 2026 — revision 11. DashVM is confirmed: pinned upstream Wasmtime/Cranelift, upstream fixes and deterministic scalar floating point. Current-state reads remain in force. All 160 tasks are owned by QuantumExplorer; dates and durations remain unset. Confirmed policy answers and provisional engineering limits. Production work remains open.

Part 4 of 14 · Revision 11 · 11 September 2026 · Parent plan · Decision register

Revision 8 capability coverage: Appendix A · Appendix B · Appendix C. This section's implementation includes the corresponding capability requirements and CAP-01–CAP-18 acceptance work. The reviewed product decisions below are unchanged; GroveDB review baseline is develop at c401b504.

4. Target architecture

4.1 Layers

Client SDKs submit signed state transitions. DPP validates their structure and authorization requirements. The Dash runtime supplies bounded guest execution and a capability-controlled host interface. Drive validates proposed operations and applies them through the existing GroveDB integration. GroveDB remains the source of state, indexes, atomic writes, and current-state proofs.

Guest code does not receive arbitrary database access. Contract behavior must go through host operations whose authorization, costs, limits, and effects can be reproduced by every node. The exact ABI and nested-call implementation remain design work.

4.2 Contracts, balances, and authorization

Ordinary contracts are not identities. Keep the current identity model and coordinate ACL changes planned for 4.3. Add a separate sum balance tree for contract credits, with multiple credit balance buckets and corresponding token buckets. Each bucket has spending rules. Include all balances in credit/token conservation and their query/proof paths.

Contracts may hold credits, documents, and tokens. Receiving contract rules determine whether credit deposits are accepted. Contract rules select identities/groups authorized to move assets. Payouts may target one or multiple identities, or another contract when both contracts permit the transfer. Direct contract-to-Core asset unlocks are excluded; ordinary identity withdrawals retain the existing limits.

Support document types whose create/replace/delete actions can only be initiated through the contract's rules. Group membership and DPNS names held by the contract itself are deferred; this does not prevent a group authorizing an action. The deleted-contract identity vestige in section 11 is a specific wipe exception, not a general contract identity scheme.

4.3 State and effects

Use Platform documents for contract state, including an internal document type when exposing queryability. Dedicated balances follow the bucket model. Reuse all existing GroveDB capabilities, including index validation and atomic writes. Proposed effects must pass the existing integration's validation and retain all-or-nothing contract effects. Do not mandate a new savepoint layer or index algorithm before examining the current integration.

Each transition reads the current execution state at its position in the agreed block order, including accepted effects of earlier transitions and its own earlier operations. Later transitions and unvalidated speculative writes are never visible. Native authorization, revisions, uniqueness, affordability and atomicity remain enforced. Parallel scheduling must preserve sequential results, fees and roots.

Cross-contract calls are in the first scope and use the latest visible target version/method, without version pinning or old-code fallback. Nested call permissions, reentry, depth, shared resource limits, failure propagation, and rollback boundaries need specification before implementation.

4.4 Fees, failures, and versioning

Check the full bound against live funds before execution, then charge actual consumed costs once. The direct-call signer pays processing/storage; stored ownership determines refunds. Paid rejection/trap/out-of-fuel results must retain no unapproved partial contract effects. Distinguish guest rejection from genuine node/storage faults rather than claiming storage failures are ordinary guest outcomes.

Keep every code version permanently in state, while compiled cache retention follows executability. Every execution uses protocol-versioned behavior; current execution and historical replay select the appropriate rules. Engine-dependent artifact details are local implementation data, not an alternative source of consensus validity.

Implementation tasks

• Specify contract credit/token bucket identifiers and separate sum-tree storage, authorization, query/proof paths, and conservation integration; coordinate the 4.3 ACL work without changing ordinary identities. Source: S04-01.
• Implement holdings and transfers for credits, documents, and tokens under contract rules: receiving-side deposit checks, identity/group authorization, multi-recipient payouts, and mutual permission for contract transfers; enforce no direct contract-to-Core unlock. Source: S04-03, S04-04.
• Integrate contract-only document create/replace/delete authorization with existing document validation, using contracts rather than keyless identities. Source: S04-05.
• Test guest rejection, invalid host arguments, traps and exhaustion as classified paid outcomes; keep genuine storage/node faults distinct and preserve the existing proposer/validator recovery behavior. Source: S04-06.
• Test CheckTx/RecheckTx structure and full-bound affordability without guest execution, then recheck the live balance at the execution seam before entering any contract code. Source: S04-07.
• Test every admitted/forbidden WASM feature and each selected structural/resource cap, including deep recursion, memory growth, compiler stress, and deterministic failure classification. Source: S04-08.
• Test atomic rollback, native predicate/trigger validation, uniqueness conflicts, exact fee/nonce effects, storage refund ownership, zero balance buckets, frozen actions, and conservation across success and failure. Source: S04-09.
• Verify the contract computation limit and Tenderdash-facing gas accounting are compatible without introducing the rejected overall execution/block-event budget or equating unlike units. Source: S04-10.

---

Revision 10 incorporates the returned owner review. Unresolved policies and provisional engineering values are labelled; implementation tasks remain open.

Owner review answers applying to this section

Q07 — Confirmed. Delegate only explicitly granted rights; retain original signer and immediate caller separately. Never automatically pass all signer rights to a callee.

Q22 — Confirmed. A network freeze blocks execution, spending and controlled writes; queries, current-state proofs and native bookkeeping continue. Frozen recipients may receive funds under Q30 and existing receiving rules.

Q30 — Confirmed direction. Pause execution of jobs whose contract is frozen. Frozen identities/contracts may receive native funds without running frozen guest code; existing asset-specific and receiving permissions still apply. Proposed queue policy resumes future runs without a catch-up burst and cancels permanently missing methods.

[QuantumExplorer]

Owner follow-up incorporated, 11 September 2026 — revision 11. DashVM is confirmed: pinned upstream Wasmtime/Cranelift, upstream fixes and deterministic scalar floating point. Current-state reads remain in force. All 160 tasks are owned by QuantumExplorer; dates and durations remain unset. Confirmed policy answers and provisional engineering limits. Production work remains open.

Part 5 of 14 · Revision 11 · 11 September 2026 · Parent plan · Decision register

5. Decisions, DIPs, and groundwork

Decision authority

This register transcribes the owner's submitted review and later amendments. Later answers supersede earlier ones. An agreed, revised, rejected, or deferred disposition is recorded; an unanswered detail is not inferred as approval. The earlier D1–D17 proposal register and its deadlines are replaced by these review entries and the remaining-details list in section 14.

Frontload design decisions. Create as many DIPs as needed from the outset; do not require a single initial DIP or delay an ABI DIP by default. Use the normal DIP process and obtain assigned numbers rather than treating old placeholders as allocations. Implementation working specs are not to be committed to the platform repository; enduring protocol specifications belong in the appropriate DIP process.

The allowed release mapping is PV15/4.3, PV16/4.4, PV17/5.0. Develop toward 5.0 and choose earlier-release candidates after implementation. Exact branches, wire identifiers, error ranges, ABI generations, and version-table generations remain allocations to verify against the current tree. Do not mechanically reuse the old phase-derived tables.

Complete reviewed decision register

R01 : Contract language : agreed

Use Rust contracts compiled to WebAssembly; Solidity and EVM compatibility remain outside this plan.

R02 : Staged delivery : revised

Use at most three activation versions: PV15 targets 4.3, PV16 targets 4.4, and PV17 targets 5.0. Build all work for 5.0 first, mark candidates for earlier release, and settle the final allocation after implementation.

R03 : Independent primitives : deferred

Do not focus on oracle feeds, escrow, allowances or auctions now. Oracle feeds are explicitly assigned to a later 5.x release; the other primitives have no release assignment yet.

R04 : Design documents : revised

Create as many DIPs as needed from the outset.

R05 : Working branch : revised

Replace the v4.2-dev branch assumption with the 4.3 / PV15, 4.4 / PV16, and 5.0 / PV17 targets. Development initially targets 5.0. The exact working branch name is not specified.

R06 : Decision deadlines : revised

Frontload as many decisions as possible.

R07 : Release approval : revised

Aim to include everything needed for the first smart-contract release in 5.0. The audit gate and SDK funding gate are removed by decisions 32 and 38; a complete replacement release checklist is not specified here.

R08 : Names and version numbers : agreed

Keep the decision register and allocation tables authoritative; revise their values to match this review, including the PV15–PV17 limit.

R09 : Contract identity : revised

Keep identities separate from contracts and preserve current identity behavior. Account for ACLs planned for 4.3; work around that ongoing work rather than introducing contract identities.

R10 : Contract identifier : revised

Use a new sum balance tree for contract credit balances. Each contract may have multiple balance buckets, each with spending rules. Support corresponding contract token balance buckets. Do not store contracts in the identity tree or call them contract identities.

R11 : Client compatibility : rejected

Remove the proposed contract-identity query, proof and associated client gate. Ordinary contract balance/data queries and proofs still need to follow the revised storage model.

R12 : Supported assets : agreed

Allow contracts to hold credits, documents and tokens; defer contracts themselves holding group membership or DPNS names. Use contracts, not keyless identities, under decisions 9 and 10. Groups may still authorize actions under decision 14.

R13 : Funding a contract : revised

Accept credit deposits according to the receiving contract’s rules.

R14 : Direct withdrawals : revised

Contract rules determine which identities or groups can move its assets. Allow payouts to one or several identities, or to another contract when both contracts permit it. Do not allow direct contract-to-Core asset unlocks for now.

R15 : Protected documents : agreed

Support document types that only the contract can create, replace or delete, subject to its rules. Apply this without creating contract identities.

R16 : State storage : revised

Keep contract state in Platform documents; use an internal document type when the contract exposes queryability. Dedicated credit and token balance buckets follow decision 10.

R17 : Check funds first : agreed

Check the full execution bound against the live balance before execution and charge actual costs once.

R18 : Failed execution : agreed

Charge for work consumed by rejected, trapped or out-of-fuel calls.

R19 : Who pays : agreed

For direct calls, the signer pays processing and storage. Refund storage fees to the owner recorded on the written data.

R20 : Fee-registry prerequisite : agreed

Repair fee-version numbering and historical refund handling before the infrastructure work merges.

R21 : Block compute limit : revised

Limit the smart-contract execution budget to smart-contract computation. Leave other execution and block-event budgeting at its existing layer; do not build the proposed combined budget.

R22 : Local node switches : agreed

Remove node-local settings that can change contract execution or conservation results.

R23 : Proposer timer : deferred

Keep the existing proposer timer for now. Decide its final policy later.

R24 : Code uploads : revised

Increase the permitted state-transition size substantially for contract code. The exact cap and whether chunking remains an optional path are not yet specified.

R25 : Code deletion : revised

Retain every old contract version's canonical WASM permanently in state; old versions can never be deleted, including by a wipe. Support explicit inactivity rules: a contract update may mark earlier versions as deprecated or no longer supported. Retain ready-to-run compiled copies for versions that remain executable; compiled copies of non-executable versions may be removed and rebuilt under the appropriate historical engine and rules when replay needs them. Deprecation is a warning period, not execution disablement; deprecated versions remain executable wherever the call-routing rules permit them, so their compiled copies remain eligible for retention. There is no protocol-wide warning minimum; enforce any contract-promised notice. Declared update authority retires versions explicitly. Direct users may select supported old code; schedules use latest. Cross-contract calls continue to target the latest version under decision 53. Contract-controlled execution history and receipts are separate from contract-version retention; receipt storage defaults to enabled under decision 50.

R26 : Scheduled work : revised

Do not require all scheduled execution to be prepaid. Drop a recurring loop on its first failure to pay. Prepay the cost of dropping the loop. Rules for unrelated upload cleanup are not specified by this answer.

R27 : Initial deployment : revised

Test on testnet and allow anyone to use the feature when it goes live. Remove the staged approved-deployer rollout.

R28 : Freeze authority : revised

Let contracts define their own freeze, unfreeze and temporary-freeze rules. One-week active-evonode votes may freeze or wipe a contract once strictly more than two-thirds of the full active eligible set approves after eligibility recheck, while permanent contract versions remain in state. On a wipe, add the contract's credits to the current processing pool. Tokens issued by the wiped contract are destroyed and cease to exist. Tokens from other contracts held by the wiped contract are retained in a special deleted contract identity vestige. This vestige does not change the separation of ordinary contracts from identities.

R29 : Freeze behavior : agreed

A frozen contract rejects affected actions rather than bypassing its rules.

R30 : Engine patches : agreed

Allow software hotfixes only when execution and fees stay identical. Behavior-changing engine updates require protocol upgrades.

R31 : Recovery from a halt : revised

Preserve the existing recovery system. Remove failing state transitions from the proposer; do not add the proposed recovery mechanisms.

R32 : Security gate : rejected

Remove the proposed requirement for a named security owner, threat register and closed stage audit as a prerequisite to building. Continue implementation; this answer does not establish that checks have passed.

R33 : Transaction admission : agreed

Check transaction structure and affordability in CheckTx without executing contract code; remove known faulting transactions. Verify existing coverage when implementing rather than assume it has been tested.

R34 : Execution engine : confirmed

DashVM uses pinned upstream Wasmtime with Cranelift. Scalar floating point is enabled with explicit NaN canonicalization; exact release/profile remains engineering allocation.

R35 : Engine maintenance : confirmed

Use a small Dash integration layer and contribute fixes upstream. A necessary temporary patch is an exception; protocol behavior changes follow normal upgrades and historical replay is retained.

R36 : Engine adoption : agreed

Adopt an exact engine revision after comparison tests and an agreed test period. The revision and test duration are still unset.

R37 : Historical replay : revised

Version the engine internally so upgrades preserve execution of previously accepted code. Associate every execution with a protocol version. Packaging and retention of historical engine implementations remain engineering details to resolve.

R38 : SDK funding gate : rejected

Remove the SDK funding gate. SDK and tooling delivery remain part of the work.

R39 : Hardware and node costs : deferred

Defer the minimum-hardware specification, benchmark-machine publication and operator cost report. No new values are approved.

R40 : What a feed means : deferred

Move oracle feeds out of 5.0 into a later 5.x release. The median policy is unanswered.

R41 : Observer selection : deferred

Move oracle feeds out of 5.0 into a later 5.x release. Observer selection is unanswered.

R42 : Signed feeds : deferred

Move oracle feeds out of 5.0 into a later 5.x release. Signed-feed policy is unanswered.

R43 : Observer payments : deferred

Move oracle feeds out of 5.0 into a later 5.x release. Observer payments are unanswered.

R44 : Read visibility : revised

Each transition reads the current execution state at its position in the agreed block order, including accepted effects of earlier transitions and its own earlier operations. Later transitions and unvalidated speculative writes are never visible. This owner amendment supersedes the former start-of-block rule.

R45 : Preflight default : deferred

Exclude preflight (a dry run before submitting a call) from 5.0. No later release is assigned. This does not remove the agreed CheckTx structure and affordability checks.

R46 : Historical proofs : revised

Provide proofs of current state using GroveDB. There is no requirement to prove past state or serve proofs for arbitrary past block heights. Historical execution replay remains required under decision 37.

R47 : Read-declaration fallback : deferred

Do not focus on the 5% undeclared-read fallback policy now. Remove it as a current planning prerequisite; its alternative is not decided.

R48 : Atomic writes : revised

Reuse existing GroveDB capabilities and the existing validation and atomic-write integration. Preserve all-or-nothing contract effects through that integration; no separate savepoint design is required by this decision.

R49 : Index prerequisite : revised

Reuse existing GroveDB capabilities, including the existing index validation and atomic-write integration. No additional index mechanism is selected.

R50 : Execution receipts : revised

Let each contract control whether execution receipts are stored. Store them by default; a contract may disable storage because of its cost. Receipt storage is separate from permanently retained contract versions and does not introduce a requirement for past-state proofs.

R51 : External assets : agreed

Keep bridges and wrapped external assets outside the plan and require a separate design before adding them.

R52 : Native asset entry : agreed

Keep the existing Core-to-Platform asset-lock route as the native entry path. Do not make a single custodian the canonical route.

R53 : Contract-to-contract calls : revised

Allow calls between contracts in the first smart-contract scope. Cross-contract calls target a contract and method in the latest version visible under the agreed execution-state rules; callers cannot pin an older target version. If that latest version does not expose an executable matching method, fail the call rather than fall back to older code. Resolve latest using consensus state and decision 44's visibility rules, not a node's local cache or wall clock. Specify nested call behavior, resource bounds, permissions, reentry and rollback during design. Method-interface compatibility and upgrade handling still need specification.

R54 : Transaction ordering : agreed

Keep the existing ordering protocol and assess ordering risk for each value-moving capability.

R55 : Zero-knowledge alternative : deferred

Move zero-knowledge predicates and their study to a future version, rather than current parallel work.

R56 : Withdrawal limits : agreed

Give contract balances no separate Core withdrawal allowance; ordinary-identity payouts remain subject to existing Core withdrawal limits.

The Cranelift/Wasmtime direction and DashVM name discussed afterward are working proposals. The 80% readiness policy is selected; engine implementation/revision, maintenance, and final naming are not silently resolved by publishing this register.

Implementation tasks

• Draft the DIPs needed for consensus behavior, ABI, activation/lifecycle, fees and storage from the outset. Record chosen rules and explicit open details; follow the current DIP formatting/number-assignment process. Source: S05-01, S05-02.
• Use this issue as the parent plan. Create implementation tracking issues when work boundaries and release allocation are settled, linking back to the reviewed decisions rather than duplicating stale phase specifications. Source: S05-03.
• Frontload remaining choices and maintain one consistent allocation register for PV15–PV17, feature placement, engine behavior, wire/error identifiers, and ABI/table generations. Keep unresolved limits and policies marked open. Source: S05-04, S05-05, S05-06.
• Settle runtime/ABI/SDK package names and normal code ownership; add a contracts commit scope if needed. DashVM is the confirmed system name; exact package names remain engineering work. Source: S05-07.
• Repair fee-version registration, historical refund lookup, and replay coverage before infrastructure merges; implement the detailed work in section 12 on the selected development branch. Source: S05-08.
• Check and correct public smart-contract target wording, protocol/version counts, state-transition lists, and actual Swift/Kotlin SDK availability. Use the 5.0 target and this issue; do not introduce calendar commitments or stale v4.2-dev instructions. Source: S05-09, S05-10, S05-11, S05-12.

---

Revision 10 incorporates the returned owner review. Unresolved policies and provisional engineering values are labelled; implementation tasks remain open.

Owner review answers applying to this section

Q01 — Confirmed. Use pinned upstream Wasmtime with Cranelift and a small Dash integration layer; contribute fixes upstream. A necessary temporary patch is an exception, not a standing engine fork.

Q02 — Confirmed direction. Coordinate engine behavior changes through normal protocol upgrades and preserve historical replay. Select the exact release, locked dependencies, Cranelift configuration and adoption evidence through engineering tests.

Q03 — Confirmed. Call the complete execution system DashVM. Wasmtime is its runtime and Cranelift its compiler; exact crate and command names remain engineering allocations.

Q04 — Confirmed. Allow f32/f64 with explicit Cranelift NaN canonicalization and deterministic host/profile tests. SIMD and relaxed SIMD are separate profile choices; proposed initial profile disables both.

Q05 — Confirmed. Reject repeated contract IDs on the active contract call stack, including A to B to A. Ordinary Rust helper calls and local recursion remain allowed within stack limits.

Q06 — Confirmed. Actual permission, resource, native validation and host/nested failures poison the whole outer call; catching them cannot retain partial effects. Internal speculative retries are not paid failures. Expected business alternatives can be successful typed return values.

Q07 — Confirmed. Delegate only explicitly granted rights; retain original signer and immediate caller separately. Never automatically pass all signer rights to a callee.

Q08 — Confirmed. Read current execution state at the transition position in agreed block order, including accepted earlier transitions and own writes. Never expose later or abandoned speculative writes. Parallel execution must match sequential roots, results, fees and receipts; internal retries are not charged.

Q09 — Confirmed. Contracts may parameterize contested indexes only through supported native declarations. Native rules select and award the winner; guest code and custom guards cannot veto, delay, redirect or retry the award. No blocked-award or guest retry workflow. Make rule scopes explicit; enforce native validation, internal award authority, atomicity and lifecycle rules.

Q10 — Confirmed direction. When readiness could cross 80%, revalidate voters against current agreed active membership and prune ineligible votes before accepting the crossing. A count tree may maintain raw votes but is not eligibility proof. Membership changes must also trigger reconsideration; bounded checks must use one coherent membership view.

Q11 — Confirmed direction. Use committed chain timestamps and a defined activation boundary. Every node must use the same Core membership view referenced by the Platform block, after the same membership-update phase. Preserve additional wait clamp(T, 2 minutes, 1 hour); exact phase/predicate belongs in the DIP.

Q12 — Confirmed. Allow one pending executable update. A replacement atomically cancels the previous pending vote round and activation timer; current active code serves until the replacement is ready. Bind votes to deployment/round so they cannot transfer to replacement code.

Q13 — Confirmed. Do not expire pending deployments automatically. Allow authorized cancellation before activation, including during the wait; retain accepted canonical code permanently and refund unused preparation funds to the recorded payer after completed costs.

Q14 — Confirmed. The deployer pays bounded protocol validation and readiness-verification costs. Evonodes pay their own compilation. No local-time compilation bill, cold-cache surcharge or repeated preparation charge on execution.

Q15 — Confirmed. No universal protocol warning period. A contract may promise an upgrade/removal delay; an announced promise cannot be shortened. Deprecation remains a warning and does not itself disable execution.

Q16 — Confirmed direction. Use the declared authorized update/self-upgrade policy to deprecate or retire versions; enforce any notice the contract promised. A new version does not automatically retire all previous versions, and all canonical code remains permanent.

Q17 — Confirmed. Direct users may explicitly select a still-supported old executable version. Direct calls without a version, cross-contract calls and scheduled jobs resolve the latest visible executable version; no cross-contract or scheduled old-version pin/fallback. Current native storage/authorization rules still apply to old code.

Q18 — Confirmed. Reuse existing versioned DPP/Drive index-update rules exactly. Do not introduce a new index-backfill/migration subsystem. The inspected v1 validator rejects adding, removing or changing indexes on existing document types; new types may declare indexes through normal validation.

Q19 — Confirmed. Only active eligible evonodes vote in network freeze/wipe governance, with one vote each. This is separate from compilation readiness and from existing contested-index polls.

Q20 — Confirmed. Freeze, wipe, unfreeze and foreign-token vestige recovery require strictly more than two-thirds of all active eligible evonodes, one vote each. Votes have a one-week window and approve early after rechecking eligibility against agreed current membership. Require N > 0 and 3yes > 2N, equivalently floor(2*N/3)+1 yes votes. Exactly two-thirds fails. Compilation readiness remains at least 80% with its existing adaptive wait and no automatic expiry.

Q21 — Confirmed. Use current active membership when deciding a governance result; do not fix the electorate at opening. Revalidate eligible voters and denominator at a potential crossing. Approve early during the one-week window once strictly more than two-thirds is verified; also reconsider after membership changes.

Q22 — Confirmed. A network freeze blocks execution, spending and controlled writes; queries, current-state proofs and native bookkeeping continue. Frozen recipients may receive funds under Q30 and existing receiving rules.

Q23 — Confirmed. A network-voted freeze needs a network vote to lift it: strictly more than two-thirds of all active eligible evonodes, one vote each, a one-week window and early approval after eligibility recheck. Authorized contract updates stay frozen. Contract-defined freezes retain their declared rules; a wipe remains permanent.

Q24 — Confirmed. Freeze, wipe, unfreeze and foreign-token recovery use a one-week voting window with early approval after a verified strictly-more-than-two-thirds tally. Commit once at the defined block boundary before affected work. Votes not approved by expiry close without approval.

Q25 — Confirmed. Foreign tokens remain in the deleted-contract identity vestige until a separate network vote approves specific token IDs, amounts and a recipient. Require strictly more than two-thirds of all active eligible evonodes, one vote each, with a one-week window and early approval after eligibility recheck. Enforce native transfer validation and conservation; no unrestricted permanent recovery authority.

Q26 — Confirmed. Later storage refunds belonging to a wiped contract go to the current processing pool. A frozen but existing owner may receive native bookkeeping refunds without acquiring spending permission.

Q27 — Confirmed. Wipe applies immediate logical destruction with validated aggregate accounting, followed by bounded physical cleanup. Destroyed issuer tokens are unusable on every path. Foreign tokens survive in the vestige; canonical code is permanent.

Q28 — Confirmed. Every scheduled job declares an authorized contract balance bucket as execution/storage payer. The submitting signer pays registration; check live payer authority and funds before each run. Additional payers require explicit authorization.

Q29 — Confirmed direction. The routine declares Drop, Retry or Skip after deterministic execution failure. Specify bounded retry counts/intervals and exhaustion behavior. Each real attempt pays once; internal speculation is not an attempt. Preserve first-inability-to-pay removal using the prepaid drop reserve.

Q30 — Confirmed direction. Pause execution of jobs whose contract is frozen. Frozen identities/contracts may receive native funds without running frozen guest code; existing asset-specific and receiving permissions still apply. Proposed queue policy resumes future runs without a catch-up burst and cancels permanently missing methods.

Q31 — Confirmed. Each scheduled job declares its cancellation authority and reserves removal costs. Charge removal and return unused reserves to their recorded owner, or the current processing pool if that owner is a wiped contract. Preserve funded removal across fee upgrades or settle affected old jobs first.

Q32 — Confirmed. Receipt storage defaults to enabled and retention is contract-defined. No declared expiry means retain until authorized removal, not an invented automatic expiry. Canonical code retention remains independent.

Q33 — Confirmed. When enabled, reserve storage before execution and store bounded success and deterministic paid-failure receipts. Local node faults and internal speculative retries are not paid failure receipts.

Q34 — Confirmed. One contract-owned receipt per outer invocation, with bounded nested outcomes. The invocation payer pays; refunds follow the recorded owner. Each scheduled attempt is an invocation. Failed-call receipts are written outside rolled-back guest effects.

Q35 — Confirmed. Detached Rust values do not save automatically. Explicit insert/edit operations and successful exported persistent-receiver wrappers stage writes in the outer transaction. No save on Drop.

Q36 — Confirmed. Use simple persistence/index/rule attributes plus typed builders for advanced native features, producing one canonical manifest. Reject unsupported/conflicting declarations; native validation remains the authority. No unrestricted database paths.

Q37 — Confirmed. Randomness uses request then finalized-result lookup, including ordinary NotReady. The separate native primitive defines production randomness/finality/proofs; current contract work supplies boundaries and stubs, with no fabricated instant entropy.

Q38 — Confirmed. Private Rust fields and ACL checks are not encryption. Keep the private capability in the catalogue while encryption, key control, query visibility and proof behavior are separately specified before enabling its interface.

Q39 — Confirmed direction. Substantially extend contract create and update state transitions to carry large code/declarations. Apply larger bounded limits consistently on every ingress path; do not merely introduce an unrelated upload route. Initial single-transition form and exact sizes are engineering proposals.

Q40 — Confirmed delegation. Maintain one protocol-versioned allocation register. Supply provisional numeric limits and prices now, then measure and revise before activation. Allocate wire/storage/ABI IDs from actual registries; keep engine/profile pin and unmeasured native costs explicitly unresolved.

Q41 — Confirmed direction with caveat. Use determinism, replay, fees, conservation, native integration, upgrade/recovery tests and a working Rust example as release evidence. Owner agreed with hesitation. Exact test windows are engineering proposals; no audit/funding/deployer-allowlist gate or new recovery authority.

Q42 — Confirmed. QuantumExplorer owns all 160 tasks for now, including runtime, SDK and separate native ACL/randomness delivery. External issue links remain to be added; dates and durations remain unset.

Latest storage and packaging decisions

Recent owner choices, reconciled 11 September 2026:

• Several named WASM modules per immutable contract-version bundle; unchanged modules can be reused and the whole bundle activates together.

• Data-only contracts contain only local keys 0/1. Smart contracts add 2=EXEC, 3=COLLECTIONS and 4=RUNTIME.

• Create the 0/1 tree first, then add 2/3/4 as a distinct Merk application within the same atomic transaction, preserving documents key 1 as root. Authorized data-to-smart conversion follows the same required final shape.

• Scheduled jobs use consensus-time triggers and one jobs_due_time queue.

• Reuse the existing prefunded ledger at 40/128/balance_id for job removal, with purpose-aware native validation and preserved legacy voting behavior; no separate DashVM reserve subtree.

• Keep rs-drive-contracts separate from Drive and DashVM. Use rs-dash-sdk-contract / dash-sdk-contract / dash_sdk_contract for the contract-author SDK.

• Keep two VM crates: rs-dashvm-validation for deterministic WASM validation and required instrumentation; rs-dashvm for Wasmtime/Cranelift compilation, caching and execution.

Engineering recommendation updated: ordinary SumTree for contract-credit root/per-contract totals. This corrects the earlier blanket provable-sum proposal; it is distinguished from owner-confirmed policy. Exact remaining codecs, limits and identifiers still need implementation validation.

Complete storage mapping, rationale and task acceptance. All 160 tasks remain open and timing remains unset.

[QuantumExplorer]

Owner follow-up incorporated, 11 September 2026 — revision 11. DashVM is confirmed: pinned upstream Wasmtime/Cranelift, upstream fixes and deterministic scalar floating point. Current-state reads remain in force. All 160 tasks are owned by QuantumExplorer; dates and durations remain unset. Confirmed policy answers and provisional engineering limits. Production work remains open.

Part 6 of 14 · Revision 11 · 11 September 2026 · Parent plan · Decision register

Revision 8 capability coverage: Appendix A · Appendix B · Appendix C. This section's implementation includes the corresponding capability requirements and CAP-01–CAP-18 acceptance work. The reviewed product decisions below are unchanged; GroveDB review baseline is develop at c401b504.

6. VM-independent infrastructure

6.1 Smart-contract computation budget

Introduce consensus limits for smart-contract computation. Leave other execution and block-event budgeting at its existing layer, and keep the existing proposer timer for now. The original combined processing-credit accumulator covering all transitions and block events is superseded.

Specify units, per-execution and block bounds, and integration with reported gas. Include contract computation invoked by predicates, nested calls, and scheduled calls without double-counting it or redesigning the surrounding native event budgets. Failed execution consumes computation and is charged for work performed. Numeric limits, their calibration, and scheduled-work admission details remain to be specified.

6.2 Code deployment and retention

Substantially increase the permitted code state-transition size. The exact cap and whether to offer chunking are open. End-to-end limits must include signatures/encoding and align DPP, transport, DAPI, Tenderdash, storage, and clients. Do not retain the old mandatory 20 KiB/chunked-upload design or its fixed wire allocations as approved requirements.

Every accepted canonical contract version's WASM remains permanently in state. There is no zero-reference deletion/refund path for this permanent code, including after a contract wipe. Separate temporary upload staging, if introduced, from canonical code; its expiry, cleanup fees and refunds need a policy rather than inheriting the old prepaid queue.

Compilation, readiness voting, activation and local artifact retention are specified in section 8. Local cache deletion never deletes canonical code.

6.3 Current-state queries and proofs

Reuse GroveDB's existing query, proof, validation, and atomic-write capabilities. Add or expose range/paging/projection support where the new code and balance APIs need it, after checking current coverage. Bound response bytes and verify requested ranges, effective limits, and absence correctly across SDKs. This is a current-state service, not an arbitrary-past-height proof service.

6.4 Recurring execution infrastructure

Support scheduling needed by contract calls, with execution paid as it runs. A recurring loop is removed on its first failure to pay, and the removal cost must already be prepaid. Do not require prepayment of the entire recurring execution stream. Specify the payer, payment authorization, admission, bounded draining, cancellation, and frozen/unsupported-version handling alongside section 10.

6.5 Deferred native features

Oracle feeds, observer selection, median/aggregation policy, signed transport, and observer payments move to a later 5.x release. Escrow, allowances, and native auctions are not current priorities and have no release assignment. Their old Phase 1b tables, thresholds, queue funding rules, and protocol allocations are historical proposals. They are not prerequisites for contract execution, activation, scheduling, or 5.0.

6.6 Receipts

Receipt storage is part of the contract design, enabled by default and configurable by the contract. The original unconditional punt is superseded; section 10 specifies the work. Optional receipt history and temporary upload staging must not weaken permanent code retention.

Implementation tasks

• Define protocol-versioned per-call and per-block smart-contract computation limits and their gas representation. Keep numeric values and native-event budget changes out of the approved policy until specified. Source: S06-01.
• Enforce the contract computation limits consistently on proposal creation and validation, including predicates, nested calls and scheduled contract execution; integrate existing non-executed/rollback classifications and preserve native budgeting. Source: S06-02.
• Test exact-limit and over-limit contract work, fees on failure, repeated calls from one balance, scheduled work and epoch/fee boundaries; compare proposer/validator roots while existing non-contract handling remains consistent. Source: S06-04, S06-05.
• Implement canonical code/version storage, contract references, queries, and protocol activation initialization. Retain all accepted versions permanently; separate any temporary upload staging and local compiled artifacts. Source: S06-06.
• Extend contract create/update transitions for large canonical code and declarations; implement bounded versioned envelopes, native validation, costs, CheckTx and all transport/execution paths. Benchmark proposed size limits and decide whether chunking is necessary. Source: S06-07, S06-08.
• Add current-state proof and client result handling for code deployment and version references in Drive, the proof verifier and SDK converters. Source: S06-09.
• Test authorized deployment, hash mismatches, duplicate/replayed submissions, maximum size, permanent old-version retention and wipe survival. If chunking is selected, also specify and test ordering, partial uploads, staging ownership, completion, cleanup and refund rules. Source: S06-10, S06-11.
• Expose required current-state code/balance queries using existing GroveDB range and projection facilities; test paging, empty ranges, byte caps, effective limits, tampering and Element projection parity across native/WASM clients. Add new API versions only where needed. Source: S06-12, S06-13, S06-14.
• Build the scheduling integration needed for contract calls with bounded processing, correct fee-pool accounting and a prepaid drop cost; specify live payment/payer rules instead of requiring full future execution prepayment. Source: S06-23.
• Test scheduling conservation, blocks with only scheduled work, bounded backlog processing, first-payment-failure removal, prepaid removal cost and fee-table changes using the selected live-payment model. Source: S06-26.
• Document the distinction between current-state proofs, stored receipts and unproven execution-result text; reflect default-enabled contract-controlled receipts in ABI capabilities and client result semantics. Source: S06-28.

---

Revision 10 incorporates the returned owner review. Unresolved policies and provisional engineering values are labelled; implementation tasks remain open.

Owner review answers applying to this section

Q12 — Confirmed. Allow one pending executable update. A replacement atomically cancels the previous pending vote round and activation timer; current active code serves until the replacement is ready. Bind votes to deployment/round so they cannot transfer to replacement code.

Q13 — Confirmed. Do not expire pending deployments automatically. Allow authorized cancellation before activation, including during the wait; retain accepted canonical code permanently and refund unused preparation funds to the recorded payer after completed costs.

Q14 — Confirmed. The deployer pays bounded protocol validation and readiness-verification costs. Evonodes pay their own compilation. No local-time compilation bill, cold-cache surcharge or repeated preparation charge on execution.

Q28 — Confirmed. Every scheduled job declares an authorized contract balance bucket as execution/storage payer. The submitting signer pays registration; check live payer authority and funds before each run. Additional payers require explicit authorization.

Q31 — Confirmed. Each scheduled job declares its cancellation authority and reserves removal costs. Charge removal and return unused reserves to their recorded owner, or the current processing pool if that owner is a wiped contract. Preserve funded removal across fee upgrades or settle affected old jobs first.

Q39 — Confirmed direction. Substantially extend contract create and update state transitions to carry large code/declarations. Apply larger bounded limits consistently on every ingress path; do not merely introduce an unrelated upload route. Initial single-transition form and exact sizes are engineering proposals.

Q40 — Confirmed delegation. Maintain one protocol-versioned allocation register. Supply provisional numeric limits and prices now, then measure and revise before activation. Allocate wire/storage/ABI IDs from actual registries; keep engine/profile pin and unmeasured native costs explicitly unresolved.

[QuantumExplorer]

Owner follow-up incorporated, 11 September 2026 — revision 11. DashVM is confirmed: pinned upstream Wasmtime/Cranelift, upstream fixes and deterministic scalar floating point. Current-state reads remain in force. All 160 tasks are owned by QuantumExplorer; dates and durations remain unset. Confirmed policy answers and provisional engineering limits. Production work remains open.

Part 7 of 14 · Revision 11 · 11 September 2026 · Parent plan · Decision register

7. Bounded expression guards

Bounded expression guards remain an implementation work group inherited from the plan. They are not assigned their own protocol activation; assess them as an earlier-release candidate within the PV15–PV17 limit while building toward 5.0. This review did not separately approve every old grammar, serialization stamp, limit or error number.

Design to specify

Define deterministic, bounded expression semantics, static cost estimation, allowed field/value operations, action-specific context and failure codes. A restricted Rust evaluator with bounded parsing/type checking remains a proposal; verify its language and ABI choices in the DIPs. Guard computation falls under contract computation limits and the pre-execution affordability rule.

Integrate contract-only document permissions, the planned ACL model, existing triggers and GroveDB validation. Freeze must reject affected actions rather than suppressing a guard and allowing a write. Open deployment replaces the deployer allowlist. Reads must follow current execution state, including earlier accepted transitions and earlier operations in the same state-transition batch.

Define guard update applicability to existing documents, including creation/version metadata if needed, before allocating schema or serialization generations. Preserve old document decoding and refund ownership. Do not assume every contract update automatically makes older versions inactive; the lifecycle rules in section 11 apply.

Acceptance focus

Test parsing/type/field errors, missing values, integer boundaries, bounded evaluation, paid rejection, affordability before evaluation, authorization, freeze behavior, same-batch visibility, and consistency across architectures. CheckTx and RecheckTx validate structure and affordability without evaluating user guards. No separate audit, funding or allowlist gate is attached to this work group.

Implementation tasks

• Specify guard grammar, type/value semantics, action bindings and static cost rules in the DIPs; implement a bounded evaluator and canonical vectors with a WASM-compatible guest-facing representation. Source: S07-01, S07-02.
• Add guard schema/model/parser support and dispatch through allocated protocol generations; preserve older contracts and client serialization. Source: S07-03, S07-04.
• Specify guard update applicability and any required document creation/version stamps, including legacy documents and protected delete behavior. Implement registration validation and pricing without assuming the old stamp/schema numbers are fixed. Source: S07-05, S07-06.
• Allocate guard limits, fee/model/serialization and validation generations within the final PV15–PV17 plan; extend mocks and preserve the fee-registry prerequisite. Source: S07-07, S07-08, S07-09.
• Integrate guard context, previous-document access, live affordability and single charging with document validation/action conversion; use the shared no-execution CheckTx/RecheckTx rule. Source: S07-10.
• Validate referenced contracts and access rules under the chosen visibility model; apply contract-defined and voted freezes by rejecting affected actions. Remove the old deployer allowlist dependency. Source: S07-11.
• Preserve guard schema/configuration and structured error information across Rust, WASM, JS, Swift and Kotlin clients and persistence; record SDK parity. Source: S07-12, S07-13.
• Document guard syntax, costs, limits, update applicability and its eventual activation release after allocation is settled. Source: S07-14.
• Run parser/evaluator property tests, fuzzing, cost/result vectors and cross-architecture comparisons; cover deep nesting, bounded stack use, parse round trips and earlier evaluator behavior. Source: S07-15, S07-16.
• Add integration and upgrade tests for guard authorization, all action contexts, live-balance exhaustion, exact single charging, freeze rejection, update/legacy-document rules, batch visibility and deterministic roots under the final protocol allocation. Source: S07-17, S07-18.

---

Revision 10 incorporates the returned owner review. Unresolved policies and provisional engineering values are labelled; implementation tasks remain open.

Owner review answers applying to this section

Q05 — Confirmed. Reject repeated contract IDs on the active contract call stack, including A to B to A. Ordinary Rust helper calls and local recursion remain allowed within stack limits.

Q06 — Confirmed. Actual permission, resource, native validation and host/nested failures poison the whole outer call; catching them cannot retain partial effects. Internal speculative retries are not paid failures. Expected business alternatives can be successful typed return values.

Q08 — Confirmed. Read current execution state at the transition position in agreed block order, including accepted earlier transitions and own writes. Never expose later or abandoned speculative writes. Parallel execution must match sequential roots, results, fees and receipts; internal retries are not charged.

Q09 — Confirmed. Contracts may parameterize contested indexes only through supported native declarations. Native rules select and award the winner; guest code and custom guards cannot veto, delay, redirect or retry the award. No blocked-award or guest retry workflow. Make rule scopes explicit; enforce native validation, internal award authority, atomicity and lifecycle rules.

Q18 — Confirmed. Reuse existing versioned DPP/Drive index-update rules exactly. Do not introduce a new index-backfill/migration subsystem. The inspected v1 validator rejects adding, removing or changing indexes on existing document types; new types may declare indexes through normal validation.

[QuantumExplorer]

Owner follow-up incorporated, 11 September 2026 — revision 11. DashVM is confirmed: pinned upstream Wasmtime/Cranelift, upstream fixes and deterministic scalar floating point. Current-state reads remain in force. All 160 tasks are owned by QuantumExplorer; dates and durations remain unset. Confirmed policy answers and provisional engineering limits. Production work remains open.

Part 8 of 14 · Revision 11 · 11 September 2026 · Parent plan · Decision register

8. WASM execution, compilation, and activation

8.1 Runtime integration

DashVM uses confirmed pinned upstream Wasmtime with Cranelift. Contribute fixes upstream; retain a small Dash integration layer. The exact release/configuration and adoption measurements remain engineering work under Q02/Q40. The selected activation mechanism moves compilation readiness ahead of contract execution; the old mandatory wasmi configuration, bounded LRU assumption, first-use retranslation charge and no-JIT rule do not govern this revision.

The runtime needs deterministic WASM validation and execution, protocol-versioned host functions and metering, bounded resources, stable guest error classification, and exact build/configuration identification. No ambient clock, randomness, filesystem or network access should influence contract results. Choose and test the admitted WASM features and exact limits in the DIPs; do not copy the old compiler-specific stack/fuel settings without validation.

8.2 Approved readiness and activation policy

1. Deploy the contract through the accepted deployment path. Each evonode compiles it before reporting ready.
2. Count at least 80% of the entire active evonode set, once per evonode. The denominator is not the currently selected validator quorum.
3. Let T be the elapsed time from deployment to the first committed 80% readiness threshold.
4. Wait one additional T, clamped to 2 minutes minimum and 1 hour maximum, then activate.

additional_wait = min(max(T, 120 seconds), 3600 seconds)
activation_time = time_80_percent_reached + additional_wait

Time to reach 80%	Additional wait	Total from deployment
30 seconds	2 minutes	2 minutes 30 seconds
5 minutes	5 minutes	10 minutes
90 minutes	1 hour	2 hours 30 minutes

The normal total is 2T, not 3T. The one-hour maximum applies only to the additional wait. This supersedes the earlier two-thirds trigger and fixed ten-minute window. There is no approved automatic activation below 80%, deadline for collecting votes, or second gate requiring current-validator-quorum readiness.

Selected: prune ineligible readiness votes when the tally could reach 80%; use agreed current membership, coherent chain time and one pending executable update. Replacement cancels its predecessor round/timer. No automatic expiry; authorized cancellation returns unused preparation funds after costs. Engineering work: exact membership phase/predicate, bounded transport and eligibility checking, crash recovery and protocol profile. A count tree is not proof of voter eligibility.

8.3 Code versions and compiled artifacts

Keep every canonical WASM version permanently in state. Retain ready-to-run compiled copies for versions that remain executable. Deprecation is a warning, so it does not by itself make a cached version disposable. Compiled copies of non-executable versions may be removed and rebuilt under the correct historical engine/rules for replay.

Design persistent cache capacity, compatibility keys, verification and failure handling around executable versions rather than making a node's local eviction determine on-chain contract validity. Code hash, engine/configuration, protocol semantics and architecture are inputs to artifact compatibility; the exact format and retention strategy are engineering choices. Votes prove reported readiness, not correctness of compiled machine code. Imported artifacts must not become an unvalidated trust shortcut.

8.4 Registration, ABI and invocation

Registration checks code/ABI/capabilities and bounds before admission. The deployer pays bounded protocol validation/readiness verification; nodes pay their own compilation. No cold-cache execution surcharge. Exact rates and resource caps are provisional engineering allocations. Avoid putting unbounded compiler work on the contract execution path.

Define canonical document/context encodings, pointer/length checks, imports, exports and error codes in the ABI. Host calls remain capability-limited and feed existing Drive validation/atomic effects. CheckTx/RecheckTx do structure and affordability checks only. Before any guest runs, check the live full bound, freeze/lifecycle status and the consensus activation status.

Engine behavior is selected by protocol version. Adoption tests and replay evidence precede selecting an exact revision. Runtime upgrades need an explicit preparation and compatibility plan; preserve execution of previously accepted code rather than silently assigning a new compiler's behavior to historical executions.

Implementation tasks

• Implement the Dash runtime abstraction, protocol-versioned engine dispatch and deterministic configuration for the selected engine; specify persistent compiled-cache behavior for executable versions and historical replay. Source: S08-01, S08-02.
• Implement bounded module preparation/registration and selected structural, compilation, stack, memory, code-size and execution limits; charge according to the specified model and classify failures consistently. Source: S08-03, S08-04.
• Add versioned module references and method/capability declarations to contracts. Specify how validation-module updates interact with contract-version activation, deprecation and protected documents; do not retain the old immutable-field restriction without resolving that interaction. Source: S08-05, S08-06.
• Implement the canonical guest ABI/context/document representation, capabilities and result-code rules; cover every supported Platform value and bound guest-wire expansion independently of stored byte size. Source: S08-07.
• Integrate predicate execution with activation/lifecycle/freeze checks, live affordability, checked metering, contract-only computation budgeting, existing fee charging, nonce handling and structured SDK errors; allocate actual version tables centrally. Source: S08-08, S08-09, S08-10, S08-11, S08-12.
• Specify and implement preparation on upgrades, restarts and cache loss. Replace the original lazy-first-call preparation policy with behavior consistent with readiness activation and deterministic historical replay; keep missing-cache handling from changing consensus validity. Source: S08-13.
• Deliver guest SDK/macros, typed document generation, native reference harness, actual-runtime tests, CLI build/check and small contract examples. Native reference execution compares outcomes; consensus fuel/cost comes from the metered runtime. Source: S08-14, S08-15, S08-16, S08-17, S08-18, S08-19.
• Add adversarial/golden runtime vectors, proposal/validator integration, cold/warm/recovered-cache comparisons, cross-architecture execution and historical replay, including integer edges, stack/memory exhaustion and host-call fuel boundaries. Source: S08-20, S08-21, S08-22.
• Validate every runtime/host error mapping, pointer/length boundary and deterministic configuration path; fuzz preparation and ABI decoding. Test that guest input cannot select ambient I/O, nondeterministic values or unbounded resource use. Source: S08-23.
• Track security fixes/advisories for the selected dependencies and apply the execution/fee-equivalence hotfix rule. No external-audit report, named security owner or closed stage audit is a prerequisite to building. Source: S08-24.
• Wire runtime and serialization generations into the final PV15–PV17 allocation and document compilation readiness, lifecycle, error handling and upgrade behavior using the approved decisions. Source: S08-25.
• Implement distinct evonode readiness votes with threshold-triggered eligibility pruning against agreed current membership. Reconsider on membership changes and commit only a fully validated 80% crossing.
• Specify consensus-time and activation-block conventions; implement the additional wait clamp(T, 2 minutes, 1 hour). Test just below/at 80%, duplicate votes, threshold persistence, and timing below/inside/above both bounds. New work from the review.
• Implement pending update replacement/cancellation, permanent accepted code, unused preparation refunds, no automatic expiry, and node/cache/engine recovery without a below-threshold fallback.

---

Revision 10 incorporates the returned owner review. Unresolved policies and provisional engineering values are labelled; implementation tasks remain open.

Owner review answers applying to this section

Q01 — Confirmed. Use pinned upstream Wasmtime with Cranelift and a small Dash integration layer; contribute fixes upstream. A necessary temporary patch is an exception, not a standing engine fork.

Q02 — Confirmed direction. Coordinate engine behavior changes through normal protocol upgrades and preserve historical replay. Select the exact release, locked dependencies, Cranelift configuration and adoption evidence through engineering tests.

Q03 — Confirmed. Call the complete execution system DashVM. Wasmtime is its runtime and Cranelift its compiler; exact crate and command names remain engineering allocations.

Q04 — Confirmed. Allow f32/f64 with explicit Cranelift NaN canonicalization and deterministic host/profile tests. SIMD and relaxed SIMD are separate profile choices; proposed initial profile disables both.

Q10 — Confirmed direction. When readiness could cross 80%, revalidate voters against current agreed active membership and prune ineligible votes before accepting the crossing. A count tree may maintain raw votes but is not eligibility proof. Membership changes must also trigger reconsideration; bounded checks must use one coherent membership view.

Q11 — Confirmed direction. Use committed chain timestamps and a defined activation boundary. Every node must use the same Core membership view referenced by the Platform block, after the same membership-update phase. Preserve additional wait clamp(T, 2 minutes, 1 hour); exact phase/predicate belongs in the DIP.

Q12 — Confirmed. Allow one pending executable update. A replacement atomically cancels the previous pending vote round and activation timer; current active code serves until the replacement is ready. Bind votes to deployment/round so they cannot transfer to replacement code.

Q13 — Confirmed. Do not expire pending deployments automatically. Allow authorized cancellation before activation, including during the wait; retain accepted canonical code permanently and refund unused preparation funds to the recorded payer after completed costs.

Q14 — Confirmed. The deployer pays bounded protocol validation and readiness-verification costs. Evonodes pay their own compilation. No local-time compilation bill, cold-cache surcharge or repeated preparation charge on execution.

Q15 — Confirmed. No universal protocol warning period. A contract may promise an upgrade/removal delay; an announced promise cannot be shortened. Deprecation remains a warning and does not itself disable execution.

Q16 — Confirmed direction. Use the declared authorized update/self-upgrade policy to deprecate or retire versions; enforce any notice the contract promised. A new version does not automatically retire all previous versions, and all canonical code remains permanent.

Q17 — Confirmed. Direct users may explicitly select a still-supported old executable version. Direct calls without a version, cross-contract calls and scheduled jobs resolve the latest visible executable version; no cross-contract or scheduled old-version pin/fallback. Current native storage/authorization rules still apply to old code.

Named modules — owner direction recorded 11 September 2026

Support several named WASM modules in one contract version in 5.0; a single-module bundle remains valid. Pin exact modules and interfaces in one immutable manifest, reuse unchanged canonical modules across versions, and activate the whole bundle under the existing readiness rule. Detailed linking, initialization and fee rules remain engineering proposals.

Detailed storage, linking, initialization, accounting and 16 expanded task acceptances. References above to a module/code archive now allow the complete named-module bundle. Canonical blobs and immutable manifests remain permanent; public methods map to module exports. Readiness covers every module, internal calls share one authority/budget/atomic scope, and cross-contract/scheduled latest-version routing is unchanged. Proposed ABI/linker/initializer specifics require engineering validation; this amendment does not claim implementation or measured limits.

[QuantumExplorer]

Owner follow-up incorporated, 11 September 2026 — revision 11. DashVM is confirmed: pinned upstream Wasmtime/Cranelift, upstream fixes and deterministic scalar floating point. Current-state reads remain in force. All 160 tasks are owned by QuantumExplorer; dates and durations remain unset. Confirmed policy answers and provisional engineering limits. Production work remains open.

Part 9 of 14 · Revision 11 · 11 September 2026 · Parent plan · Decision register

Revision 8 capability coverage: Appendix A · Appendix B · Appendix C. This section's implementation includes the corresponding capability requirements and CAP-01–CAP-18 acceptance work. The reviewed product decisions below are unchanged; GroveDB review baseline is develop at c401b504.

9. Reads, visibility, and current-state proofs

9.1 State visibility

Each transition reads the current execution state at its position in the agreed block order, including accepted effects of earlier transitions and its own earlier operations. Later transitions and unvalidated speculative writes are never visible. Specify all host reads and nested calls against this view, including contract metadata, methods, balances and indexes. CPU completion order cannot choose visible state.

For cross-contract calls, resolve the latest target version/method visible under that rule. A missing/non-executable latest matching method fails rather than selecting old code. Pending-version activation/handover and direct/scheduled routing still need precise lifecycle definitions; do not turn a local compiled-cache lookup into method selection.

Native affordability, authorization, revisions, uniqueness and atomic effects must agree with the ordered execution view. Test that parallel scheduling produces the same outcome as sequential execution, including fees and failures. Internal retries cannot create an additional contract failure or machine-dependent fee.

9.2 Reads, capabilities, and bounds

Reuse existing GroveDB read/index capabilities. The prior declared-footprint model remains an implementation proposal, with canonical encoding, capability checks, bounded result bytes, host-call limits, cost estimation and absence semantics to specify. The proposed 5% undeclared-read fallback policy is deferred and is not a current gate. Do not imply that omitting the fallback decides its replacement.

Bound stored documents, decoded values and guest wire representations separately. Nested property names, wrappers, system fields and repeated copies can expand the guest encoding. Compute/test sound limits using the actual serializers and schema rules; increasing code upload size is not proof that all document/guest encodings are bounded by the same number.

9.3 Proof scope

Provide current-state proofs using GroveDB for supported contract data, balances, code/lifecycle and stored receipts. There is no requirement to serve proofs for arbitrary past heights or reconstruct a historical execution proof service. Historical block replay is retained under the corresponding protocol rules, independently of query proof retention.

Clients must distinguish current state and stored receipts from an execution claim. When receipts are disabled, absence of a stored receipt must not be represented as proof that a call succeeded or failed. Receipt format and result-verification details belong to section 10.

9.4 Preflight

Network preflight is excluded from 5.0, including its DAPI endpoint, SDK bindings, availability flags, pool/disable configuration and launch criteria. No later release is assigned. Local fixture-based contract testing and offline cost tooling remain useful development tools; they do not add a live preflight endpoint to this release. CheckTx/RecheckTx structure and affordability checks remain required and do not execute contract code.

Implementation tasks

• Specify canonical read requests/declarations and structured errors, then implement the selected wire/context model with signing and decoding coverage; leave exact ABI/version allocations to the central register. Source: S09-01, S09-02, S09-03.
• Specify read and host-call cost bounds, stored-document/guest-wire limits and memory/copy caps. Integrate full affordability estimates and protocol tables; omit preflight limits and endpoints from 5.0. Source: S09-04, S09-05, S09-06.
• Implement host read resolution through existing GroveDB capabilities using current execution state including earlier accepted transitions and same-transition prior effects, with authorization, byte/call limits, deterministic absence/error results and single charging. Keep CheckTx checks structural and non-executing. Source: S09-07, S09-08, S09-09, S09-10.
• Expose the selected read-declaration inputs and current-state proof results in Rust/WASM/JS/mobile call/document builders and parity manifests, without network preflight surfaces in 5.0. Source: S09-13, S09-14, S09-15.
• Add typed read constructors, canonical vectors, fixtures and block/batch visibility tests to guest SDK/tooling; use local fixtures for tests and metered cost reports. Source: S09-16, S09-17.
• Document ordered current-state and same-batch visibility, capabilities, bounds, current-state proof limits and the explicit preflight exclusion. Source: S09-18.
• Test missing values, unauthorized reads, canonical encoding, caps, repeated copies and failed-read charging. Cover visibility of earlier accepted transitions and isolation from later or abandoned speculative transitions, same-transition prior-write visibility, metadata/index updates and cross-architecture roots; do not claim arbitrary transaction reorderings preserve all effects. Source: S09-19, S09-20, S09-21.
• Test current-state proofs for contract data/balances/code and enabled receipts, including tampered or wrong-root proofs. Keep historical execution replay tests distinct; do not require a past-height proof endpoint. Source: S09-22.
• Add upgrade, adversarial-bound and fuzz coverage for reads and guest encodings: deep/nested schemas, large indexes, absent entries, serializer growth, maximum signed wire size and worst-case repeated copies. Verify actual cost stays within the admitted bound. Source: S09-23, S09-24, S09-25, S09-26.

---

Revision 10 incorporates the returned owner review. Unresolved policies and provisional engineering values are labelled; implementation tasks remain open.

Owner review answers applying to this section

Q08 — Confirmed. Read current execution state at the transition position in agreed block order, including accepted earlier transitions and own writes. Never expose later or abandoned speculative writes. Parallel execution must match sequential roots, results, fees and receipts; internal retries are not charged.

Q38 — Confirmed. Private Rust fields and ACL checks are not encryption. Keep the private capability in the catalogue while encryption, key control, query visibility and proof behavior are separately specified before enabling its interface.

[QuantumExplorer]

Owner follow-up incorporated, 11 September 2026 — revision 11. DashVM is confirmed: pinned upstream Wasmtime/Cranelift, upstream fixes and deterministic scalar floating point. Current-state reads remain in force. All 160 tasks are owned by QuantumExplorer; dates and durations remain unset. Confirmed policy answers and provisional engineering limits. Production work remains open.

Part 10 of 14 · Revision 11 · 11 September 2026 · Parent plan · Decision register

10. Entry points, cross-contract calls, and scheduled execution

10.1 Contract calls and authorization

The first smart-contract scope includes entry points and calls between contracts. Define methods, capabilities, argument/result encodings, caller authentication, and operation limits. Do not carry forward the old single-entry-point/no-nesting restriction or defer contract composition beyond the first release.

Ordinary contract balances use the dedicated sum tree and credit/token buckets; no identity is created for a live contract. Contract rules control assets and protected document writes. They may authorize identities/groups and pay one or multiple identities or another contract when both permit it. The direct-call signer pays processing/storage, with storage refunds to the recorded owner. Reject unauthorized effects through existing native validation.

10.2 Cross-contract routing and atomic effects

Resolve a call by contract and method against the latest version visible under section 9's state view. No older-version pinning or fallback is allowed. If the latest version has no executable matching method, fail the call. Specify activation handover and method compatibility so an update cannot make routing depend on local compilation completion.

Reuse existing GroveDB validation, indexes and atomic writes. Preserve all-or-nothing contract effects. The selected nested model rejects active-contract reentry, delegates only explicit rights and shares atomic effects and resource limits. Actual host/nested failures poison the outer call; internal speculative retries are not paid failures. Numeric depth/resource bounds remain provisional. Do not present the old one-savepoint-per-call design or a new index algorithm as selected prerequisites.

Proposed operations must be bounded in count, encoded/decoded size, resource use and cost. Native validation must account for earlier effects where needed to detect duplicate unique keys, balance conflicts and unauthorized operations. Guest reads and native validation use the correct ordered current state, including earlier accepted effects. Do not execute an unaffordable unit and then rely on an unapproved fee-writeoff/degradation policy.

10.3 Receipts and result verification

Contracts control execution receipt storage; the default is enabled. A contract may disable it because storage has a cost. Specify the format, receipt owner, retention/update rules, success/paid-failure behavior, tamper protection, effect linkage and charging. The old fixed system-contract/last-call-slot design is an implementation alternative, not an approved storage requirement.

Stored receipts and contract effects may be covered by current-state proofs while present. Do not promise a stored execution proof when a contract disables receipt storage or when the required record no longer exists. Canonical code versions are permanently retained regardless of receipt settings, and this receipt policy does not require arbitrary past-state proofs.

10.4 Scheduled and recurring calls

Scheduled execution does not require all future execution to be prepaid. A recurring loop is dropped on its first failure to pay, using a prepaid drop cost. Specify who pays, how payment is authorized, admission/reservation, bounded processing, cancellation, and behavior under freeze, unsupported versions and engine updates. The payment rule alone does not select a retry rule for every non-payment failure.

Direct users may select a still-supported old version; schedules and cross-contract calls resolve the latest visible executable version, with no old fallback. Scheduling must use agreed chain state and maintain conservation through execution, failure, removal and fee changes. Native escrow/allowances/auctions are deferred and are not dependencies.

10.5 Ordering and scope boundaries

Keep the existing transaction ordering protocol and assess ordering exposure for each value-moving capability. No external bridge or wrapped-asset mechanism is included. Native DASH entry remains Core-to-Platform asset lock; no single custodian becomes canonical. No direct contract Core withdrawal or separate contract withdrawal allowance is added.

Implementation tasks

• Specify and implement contract-call transitions, method declarations, ABI, authentication/capabilities, structured errors and bounded host operations under allocated protocol generations; include cross-contract calls in the first scope. Source: S10-01, S10-02.
• Implement call action conversion and separate contract sum balances/token buckets through existing Drive validation; test conservation, bucket permissions, deposit rules, multi-identity payouts and mutually permitted contract transfers. Source: S10-03, S10-04.
• Specify and implement default-enabled contract-controlled receipt storage and current-state result verification, including disabled receipts, bounded deterministic paid-failure receipts, effect linkage, retention, charging, ownership and tamper protection. Source: S10-05.
• Integrate full live affordability, bounded operation estimation, actual single charging and atomic GroveDB effects for direct/nested calls; preserve native validation and explicitly specify nested failure/rollback semantics. Source: S10-06.
• Implement authorized live-paid scheduling, declared Drop/Retry/Skip, bounded retries, first-payment-failure removal, frozen-execution pause and explicit cancellation settlement. Source: S10-07.
• Expose call builders, activation/lifecycle status, structured errors and honest receipt/current-state result semantics in Rust/WASM/JS/Swift/Kotlin SDKs. Deliver guest entry-point support, local fixture tests and examples without adding network preflight to 5.0. Source: S10-08, S10-09, S10-10.
• Test all call outcome classes, authorization boundaries, exact live-balance/fee limits, uniqueness conflicts, protected documents, bucket conservation, refunds, receipt configuration/tampering and stored/guest-wire size bounds. Verify failure leaves only the specified fee/nonce/receipt effects. Source: S10-11.
• Run mixed direct/nested/recurring-call strategy and upgrade tests across both proposal paths and architectures; cover execution, first-payment-failure removal, cancellation and frozen/unsupported behavior once specified. Native auction/allowance/prepaid-subscription fixtures are not required scope. Source: S10-12.
• Fuzz call and proposed-operation decoding/validation/application boundaries; test current-state proof/result converters and maximal signed call size using the final cap, without assuming 20 KiB or mandatory receipt retention. Source: S10-13.
• Implement explicit delegated rights, distinct signer/caller identity, no active-contract reentry and one shared atomic effect/resource scope. Actual nested failures poison the whole call; internal speculative retries are not failures.
• Implement latest-visible method routing for cross-contract calls and schedules; direct users may select supported old code. Test current storage permissions, missing methods, frozen targets and atomic activation handover.

---

Revision 10 incorporates the returned owner review. Unresolved policies and provisional engineering values are labelled; implementation tasks remain open.

Owner review answers applying to this section

Q05 — Confirmed. Reject repeated contract IDs on the active contract call stack, including A to B to A. Ordinary Rust helper calls and local recursion remain allowed within stack limits.

Q06 — Confirmed. Actual permission, resource, native validation and host/nested failures poison the whole outer call; catching them cannot retain partial effects. Internal speculative retries are not paid failures. Expected business alternatives can be successful typed return values.

Q07 — Confirmed. Delegate only explicitly granted rights; retain original signer and immediate caller separately. Never automatically pass all signer rights to a callee.

Q08 — Confirmed. Read current execution state at the transition position in agreed block order, including accepted earlier transitions and own writes. Never expose later or abandoned speculative writes. Parallel execution must match sequential roots, results, fees and receipts; internal retries are not charged.

Q17 — Confirmed. Direct users may explicitly select a still-supported old executable version. Direct calls without a version, cross-contract calls and scheduled jobs resolve the latest visible executable version; no cross-contract or scheduled old-version pin/fallback. Current native storage/authorization rules still apply to old code.

Q28 — Confirmed. Every scheduled job declares an authorized contract balance bucket as execution/storage payer. The submitting signer pays registration; check live payer authority and funds before each run. Additional payers require explicit authorization.

Q29 — Confirmed direction. The routine declares Drop, Retry or Skip after deterministic execution failure. Specify bounded retry counts/intervals and exhaustion behavior. Each real attempt pays once; internal speculation is not an attempt. Preserve first-inability-to-pay removal using the prepaid drop reserve.

Q30 — Confirmed direction. Pause execution of jobs whose contract is frozen. Frozen identities/contracts may receive native funds without running frozen guest code; existing asset-specific and receiving permissions still apply. Proposed queue policy resumes future runs without a catch-up burst and cancels permanently missing methods.

Q31 — Confirmed. Each scheduled job declares its cancellation authority and reserves removal costs. Charge removal and return unused reserves to their recorded owner, or the current processing pool if that owner is a wiped contract. Preserve funded removal across fee upgrades or settle affected old jobs first.

Q32 — Confirmed. Receipt storage defaults to enabled and retention is contract-defined. No declared expiry means retain until authorized removal, not an invented automatic expiry. Canonical code retention remains independent.

Q33 — Confirmed. When enabled, reserve storage before execution and store bounded success and deterministic paid-failure receipts. Local node faults and internal speculative retries are not paid failure receipts.

Q34 — Confirmed. One contract-owned receipt per outer invocation, with bounded nested outcomes. The invocation payer pays; refunds follow the recorded owner. Each scheduled attempt is an invocation. Failed-call receipts are written outside rolled-back guest effects.

Named modules — owner direction recorded 11 September 2026

Support several named WASM modules in one contract version in 5.0; a single-module bundle remains valid. Pin exact modules and interfaces in one immutable manifest, reuse unchanged canonical modules across versions, and activate the whole bundle under the existing readiness rule. Detailed linking, initialization and fee rules remain engineering proposals.

Detailed storage, linking, initialization, accounting and 16 expanded task acceptances. References above to a module/code archive now allow the complete named-module bundle. Canonical blobs and immutable manifests remain permanent; public methods map to module exports. Readiness covers every module, internal calls share one authority/budget/atomic scope, and cross-contract/scheduled latest-version routing is unchanged. Proposed ABI/linker/initializer specifics require engineering validation; this amendment does not claim implementation or measured limits.

Scheduled-job clock — confirmed

Scheduled contract jobs use time-based triggers only, evaluated against agreed consensus time. Keep one jobs_due_time index. Remove height-based and epoch-based scheduled-job queues and trigger modes from the current scope; do not create empty placeholders or silently translate those unsupported modes into times.

R10-05 acceptance: Use only the jobs_due_time queue, with agreed consensus-time deadlines and deterministic tie-breaking. Recurrence and retry delays are time-based. Update job records and the time index atomically on registration, retry, cancellation and removal; reject unsupported scheduling modes before storing a job. Local wall clocks cannot decide consensus execution.

R10-06 acceptance: Expose only time-based scheduled-job triggers in client/guest declarations, call builders and serialized scheduling descriptors. Keep SDK and native validation consistent; no placeholder height/epoch trigger support.

R10-08 acceptance: Verify time-based due ordering, recurrence, retries, cancellation, frozen-job handling and first-payment-failure removal across both proposal paths. Verify unsupported height/epoch scheduling requests fail without creating jobs or queues; node-local clock differences do not change due jobs.

Current queue storage mapping.

Existing prefunded balances — confirmed reuse

Reuse the existing prefunded balance ledger and operations for scheduled-job removal funding. Use the existing 40/128/balance_id storage with purpose-bound job identifiers and native spending validation; do not add a dedicated DashVM reserve subtree or duplicate monetary ledger. Preserve legacy voting identifiers, balances and behavior. Job owner/purpose/refund metadata contains no second credit amount.

Native integration, purpose validation, ownership/refunds and revised storage mapping. R10-05, R12-10 and CAP-09 include these acceptance requirements. The same storage supplement also records the ordinary-SumTree engineering recommendation, separately from confirmed owner choices.

[QuantumExplorer]

Owner follow-up incorporated, 11 September 2026 — revision 11. DashVM is confirmed: pinned upstream Wasmtime/Cranelift, upstream fixes and deterministic scalar floating point. Current-state reads remain in force. All 160 tasks are owned by QuantumExplorer; dates and durations remain unset. Confirmed policy answers and provisional engineering limits. Production work remains open.

Part 11 of 14 · Revision 11 · 11 September 2026 · Parent plan · Decision register

11. Determinism, lifecycle, freeze/wipe, and engine governance

11.1 Determinism and failures

The same accepted execution under the same protocol rules must produce the same outcome, fees and state on all supported nodes, independent of architecture, local cache state or local settings. Version metering, host semantics, limits and engine behavior. Bound compiler/guest work and validate all guest-controlled sizes, paths, pointers and values.

Map guest rejection, traps, exhaustion and invalid operations to the specified paid outcomes. Charge consumed work once and roll back contract effects according to the atomicity rules. Genuine database corruption or node faults remain distinct; do not hide them as a contract rejection. Keep existing recovery and remove failing state transitions from the proposer. The old additional denylist-distribution, special network-height recovery binary and drain-halt mechanism are not selected.

Remove node-local switches that can change contract execution or credit/token conservation results. Keep the existing proposer timer while its final policy is deferred. Local operational settings may control preparation/resources only where they do not change consensus validity or execution results; cache loss is a readiness/recovery concern, not an alternative contract rule.

11.2 Contract version lifecycle

Keep every canonical code version permanently in state, including after updates, inactivity and wipes. An update may mark earlier versions deprecated or unsupported under explicit inactivity rules. Deprecated means a warning period, not execution disablement. A newer version does not automatically retire every older one.

Keep compiled copies for versions still executable. Inactive compiled copies can be deleted locally and rebuilt under the corresponding historical engine/rules for replay. Use declared update authority, no universal warning minimum, binding contract-promised notice, supported-version selection for direct calls and latest-version scheduling. Cross-contract calls always use the latest visible version/method without pinning or fallback. Pending-version handover must be defined consistently with compilation activation.

11.3 Freeze, unfreeze, temporary freeze, and wipe

Contracts define their own freeze, unfreeze and temporary-freeze rules. Freeze, wipe, unfreeze and foreign-token vestige recovery require strictly more than two-thirds of all active eligible evonodes, one vote each. Votes have a one-week window and approve early after rechecking eligibility against agreed current membership. Require N > 0 and 3yes > 2N, equivalently floor(2*N/3)+1 yes votes. Exactly two-thirds fails. Compilation readiness remains at least 80% with its existing adaptive wait and no automatic expiry. Existing contested-index polls retain their own native rules.

Freeze rejects affected actions; it must not bypass a guard, predicate or contract rule. Specify the exact affected surfaces and scheduled behavior. No approved-deployer allowlist or named emergency key-holder hierarchy is required by the selected policy.

On a successful wipe:

Item	Selected disposition
Contract data	Wiped according to the voted scope; exact covered records and cleanup procedure need specification.
Every canonical contract code version	Remains permanently in state.
Contract credits	Added to the current processing pool.
Tokens issued by this contract	Destroyed; they cease to exist, including balances held outside the wiped contract.
Other contracts' tokens held by this contract	Retained in a special deleted-contract identity vestige.

Foreign tokens remain in the deleted-contract identity vestige until a separate network vote approves specific token IDs, amounts and a recipient. Require strictly more than two-thirds of all active eligible evonodes, one vote each, with a one-week window and early approval after eligibility recheck. Enforce native transfer validation and conservation; no unrestricted permanent recovery authority. Exact storage representation remains engineering work. Implement token-supply and holder accounting consistently with destruction; specify treatment of associated indexes, references, scheduled work, receipts and any prepaid removal balance without inventing additional asset distributions or code deletion.

11.4 Engine upgrades and maintenance

Dash remains responsible for its integration and security fixes. Use pinned upstream Wasmtime/Cranelift with a small Dash integration layer and upstream contributions. An exact revision is adopted after comparison testing and an agreed test period. Internal engine behavior is versioned, and each execution is associated with its protocol version; preserve execution of previously accepted code.

A software-only hotfix is permitted only when execution and fees remain identical. A change in either requires a protocol upgrade. Test traps and resource boundaries as well as successful results, since those affect charged behavior. Historical-engine packaging and artifact retention are unresolved engineering details; no mandatory vendored wasmi-engine-vN layout is approved.

11.5 Implementation checks and ordering

The named security-owner, threat-register and closed audit prerequisite is removed, as are audit/funding release gates. Determinism tests, fuzzing, fee/conservation tests and the selected engine adoption checks remain engineering work, not claims that any audit has passed.

Keep the existing ordering protocol and assess ordering exposure for each value-moving feature. External bridges/wrapped assets require a separate future design; no bridge custody policy or exposure cap is selected here.

Implementation tasks

• Enforce deterministic host/runtime configuration and dependency identification with appropriate linting and tests; keep golden outcomes/costs per protocol engine behavior and detect accidental dependency/configuration drift. Source: S11-01, S11-02.
• Inspect consensus-path configuration and remove switches that alter contract execution or credit/token conservation. Preserve test-only controls and legitimate existing proposer timing; verify equal block results under remaining local configurations. Source: S11-03, S11-04.
• Implement explicit guest/host fault classification and inject failures on proposer, validator and scheduled paths. Assert atomic contract rollback and only specified fee/nonce/receipt/queue effects on paid failure; retain existing recovery behavior. Source: S11-06, S11-07, S11-08.
• Share sound full-bound estimation, live affordability and exact actual charging across hooks, direct/nested calls and scheduled contract work. Enforce only the new smart-contract computation budget; retain native execution/event budgeting and test both proposal paths. Source: S11-09, S11-10, S11-11, S11-12.
• Document how protocol changes update metering, limits, cost vectors and compatibility evidence. Use appropriate measurements to choose limits without reintroducing the deferred hardware publication requirement. Source: S11-13.
• Bound compilation/preparation, executable-cache resources and invocation/instantiation work consistently with readiness activation; test cache loss and cold/recovered nodes. Do not make block validity depend on counting local cache misses. Source: S11-14.
• Document the selected software-hotfix versus protocol-upgrade rule and integration with existing recovery. Test proposer removal of failing transitions; do not add the old bespoke recovery/denylist-distribution mechanisms. Source: S11-16.
• Maintain pinned upstream Wasmtime/Cranelift with a small Dash integration layer and upstream fixes; retain locked historical engine profiles for replay. Source: S11-17.
• Build engine compatibility/differential tooling over stored contract versions, recorded executions and adversarial generated modules; report result, fee, trap and resource differences, preserve historical replay, and use equivalence evidence for software-only hotfixes. Source: S11-18, S11-19.
• Specify and implement contract-defined freeze/unfreeze/temporary freeze and masternode freeze/wipe voting with a one-week voting window (early approval versus end-only decision remains unresolved). Resolve voter eligibility, thresholds and execution boundaries; reject affected actions without bypassing logic, and omit the old deployer allowlist. Source: S11-20.
• Version selected resource limits and feature gates in the final allocation; test pre-activation rejection and correct active behavior without inventing unchosen constants. Source: S11-22.
• Test scheduled execution under traps, exhaustion, freeze, unsupported versions, fee changes and payment failure, using live payment and prepaid drop cost. Verify deterministic queue effects, conservation and existing host-fault handling. Source: S11-23.
• Document and assess ordering exposure per value-moving capability using the existing ordering protocol; deferred native primitives and bridges are not current prerequisites. Source: S11-24.
• Implement declared update authority, optional contract-promised notice, explicit deprecation/retirement, direct supported-version selection and latest cross-contract/scheduled routing. Preserve canonical code and atomic pending-update replacement.
• Implement bounded wipe accounting: credits and later refunds to current processing pool, issuer tokens destroyed everywhere, foreign tokens held in a vestige until separate network-authorized recovery, and permanent code retention.

---

Revision 10 incorporates the returned owner review. Unresolved policies and provisional engineering values are labelled; implementation tasks remain open.

Owner review answers applying to this section

Q15 — Confirmed. No universal protocol warning period. A contract may promise an upgrade/removal delay; an announced promise cannot be shortened. Deprecation remains a warning and does not itself disable execution.

Q16 — Confirmed direction. Use the declared authorized update/self-upgrade policy to deprecate or retire versions; enforce any notice the contract promised. A new version does not automatically retire all previous versions, and all canonical code remains permanent.

Q17 — Confirmed. Direct users may explicitly select a still-supported old executable version. Direct calls without a version, cross-contract calls and scheduled jobs resolve the latest visible executable version; no cross-contract or scheduled old-version pin/fallback. Current native storage/authorization rules still apply to old code.

Q19 — Confirmed. Only active eligible evonodes vote in network freeze/wipe governance, with one vote each. This is separate from compilation readiness and from existing contested-index polls.

Q20 — Confirmed. Freeze, wipe, unfreeze and foreign-token vestige recovery require strictly more than two-thirds of all active eligible evonodes, one vote each. Votes have a one-week window and approve early after rechecking eligibility against agreed current membership. Require N > 0 and 3yes > 2N, equivalently floor(2*N/3)+1 yes votes. Exactly two-thirds fails. Compilation readiness remains at least 80% with its existing adaptive wait and no automatic expiry.

Q21 — Confirmed. Use current active membership when deciding a governance result; do not fix the electorate at opening. Revalidate eligible voters and denominator at a potential crossing. Approve early during the one-week window once strictly more than two-thirds is verified; also reconsider after membership changes.

Q22 — Confirmed. A network freeze blocks execution, spending and controlled writes; queries, current-state proofs and native bookkeeping continue. Frozen recipients may receive funds under Q30 and existing receiving rules.

Q23 — Confirmed. A network-voted freeze needs a network vote to lift it: strictly more than two-thirds of all active eligible evonodes, one vote each, a one-week window and early approval after eligibility recheck. Authorized contract updates stay frozen. Contract-defined freezes retain their declared rules; a wipe remains permanent.

Q24 — Confirmed. Freeze, wipe, unfreeze and foreign-token recovery use a one-week voting window with early approval after a verified strictly-more-than-two-thirds tally. Commit once at the defined block boundary before affected work. Votes not approved by expiry close without approval.

Q25 — Confirmed. Foreign tokens remain in the deleted-contract identity vestige until a separate network vote approves specific token IDs, amounts and a recipient. Require strictly more than two-thirds of all active eligible evonodes, one vote each, with a one-week window and early approval after eligibility recheck. Enforce native transfer validation and conservation; no unrestricted permanent recovery authority.

Q26 — Confirmed. Later storage refunds belonging to a wiped contract go to the current processing pool. A frozen but existing owner may receive native bookkeeping refunds without acquiring spending permission.

Q27 — Confirmed. Wipe applies immediate logical destruction with validated aggregate accounting, followed by bounded physical cleanup. Destroyed issuer tokens are unusable on every path. Foreign tokens survive in the vestige; canonical code is permanent.

Q30 — Confirmed direction. Pause execution of jobs whose contract is frozen. Frozen identities/contracts may receive native funds without running frozen guest code; existing asset-specific and receiving permissions still apply. Proposed queue policy resumes future runs without a catch-up burst and cancels permanently missing methods.

[QuantumExplorer]

Owner follow-up incorporated, 11 September 2026 — revision 11. DashVM is confirmed: pinned upstream Wasmtime/Cranelift, upstream fixes and deterministic scalar floating point. Current-state reads remain in force. All 160 tasks are owned by QuantumExplorer; dates and durations remain unset. Confirmed policy answers and provisional engineering limits. Production work remains open.

Part 12 of 14 · Revision 11 · 11 September 2026 · Parent plan · Decision register

Revision 8 capability coverage: Appendix A · Appendix B · Appendix C. This section's implementation includes the corresponding capability requirements and CAP-01–CAP-18 acceptance work. The reviewed product decisions below are unchanged; GroveDB review baseline is develop at c401b504.

12. Fees and economics

12.1 Fee-version prerequisite

Repair fee-version numbering and historical refund handling before infrastructure merges. Every registered fee number must resolve to the intended table, persisted state must round-trip its number, and storage refunds must use the appropriate historical rates. Recheck the current tree rather than treating the original registry contents/caller counts as current facts. Allocation and repair must preserve existing history.

12.2 Affordability and charging

Check the full admitted execution bound against the live balance before any user code runs. Include already-accrued work and applicable fee multipliers/nonce costs correctly; a CheckTx estimate against an earlier balance is not enough. Charge actual consumed work once. Rejection, traps and exhaustion are paid for their consumed work; do not execute many sequential transactions for free against one exhausted balance.

For direct calls the signer pays processing and storage. Written data records its owner for storage refunds. Asset-moving authorization is distinct from the processing/storage payer. Specify how the direct-call bound covers nested work; scheduled-call payer/admission rules remain open. Preserve all-or-nothing contract effects through existing GroveDB validation and atomic writes.

Cost estimates must bound parsing, context conversion/copying, execution, host reads/calls, emitted operations, validation and storage where applicable. Choose compiler preparation/deployment pricing explicitly. Consensus charges cannot change with a node's compiler cache warmth or hardware speed. Actual costs and admitted bounds must use consistent units and checked arithmetic.

12.3 Computation and native events

The new budget covers smart-contract computation only, including contract work reached from scheduling. Existing native execution/block-event accounting stays at its current layer. The proposer timer remains for now. The old combined all-work budget, fixed budget/gas equality, and hardware-report release gate are superseded. Define gas integration and exact limits without double-counting or omitting costs.

12.4 Storage, receipts, recurring work and wipe

• Permanent canonical code pays the applicable storage charges and is never deleted for a zero-reference refund, including after wipe. Temporary upload staging, if supported, needs separately specified cleanup/refund rules.
• Receipt storage defaults to enabled and is controlled by each contract. Specify format, charged bytes, owner and retention semantics; no mandatory always-stored receipt or past-state proof service is inferred.
• Recurring execution is paid as it runs; drop the loop on its first failure to pay. Prepay its drop cost, not all future execution. Specify which balances pay which work and how reserves are represented.
• Include the separate contract credit sum tree and token buckets in conservation. Do not store ordinary contract balances in the identity tree.
• Wiped contract credits go to the current processing pool. Its issued tokens are destroyed; foreign tokens it holds remain in the special deleted-contract identity vestige. Specify supply, holder, index and reserve accounting consistently with those decisions.
• No direct contract-to-Core unlock or special contract withdrawal allowance is introduced. Payouts to ordinary identities remain governed by the existing withdrawal limits.

12.5 Client estimation

Expose the protocol's full-bound estimation and minimum-admission floor distinctly. An estimate is not a network preflight result. SDK/CLI vectors must agree with DPP/runtime pricing under the chosen fee version and report actual costs and structured failure codes honestly.

Implementation tasks

• Repair and test fee-registry numbering/index lookup, every PlatformVersion reference, persisted-number round trips and historical storage-table compatibility against the current tree. Source: S12-01, S12-02.
• Audit all fee/refund callers and require historical fee context where needed, including block lifecycle cleanup. Test replay-from-genesis versus saved-state refunds across affected boundaries; document the agreed invariant in the DIPs. Source: S12-03, S12-04, S12-05.
• Define the selected runtime/host preparation, computation, memory, read/copy and storage pricing tables; allocate actual generations centrally and version any behavior changes. Source: S12-06.
• Measure representative and adversarial workloads to choose sound computation/memory/host costs and limits; retain reproducible cost vectors. The deferred hardware publication and fixed benchmark-machine gate are not prerequisites. Source: S12-07.
• Integrate metered contract costs, full live affordability and one actual charge into the fee pipeline; remove execution-changing local switches and test CheckTx/RecheckTx never execute user code. Source: S12-09, S12-10, S12-11.
• Validate contract computation/gas bounds and enforce them on both proposal paths without the rejected combined native-event budget or invented numeric ratios. Source: S12-12, S12-13.
• Integrate structured paid outcomes, nonce/cost handling and existing proposer removal of known faulting transitions. Test guest failures separately from genuine storage/node faults and allocate error codes against the actual registry. Source: S12-14, S12-15, S12-16.
• Reuse existing GroveDB validation and atomic writes for bounded proposed/nested effects; verify no unauthorized partial effect survives a failed call, with exact rollback semantics specified in section 10. Source: S12-17.
• Implement permanent-code storage charges, contract-controlled receipt costs, recorded-owner refunds and historical-rate handling; specify any temporary staging cleanup separately and prohibit zero-reference deletion of retained canonical code. Source: S12-18, S12-19, S12-20.
• Extend credit/token conservation for contract buckets, live-paid scheduling with prepaid drop costs, fee pools and the approved wipe dispositions; test zero/exhausted balances, epoch changes and blocks containing only scheduled work. Source: S12-21.
• Expose minimum floor, full admitted bound and actual metered fees consistently through DPP, SDKs, CLI and mobile estimators; test shared vectors without introducing network preflight. Source: S12-22.

---

Revision 10 incorporates the returned owner review. Unresolved policies and provisional engineering values are labelled; implementation tasks remain open.

Owner review answers applying to this section

Q14 — Confirmed. The deployer pays bounded protocol validation and readiness-verification costs. Evonodes pay their own compilation. No local-time compilation bill, cold-cache surcharge or repeated preparation charge on execution.

Q26 — Confirmed. Later storage refunds belonging to a wiped contract go to the current processing pool. A frozen but existing owner may receive native bookkeeping refunds without acquiring spending permission.

Q28 — Confirmed. Every scheduled job declares an authorized contract balance bucket as execution/storage payer. The submitting signer pays registration; check live payer authority and funds before each run. Additional payers require explicit authorization.

Q31 — Confirmed. Each scheduled job declares its cancellation authority and reserves removal costs. Charge removal and return unused reserves to their recorded owner, or the current processing pool if that owner is a wiped contract. Preserve funded removal across fee upgrades or settle affected old jobs first.

Q32 — Confirmed. Receipt storage defaults to enabled and retention is contract-defined. No declared expiry means retain until authorized removal, not an invented automatic expiry. Canonical code retention remains independent.

Q33 — Confirmed. When enabled, reserve storage before execution and store bounded success and deterministic paid-failure receipts. Local node faults and internal speculative retries are not paid failure receipts.

Q34 — Confirmed. One contract-owned receipt per outer invocation, with bounded nested outcomes. The invocation payer pays; refunds follow the recorded owner. Each scheduled attempt is an invocation. Failed-call receipts are written outside rolled-back guest effects.

Q40 — Confirmed delegation. Maintain one protocol-versioned allocation register. Supply provisional numeric limits and prices now, then measure and revise before activation. Allocate wire/storage/ABI IDs from actual registries; keep engine/profile pin and unmeasured native costs explicitly unresolved.

Named modules — owner direction recorded 11 September 2026

Support several named WASM modules in one contract version in 5.0; a single-module bundle remains valid. Pin exact modules and interfaces in one immutable manifest, reuse unchanged canonical modules across versions, and activate the whole bundle under the existing readiness rule. Detailed linking, initialization and fee rules remain engineering proposals.

Detailed storage, linking, initialization, accounting and 16 expanded task acceptances. References above to a module/code archive now allow the complete named-module bundle. Canonical blobs and immutable manifests remain permanent; public methods map to module exports. Readiness covers every module, internal calls share one authority/budget/atomic scope, and cross-contract/scheduled latest-version routing is unchanged. Proposed ABI/linker/initializer specifics require engineering validation; this amendment does not claim implementation or measured limits.

Existing prefunded balances — confirmed reuse

Reuse the existing prefunded balance ledger and operations for scheduled-job removal funding. Use the existing 40/128/balance_id storage with purpose-bound job identifiers and native spending validation; do not add a dedicated DashVM reserve subtree or duplicate monetary ledger. Preserve legacy voting identifiers, balances and behavior. Job owner/purpose/refund metadata contains no second credit amount.

Native integration, purpose validation, ownership/refunds and revised storage mapping. R10-05, R12-10 and CAP-09 include these acceptance requirements. The same storage supplement also records the ordinary-SumTree engineering recommendation, separately from confirmed owner choices.

[QuantumExplorer]

Owner follow-up incorporated, 11 September 2026 — revision 11. DashVM is confirmed: pinned upstream Wasmtime/Cranelift, upstream fixes and deterministic scalar floating point. Current-state reads remain in force. All 160 tasks are owned by QuantumExplorer; dates and durations remain unset. Confirmed policy answers and provisional engineering limits. Production work remains open.

Part 13 of 14 · Revision 11 · 11 September 2026 · Parent plan · Decision register

Revision 8 capability coverage: Appendix A · Appendix B · Appendix C. This section's implementation includes the corresponding capability requirements and CAP-01–CAP-18 acceptance work. The reviewed product decisions below are unchanged; GroveDB review baseline is develop at c401b504.

13. Developer experience, SDK, and tooling

13.1 Developer deliverables

Ship a Rust guest SDK and macros, canonical ABI/types, actual-runtime and native-reference test utilities, CLI and examples. Exact crate names and DashVM branding remain to be selected. A no_std/WASM-compatible shared value representation is an implementation approach to validate, not a reason to pull the whole node dependency graph into guests.

The CLI should support reproducible building, module checks, size/cost inspection, deployment, activation progress, version updates, deprecation warnings and calling contracts. Local fixture-based simulation remains a developer tool. Network preflight and its SDK/DAPI surface are excluded from 5.0. Native reference tests compare behavior; the selected metered runtime supplies consensus execution costs.

13.2 Client capabilities

Extend Rust SDK, WASM SDK, js-evo-sdk, Rust FFI/JNI, Swift and Kotlin as appropriate, including configuration round trips and mobile persistence. Preserve existing identities and add ordinary contract balance/data queries and current-state proofs. No empty-key contract-identity proof migration or minimum-client gate is required.

Provide larger code deployment support, compilation/activation status, call builders, full-bound estimation, structured errors, credit/token buckets and permitted transfers, freeze/lifecycle state, latest-version method routing and deprecation warnings. Update SDK parity tracking and examples. A client must not offer an old-version pin or silent fallback for cross-contract calls.

Receipt APIs must reflect default-enabled contract-controlled storage. Distinguish stored receipts/current-state proofs from mere transaction inclusion or result text; explain the result available when receipt storage is disabled. Do not promise arbitrary past-state proofs.

13.3 Documentation and delivery

Document the 5.0 target, PV15/4.3–PV17/5.0 allocation rule, fees/refunds, ABI/capabilities, contract/identity separation, state visibility, compilation readiness, lifecycle, cross-contract composition, freeze/wipe and SDK usage. Correct obsolete v4.0 claims after checking the current docs; do not substitute unapproved calendar dates or a PV18/PV19 roadmap.

Provide small examples for guards, predicates, contract-owned documents/buckets, cross-contract calls, configurable receipts and recurring execution that stops on payment failure. Native escrow/auction/allowance infrastructure is deferred and not required merely to produce an example.

SDK/tooling delivery remains in scope. The separate SDK funding sign-off gate is removed. Normal package release ownership, compatibility tests, documentation and integration checks are still work to complete; this issue does not authorize publishing packages before they are built and reviewed through the normal release process.

Implementation tasks

• Implement a guest-compatible value/ABI foundation and canonical codec with golden vectors, verifying WASM/no_std builds and avoiding unnecessary node dependencies; settle exact package names. Source: S13-01, S13-02.
• Integrate the fee-registry prerequisite and reject unknown fee versions in tooling; verify full-bound and actual-cost vectors use the correct registered table. Source: S13-03.
• Keep contract configuration/schema mirrors consistent across Rust, WASM/TypeScript, Swift and Kotlin, including persistence of new policy, version and receipt fields. Source: S13-04.
• Update public roadmap/product/SDK documentation to the revised scope and actual code facts, preserving historical code references where useful and omitting invented dates or extra protocol activations. Source: S13-05.
• Deliver guard/module checking, guest SDK/macros, typed schema generation, native reference tests and actual-runtime tests; use the selected engine rather than hard-coding wasmi as the default. Source: S13-06, S13-07, S13-08.
• Build CLI commands for reproducible builds, checks, sizes, metered cost estimates and deployment, with local fixture simulation and exact-version compatibility. Verify canonical artifacts and DPP/runtime fee parity. Source: S13-09, S13-10.
• Test all CheckTx/RecheckTx entry paths for no guest execution, full affordability estimates, structured errors and maximal signed upload size; integrate readiness/lifecycle-aware engine preparation instead of the old lazy-first-use policy. Source: S13-11, S13-12.
• Expose code deployment, activation readiness/progress and structured consensus errors across Rust/WASM/JS/mobile SDKs; add chunk sequencing only if chunking is selected and update parity manifests. Source: S13-13, S13-14.
• Write contract author guides and predicate examples using the actual lifecycle/update policy and selected release allocation; cover local network use and error/cost interpretation. Source: S13-15.
• Add versioned read and entry-point APIs, local fixtures and compatibility tests for older accepted modules under their historical protocol behavior; do not assume the old ABI/PV allocation is final. Source: S13-16.
• Expose direct and cross-contract calls, latest-version method semantics and configurable receipt/current-state results across SDKs and both mobile examples, with shared wire/error/proof vectors. Source: S13-18.
• Prepare package ownership, release automation and install/use validation for the chosen ABI/SDK/testutils/CLI names through the normal release process; no separate SDK funding sign-off prerequisite. Source: S13-19.
• Maintain a protocol-change checklist for ABI, runtime/metering, capabilities, compilation readiness, historical replay, vectors, SDK compatibility and docs, reflecting the final engine/maintenance choice. Source: S13-20.
• Add user-facing lifecycle/deprecation warnings, version and readiness status, contract balance/token bucket queries, transfer authorization and wipe/vestige status. Keep still-unselected policy controls out of documented default behavior. New work from the review.

---

Revision 10 incorporates the returned owner review. Unresolved policies and provisional engineering values are labelled; implementation tasks remain open.

Owner review answers applying to this section

Q03 — Confirmed. Call the complete execution system DashVM. Wasmtime is its runtime and Cranelift its compiler; exact crate and command names remain engineering allocations.

Q17 — Confirmed. Direct users may explicitly select a still-supported old executable version. Direct calls without a version, cross-contract calls and scheduled jobs resolve the latest visible executable version; no cross-contract or scheduled old-version pin/fallback. Current native storage/authorization rules still apply to old code.

Q18 — Confirmed. Reuse existing versioned DPP/Drive index-update rules exactly. Do not introduce a new index-backfill/migration subsystem. The inspected v1 validator rejects adding, removing or changing indexes on existing document types; new types may declare indexes through normal validation.

Q35 — Confirmed. Detached Rust values do not save automatically. Explicit insert/edit operations and successful exported persistent-receiver wrappers stage writes in the outer transaction. No save on Drop.

Q36 — Confirmed. Use simple persistence/index/rule attributes plus typed builders for advanced native features, producing one canonical manifest. Reject unsupported/conflicting declarations; native validation remains the authority. No unrestricted database paths.

Q37 — Confirmed. Randomness uses request then finalized-result lookup, including ordinary NotReady. The separate native primitive defines production randomness/finality/proofs; current contract work supplies boundaries and stubs, with no fabricated instant entropy.

Q38 — Confirmed. Private Rust fields and ACL checks are not encryption. Keep the private capability in the catalogue while encryption, key control, query visibility and proof behavior are separately specified before enabling its interface.

Q39 — Confirmed direction. Substantially extend contract create and update state transitions to carry large code/declarations. Apply larger bounded limits consistently on every ingress path; do not merely introduce an unrelated upload route. Initial single-transition form and exact sizes are engineering proposals.

Q42 — Confirmed. QuantumExplorer owns all 160 tasks for now, including runtime, SDK and separate native ACL/randomness delivery. External issue links remain to be added; dates and durations remain unset.

Named modules — owner direction recorded 11 September 2026

Support several named WASM modules in one contract version in 5.0; a single-module bundle remains valid. Pin exact modules and interfaces in one immutable manifest, reuse unchanged canonical modules across versions, and activate the whole bundle under the existing readiness rule. Detailed linking, initialization and fee rules remain engineering proposals.

Detailed storage, linking, initialization, accounting and 16 expanded task acceptances. References above to a module/code archive now allow the complete named-module bundle. Canonical blobs and immutable manifests remain permanent; public methods map to module exports. Readiness covers every module, internal calls share one authority/budget/atomic scope, and cross-contract/scheduled latest-version routing is unchanged. Proposed ABI/linker/initializer specifics require engineering validation; this amendment does not claim implementation or measured limits.

[QuantumExplorer]

Owner follow-up incorporated, 11 September 2026 — revision 11. DashVM is confirmed: pinned upstream Wasmtime/Cranelift, upstream fixes and deterministic scalar floating point. Current-state reads remain in force. All 160 tasks are owned by QuantumExplorer; dates and durations remain unset. Confirmed policy answers and provisional engineering limits. Production work remains open.

Part 14 of 14 · Revision 11 · 11 September 2026 · Parent plan · Decision register

Revision 8 capability coverage: Appendix A · Appendix B · Appendix C. This section's implementation includes the corresponding capability requirements and CAP-01–CAP-18 acceptance work. The reviewed product decisions below are unchanged; GroveDB review baseline is develop at c401b504.

14. Delivery, validation, deferred work, and remaining decisions

14.1 Sequencing and release allocation

Develop toward the full first smart-contract scope in 5.0. Identify candidates for 4.3 and 4.4 as implementation progresses, then settle their allocation. The only planned protocol/release mapping is PV15 → 4.3; PV16 → 4.4; PV17 → 5.0, at most three activations. No section/work group automatically consumes its own protocol version. Dates and task durations remain unset.

Dependency order is engineering guidance: frontload DIPs and decisions; repair fee-registry/refund handling before infrastructure merges; build storage, authorization, limits and compilation activation; integrate guards/predicates, reads, direct/nested/scheduled calls and receipt policies; deliver SDKs and verify the complete flow. Much of SDK work and independent testing can proceed alongside implementation. Cross-contract calls are part of the first scope, not a post-launch prerequisite study.

The old exact root-tree keys, wire/error ranges, ABI generations and fee/validation table schedule are unconfirmed allocations, not commitments. Allocate from the actual tree and keep one consistent register. The exact development branch is unselected; old v4.2-dev references describe the source baseline only.

14.2 Validation and rollout

Test on testnet, then allow deployment by everyone at launch. Remove the approved-deployer rollout and the audit/SDK-funding gates. Keep meaningful implementation checks and the explicitly approved engine comparison/adoption period. The exact engine test duration and remaining release checklist are still open; no new soak duration or signed release gate is invented here.

Validation should cover:

• Cross-architecture outcomes, fees, errors, resource boundaries and application hashes, with cold/warm/recovered caches yielding the same execution results.
• Full live affordability before execution; exact single charging, failed work, refunds and conservation; no execution in CheckTx/RecheckTx.
• Separate contract balances/buckets, deposit and spending permissions, protected documents, native validation/index conflicts and atomic effects.
• Current-state reads in agreed execution order, including earlier accepted transitions and own operations, and latest-version cross-contract routing without fallback.
• Compilation-readiness authentication/counting, the 80% total-active-set threshold, adaptive waiting bounds, timing/membership conventions once chosen, and node/engine recovery.
• Permanent canonical code versions, deprecation warning behavior and selected inactivity rules; historical protocol replay independently of current-state proof service.
• Contract-controlled/default-enabled receipts, disabled-receipt client behavior, current-state proof tampering, and honest result classifications.
• Contract-defined freezes and one-week active-evonode governance votes strictly exceeding two-thirds, with early approval after eligibility recheck; correct credits, token destruction, vestige accounting and retained code.
• Recurring live payment, first failure-to-pay removal and prepaid drop cost; deterministic queue handling and no dependence on deferred native primitives.
• End-to-end Rust/WASM/JS/mobile SDK behavior, maximum signed sizes, ABI/serializer expansion, structured errors and upgrade boundaries.

These remain unchecked implementation requirements, not claims of completed tests or audits.

14.3 Remaining decisions and details

All 42 review directions and all five follow-up policy topics have recorded answers. Exact allocations remain engineering work, and Q41 retains its recorded caveat. The current rules and provisional engineering proposals follow.

The final policy answers are recorded below. Freeze, wipe, unfreeze and foreign-token vestige recovery require strictly more than two-thirds of all active eligible evonodes, one vote each. Votes have a one-week window and approve early after rechecking eligibility against agreed current membership. Require N > 0 and 3yes > 2N, equivalently floor(2*N/3)+1 yes votes. Exactly two-thirds fails. Compilation readiness remains at least 80% with its existing adaptive wait and no automatic expiry. Contracts may parameterize contested indexes only through supported native declarations. Native rules select and award the winner; guest code and custom guards cannot veto, delay, redirect or retry the award. No blocked-award or guest retry workflow. Make rule scopes explicit; enforce native validation, internal award authority, atomicity and lifecycle rules. Each scheduled job declares its cancellation authority and reserves removal costs. Charge removal and return unused reserves to their recorded owner, or the current processing pool if that owner is a wiped contract. Preserve funded removal across fee upgrades or settle affected old jobs first.

14.4 Deferred or removed scope

Scope	Current disposition
Oracle feeds: observations, aggregation/median, committee selection, signatures, payments	Later 5.x; individual policies are unanswered.
Native escrow, allowances, auctions	Not current priorities; no release assigned.
Network preflight, endpoint configuration and SDK bindings	Excluded from 5.0; no later release assigned.
Proposed 5% undeclared-read fallback	Deferred; no replacement selected and no current gate.
Proposer-timer replacement/final policy	Deferred; keep the current timer.
Minimum/reference hardware publication and operator cost report	Deferred; no new values approved.
ZK predicates/coprocessor and parallel study	Future version.
Contract-held group membership and DPNS names	Deferred; groups may still authorize actions.
External bridges/wrapped assets	Separate future design; existing native asset lock remains.
Keyless contract identities and their query/proof/client gate	Removed; use separate contract balances and ordinary current-state APIs.
Combined budget for all execution and native block events	Removed; the new budget covers contract computation only.
Deployer allowlist, named security/threat-register/audit prerequisite, SDK funding gate, added bespoke recovery mechanisms	Removed; retain open launch, ordinary implementation checks, engine adoption tests and existing recovery.
Zero-reference deletion of canonical code; mandatory full recurring prepayment; mandatory wasmi/no-JIT; phase-derived PV18/PV19 schedule	Superseded by the selected retention, payment, engine-discussion and release rules.

14.5 Research and review history

The earlier discussion/revision comments remain intact as historical review. Their statements about former proposals:such as allowlist layers, preflight defaults, code deletion, fee tables and audits:do not override revision 7. Relevant serializer-bound and CheckTx coverage concerns are retained as tasks in sections 2, 9, 10 and 13. External-asset questions are answered by R12/R14/R51/R52/R56 and the freeze/wipe dispositions.

The current MPM/Gantt retains all 160 task IDs, 234 dependencies and 110 capabilities, with updated owner answers and QuantumExplorer assigned throughout. No effort or schedule estimate is introduced by contract activation's protocol waiting period.

Original checklist traceability

Every one of the 213 original checkbox rows is accounted for. Rebased work cites its original Sxx-yy identifier beside the replacement task. The rows below are resolved, deferred or removed rather than silently dropped or marked complete. Related surviving requirements are carried in the replacement sections.

Original task	Disposition	Reason
S04-02	removed	Review 11 rejects the contract-identity compatibility query/proof/client gate; ordinary contract balance/data proofs remain under sections 4, 9, and 13.
S05-13	removed	Review 32 removes the named-owner/threat-register/audit prerequisite. Relevant determinism, fee, validation and recovery checks remain implementation work in sections 8–12 and 14.
S06-03	deferred	Review 39 defers publishing a minimum/reference hardware specification, benchmark-machine report and operator cost report. Appropriate implementation measurements remain, without this release gate.
S06-15	deferred	Oracle feeds and related observation, aggregation, signing, payment and test work move to later 5.x; no detailed oracle policy is selected.
S06-16	deferred	Oracle feeds and related observation, aggregation, signing, payment and test work move to later 5.x; no detailed oracle policy is selected.
S06-17	deferred	Oracle feeds and related observation, aggregation, signing, payment and test work move to later 5.x; no detailed oracle policy is selected.
S06-18	deferred	Oracle feeds and related observation, aggregation, signing, payment and test work move to later 5.x; no detailed oracle policy is selected.
S06-19	deferred	Oracle feeds and related observation, aggregation, signing, payment and test work move to later 5.x; no detailed oracle policy is selected.
S06-20	deferred	Oracle feeds and related observation, aggregation, signing, payment and test work move to later 5.x; no detailed oracle policy is selected.
S06-21	deferred	Oracle feeds and related observation, aggregation, signing, payment and test work move to later 5.x; no detailed oracle policy is selected.
S06-22	deferred	Oracle feeds and related observation, aggregation, signing, payment and test work move to later 5.x; no detailed oracle policy is selected.
S06-24	deferred	Native escrow, allowance and auction implementation/tests are not current priorities and have no assigned release; they do not gate contract scheduling.
S06-25	deferred	Native escrow, allowance and auction implementation/tests are not current priorities and have no assigned release; they do not gate contract scheduling.
S06-27	deferred	Native escrow, allowance and auction implementation/tests are not current priorities and have no assigned release; they do not gate contract scheduling.
S09-11	deferred	Review 45 excludes network preflight and its availability/pool/configuration surface from 5.0; no later release is assigned.
S09-12	resolved	Review 46 selects current-state proofs only; no arbitrary past-height proof service is required.
S11-05	deferred	Review 23 keeps the existing proposer timer and defers its final policy; removal and automatic replacement are not current requirements.
S11-15	removed	Reviews 7/32 remove the mandatory staged audit/security-owner prerequisite. Dependency advisory handling and meaningful implementation checks remain under sections 8 and 11.
S11-21	removed	Review 31 retains existing recovery and proposer removal of failing transitions; the proposed additional configurable contract denylist mechanism is not selected.
S12-08	deferred	Review 39 defers minimum/reference hardware publication and operator cost reports; no hardware values are approved.
S13-17	deferred	Review 45 excludes network preflight, its SDK/mobile bindings and endpoint load-test deliverables from 5.0.
S14-06	removed	Review 27 selects testnet testing followed by open deployment, so no testnet/mainnet approved-deployer allowlist seeding is required.

Implementation tasks

• Integrate deterministic cross-architecture execution/replay, targeted fuzzing and meaningful protocol upgrade tests into CI with workable resource/time bounds; compare artifacts and exercise failure detection without asserting checks already pass. Source: S14-01, S14-02, S14-03.
• Replace obsolete PV-opening audit/funding/allowlist gate text with the selected scope and actual implementation validation, SDK delivery and engine adoption evidence. Settle the remaining release checklist without inventing new sign-offs. Source: S14-04.
• Create linked implementation/release tracking issues when allocation is settled within PV15–PV17; record useful testnet execution/fee/readiness/replay evidence without assuming one issue or activation per old phase. Source: S14-05.
• Test the chosen freeze/unfreeze/temporary-freeze and masternode wipe flows on testnet, including the one-week window, strictly-more-than-two-thirds full-active-set threshold and early approval after eligibility checks, rejected affected actions, permanent code, current-pool credits, destroyed issued tokens and foreign-token vestige. Test the selected governance and scheduled behavior without restoring old key-holder/allowlist layers. Source: S14-07.

---

Revision 10 incorporates the returned owner review. Unresolved policies and provisional engineering values are labelled; implementation tasks remain open.

---

DashVM: implementation proposals after the owner review

11 September 2026. These are concrete starting designs for review and testing, not implemented features or approved production constants. QuantumExplorer owns all current tasks; dates and durations remain unset.

Contested indexes and custom rules — Q09

Contracts may declare supported contested-index parameters, validated through the existing versioned native rules. The native protocol selects and awards the winner. Contract code and custom guards cannot veto, delay, replace, redirect or retry that award. There is no guest-controlled blocked-award state, award reserve or paid guest retry workflow.

Make the action scope explicit in the manifest, SDK and host: ordinary contract rules govern only their declared ordinary actions; native contested awards use the native contested-index rules and supported parameters. Do not invoke a guest predicate, callback or custom create guard to authorize a native award, including a guard implemented by the native generic evaluator. Reject declarations claiming such an award veto; this does not ban contested indexes alongside rules on other actions.

Preserve native eligibility, locks, tally/finalization, document validation, atomic index/reference effects and native lifecycle handling. Only an authenticated internal native award action can perform the award; arbitrary guest requests cannot impersonate it. Existing index-update restrictions also govern parameter changes; a later contract update cannot use guest logic to rewrite an existing native poll's outcome. Contract lifecycle never authorizes resurrection of wiped state. Any lifecycle handling belongs to deterministic native protocol rules, not a guest veto.

Acceptance covers allowed/invalid parameters, forged award requests, a trap/reject/infinite-loop guest guard never being invoked for an award, ordinary guard enforcement on ordinary actions, finalization once, code-update/freeze/wipe boundaries and identical native/contract-declared contest outcomes. Reuse native contest fees; do not introduce the former proposed guest-award funding and rejection system. Work: FIX-10, R07-10, CAP-03/09/14/16, SDK-01.

Readiness counting and the Core/Platform boundary — Q10–Q14

Use one keyed vote per evonode and activation round. A GroveDB count tree can maintain the raw distinct-vote count. It cannot prove that all voters are still eligible.

When that count could meet 80%, validate the voters against the agreed current active-evonode set, remove ineligible votes, and test 5 × valid_yes >= 4 × active_count with checked integer arithmetic. Do not activate when the active set is empty. Reconsider candidates on membership changes as well as new votes: a smaller denominator can create a crossing without a new vote. Cap membership-validation work; a paged check must use one consistent membership view and cannot start the timer on an unverified tally. Cache validated eligibility against a membership revision to avoid repeatedly charging full scans when nothing changed.

The state boundary means: every node uses the same Core masternode list referenced by the Platform block, after the same defined membership-update phase. It must not use whatever newer list its local Core RPC happens to have. Platform already updates the masternode list at a supplied Core height. The DIP must fix this processing order and the precise active-eligibility predicate.

Record the membership reference and first validated crossing. Let T be accepted deployment to crossing, measured with committed chain time. The additional wait is clamp(T, 2 minutes, 1 hour). Later joins prepare without restarting that timer. Activation occurs at the first defined block boundary at or after the deadline. Replacement atomically cancels the previous pending version's vote round and timer; old messages cannot vote for the replacement. Accepted canonical code remains permanent even after cancellation.

Keep pending deployments until authorized cancellation; no automatic expiry or below-threshold fallback. Deduplicate retransmitted reports without making a failed report permanently unreportable. Test mechanism failures separately from operators withholding votes. The deployer pays bounded protocol validation and readiness verification; nodes pay their own compilation. A local missing artifact is a node-readiness problem, not an execution surcharge or contract rejection.

Existing index updates — Q18

Use the existing versioned DPP/Drive validator unchanged. Do not add a general schema-migration/index-backfill subsystem to this contract project. The inspected v1 document-type update validator rejects adding, removing or changing index definitions on an existing document type. New document types may declare indexes through normal validation. Dispatch remains protocol-versioned; this is not a claim that every historical version had identical rules.

Rust attributes and builders must produce declarations that pass that same validator. A still-supported old executable must use compatible current storage and current authorization; choosing old code cannot restore an obsolete schema or weaker native permissions.

Scheduled failures, frozen recipients and cancellation — Q29–Q31

Require an explicit on_failure policy: Drop, Skip, or Retry { max_attempts, interval, then }. Proposed initial retry cap: 10 total attempts, at least one later block between attempts, with then restricted to Drop or Skip. Skip advances to the next normal run; a one-shot job completes without another run. Retry preserves that occurrence and never creates overlapping retries. Missed recurring times are not replayed in a burst. Each actual attempt has its own payment check, cost and optional receipt. The first inability to pay still removes the job using its prepaid removal reserve. Internal parallel-execution retries are not scheduled failures or extra paid attempts.

Pause jobs whose executing contract is frozen; resume future runs after unfreezing. A frozen recipient may receive native credits/transfers without running its guest code. Existing asset-specific freeze/receiving rules still apply. Receiving policies must have a native-verifiable path for this case; no guest callback runs while its contract is frozen. A required guest check that cannot run must leave that particular transfer pending or rejected, rather than silently bypassing authorization. Permanently missing methods need an explicit terminal queue outcome; propose cancellation using the removal reserve.

Cancellation confirmed: Each scheduled job declares its cancellation authority and reserves removal costs. Charge removal and return unused reserves to their recorded owner, or the current processing pool if that owner is a wiped contract. Preserve funded removal across fee upgrades or settle affected old jobs first.

Provisional resource and price register — Q39–Q40

These are engineering guesses requested by the owner. Benchmark them before selecting protocol values. They deliberately permit large contract create/update transitions. A contract limit never relaxes a smaller existing native document, query or operation limit.

Resource	Starting proposal	Rationale / validation needed
Canonical WASM	16 MiB per version	Room for large Rust contracts; stress compilation and permanent storage cost.
Signed contract create/update transition	32 MiB total	Includes code, manifest, signatures and envelope; not 32 MiB per field. Keep other transition-family limits. Check DAPI, gRPC, mempool, proposal/block transport and replay all accept the same bounded envelope.
Upload form	One bounded create/update transition	Prototype this first; chunking remains an engineering option if transport/compilation measurements require it.
Guest linear memory	128 MiB per instance; 256 MiB across the call tree	Reserve before execution; no machine-dependent memory.grow outcomes. Initial logical memory 16 MiB.
Memory/table shape	One 32-bit memory and one function table, at most 65,536 entries	Explicit initial profile; no shared memory, threads or memory64. Validate Rust toolchain compatibility.
Portable logical stack	1 MiB total; 512 guest activation frames	Charge locals and operand slots, not only recursion depth; prove native-stack headroom separately.
Contract nesting	8 active contract frames including the root	No repeated active contract ID; ordinary local Rust recursion uses the separate stack bound.
Module structure	50,000 functions; 10,000 types; 128 params and 1,024 locals per function; 1,024 exports	Independent limits for large modules with costly shapes; reduce if adversarial Cranelift tests justify it.
Compilation complexity	2 million decoded operators; 100,000 operators and 4,096 basic blocks per function; structural nesting 512	Check before full compilation; reject excessive instrumented growth, initially cap instrumented bytes at 64 MiB.
Native host calls	10,000 per outer invocation	One shared budget covers all nested work and predicates.
Returned read bytes	8 MiB total; 1 MiB per query page	Also charge scanned/visited work; output limits alone do not bound query cost.
Logical dependency tracking	100,000 distinct keys/range descriptors	Bound memory; coarsen or execute sequentially when necessary without changing ordered semantics.
Logical writes	1,000 explicit operations and 4 MiB payload total	Meter and bound derived index/reference/cascade work too; native limits still apply.
Arguments / return / stored receipt	256 KiB arguments; 64 KiB return; 64 KiB receipt	Shared nested byte accounting; reserve receipt bound before execution. Failure receipt cannot exceed reserved size.
Compute	25 million units per outer invocation; 250 million contract units per block	Includes scheduled/guard/nested work; separate from existing native event budgets. No measured wall-clock limit decides consensus validity.
Readiness messages	128 reports per batch; one pending executable version per contract	Deduplicate and rate-limit transport; membership sweeps need separate bounded accounting.
Scheduled retries	At most 10 attempts, interval at least one later block	Declared Drop/Retry/Skip policy; no same-block retry storm.

Provisional computation weights: simple/control operation 1 unit; integer multiply and floating add/multiply 2; load/store 4; divide/remainder, floating divide/sqrt and conversions 8. Copy/hash work adds units per byte or native measured work. Every admitted Wasm operator must have an explicit weight before launch; this short list is not a complete opcode table. Propose 100 units for host entry plus actual native operation cost, 1 unit per copied byte, and 65,536 units per 64-KiB memory growth page. Never price a complex query as only 100 units.

Provisional price: 1 processing credit per computation unit, deployment validation 100,000 processing credits plus 20 per canonical WASM byte and 5 per decoded operator, readiness verification 10,000 processing credits per newly accepted signature plus metered membership lookup work. These are unbenchmarked candidate rates, not existing Platform prices. Add existing versioned native processing and storage charges exactly once; do not double-charge an operation already included in those tables. Permanent code, indexes and receipts pay actual native storage charges; use historical native refund rules with typed recorded owners. Local compilation time, cache misses and internal speculative retries add no fee. Verify admission estimates cover worst-case actual costs, charge only final ordered work, and adjust prices together with compute limits after measurements.

For operations not covered here, reuse existing native fees if available; otherwise keep the allocation explicitly unresolved until a bounded implementation and measured formula exist. Reserve names for ABI/features now, then allocate numeric wire/error/storage IDs from the real registries. No fabricated numeric IDs or exact engine revision are selected here.

Engine profile and adoption evidence — Q01–Q04, Q40–Q41

DashVM uses pinned upstream Wasmtime with the Cranelift backend; contribute fixes upstream and use a small integration layer. Pin the release/commit, dependency lockfile, compiler backend, instrumentation, CPU features, memory guards and engine settings together. A semver range alone is not the reproducibility record. Engine behavior changes use normal protocol upgrades and retain historical replay behavior. Winch remains a comparison target, not a selectable production backend or automatic fallback.

Enable f32/f64 and cranelift_nan_canonicalization(true). Wasmtime documents deterministic execution considerations and the explicit NaN option. Also test signed zero, NaN bit reinterpretation, rounding/conversions, subnormals and traps across supported profiles; normalization alone does not prove the whole host deterministic. Proposed first profile keeps SIMD and relaxed SIMD disabled, separately from the approved scalar floating-point support. No OS I/O, ambient clock or entropy imports.

Retain the new Dashbot comments as evidence leads, not test results reproduced by this task. Its readiness mechanism examples motivate report retransmission and membership/key-format upgrade tests. Its backend comparison motivates pinning fuel/trap and NaN expectations to Cranelift, including exact CPU/guard settings and a genuinely failing pre-fix regression where available. Older Winch measurements do not reverse the owner's floating-point choice for Cranelift.

The upstream Cranelift advisory identifies an x86-64/SSE3-disabled edge-load defect and patched releases; the Winch advisory concerns that separate backend. Check all relevant advisories at pin selection. Merely running a named test under unaffected defaults does not establish regression coverage.

Proposed adoption evidence: the existing determinism, replay, fees, conservation, native integration, SDK example, upgrade and recovery suites, plus representative/adversarial deployment stress on both architectures and a testnet upgrade rehearsal. An initial engineering target is 7 consecutive days of clean shadow/replay comparison and 2 successful upgrade/restart/cache-loss rehearsals. This is a proposed test window, not a delivery date, new external approval gate, or a substitute for passing failure cases. Q41 accepted this direction with some hesitation; these numeric test targets remain provisional.

Final owner policy answers

Freeze, wipe, unfreeze and foreign-token vestige recovery all require strictly more than two-thirds of all active eligible evonodes, one vote each. The owner's “67%” means this exact fraction, not a rounded 67.00% rule and not at least two-thirds. Existing contested-index polls keep their own native voting parameters.

For N active eligible evonodes and Y eligible yes votes, require N > 0 and 3 × Y > 2 × N. Equivalently, the minimum yes count is floor(2 × N / 3) + 1. Use checked wide integer arithmetic, not floating point. An empty active set cannot approve a vote.

Active eligible evonodes	Minimum yes votes
3	3
100	67
300	201
400	267
1,000	667

Each vote has a one-week window and may approve early, as soon as a revalidated eligible tally exceeds two-thirds. Recheck voters and the denominator against the same agreed current membership view at the decision boundary; do not fix the electorate at opening or trust a raw count of stale votes. Reconsider on membership changes as well as vote arrival. Commit an approved outcome exactly once at the defined block boundary before affected work. An unapproved vote closes without approval at the end of the window; do not extend it or approve below threshold.

The DIP still allocates the exact phase for membership updates, vote messages, expiry and application when they meet in one block. Test boundary timestamps, membership joins/removals, duplicate/replayed votes, exactly two-thirds failing, the first larger count passing, empty membership and once-only execution. Processing phases and bounded tally work are engineering details, not unanswered policy choices.

Network-frozen contracts need this same network vote to unfreeze. Authorized code updates remain possible while frozen and do not lift the freeze. Contract-defined freezes still follow their declared rules. Foreign-token recovery votes bind the exact token IDs, amounts and recipient; assets remain in the deleted-contract identity vestige until approval. Native transfer validation and atomic conservation apply, with no permanent unrestricted recovery key or guest spending shortcut.

Compilation readiness is unchanged: at least 80% of the full active eligible evonode set, followed by the existing additional wait clamp(T, 2 minutes, 1 hour). Its vote has no automatic collection expiry. Do not apply the governance threshold or one-week window to compilation readiness. It uses 5 × ready >= 4 × N, with N > 0. Work: R11-10/15, R14-04, CAP-08/09/14, FIX-07; readiness distinction remains R08-12/13/14 and FIX-09.

Each job declares who can cancel it and reserves enough to pay its removal cost. On cancellation, charge removal and refund unused reserves to their recorded owner. If that owner is a wiped contract, send the refund to the current processing pool. Preserve removal funding across fee upgrades or settle affected old jobs first. This is now confirmed, including the previously tentative Q31 settlement details.

Live execution payment, first-inability-to-pay removal and the declared Drop/Retry/Skip execution-failure policy remain separate. A failed speculative scheduling attempt is not an additional paid contract attempt. Test authorized/unauthorized cancellation, empty operating balance with funded removal, exhausted jobs, historical fee tables, wiped/frozen refund owners and exact conservation. Work: R06-09/10, R10-05, R11-12, R12-10.

All five follow-up topics are settled. Exact engine/profile, limits, pricing and implementation details remain engineering work.

Owner review answers applying to this section

Q40 — Confirmed delegation. Maintain one protocol-versioned allocation register. Supply provisional numeric limits and prices now, then measure and revise before activation. Allocate wire/storage/ABI IDs from actual registries; keep engine/profile pin and unmeasured native costs explicitly unresolved.

Q41 — Confirmed direction with caveat. Use determinism, replay, fees, conservation, native integration, upgrade/recovery tests and a working Rust example as release evidence. Owner agreed with hesitation. Exact test windows are engineering proposals; no audit/funding/deployer-allowlist gate or new recovery authority.

Q42 — Confirmed. QuantumExplorer owns all 160 tasks for now, including runtime, SDK and separate native ACL/randomness delivery. External issue links remain to be added; dates and durations remain unset.

Final policy record and acceptance

DashVM: final five policy answers

11 September 2026. The owner answered all five remaining policy topics. Exact engine/configuration, benchmarked resource limits, prices and implementation details remain engineering work. All 160 implementation tasks remain open and assigned to QuantumExplorer; dates and durations remain unset.

Contested-index awards

Contracts may declare supported contested-index parameters, validated through the existing versioned native rules. The native protocol selects and awards the winner. Contract code and custom guards cannot veto, delay, replace, redirect or retry that award. There is no guest-controlled blocked-award state, award reserve or paid guest retry workflow.

Make the action scope explicit in the manifest, SDK and host: ordinary contract rules govern only their declared ordinary actions; native contested awards use the native contested-index rules and supported parameters. Do not invoke a guest predicate, callback or custom create guard to authorize a native award, including a guard implemented by the native generic evaluator. Reject declarations claiming such an award veto; this does not ban contested indexes alongside rules on other actions.

Preserve native eligibility, locks, tally/finalization, document validation, atomic index/reference effects and native lifecycle handling. Only an authenticated internal native award action can perform the award; arbitrary guest requests cannot impersonate it. Existing index-update restrictions also govern parameter changes; a later contract update cannot use guest logic to rewrite an existing native poll's outcome. Contract lifecycle never authorizes resurrection of wiped state. Any lifecycle handling belongs to deterministic native protocol rules, not a guest veto.

Acceptance covers allowed/invalid parameters, forged award requests, a trap/reject/infinite-loop guest guard never being invoked for an award, ordinary guard enforcement on ordinary actions, finalization once, code-update/freeze/wipe boundaries and identical native/contract-declared contest outcomes. Reuse native contest fees; do not introduce the former proposed guest-award funding and rejection system. Work: FIX-10, R07-10, CAP-03/09/14/16, SDK-01.

Network governance: strictly more than two-thirds

Freeze, wipe, unfreeze and foreign-token vestige recovery all require strictly more than two-thirds of all active eligible evonodes, one vote each. The owner's “67%” means this exact fraction, not a rounded 67.00% rule and not at least two-thirds. Existing contested-index polls keep their own native voting parameters.

For N active eligible evonodes and Y eligible yes votes, require N > 0 and 3 × Y > 2 × N. Equivalently, the minimum yes count is floor(2 × N / 3) + 1. Use checked wide integer arithmetic, not floating point. An empty active set cannot approve a vote.

Active eligible evonodes	Minimum yes votes
3	3
100	67
300	201
400	267
1,000	667

Each vote has a one-week window and may approve early, as soon as a revalidated eligible tally exceeds two-thirds. Recheck voters and the denominator against the same agreed current membership view at the decision boundary; do not fix the electorate at opening or trust a raw count of stale votes. Reconsider on membership changes as well as vote arrival. Commit an approved outcome exactly once at the defined block boundary before affected work. An unapproved vote closes without approval at the end of the window; do not extend it or approve below threshold.

The DIP still allocates the exact phase for membership updates, vote messages, expiry and application when they meet in one block. Test boundary timestamps, membership joins/removals, duplicate/replayed votes, exactly two-thirds failing, the first larger count passing, empty membership and once-only execution. Processing phases and bounded tally work are engineering details, not unanswered policy choices.

Network-frozen contracts need this same network vote to unfreeze. Authorized code updates remain possible while frozen and do not lift the freeze. Contract-defined freezes still follow their declared rules. Foreign-token recovery votes bind the exact token IDs, amounts and recipient; assets remain in the deleted-contract identity vestige until approval. Native transfer validation and atomic conservation apply, with no permanent unrestricted recovery key or guest spending shortcut.

Compilation readiness is unchanged: at least 80% of the full active eligible evonode set, followed by the existing additional wait clamp(T, 2 minutes, 1 hour). Its vote has no automatic collection expiry. Do not apply the governance threshold or one-week window to compilation readiness. It uses 5 × ready >= 4 × N, with N > 0. Work: R11-10/15, R14-04, CAP-08/09/14, FIX-07; readiness distinction remains R08-12/13/14 and FIX-09.

Scheduled-job cancellation

Each job declares who can cancel it and reserves enough to pay its removal cost. On cancellation, charge removal and refund unused reserves to their recorded owner. If that owner is a wiped contract, send the refund to the current processing pool. Preserve removal funding across fee upgrades or settle affected old jobs first. This is now confirmed, including the previously tentative Q31 settlement details.

Live execution payment, first-inability-to-pay removal and the declared Drop/Retry/Skip execution-failure policy remain separate. A failed speculative scheduling attempt is not an additional paid contract attempt. Test authorized/unauthorized cancellation, empty operating balance with funded removal, exhausted jobs, historical fee tables, wiped/frozen refund owners and exact conservation. Work: R06-09/10, R10-05, R11-12, R12-10.

Remaining engineering work

The five policy topics are settled. The earlier resource/price guesses remain provisional, including 16 MiB canonical WASM, 32 MiB signed contract create/update, memory and compute limits, retry bounds and test-window suggestions. No production constant, benchmark result or engine pin is finalized by these answers. Implementation may proceed against the selected policies with those allocations tracked explicitly.

The latest Dashbot comment adds a useful shared engine acceptance predicate: for each corpus case under the same protocol profile and recorded target-specific CPU/guard settings, x86_64 and aarch64 must agree on canonical NaN bit patterns and protocol-metered cost on traps. If raw Wasmtime fuel affects consensus costs or limits, trap-path fuel must also agree. Record raw fuel diagnostically either way; distinguish it from protocol metering. A consensus-visible mismatch rejects the profile. The comment reports no established cross-architecture mismatch, and this planning update does not claim to have run the corpus. Work: R03-01, R08-08, R14-01, FIX-05. Review comment.

Named modules — owner direction recorded 11 September 2026

Support several named WASM modules in one contract version in 5.0; a single-module bundle remains valid. Pin exact modules and interfaces in one immutable manifest, reuse unchanged canonical modules across versions, and activate the whole bundle under the existing readiness rule. Detailed linking, initialization and fee rules remain engineering proposals.

Detailed storage, linking, initialization, accounting and 16 expanded task acceptances. References above to a module/code archive now allow the complete named-module bundle. Canonical blobs and immutable manifests remain permanent; public methods map to module exports. Readiness covers every module, internal calls share one authority/budget/atomic scope, and cross-contract/scheduled latest-version routing is unchanged. Proposed ABI/linker/initializer specifics require engineering validation; this amendment does not claim implementation or measured limits.

Existing prefunded balances — confirmed reuse

Reuse the existing prefunded balance ledger and operations for scheduled-job removal funding. Use the existing 40/128/balance_id storage with purpose-bound job identifiers and native spending validation; do not add a dedicated DashVM reserve subtree or duplicate monetary ledger. Preserve legacy voting identifiers, balances and behavior. Job owner/purpose/refund metadata contains no second credit amount.

Native integration, purpose validation, ownership/refunds and revised storage mapping. R10-05, R12-10 and CAP-09 include these acceptance requirements. The same storage supplement also records the ordinary-SumTree engineering recommendation, separately from confirmed owner choices.

[QuantumExplorer]

Revision 2 (2026-09-08): edits made in place above, in response to an external review.

The body and all thirteen parts were edited in place rather than reposted, so section anchors are unchanged. The review found eight defects and one scoping problem; each is resolved as follows, with the sections that changed.

1. $contractVersion could not carry guard policy (section 7). The replace conversion re-stamps $contractVersion with the current contract version, so a version-1 document replaced under version 2 would have acquired version 2's delete prohibition. Guards' since now keys on a new immutable $createdAtContractVersion, written once at create, copied on replace, carried unchanged by transfer, price update and purchase, stored in document serialization format 4 (DOCUMENT_VERSIONS_V5, PV16). Pre-PV16 documents have no stamp and are never subject to a since guard, which is exact since they predate every guard. since may not be lower than the version installing the guard. Tests cover create, contract update, replace, delete. Sections 7 and 14.2.
2. Freezing guards would have bypassed application invariants (section 7). A frozenGuard or globalFreeze now rejects every guarded action, paid, deletes included, and never suppresses evaluation. Recovery authority is exactly two paths: unfreeze under 11.2.6's thresholds, or the contract owner removing the guard by contract update. Section 8.2.5 applies the same rule to frozen modules; only the permanent unavailability reasons keep deletes open. Sections 7, 8.2.5, 8.2.7, 11.2.6, 14.4.
3. Auction settlement bypassed guards (sections 6.5, 7). Section 7 now carries the same admissibility rule as 8.2.2 rule 6: a type whose documents can be written outside the batch seam declares no guards, so tradeMode: Auction is excluded beside contested types. Also excluded: on: [delete] guards on indexOnly types (no old, no stamp) and system data contracts. Section 7.
4. A nonce proof did not prove execution (section 10.2.5). Every executed ContractCall, success or paid failure, writes a fixed-size callReceipt document (call hash, nonce, outcome code, effects hash) in the ContractCalls system contract, one slot per caller per contract, replaced in place. VerifiedContractCallEffects is ExecutionProved only when the proven receipt's call hash matches the transition; otherwise AffectedState, consistent with the existing verifier's classifier. Sections 10.2.4, 10.2.5, 10.3, 10.4, 11.2.2, 11.3.
5. No execution-time affordability gate at PV16 (section 7). Section 7 gained the PV16 instance of 11.2.3's one bound per phase: validate_state_v1 receives the signer's PartialIdentity and, before the first guard runs, requires live balance minus accrued processing to cover the static guard bound G plus the nonce bump; a shortfall is InsufficientBalanceForGuardEvaluation, paid, with no guard evaluated. Sections 7, 11.2.3, 12.
6. The Phase 5 failure-fee bound was asserted, not derived (section 10.2.4). The claim that the degraded fee stays under floor is withdrawn. Every unit of work in a call (fuel, reads, each proposed operation's validation stages, predicates at their bound, dry runs) has a worst-case cost checked against max_fee before the unit runs, so the degraded fee is accrued <= max_fee <= live pre-call balance, which the in-block pre-check established. Scheduled calls apply the same rule against the prepaid remainder. Tests: a caller funded exactly to max_fee with maximal predicate-bearing operations failing at the last one. Sections 10.2.4, 10.2.6, 10.4, 11.2.3.
7. The oracle's at-most-k bound was not established (section 6.4). The committee for a slot is now computed once at slot open from the masternode list committed at that height and stored as a SlotCommittee element; observations are accepted only from stored members still in the list, uniqueness is checked against the block transaction, RecheckTx evicts committed duplicates, and pending duplicates are bounded per block by max_state_transitions_per_type_per_block. Equivocation is recorded as an accepted gap for Phase 1b. Sections 6.1, 6.4, 11.2.3, 14.5.
8. Contradictory requirements. No eager engine re-prepare sweep exists anywhere now: 8.2.7's lazy, charged re-preparation is canonical and the sweep was removed from 4.7, 6.1, 11.2.3, 11.2.5, 11.3 and 13. Deployment is allowlisted from PV16 everywhere: 5, 11.2.4, 11.2.6, 11.3 and 11.6 now agree with 7 and 14. Application-state rollback is specified separately from permitted failure effects: 14.5 row 5, 10.2.6, 10.4 and 11.3 require every touched subtree to equal its pre-call state while the fee debit, nonce, pools and receipt (or queue entry, prepaid balance and callOutcome) differ exactly by the paid-failure effects.

Scoping. Section 6 is now two tracks. Phase 1 (PV15) is the VM prerequisites: block budget, code blobs, range proofs and the settlement queue. Phase 1b is oracle feeds and the escrow, allowance and auction primitives: value-moving, externally audited, in its own protocol version, and a prerequisite of nothing in sections 7 to 10. Sections 1.1, 1.4, 1.6, 3.1, 5, 6, 9.2.2, 10.2.6, 11.3, 12, 13, 14.2, 14.5, 14.6, 14.9 reflect the split; 14.2 states the one-edit renumbering of contract-versions generations if Phase 1b lands after PV16.

Checkbox count: 211 (one added, the format 4 task in section 7). Revision 1 text is available from the edit history of each comment.