Release Status & Versioning
What the Aqua Protocol v4 release contains, what it deliberately excludes, and which stability guarantees apply
This page is the definitive statement of the current status of Aqua Protocol v4: what is published, what is deliberately out of scope, and which guarantees do — and do not — apply.
Aqua Protocol v4 is under active development. The published components — aqua-rs-sdk-core and aqua-template-registry — are an early community release with a deliberately limited functionality scope. Version numbers have not yet been increased, backward compatibility is not yet provided, and breaking changes are expected and may occur without notice. The full aqua-rs-sdk, which extends this core, is scheduled for a later publication. For production use today, refer to the stable v3 documentation.
Specification status
The normative protocol specification has status Draft. It lives in the aqua-rs-sdk-core repository under protocol-specification/ and is the authoritative description of the v4 core profile: where the specification and an implementation disagree, the specification states the intended protocol. Revisions on the wire carry the schema version identifier https://aqua-protocol.org/docs/v4/schema.
What this release contains
| Component | Version | Scope |
|---|---|---|
aqua-rs-sdk-core | 0.1.0 | Protocol engine: object, template, signature, and anchor revisions; hashing and canonicalization (SHA3-256 default, BLAKE3-256 optional); four signature suites (Ed25519, Ethereum EIP-191, ECDSA P-256, WebAuthn P-256); selective disclosure; the verification pipeline; 19 shipped templates (machinery, file, signature, and audit families). Library only; ships zero WASM bytes. |
aqua-template-registry | 0.1.0 | Distribution layer: a publisher-DID-scoped template registry, as a Rust library and an HTTP service (registryd), with publisher tooling and a subscribing consumer client. A hosted instance runs at aqua-registry.inblock.io, provided without SLA. |
Both are licensed Apache-2.0. aqua-rs-sdk-core is a compatible subset of the full aqua-rs-sdk: trees created and signed with the core verify in the full SDK and vice versa, enforced by an integration test suite that runs both crates side by side.
What this release deliberately excludes
The core profile is explicit about what it does not do, and it is never silently permissive about it:
| Excluded capability | Behavior in this release |
|---|---|
| WASM compute execution | Rejected, fail closed. Any template whose chain carries a verification (compute) section produces COMPUTE_UNSUPPORTED: the core has no WASM runtime and refuses to guess. The registry service likewise refuses definitions containing a WASM verification section. |
| Full-SDK template set | Answered explicitly. Template hashes published by the full SDK but not shipped by the core sit in a built-in lookup; a resolution miss answers with an explicit "not supported for verification by aqua-rs-sdk-core: it depends on <module>" message instead of guessing. |
| Timestamping | Not created; classified on input. The core creates no timestamp revisions and ships no TSA or EVM providers. Incoming timestamp revisions are still classified: the strict() policy rejects them, offline() tolerates them with a warning. |
| Policy engine | Not included. The core's VerificationPolicy presets (strict(), offline(), debug()) are part of the verification pipeline, not a policy engine; the policy engine belongs to the full SDK. |
| Daemon / forest runtime | Not included. The core is a library; there is no long-running service runtime. |
| Template registry client | Not bundled. Template distribution is the separate aqua-template-registry project; retrieved templates are passed to the core as explicit template sources. |
The invariant behind this table: the core is never more permissive than the full SDK under the same verification policy.
Registry scope
The registry deliberately validates coherence, not trustworthiness: every write is a signed Aqua tree that authenticates itself, vendor namespaces are first-come-first-served, and templates are identified by hash — names are display data. In the registry's own words, "'this registration is coherent' and 'this publisher is someone you should trust' are different claims, and only the first is in scope for a registry." Out of scope by design: on-chain registration, trust stores or ENS/DNS resolution, freshness or liveness guarantees, cross-registry mirroring and federation, transport security in the built-in client, and plugin/WASM distribution. Templates on the hosted instance may be wiped without notice while it runs under experimental conditions.
Versioning policy
-
Both crates are at version 0.1.0. Version numbers have not been increased since the initial release.
-
No backward-compatibility guarantees are provided yet. Breaking changes are expected and may occur without notice.
-
Neither repository carries release tags, a changelog, or a semantic-versioning policy yet.
-
Not on crates.io yet. Publication is planned; until then, install via git dependency:
Codetoml1[dependencies]2aqua-rs-sdk-core = { git = "https://github.com/inblockio/aqua-rs-sdk-core" } -
No MSRV commitment.
aqua-rs-sdk-coredeclares no minimum supported Rust version;aqua-template-registrycurrently setsrust-version = "1.85"in its manifest, but neither value is a compatibility commitment.
Known upcoming changes
Two changes are already announced and worth planning for:
- Audit templates move to registry-only distribution. The sanctioned distribution channel for the audit/agent template family is the template registry. This release still carries in-crate copies (they back the compatibility test suite), so built-in resolution of these templates still succeeds today — do not depend on it: it is not part of the supported contract, and removal from the catalog is a tracked breaking change.
- Audit-family harmonization will change template hashes. The audit templates in this release are a deliberate, test-bounded fork of the full SDK's family, pending upstream harmonization. When the two families are reunified, the audit template hashes will change. Treat current audit template hashes as pinned per release, not as permanent identifiers.
Relationship to Aqua v3
Aqua Protocol v3 is the stable, production release, built around a JavaScript/TypeScript SDK. It is documented under v3 documentation and is unaffected by v4's experimental status.
| If you need | Use |
|---|---|
| A production deployment today | v3 — stable JavaScript/TypeScript SDK |
| Timestamping / witnessing today | v3 — the published v4 core profile excludes timestamping |
| The v4 data model in Rust: typed objects, selective disclosure, template distribution, agent audit trails | v4 — accepting experimental status and breaking changes |
Where future components will appear
The full aqua-rs-sdk — which extends the published core with the WASM compute runtime, the policy engine, the daemon runtime, and timestamping providers — is scheduled for a later publication. Until then, the capabilities listed above remain outside the published surface, with the fail-closed behavior described.
The Aqua CLI and the hosted Aquafier application belong to the v3-era toolchain today; they are not part of the v4 release. For current CLI and Aquafier usage, see the v3 tooling documentation.
See also
- Welcome — what Aqua Protocol v4 is
- aqua-rs-sdk-core — the published crate in detail
- Template Registry — the distribution layer
- Verification — policies and decision points in detail
- Aqua v3 introduction — the stable release