Deliver DAPI, Rust, Wasm/JS and mobile parity

Parent: #4626 · Complete tracking register

Proposed target: 5.0-dev. This is a workstream tracking issue, not a claim that the release branch exists or the implementation is done. Owner: QuantumExplorer. Dates and effort remain unset.

Scope

Expose all contract declarations/calls/lifecycle/readiness/fees/proofs through consistent client models and shared vectors, including Swift and Kotlin persistent models and examples.

Specification

DVM-01 · DVM-03 · DVM-10 · DVM-11

The current parent acceptance and module/capability appendices remain authoritative; these DIP drafts add proposed engineering detail without silently approving open allocations.

Completion criteria

Complete every listed task acceptance item, its applicable capability matrix, and the linked specification vectors. Record actual PR/test evidence; drafting is not production completion.

Task acceptance

R07-07

• Preserve guard schema/configuration and structured error information across Rust, WASM, JS, Swift and Kotlin clients and persistence; record SDK parity.

Prerequisites: R07-03, R07-02, R13-03.

Dependents: R07-10.

Modules: CLIENT, FFI, SWIFT, JNI, KOTLIN, WASM_CLIENT. Original task context.

R09-04

• 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.

Prerequisites: R09-01, R09-03, R08-07.

Dependents: R10-06.

Modules: CLIENT, FFI, SWIFT, JNI, KOTLIN, WASM_CLIENT. Original task context.

R10-06

• 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.

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. Scheduled-job clock: 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. Engineering architecture: Include existing Rust platform-wallet, wallet FFI, unified iOS artifact and Android JNI. Keep wallet orchestration in Rust; preserve proof outcomes, native result ownership, unsigned domains, teardown/cancellation fences and mobile large-stack proof runtime.

Prerequisites: R10-03, R10-04, R09-04, R13-08, R10-05, R13-06.

Dependents: R10-08, R13-11.

Modules: CLIENT, AUTHOR, FFI, SWIFT, JNI, KOTLIN, WASM_CLIENT, WALLET, WALLET_FFI. Original task context.

R13-03

• Keep contract configuration/schema mirrors consistent across Rust, WASM/TypeScript, Swift and Kotlin, including persistence of new policy, version and receipt fields.

Prerequisites: None recorded.

Dependents: R07-07.

Modules: DPP, CLIENT, WASM_CLIENT, FFI, SWIFT, JNI, KOTLIN. Original task context.

R13-08

• 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.

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. Engineering architecture: Include existing Rust platform-wallet, wallet FFI, unified iOS artifact and Android JNI. Keep wallet orchestration in Rust; preserve proof outcomes, native result ownership, unsigned domains, teardown/cancellation fences and mobile large-stack proof runtime.

Prerequisites: R06-06, R13-06, R08-05.

Dependents: R10-06.

Modules: CLIENT, READINESS, WIRE, FFI, SWIFT, JNI, KOTLIN, WASM_CLIENT, WALLET, WALLET_FFI. Original task context.

R13-11

• 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.

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. Engineering architecture: Include existing Rust platform-wallet, wallet FFI, unified iOS artifact and Android JNI. Keep wallet orchestration in Rust; preserve proof outcomes, native result ownership, unsigned domains, teardown/cancellation fences and mobile large-stack proof runtime.

Prerequisites: R10-06.

Dependents: None recorded.

Modules: CLIENT, CALLS, PROOF_CLIENT, FFI, SWIFT, JNI, KOTLIN, WASM_CLIENT, WALLET, WALLET_FFI. Original task context.

R13-14

• 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.

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.

Prerequisites: None recorded.

Dependents: None recorded.

Modules: CLIENT, EXEC_STORE, ASSETS, FFI, SWIFT, JNI, KOTLIN, WASM_CLIENT. Original task context.

CAP-13

• Expose capability parity across guest SDK, DAPI and clients

Rust guest builders, DAPI/result schemas, Rust/WASM/JS/mobile conversion and proof vectors; no network preflight in5.0. Engineering architecture: Preserve query-library -> proof-verifier -> Drive verification dependency direction. Implement a real alloc-only guest value/codec feature path excluding full native PlatformVersion dispatch, DPP, Drive, clients and execution engine; verify separate guest-target builds.

Prerequisites: CAP-12.

Dependents: CAP-16, CAP-18.

Modules: ABI, AUTHOR, QUERY_SERVER, WIRE, CLIENT, FFI, SWIFT, JNI, KOTLIN, WASM_CLIENT. Original task context. Capabilities: O05. Refinements (not extra dependency edges): SDK-02, SDK-04.

Coordination and dependencies

Task-level prerequisites above govern order. Workstreams contain multiple stages, so a cross-link is not a claim that the entire other issue must close first. These are Markdown relationships, not native GitHub blocked-by edges. The parent dependency register preserves all 234 links, reasons and explicit/inferred labels.

• CAP-12 → CAP-13 (inferred): Implementation dependency between the specified adapters and their integration checks.
• CAP-13 → CAP-16 (inferred): Implementation dependency between the specified adapters and their integration checks.
• CAP-13 → CAP-18 (inferred): Implementation dependency between the specified adapters and their integration checks.
• R07-03 → R07-07 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R07-02 → R07-07 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R07-07 → R07-10 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R06-06 → R13-08 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R13-06 → R13-08 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-05 → R13-08 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R09-01 → R09-04 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R09-03 → R09-04 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R08-07 → R09-04 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R10-03 → R10-06 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R10-04 → R10-06 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R10-05 → R10-06 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R13-06 → R10-06 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.
• R10-06 → R10-08 (inferred): Rebased source dependency; confirm the implementation ordering. Implementation prerequisite inferred from the described interfaces.

PR and evidence tracking

Create focused PRs against the chosen development branch. Link this issue with Refs #<issue-number> for partial work. Do not use Fixes for the whole workstream until every listed full task and acceptance criterion is complete.

For a PR that completes an entire task, add a standalone line in its actual PR body: Dash-Tasks: <completed task IDs>. Replace the placeholder with only fully completed IDs. Preparation PRs use ordinary references and omit the completion marker for their broader parent tasks. The site reads this marker on PRs in dashpay/platform and dashpay/grovedb: draft = red, ready for review = yellow, merged with no linked open PR = green. Closed-unmerged is not completion. This does not automatically close issue checkboxes and does not prove acceptance tests passed; reviewers must record the evidence.