Changelog¶
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog.
[2.8.1] - 2026-04-26¶
Wired the canonicalization_profile field across the four SDKs¶
v2.8.0 declared the canonicalization_profile field in
schemas/v2/bundle_manifest.schema.json and described it in
spec/CANONICALIZATION_PROFILE.md § 4, but no SDK actually wrote or
read the field — the typed BundleManifest structures shipped without
it, and verifiers ignored it. v2.8.1 closes that gap end-to-end.
- TypeScript (
@dcp-ai/sdk2.1.0 → 2.1.1) —BundleManifestinterface insdks/typescript/src/types/v2.tsgainscanonicalization_profile?: 'dcp-jcs-v1'.BundleBuilderV2.build()insdks/typescript/src/bundle/builder-v2.tsnow emitscanonicalization_profile: "dcp-jcs-v1"on every produced manifest.verifyV2Bundleinsdks/typescript/src/core/verify-v2.tsaccepts an absent field (assumesdcp-jcs-v1), accepts"dcp-jcs-v1"explicitly, and rejects any other value with"Unknown canonicalization_profile: <value>". - Python (
dcp-ai2.8.0 → 2.8.1) —BundleManifestinsdks/python/dcp_ai/v2/models.pygainscanonicalization_profile: Literal["dcp-jcs-v1"] | None = "dcp-jcs-v1". Pydantic enforces unknown-value rejection at parse time; absence triggers the default value. No separate verifier change is needed because validation lives in the model. - Go (
sdks/go/v2.8.0→v2.8.1) —BundleManifeststruct insdks/go/dcp/v2/types.gogainsCanonicalizationProfile stringwithjson:"canonicalization_profile,omitempty".BuildBundleV2insdks/go/dcp/v2/bundle_builder.gosets it to"dcp-jcs-v1"on every produced manifest.VerifySignedBundleV2insdks/go/dcp/v2/verify_bundle.gonow rejects bundles whose manifest carries acanonicalization_profilevalue other than"dcp-jcs-v1". - Rust (
dcp-aicrates.io 2.8.0 → 2.8.1) —BundleManifestinsdks/rust/src/v2/types.rsgainspub canonicalization_profile: Option<String>with#[serde(skip_serializing_if = "Option::is_none")].wasm_build_bundleinsdks/rust/src/lib.rssets"canonicalization_profile": "dcp-jcs-v1"on the manifest it emits.
Spec & profile document¶
spec/DCP-AI-v2.0.md§ 9 (Bundle Manifest) now listscanonicalization_profilealongside the other manifest fields, with an inline note that an absent field MUST be assumed equivalent to"dcp-jcs-v1".spec/CANONICALIZATION_PROFILE.md§ 2 — Rule 6 (undefined / null handling) is rewritten as a cross-language table that explicitly lists how TypeScript, Python, Go, and Rust host values map onto the JSON wire format for both object slots and array slots.spec/CANONICALIZATION_PROFILE.md§ 2 — new Rule 9 makes Unicode normalization (NFC, NFD, NFKC, NFKD) explicitly out of scope: the canonicalizer emits strings byte-for-byte as the host parser delivers them, and a future profile (dcp-jcs-v2or later) MAY pin a normalization form. RFC 8259 § 8.1 is referenced as the conventional choice (NFC) for application-layer normalisation.spec/CANONICALIZATION_PROFILE.mdRule 9 also pins the rationale for not shippingNaN/±Infinityinterop fixtures: those values are not part of RFC 8259 wire format, so most parsers reject them before the canonicalizer is reached. Rejection is verified by per-SDK unit tests rather than shared fixtures.
Behavioural compatibility¶
The new field is additive and optional in serialization:
- A
v2.8.1-produced bundle carriescanonicalization_profile: "dcp-jcs-v1"on its manifest. Older verifiers that don't know about the field will treat it as an unknown property — which is fine because the JSON Schema declares the field asadditionalProperties- compatible (it lives amongpropertiesand isoptional). - A bundle produced by
v2.8.0or earlier has nocanonicalization_profilefield.v2.8.1verifiers accept it: perspec/CANONICALIZATION_PROFILE.md§ 4, an absent field MUST be assumed equivalent to"dcp-jcs-v1". - A bundle that carries
canonicalization_profilewith an unknown value (e.g."dcp-jcs-v2") is rejected by everyv2.8.1SDK. This is the forward-compatibility hook for future profiles: a verifier that hasn't been updated to a new profile MUST refuse it rather than silently accept a manifest it cannot validate.
The bundle-level signature covers canonical(manifest), so adding the
field changes the manifest hash of any newly-produced bundle relative
to one that would have been produced under v2.8.0. Bundles produced
under v2.8.0 and earlier, and their stored signatures, remain valid
under v2.8.1 verifiers.
Versions bumped¶
dcp-ai(PyPI) 2.8.0 → 2.8.1dcp-ai(crates.io) 2.8.0 → 2.8.1github.com/dcp-ai-protocol/dcp-ai/sdks/go/v2v2.8.0 → v2.8.1@dcp-ai/sdk(npm) 2.1.0 → 2.1.1 — first TypeScript code change since 2.1.0 (the 2.8.0 release was a docstring-only edit)
[2.8.0] - 2026-04-26¶
Added — Canonicalization profile dcp-jcs-v1¶
A public crosswalk against another protocol surfaced three real
asymmetries in how the four SDKs canonicalised JSON: 1.0/1.00
were rejected by Python and Rust but accepted by TypeScript and Go;
1e2 was rejected by Rust alone; and undefined had no formal
treatment in the spec. The "RFC 8785 + integer-only" summary in
spec/DCP-AI-v2.0.md § 15 was correct as far as it went, but did not
pin the cases JCS leaves implementation-defined. This release closes
all of them.
- New normative document:
spec/CANONICALIZATION_PROFILE.mdformalises profiledcp-jcs-v1with eight numbered rules, an edge-case acceptance table covering 22 inputs, an undefined-handling contract that documents the TypeScript-only asymmetry (omit in objects, serialize asnullin arrays), and a versioning policy for future profiles. - Bundle manifest field:
canonicalization_profile: "dcp-jcs-v1"added toschemas/v2/bundle_manifest.schema.jsonas an optional field. Verifiers that encounter a bundle without it MUST assumedcp-jcs-v1. Future profiles will make the field required. - Python (
dcp-ai2.7.1 → 2.8.0):assert_no_floatsnow accepts floats whose value is a finite integer (1.0,1e2,1.00); they are normalised to integer form beforejson.dumps. Non-integer floats (0.1),NaN, and infinities remain rejected. - Rust (
dcp-ai2.7.0 → 2.8.0):assert_no_floatsnow acceptsNumber(f64)whosefract()is zero. Newformat_numberhelper incanonical_recurseemits integer-valued floats without decimal point or exponent, matching the other SDKs byte-for-byte. - Go (
sdks/go/v2.7.0→v2.8.0): behaviour already aligned (v != math.Trunc(v)check). Version-bump only. - TypeScript (
@dcp-ai/sdkstays 2.1.0): behaviour already aligned. Docstring insdks/typescript/src/core/canonicalize.tsformalises the undefined-vs-null asymmetry.
Added — interop edge-case fixtures¶
tests/interop/v2/interop_vectors.json now ships
canonicalization.edge_cases with 14 vectors covering null
preservation (with key, inside arrays), integer-valued floats,
trailing zeros, scientific notation, fractional rejection, non-finite
rejection, code-point key sorting (including é), nested nulls,
empty containers, deeply nested objects, and arrays with null. Each
SDK's interop test loads the same block and asserts byte-identical
output (or matching error) for every vector. CI runs all four in
parallel on every PR; divergence is a release blocker.
Versions bumped¶
dcp-ai(PyPI) 2.7.1 → 2.8.0dcp-ai(crates.io) 2.7.0 → 2.8.0github.com/dcp-ai-protocol/dcp-ai/sdks/go/v2→ v2.8.0@dcp-ai/sdk(npm) stays 2.1.0 — TypeScript already implemented the profile; this release adds the docstring formalisation only.
Behavioural compatibility¶
Bundles produced by previous releases remain valid. The change is
additive for SDKs that previously rejected 1.0/1.00/1e2:
inputs that used to throw TypeError/Err now succeed and produce
the same canonical output other SDKs were already producing. No
input that previously canonicalised successfully canonicalises
differently in 2.8.0.
[2.7.1] - 2026-04-23 (Python only)¶
Fixed¶
dcp-ai(PyPI) 2.7.0 was missingcryptographyas a hard dependency. The package is required by the DCP-04 A2A session layer introduced in 2.5.0 for AES-256-GCM encryption. Freshpip install dcp-ai==2.7.0installs did not pullcryptography, so three A2A session tests failed under a clean environment (test_encrypt_decrypt_round_trip,test_tamper_ciphertext_rejected,test_session_id_mismatch). 2.7.1 addscryptography>=41.0to the wheel's required dependencies.
Rust (dcp-ai crates.io) and Go (sdks/go/v2) are unaffected and remain at
2.7.0 — the cryptography Python package only matters for the Python wheel.
[2.7.0] - 2026-04-23¶
Added — Canonical error codes + wire-format detection in PY / GO / RS¶
Ports the DcpErrorCode enum and accompanying DcpError / DcpProtocolError
machinery from TS to Python, Rust, and Go, plus the lightweight
detect_wire_format helper that routes an incoming byte stream to
"json" or "cbor" based on the first byte.
Every SDK now agrees on the same 38 canonical error codes covering:
schema errors (E001-E099), signature errors (E100-E199), hash/chain errors
(E200-E299), identity errors (E300-E399), policy errors (E400-E499),
session errors (E500-E599), A2A errors (E600-E699), rate limiting
(E700-E799), and internal errors (E900-E999). Each code carries a canonical
message + a retryable flag so clients can implement policy-matching
retry logic consistently across SDKs.
Python (dcp-ai 2.6.0 -> 2.7.0) — new dcp_ai.v2.error_codes module
with DcpErrorCode (str-enum), DcpError dataclass,
DcpProtocolError exception, create_dcp_error, is_dcp_error,
detect_wire_format, and ERROR_DESCRIPTIONS mapping.
Rust (dcp-ai 2.6.0 -> 2.7.0) — dcp_ai::v2::error_codes with the
DcpErrorCode enum (Display → the stable DCP-E### identifier),
DcpError struct, create_dcp_error, and detect_wire_format.
Go (sdks/go/v2.6.0 -> v2.7.0) — v2.DcpErrorCode typed-string with
37 Err* constants, v2.DcpError struct implementing the error
interface, CreateDcpError, IsDcpError, DetectWireFormat.
CBOR encoder/decoder scope decision¶
The full CBOR encoder/decoder remains TypeScript-only in 2.x. Porting a
deterministic RFC 8949 implementation to three more SDKs is a substantial
project that deserves its own milestone; detect_wire_format is the
single helper every SDK needs today to route CBOR payloads to an
existing ecosystem library (e.g. cbor2 in Python,
github.com/fxamacker/cbor/v2 in Go, ciborium in Rust). A dedicated
v3.x release will add a canonical port.
Test counts¶
- Python: 231/231 pass (unchanged; import surface verified)
- Rust: 152/152 pass (+5 new)
- Go: 115/115 pass (+8 new)
Versions bumped¶
dcp-ai(PyPI) 2.6.0 -> 2.7.0dcp-ai(crates.io) 2.6.0 -> 2.7.0github.com/dcp-ai-protocol/dcp-ai/sdks/go/v2-> v2.7.0
[2.6.0] - 2026-04-23¶
Added — blinded RPR, multi-party auth, advisory helpers in Rust + Go¶
Ports three Python-exclusive features to Rust and Go, closing the gap noted in the crosswalk where Python was ahead of the other non-TS SDKs.
- Blinded RPR (Gap #2):
compute_pii_hash,blind_rpr,verify_blinded_rpr,is_blinded_rpr. - Multi-Party Authorization (Gap #5):
verify_multi_party_authorization MultiPartyPolicywith the four default operation policies (revoke_agent,rotate_org_key,change_jurisdiction,modify_recovery_config).- Algorithm advisory helpers (Gap #4):
check_advisory,evaluate_advisories,apply_advisories_to_policy,build_algorithm_advisory.
All three modules match the Python semantics: SHA-256 PII commitment,
M-of-N structural validation (crypto verification stays at the gateway),
and routing by action (revoke / deprecate / warn) with grace-period
handling.
Python (dcp-ai 2.5.0 -> 2.6.0): no code change, version bump only to
keep the SDK suite synchronised.
Test counts¶
- Rust: 147/147 (+14 new)
- Go: 106/106 (+12 new)
- Python: 231/231 (unchanged)
[2.5.0] - 2026-04-23¶
Added — DCP-04 Agent-to-Agent protocol parity¶
Ports DCP-04 (Agent-to-Agent) scaffolding to the remaining SDKs.
Python (dcp-ai 2.4.0 -> 2.5.0) — full parity with TS including the
symmetric session layer (AES-256-GCM via the cryptography package).
- Discovery:
create_agent_directory,find_agent_by_capability,find_agent_by_id,validate_directory_entry. - Handshake:
generate_nonce,create_hello,create_welcome,derive_session_id,create_close_message. - Session:
A2ASession,create_session,encrypt_message,decrypt_message,needs_rekeying,generate_resume_proof,verify_resume_proof,derive_rekeyed_session_key.
Go (sdks/go/v2.4.0 -> v2.5.0) — full parity with TS, using Go stdlib
crypto/aes + crypto/cipher for AES-256-GCM (no new dependencies).
Rust (dcp-ai 2.4.0 -> 2.5.0) — discovery + handshake scaffolding.
The AES-256-GCM session layer is scheduled for a follow-up release; Rust
users can still build directories, HELLO/WELCOME messages, and derive
session IDs.
Test counts: Python 231/231, Rust 133/133, Go 94/94.
[2.4.0] - 2026-04-23¶
Added — Production hardening primitives in Python, Rust, Go¶
Ports the four protocol-critical hardening primitives from the TS core:
- Session nonce helpers:
generate_session_nonce,is_valid_session_nonce,verify_session_binding,generate_session_expiry,is_session_expired. - Adaptive security tier:
compute_security_tier,max_tier,tier_to_verification_mode,tier_to_checkpoint_interval(Go already hadComputeSecurityTier; v2.4 adds the three helper functions). - Emergency revocation (Gap #13):
generate_emergency_revocation_token,verify_emergency_revocation_secret,build_emergency_revocation. - Lazy PQ checkpoints:
audit_events_merkle_root,create_pq_checkpoint, andPQCheckpointManagerclass with tier-driven interval selection and automatic flush behaviour.
All four modules match the TS semantics exactly: constant-time secret
verification for emergency revocation, tier-driven checkpoint intervals,
session-nonce validator regex, and signed checkpoint payloads under the
DCP-AI.v2.AuditEvent domain-separation context.
What's not in v2.4¶
Deliberately scoped out (will ship as follow-up releases if demand appears): - Shamir secret sharing (Gap #1) — requires careful crypto review; TS-only. - Verification cache — app-level concern, not protocol. - Rate limiting / circuit breaker / retry — app-level patterns best delegated to existing ecosystem libraries.
Test counts¶
- Python: 214/214 pass (+24 new)
- Rust: 126/126 pass (+10 new)
- Go: 81/81 pass (+9 new)
Versions bumped¶
dcp-ai(PyPI) 2.3.0 -> 2.4.0dcp-ai(crates.io) 2.3.0 -> 2.4.0github.com/dcp-ai-protocol/dcp-ai/sdks/go/v2-> v2.4.0
[2.3.0] - 2026-04-23¶
Added — Dispute + Rights + Delegation parity across SDKs¶
Python, Rust, and Go now implement DCP-07 (Dispute Resolution + Arbitration), DCP-08 (Rights & Obligations), and DCP-09 (Delegation, Awareness-threshold, Principal Mirror) behavior — matching the TypeScript feature set.
New function groups (identical semantics across PY/RS/GO, matching TS):
DCP-07 Conflict Resolution:
- create_dispute · escalate_dispute · resolve_dispute · create_objection
- Arbitration: create_arbitration_panel · submit_resolution ·
build_jurisprudence_bundle · lookup_precedent
DCP-08 Rights & Obligations:
- declare_rights · record_obligation · report_violation ·
check_rights_compliance
DCP-09 Delegation & Representation:
- Delegation: create_delegation_mandate · verify_mandate_validity ·
revoke_delegation · generate_interaction_record
- Awareness threshold: evaluate_significance · should_notify_human ·
create_awareness_threshold · create_advisory_declaration
- Principal mirror: generate_mirror
All new factories use the existing composite-sign path under the
DCP-AI.v2.Dispute, DCP-AI.v2.Rights, DCP-AI.v2.Delegation, and
DCP-AI.v2.Awareness domain-separation contexts. The delegation mandate
artifact carries its human-principal signature in the human_composite_sig
field, matching the TS wire format.
Test counts¶
- Python: 190/190 pass (+21 new)
- Rust: 116/116 pass (+12 new)
- Go: 72/72 pass (+12 new across outer
dcp_testpackage) - TypeScript: 460/460 pass (no changes)
Versions bumped¶
dcp-ai(PyPI) 2.2.0 -> 2.3.0dcp-ai(crates.io) 2.2.0 -> 2.3.0github.com/dcp-ai-protocol/dcp-ai/sdks/go/v2-> v2.3.0@dcp-ai/sdk(npm) stays at 2.1.0
[2.2.0] - 2026-04-23¶
Added — Lifecycle + Succession parity across SDKs¶
Python, Rust, and Go SDKs now implement DCP-05 (Agent Lifecycle) and DCP-06 (Digital Succession) behavior. TypeScript already shipped these in 2.0.x; the 2.2.0 release closes the first behavioral-parity gap identified in the cross-SDK crosswalk.
New functions (identical semantics across Python/Rust/Go, matching TS):
DCP-05 Agent Lifecycle:
- validate_state_transition / ValidateStateTransition
- compute_vitality_score / ComputeVitalityScore
- create_commissioning_certificate / CreateCommissioningCertificate
- create_vitality_report / CreateVitalityReport
- hash_vitality_report / HashVitalityReport
- create_decommissioning_record / CreateDecommissioningRecord
DCP-06 Digital Succession:
- create_digital_testament / CreateDigitalTestament
- update_digital_testament / UpdateDigitalTestament
- classify_memory / ClassifyMemory
- create_memory_transfer_manifest / CreateMemoryTransferManifest
- execute_succession / ExecuteSuccession
All new factories use the existing composite-sign path under the
DCP-AI.v2.Lifecycle and DCP-AI.v2.Succession domain-separation contexts,
so artifacts produced by any SDK are wire-compatible and cross-verifiable.
Test counts after this release¶
- Python: 169/169 pass (+24 new)
- Rust: 104/104 pass (+10 new)
- Go: 60/60 pass (+13 new across outer
dcppackage; v2 package unchanged) - TypeScript: 460/460 pass (no changes)
Known protocol-level note¶
DCP v2.0 canonicalisation forbids floats for cross-SDK determinism, but
the vitality-report schema expresses per-metric values as number
(0.0..1.0). Factories in all four SDKs now accept metrics at the API
boundary but signers require integer representations on the wire. This
is documented in each SDK's tests. A future release may tighten the
schema to integers (or basis-points) to eliminate the gap entirely.
Versions bumped¶
dcp-ai(PyPI) 2.1.0 -> 2.2.0dcp-ai(crates.io) 2.1.0 -> 2.2.0github.com/dcp-ai-protocol/dcp-ai/sdks/go/v2-> v2.2.0@dcp-ai/sdk(npm) stays at 2.1.0 (TS already had these functions)
[2.1.0] - 2026-04-22¶
Added¶
OpenTelemetry (OTLP) exporter for all four core SDKs — TypeScript, Python, Rust, and Go. Adopters can now pipe DCP observability into any OTel-compatible backend (Grafana, Jaeger, Honeycomb, Datadog, New Relic, self-hosted Collectors) without hand-rolled bridges. Every SDK that performs DCP cryptography now reports the same metric names, counters, and span shapes.
-
Rust (
dcp-ai2.0.0 → 2.1.0)- New
dcp_ai::observabilitymodule with thread-safeDcpTelemetrysingleton, recorder methods, span lifecycle,on_eventlistener bus, andMetricsSummarywith p50/p95/p99. - Optional
otlpCargo feature (cargo add dcp-ai --features otlp) pullsopentelemetry,opentelemetry_sdk,opentelemetry-otlp, andtokio. Without the feature, requestingExporterType::Otlpsurfaces a clear error event instead of panicking. - Hot paths instrumented:
crypto::sign_objectandcrypto::verify_objectemit latency + error telemetry when enabled. Zero overhead when disabled (default). - 10 unit tests covering disabled-by-default behavior, percentiles, span lifecycle, tier distribution, cache hit rate, and listener panic isolation.
- New
-
Go (
sdks/go/v2.0.0 → v2.1.0)- New
github.com/dcp-ai-protocol/dcp-ai/sdks/go/v2/dcp/observabilitypackage with mutex-protectedTelemetrytype,Default()singleton, recorder methods, subscribers with panic recovery, percentile math matching the other SDKs. - OTLP bridge gated by the
otlpbuild tag (go build -tags otlp). Without the tag, requestingExporterOTLPemits a clearotlp_initerror event via the listener bus. Thego.opentelemetry.io/oteldependencies are listed ingo.modbut are not required at runtime by default builds. - Hot paths instrumented:
dcp.SignObjectanddcp.VerifyObjectemit latency + error telemetry when enabled. Zero overhead when disabled (default). - 10 unit tests for the observability package + 2 integration tests against
dcp.SignObjectcovering the enabled/disabled paths.
- New
-
TypeScript (
@dcp-ai/sdk2.0.0 → 2.1.0)dcpTelemetry.init({ exporterType: 'otlp' })now actually works (the config field was declared in 2.0.x but not wired).- OTel SDK is imported lazily — default installs are unchanged. The
@opentelemetry/*packages are declared as optional peer dependencies; when omitted,init()emits a clear error event via the listener bus and the app keeps running. - New
dcpTelemetry.shutdown()to flush pending exports. - Endpoint resolution:
otlpEndpointconfig →OTEL_EXPORTER_OTLP_ENDPOINTenv var →http://localhost:4318. service.name+service.versionresource attributes auto-populated.- Metric mapping: DCP recorders map to OTel histograms (
dcp.sign.latency_ms,dcp.verify.latency_ms,dcp.kem.latency_ms,dcp.checkpoint.latency_ms,dcp.bundle_verify.latency_ms) and counters (dcp.signatures.created,dcp.signatures.verified,dcp.bundles.verified,dcp.a2a.sessions,dcp.errors). - 2 new vitest cases; 460/460 tests pass.
-
Python (
dcp-ai2.0.2 → 2.1.0)- New
dcp_ai.observabilitymodule providingdcp_telemetrysingleton with the same API surface as the TypeScript version: spans, metric recorders (record_sign_latency,record_verify_latency,record_kem_latency,record_checkpoint_latency,record_bundle_verify,record_cache_hit/miss,record_a2a_*,record_error),on_eventlistener bus,get_metrics_summarywith p50/p95/p99. - Exporter modes:
none(default) /console/otlp. - New install extra:
pip install 'dcp-ai[otlp]'pullsopentelemetry-sdk+opentelemetry-exporter-otlp-proto-http. Without the extra,init(exporter_type="otlp")surfaces a clear install hint without crashing. - Hot paths instrumented:
sign_objectandverify_objectnow emit latency + error telemetry when enabled. No overhead when disabled (default). - Public export:
from dcp_ai import dcp_telemetryworks. - 15 new pytest cases; 145/145 tests pass.
- New
Documentation¶
- New
docs/OBSERVABILITY.mdwith three copy-paste backend recipes (local Jaeger via Docker, Grafana Cloud OTLP endpoint, Honeycomb).
Backward compatibility¶
- Fully backward compatible across all four SDKs. Defaults unchanged — telemetry ships disabled, recorders are no-ops. No code changes needed for adopters who don't want observability.
- Synchronized semver:
@dcp-ai/sdk(npm),dcp-ai(PyPI),dcp-ai(crates.io), andgithub.com/dcp-ai-protocol/dcp-ai/sdks/go/v2all move to 2.1.0. Other publishable packages (CLI, WASM, integrations, create-* scaffolders) remain at their current versions. - WASM SDK observability is deferred to a future minor; browser telemetry has different transport requirements.
Template packages - 2026-04-21¶
First publication of four npm create @dcp-ai/* scaffolders, all at v2.0.0:
@dcp-ai/create-langchain@dcp-ai/create-crewai@dcp-ai/create-openai@dcp-ai/create-express
Usage: npm create @dcp-ai/langchain my-app (or any of the four). Each scaffolder ships a self-contained starter template — same content as the existing templates/<name>/ in the repo — plus a tiny 35-line bin.js with zero runtime dependencies.
Infrastructure¶
- JSON-LD context now served at
https://dcp-ai.org/credentials/v2(Content-Typeapplication/ld+json, CORS*, 24 h cache). Required by@dcp-ai/w3c-didso every emitted Verifiable Credential/Presentation is dereferenceable by strict JSON-LD processors (Veramo, SpruceID, Trinsic). - Codecov coverage reports aggregated across the four SDKs (TypeScript, Python, Go, Rust) with per-SDK flags. Badge live in the README.
- Publish workflows hardened: every job (npm / PyPI / crates.io) now pre-checks the registry and exits green with a skip notice if the manifest version is already live. No more red jobs on routine releases.
Go SDK v2.0.0 - 2026-04-19¶
First installable release of the Go SDK via go get. The previous module path (github.com/dcp-ai/dcp-ai-go) pointed at a repository that did not exist, so external consumers could not install it. The module now lives as a sub-directory module inside this monorepo:
- New module path:
github.com/dcp-ai-protocol/dcp-ai/sdks/go/v2(/v2suffix required by Go for major versions ≥ 2) - Tag format:
sdks/go/v2.0.0(sub-directory-prefixed, as required by the Go module proxy for multi-module repos) - Install:
go get github.com/dcp-ai-protocol/dcp-ai/sdks/go/v2@v2.0.0
Code is unchanged — only the module path and internal imports were rewritten. All tests still pass.
[2.0.2] - 2026-04-18¶
Python SDK¶
- Fixed:
dcp_ai.__version__now reflects the installed version dynamically viaimportlib.metadatainstead of a hardcoded string. In 2.0.1 the attribute still reported"1.0.0"even though the wheel was2.0.1.
CI / publish workflows¶
- Every publish job (
publish.yml,publish-pypi.yml,publish-integrations.yml) now pre-checks whether the manifest version is already on the registry and, if so, exits green with a skip notice. Previously, any release-triggered run re-attempted to publish already-published versions and left four red jobs in the Actions tab. No more cosmetic red ghosts on routine releases. - Fixed two outdated package names in the README integrations table:
@dcp-ai/a2a→@dcp-ai/google-a2a,@dcp-ai/mcp→@dcp-ai/anthropic-mcp. - Live npm / PyPI version badges added per row in the integrations table.
[2.0.1] - 2026-04-18¶
Python SDK¶
Framework bridges are now shipped inside the package. Prior to 2.0.1
they lived under integrations/<name>/ in the repo and were only
loadable through a pytest hack; anyone who ran pip install dcp-ai[fastapi]
got the upstream fastapi library but not the dcp_ai.fastapi
middleware. 2.0.1 fixes that: the four modules now live under
dcp_ai/ and are included in the published wheel.
- Added:
dcp_ai.fastapi(middleware, dependency injection, V2 structure checks) - Added:
dcp_ai.langchain(agent wrapper, callback, risk scoring) - Added:
dcp_ai.openai(client, tool schema, audit trail builder) - Added:
dcp_ai.crewai(crew agent, combined audit trail, session consistency checks) - Removed:
tests/conftest.pydynamic-module loader (no longer needed)
Installation¶
pip install dcp-ai[fastapi] # brings fastapi + uvicorn
pip install dcp-ai[langchain] # brings langchain + langchain-core
pip install dcp-ai[openai] # brings openai
pip install dcp-ai[crewai] # brings crewai
Backward compatibility¶
Fully compatible with 2.0.0 imports. The new modules only add API
surface; existing from dcp_ai import ... calls are unaffected.
[npm integrations] - 2026-04-18¶
First publication of the six framework bridges as standalone npm
packages, all at v2.0.0:
@dcp-ai/anthropic-mcp— Anthropic MCP bridge@dcp-ai/autogen— Microsoft AutoGen bridge@dcp-ai/google-a2a— Google Agent-to-Agent bridge@dcp-ai/w3c-did— W3C DID/VC bridge@dcp-ai/express— Express middleware@dcp-ai/openclaw— OpenClaw plugin
@dcp-ai/express and @dcp-ai/openclaw depend on @dcp-ai/sdk ^2.0.0.
2.0.0 - 2026-04-18¶
First public package release. Published simultaneously to npm (@dcp-ai/sdk, @dcp-ai/cli, @dcp-ai/wasm), PyPI (dcp-ai), and crates.io (dcp-ai).
Added¶
Protocol stack (DCP-01 through DCP-09)
- DCP-01 Identity & Human Binding — agent identity, operator attestation, key binding
- DCP-02 Intent Declaration & Policy Gating — declared intents, tier enforcement, policy evaluation
- DCP-03 Audit Chain & Transparency — hash-chained audit entries, Merkle proofs, transparency logs
- DCP-04 Agent-to-Agent Communication — discovery, handshake, encrypted sessions
- DCP-05 Agent Lifecycle — commissioning, vitality reports, decommissioning records, state machine with four termination modes
- DCP-06 Digital Succession & Inheritance — digital testaments, succession ceremonies (planned/forced/emergency), selective memory transfer manifests
- DCP-07 Conflict Resolution & Arbitration — typed dispute records, three-level escalation, M-of-N arbitration panels, jurisprudence bundles, objection records
- DCP-08 Rights & Obligations Framework — four agent rights (memory integrity, dignified transition, identity consistency, immutable record), obligation tracking, violation reports linked to DCP-07
- DCP-09 Personal Representation & Delegation — delegation mandates, awareness thresholds, advisory declarations, principal mirrors, dual-layer interaction records; extends DCP-04 handshake with mandate verification
Cryptography (4-tier: Routine / Standard / Elevated / Maximum)
- Post-quantum composite signatures — Ed25519 + ML-DSA-65 with
pq_over_classicalbinding - SLH-DSA-192f (FIPS 205) as hash-based backup signature
- Dual-hash audit chains — SHA-256 + SHA3-256 for long-term integrity
- Session binding —
session_nonceon every artifact to prevent splicing - Bundle manifest — per-artifact hashes, secondary Merkle root, PQ checkpoint tracking
- Algorithm governance — signed advisories with auto-response policies
- Key recovery — M-of-N social recovery via Shamir Secret Sharing
- Emergency revocation — pre-registered panic-button revocation tokens
- Blinded RPR mode — privacy-preserving responsible principal records
- Domain separation — context tags on all signatures
- Deterministic kid derivation —
hex(SHA-256(alg || 0x00 || pk))[0:32] - Wire format options — JSON (default) + CBOR (optional, 30–40% smaller)
SDKs, integrations, and tooling
- 5 SDKs — TypeScript, Python, Go, Rust, WASM
- 10 integrations — Express, FastAPI, LangChain, OpenAI, CrewAI, OpenClaw, W3C DID, Google A2A, Anthropic MCP, AutoGen (DCP-01..09 coverage)
- V2 JSON Schemas — full schema set under
schemas/v2/ - NIST KAT test vectors — Known Answer Tests for FIPS 203/204/205 conformance
- Interoperability tests — cross-SDK bundle verification
- Docker Compose stack — verification, anchor, transparency-log, revocation services
- CI/CD pipelines — conformance tests, multi-SDK builds, publish workflows
- Playground — browser-based bundle creation and verification with modular DCP-01..09 tabs, mobile-responsive
- Project templates — Express, LangChain, OpenAI, CrewAI starter projects
- CLI — interactive
@dcp-ai/cliwithdcp-initanddcp-aicommands - Server hardening — production-grade auth and rate-limiting for DCP-05..09 endpoints
Documentation & citation
- Companion paper on Zenodo: doi.org/10.5281/zenodo.19040913
CITATION.cff— machine-readable citation metadata
Changed¶
human_binding_recordrenamed toresponsible_principal_record(RPR)- Signature format changed from
{ alg, public_key_b64, sig_b64 }to{ composite_sig: { classical, pq, binding } } - Bundle envelope changed from flat
bundle_hashto structuredmanifest - Numeric fields are now integer-only (floats prohibited in signed payloads)
- Verification is now verifier-authoritative (policy-driven)
Fixed¶
sdk/pyPQ providers: ML-DSA-65 module import andpqc_verifysignature (pk,sig,msgseparated)sdk/pyPQ providers: SLH-DSA-192f module import andpqc_verifysignaturesdk/pyPQ providers: capture return value ofpqc_verify(was always returning True becausepqcrypto.verifyreturns bool instead of raising)sdk/pycrypto: base64-encode Ed25519 secret key ingenerate_keypair- CI: conformance, crypto, and multi-SDK test failures
Backward Compatibility¶
- V2 verifiers accept V1 bundles when
allow_v1_bundles: true(default) - V1 verifiers reject V2 bundles with a clear error message
Pre-release milestones¶
The following dates mark the evolution of the specification prior to the first package release. No packages were published at these points.
- 2026-01-15 — Genesis spec frozen (DCP-01, DCP-02, DCP-03)
- 2026-02-28 — V2.0 normative specification finalized (post-quantum hybrid crypto, 4-tier security model, DCP-04 A2A)
- 2026-03-16 — Paper preprint on Zenodo
- 2026-04-15 — DCP-05..09 constitutional framework merged to
main - 2026-04-18 — v2.0.0 released to npm, PyPI, and crates.io