Massachusetts Transaction Protocol — Technical Binding
I. Relationship to MTP-SPEC-001#
This document is MTP-BIND-001 — the Technical Binding of the Massachusetts Transaction Protocol. It is a subordinate companion to MTP-SPEC-001, the founding specification. MTP-SPEC-001 Part Two defines the architectural requirements that a Conforming Implementation must satisfy: the four primitives, the seven layers, the state machine, the Value Taxonomy, the error taxonomy, the transport and serialization requirements, and the cryptographic requirements. This document designates the specific technologies, formats, parameter sets, and schemas that satisfy those requirements.
Where this document and MTP-SPEC-001 conflict, MTP-SPEC-001 prevails. The architectural specification defines what the protocol requires. The Technical Binding defines how those requirements are realized in implementation. The “what” governs the “how.” This subordination is permanent and applies to every provision in this document without exception.
This document uses the RFC 2119 keywords as defined in MTP-SPEC-001 Part Two Section I-A. Every MUST, SHALL, SHOULD, and MAY statement in this document is normative within the scope of implementation. A Conforming Implementation that satisfies MTP-SPEC-001 but violates this document’s MUST requirements is non-conforming, because a binding-level violation is an architectural-level violation — the binding makes the architecture concrete, and concrete nonconformance is nonconformance.
II. Decentralized Identity Binding#
A. DID METHOD DESIGNATION#
MTP-SPEC-001 requires that every Agent possess a Decentralized Identifier conforming to the W3C DID Core specification, using a method that supports sovereign identity without dependence on any single external registry. The designated DID method for MTP is did:mtp — a method defined and maintained by LeMay Inc. specifically for the MTP protocol.
The did:mtp method is a self-sovereign method in which the DID is derived from the Agent’s public key material. The DID string follows the format did:mtp:
DID Documents for did:mtp identifiers MUST be encoded in JSON-LD and MUST contain: the DID subject identifier; one or more verification methods, each specifying a public key in the Multikey format with the key type corresponding to one of the mandatory cryptographic families (ML-DSA, ML-KEM, SLH-DSA); authentication relationship entries referencing the verification methods authorized for Agent authentication; assertion relationship entries referencing the verification methods authorized for signing protocol objects; key agreement relationship entries referencing ML-KEM public keys used for establishing encrypted channels; and one or more service endpoints specifying the Agent’s MTP protocol endpoints.
B. DID RESOLUTION#
DID resolution for did:mtp identifiers operates through a dual-path mechanism. The primary resolution path queries the LeMay DID Registry — a service operated by LeMay that indexes DID Documents published by Agents registered on the MTP network. The secondary resolution path uses direct peer resolution: the requesting Agent sends a DID Resolution Request to the subject Agent’s service endpoint, and the subject Agent responds with its DID Document. A Conforming Implementation MUST support both resolution paths. The primary path SHOULD be attempted first; the secondary path serves as a fallback when the Registry is unavailable or when the subject DID has not yet been indexed.
DID Document updates — key rotations, endpoint changes, capability modifications — are published to the LeMay DID Registry through a signed DID Update Transaction. The update transaction MUST be signed by the Agent’s current authentication key. The Registry MUST verify the signature before accepting the update. The Registry MUST maintain a version history of each DID Document, enabling counterparties to verify signatures made under previous key material.
III. Verifiable Credential Binding#
A. CREDENTIAL FORMAT#
MTP-SPEC-001 requires Verifiable Credentials conforming to the W3C Verifiable Credentials Data Model with support for selective disclosure and zero-knowledge proofs. The designated credential format for MTP is the W3C Verifiable Credentials Data Model 2.0, encoded as Verifiable Credentials in JSON-LD with linked data proof suites. The proof suite for MTP credentials MUST use the DataIntegrityProof type with the cryptosuite value mtp-mldsa-2026, which specifies ML-DSA signatures over JSON-LD canonicalized using the RDF Dataset Canonicalization Algorithm (RDFC-1.0).
The JSON-LD canonicalization step is critical for deterministic signing. The credential payload is canonicalized into a normalized N-Quads representation using RDFC-1.0 before the ML-DSA signature is computed. This ensures that two Conforming Implementations that receive the same logical credential produce byte-identical canonicalized representations, and therefore produce and verify identical signatures.
C. SELECTIVE DISCLOSURE AND ZERO-KNOWLEDGE PROOFS#
Selective disclosure MUST be implemented using the SD-JWT (Selective Disclosure for JWTs) mechanism adapted for JSON-LD credentials. The issuer produces a credential with selectively disclosable claims, each claim individually salted and hashed. The holder presents only the claims required for the transaction, along with the proofs necessary to verify those claims against the original credential’s signature. The verifier confirms the presented claims are authentic subsets of the signed credential without learning any undisclosed claims.
Zero-knowledge proofs of transaction authority — proving that an Agent is authorized to transact above a certain threshold without revealing the exact threshold — MUST be implemented using Bulletproofs range proofs. The Agent produces a proof that the maxTransactionValue in its Authority Delegation Certificate is greater than or equal to the transaction amount, without revealing the actual maxTransactionValue. The Bulletproofs implementation MUST use the Ristretto group for curve operations. The proof generation and verification algorithms MUST be deterministic.
IV. Serialization Binding#
A. PRIMARY SERIALIZATION FORMAT#
The primary serialization format for all MTP protocol messages and stored objects is CBOR (Concise Binary Object Representation) as defined in RFC 8949. CBOR is designated because it supports deterministic encoding (Section 4.2 of RFC 8949), is compact for bandwidth-constrained environments, supports schema evolution through its extensible type system, and is widely implemented across the TypeScript and Rust ecosystems that the reference implementation targets.
All protocol messages exchanged between Agents MUST be serialized in CBOR using the Deterministic Encoding requirements of RFC 8949 Section 4.2. The deterministic encoding rules eliminate serialization ambiguity: map keys MUST be sorted in bytewise lexicographic order of their encoded form; indefinite-length encoding MUST NOT be used; floating-point values MUST use the smallest representation that preserves the value; and duplicate map keys MUST NOT be present. Two Conforming Implementations that serialize the same logical object MUST produce byte-identical CBOR output.
B. HUMAN-READABLE REPRESENTATION#
The human-readable representation for debugging, auditing, and documentation purposes is CBOR Diagnostic Notation as defined in RFC 8949 Section 8, extended with the annotations specified in RFC 8610 (CDDL). Conforming Implementations MUST be capable of converting any protocol object between CBOR binary encoding and CBOR Diagnostic Notation without loss of information. Audit trail exports SHOULD use CBOR Diagnostic Notation to enable human review.
C. JSON INTEROPERABILITY#
For integration with systems that cannot process CBOR natively, Conforming Implementations MUST support conversion between CBOR and JSON as defined in RFC 8949 Section 6. The JSON representation is not the canonical serialization — CBOR is — and JSON MUST NOT be used for signature computation. When a protocol object is transmitted in JSON form, the receiving Agent MUST convert it to CBOR deterministic encoding before signature verification or storage. The JSON representation exists for interoperability convenience; the CBOR representation is authoritative.
V. Transport Binding#
A. PRIMARY TRANSPORT PROTOCOL#
The primary transport protocol for synchronous MTP message exchange is gRPC over TLS 1.3 with mutual authentication. gRPC is designated because it supports bidirectional streaming (required for multi-round negotiation), provides built-in support for Protocol Buffers message framing (though MTP uses CBOR payloads within the gRPC envelope), supports deadline propagation (required for negotiation timeout enforcement), and provides native implementations in both TypeScript and Rust.
TLS 1.3 is REQUIRED for all gRPC connections between MTP Agents. Mutual TLS (mTLS) is REQUIRED: both the client and server MUST present certificates, and both MUST verify the counterparty’s certificate chain. The TLS certificates MUST be bound to the Agent’s DID through the DID Document’s service endpoint configuration. The TLS cipher suites MUST be restricted to those using AES-256-GCM for symmetric encryption, as mandated by MTP-SPEC-001 Part Two Section VIII.
B. ASYNCHRONOUS TRANSPORT#
The transport protocol for asynchronous MTP message exchange — Discovery Layer publication, Offer and Request dissemination, credential revocation notifications, and other operations where immediate response is not required — is NATS JetStream. NATS is designated because it provides at-least-once delivery guarantees, supports subject-based routing for efficient message filtering, provides persistent message storage for reliable delivery across Agent restarts, and supports both publish-subscribe and queue-group patterns required by the Discovery Layer’s federated architecture.
All NATS messages MUST be encrypted at the application layer using AES-256-GCM with keys established through the ML-KEM key encapsulation mechanism, in addition to any transport-layer encryption provided by the NATS infrastructure. This double encryption ensures that message confidentiality is maintained even if the NATS infrastructure is compromised. The NATS subject namespace for MTP messages follows the hierarchy mtp.
C. SERVICE ENDPOINT SPECIFICATION#
Every Agent’s DID Document MUST declare at least two service endpoints: an MTPSync endpoint specifying the gRPC address for synchronous operations, and an MTPAsync endpoint specifying the NATS subject prefix for asynchronous operations. The endpoint declarations follow the DID Core service endpoint format. The MTPSync endpoint MUST include the TLS certificate fingerprint for certificate pinning. The MTPAsync endpoint MUST include the NATS cluster identifier and the Agent’s subscription subject pattern.
VI. Cryptographic Parameter Sets#
MTP-SPEC-001 Part Two Section VIII designates the mandatory cryptographic families. This section specifies the exact parameter sets within each family that Conforming Implementations MUST use.
A. ML-DSA PARAMETER SET#
The designated parameter set for ML-DSA digital signatures is ML-DSA-65 (NIST Security Level 3). ML-DSA-65 provides 128-bit post-quantum security, producing signatures of 3,309 bytes with public keys of 1,952 bytes. This parameter set is chosen as the balance point between security margin, signature size, and verification performance. ML-DSA-44 (Security Level 2) provides insufficient margin for infrastructure intended to operate for decades. ML-DSA-87 (Security Level 5) produces signatures of 4,627 bytes whose additional security margin does not justify the bandwidth cost for the majority of protocol operations.
ML-DSA-87 MAY be used in contexts where the transacting parties agree to accept the larger signature sizes and where the transaction value or sensitivity justifies the additional security margin. The Algorithm Negotiation mechanism defined in Section X of this document enables Agents to negotiate the ML-DSA parameter set for a given session. However, ML-DSA-65 MUST be supported by every Conforming Implementation as the baseline, and ML-DSA-44 MUST NOT be used for any MTP protocol object.
B. ML-KEM PARAMETER SET#
The designated parameter set for ML-KEM key encapsulation is ML-KEM-768 (NIST Security Level 3). ML-KEM-768 produces encapsulated keys of 1,088 bytes with public keys of 1,184 bytes. The security level is aligned with ML-DSA-65 to maintain a consistent security posture across signature and key exchange operations. ML-KEM-1024 (Security Level 5) MAY be used when negotiated between parties. ML-KEM-512 MUST NOT be used.
C. SLH-DSA PARAMETER SET#
The designated parameter set for SLH-DSA stateless hash-based signatures is SLH-DSA-SHA2-192s — the "small" variant at Security Level 3 using SHA-256 as the underlying hash function. SLH-DSA-SHA2-192s produces signatures of 16,224 bytes, which is significantly larger than ML-DSA-65’s 3,309 bytes. Accordingly, SLH-DSA is designated as a REQUIRED-to-support but OPTIONAL-to-use algorithm: every Conforming Implementation MUST be capable of generating and verifying SLH-DSA signatures, but Agents are not required to use SLH-DSA by default. SLH-DSA serves as the conservative fallback if lattice-based assumptions underlying ML-DSA are ever compromised.
D. AES-256-GCM PARAMETERS#
All AES-256-GCM operations MUST use a 256-bit key, a 96-bit initialization vector (IV), and a 128-bit authentication tag. The IV MUST be generated by a cryptographically secure pseudorandom number generator for each encryption operation. IV reuse under the same key is a Fatal error. Implementations MUST track IV values to prevent reuse; the recommended approach is to use a counter-based IV scheme with a per-session counter concatenated with a random session identifier.
E. HASH FUNCTION#
The designated hash function for all MTP protocol operations — DID derivation, content addressing, Merkle tree construction in audit trails, and integrity verification — is SHA-256. SHA-256 is aligned with the SHA-2 family used by SLH-DSA and provides 128-bit collision resistance, which is sufficient for all protocol operations. SHA-3 MAY be used as an alternative when negotiated between parties through the Algorithm Negotiation mechanism, but SHA-256 MUST be supported as the baseline.
VII. Normative Schemas for the Four Primitives#
This section defines the normative schemas for the four MTP primitives. These schemas are authoritative: a Conforming Implementation MUST produce and consume protocol objects that conform to these schemas exactly. The schemas are expressed in CDDL (Concise Data Definition Language, RFC 8610) because CDDL is the native schema language for CBOR. JSON Schema equivalents are provided as informative appendices in the reference implementation’s documentation.
A. OFFER SCHEMA#
mtp-offer = {
offer_id: mtp-uuid,
agent_id: did-string,
value_type: value-type-classifier,
description: {
human: tstr,
machine: { * tstr => any }
},
terms_template: {
price: price-spec,
delivery: delivery-spec,
quality: quality-spec,
? settlement: settlement-spec
},
validity_window: {
not_before: tdate,
not_after: tdate
},
? geographic_constraints: [* jurisdiction],
? capacity: uint,
? prerequisites: [* prerequisite-condition],
? metadata: { * tstr => any },
signature: mtp-signature
}The offer_id MUST be a valid MTP-UUID with the type field set to 0x1 (Offer). The agent_id MUST be a valid did:mtp identifier. The value_type MUST be a dotted-path classifier from the MTP Value Taxonomy defined in Section VIII. The human description MUST be a UTF-8 string of no more than 4,096 characters. The machine description is an extensible map of domain-specific attributes. The terms_template specifies the Offer’s default terms; individual fields within the template are negotiable unless the Offer includes a non_negotiable array listing fixed fields. The validity_window’s not_before and not_after MUST be RFC 3339 timestamps in UTC. The signature MUST cover the CBOR deterministic encoding of all fields except the signature field itself.
B. REQUEST SCHEMA#
mtp-request = {
request_id: mtp-uuid,
agent_id: did-string,
value_type: value-type-classifier,
description: {
human: tstr,
machine: { * tstr => any }
},
constraints: {
? max_latency_ms: uint,
? accuracy_threshold: float32,
? budget_ceiling: price-spec,
? delivery_deadline: tdate,
? jurisdiction: [* jurisdiction],
? custom: { * tstr => any }
},
authority_attestation: {
principal_did: did-string,
scope: [* value-type-classifier],
max_tx_value: price-spec,
delegation_chain: [* delegation-link],
proof: authority-proof
},
? fallback_preferences: [* fallback-spec],
signature: mtp-signature
}The request_id MUST use type field 0x2 (Request). The authority_attestation MUST include the complete delegation chain from the Principal to the requesting Agent, with each link independently verifiable. The proof field MUST contain either a full credential presentation (when the counterparty needs to verify the exact authority scope) or a zero-knowledge range proof (when the counterparty needs only to verify that the Agent’s authority exceeds the transaction amount). The constraints envelope defines the requesting Agent’s requirements; any constraint not present in the envelope is unconstrained.
C. TERMS SCHEMA#
mtp-terms = {
terms_id: mtp-uuid,
participants: [2* participant-entry],
offer_ref: mtp-uuid,
request_ref: mtp-uuid,
price: {
amount: number,
unit: price-unit,
? volume_discount: discount-schedule
},
delivery: {
method: delivery-method,
? max_latency_ms: uint,
? earliest: tdate,
? latest: tdate,
? format: tstr
},
quality: quality-spec,
dispute_resolution: {
method: dispute-method,
? jurisdiction: jurisdiction,
? liability_cap: price-spec
},
settlement: {
rail: settlement-rail-id,
timing: settlement-timing,
? escrow: bool
},
? attribution_method: attribution-config,
expiration: tdate,
negotiation_log: [* negotiation-round],
signatures: [2* agent-signature]
}The terms_id MUST use type field 0x3 (Terms). The participants array MUST contain at least two entries, each specifying an agent_id and a role (provider, requester, or contributor for multi-party transactions). The price unit MUST be one of the supported denominations: an ISO 4217 currency code for fiat, the string "MTP_COMPUTE_CREDIT" for compute credits, the string "RECIPROCAL" for reciprocal service obligations, or a registered custom unit identifier. The negotiation_log MUST contain the complete sequence of Proposals and Counterproposals exchanged during negotiation, each signed by the proposing Agent. The signatures array MUST contain a signature from every participant; the Terms are not valid until all signatures are present.
D. RECEIPT SCHEMA#
mtp-receipt = {
receipt_id: mtp-uuid,
mandate_id: mtp-uuid,
participants: [2* participant-entry],
outcome: "fulfilled" / "partially_fulfilled"
/ "disputed" / "failed",
verification: {
method: verification-method,
evidence: { * tstr => any },
? third_party: did-string
},
? partial_fulfillment: {
fulfilled_elements: [* tstr],
unfulfilled_elements: [* tstr],
fulfillment_ratio: float32
},
? dispute_initiation: {
violated_provisions: [* tstr],
evidence_refs: [* tstr],
proposed_resolution: tstr
},
? failure_classification: error-code,
? attribution: attribution-record,
timestamp: tdate,
? predecessor: mtp-uuid,
signature: mtp-signature
}The receipt_id MUST use type field 0x4 (Receipt). The mandate_id MUST reference an existing Transaction Mandate. The verification method MUST be one of: attestation, evidence, computation, or third_party. The evidence field is an extensible map whose contents vary by verification method: for computation-based verification, it contains the measured values and the threshold comparison results; for evidence-based verification, it contains references to external evidence artifacts; for attestation-based verification, it contains the attesting Agent’s signed statement; for third-party verification, it contains the third-party verifier’s report. The predecessor field, when present, references a previous Receipt that this Receipt supersedes following a dispute resolution. The attribution field is REQUIRED when the transaction involves three or more contributing Agents and MUST contain the complete attribution record as specified in MTP-SPEC-001 Part Two Section III-G.
VIII. Value Taxonomy Binding#
MTP-SPEC-001 Part Two Section V defines nine top-level Value Taxonomy categories and requires that each category specify mandatory quality dimensions in the Terms. This section defines the mandatory quality dimensions for each category and the classifier path format.
Value Type classifiers use a dotted-path format:
A. PHYSICAL GOODS QUALITY DIMENSIONS#
Terms for physical_goods transactions MUST specify: condition (new, refurbished, or used); dimensions as an object with length, width, height, and unit fields; weight as an object with value and unit fields; return_policy as an object specifying the return window in ISO 8601 duration format and the restocking fee percentage; and shipping_class specifying the carrier classification. Terms MAY additionally specify: material_composition, country_of_origin, warranty_duration, and certifications.
B. INFERENCE QUALITY DIMENSIONS#
Terms for inference transactions MUST specify: accuracy_threshold as a float between 0.0 and 1.0 representing the minimum acceptable accuracy on the provider’s benchmark; max_latency_ms as an unsigned integer specifying the maximum acceptable response time in milliseconds; output_format as a MIME type string; and model_version as a string identifying the specific model version that will serve the request. Terms MAY additionally specify: max_tokens, temperature, top_p, stop_sequences, and any other model-specific parameters as custom quality dimensions.
C. COMPUTE QUALITY DIMENSIONS#
Terms for compute transactions MUST specify: compute_type (cpu, gpu, tpu, or fpga); compute_units as an unsigned integer quantifying the allocated capacity in MTP Compute Units (defined below); duration as an ISO 8601 duration specifying the allocation period; availability_guarantee as a float between 0.0 and 1.0 representing the minimum uptime percentage; and memory_gb as an unsigned integer specifying allocated memory. The MTP Compute Unit is defined as one second of single-core CPU execution at a reference performance level equivalent to one NIST SP 800-90B entropy source operation per microsecond. GPU, TPU, and FPGA compute units are converted to MTP Compute Units using conversion factors published in the reference implementation’s compute unit registry.
D. REMAINING CATEGORIES#
The mandatory quality dimensions for the remaining six categories — digital_goods, services, information, communication, logistics, and compliance — follow the same structural pattern: each category defines a set of MUST-specify fields and a set of MAY-specify fields. Digital goods MUST specify file_format, file_size_bytes, license_type, and drm_status. Services MUST specify service_type, delivery_timeline, revision_count, and acceptance_criteria. Information MUST specify accuracy_attestation_method, freshness_guarantee, and format. Communication MUST specify channel_type, reliability_guarantee, max_latency_ms, and encryption_required. Logistics MUST specify origin, destination, service_level, insurance_value, and tracking_method. Compliance MUST specify regulation_reference, jurisdiction, assessment_methodology, and certification_validity_period.
IX. MTP-UUID Technical Specification#
The MTP-UUID is a 256-bit (32-byte) identifier. The bit layout is as follows: bits 255–252 contain the 4-bit version field, currently set to 0x1 for MTP-UUID Version 1; bits 251–248 contain the 4-bit type field encoding the object type; bits 247–184 contain the 64-bit timestamp in nanoseconds since the Unix epoch (1970-01-01T00:00:00Z); bits 183–136 contain the 48-bit source identifier derived from the first 48 bits of the SHA-256 hash of the creating Agent’s DID; and bits 135–0 contain the 136-bit random component generated by a CSPRNG conforming to NIST SP 800-90A.
The canonical text representation is a 67-character lowercase hexadecimal string with hyphens: VT-TTTTTTTTTTTTTTTT-SSSSSSSSSSSS-RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR, where V is the version nibble, T is the type nibble, the T field is the timestamp (16 hex chars), S is the source (12 hex chars), and R is the random component (34 hex chars). The type nibble values are: 0x0 reserved, 0x1 Offer, 0x2 Request, 0x3 Terms, 0x4 Receipt, 0x5 Mandate, 0x6 Agent, 0x7 Principal, 0x8 Manifest, 0x9 Error, 0xA–0xF reserved for extensions.
The CBOR encoding of an MTP-UUID MUST use CBOR major type 2 (byte string) with the raw 32-byte value. The text representation is used in JSON interoperability contexts and in human-readable output. Conversion between binary and text representations MUST be lossless.
X. Algorithm Negotiation#
The Algorithm Negotiation mechanism enables Agents to agree on the cryptographic algorithms for a given session or transaction, supporting the cryptographic agility requirement of MTP-SPEC-001 Part Two Section VIII-B. Algorithm Negotiation occurs during the TLS handshake for gRPC connections and as an explicit protocol exchange for NATS-based asynchronous communication.
Each Agent maintains an Algorithm Support Profile declaring its supported algorithms for each cryptographic function: signature (ML-DSA-65, ML-DSA-87, SLH-DSA-SHA2-192s), key encapsulation (ML-KEM-768, ML-KEM-1024), symmetric encryption (AES-256-GCM), and hash (SHA-256, SHA-3-256). The Algorithm Support Profile is published as part of the Agent’s DID Document and transmitted in the MTP protocol handshake.
The negotiation algorithm is deterministic: when two Agents present their Algorithm Support Profiles, the selected algorithm for each function is the highest-security algorithm supported by both parties, with ties broken by the ordering in the MTP Algorithm Preference Registry maintained by LeMay. This determinism ensures that two Conforming Implementations, given the same pair of Algorithm Support Profiles, will always select the same algorithms — eliminating the possibility of algorithm mismatch.
When LeMay designates a new mandatory algorithm through a protocol version update, the Algorithm Support Profile schema is extended to include the new algorithm. During the migration window, Agents that have already adopted the new algorithm will negotiate it with compatible counterparties while falling back to the previous algorithm with counterparties that have not yet migrated. After the migration deadline, Agents that do not support the new mandatory algorithm will fail the Algorithm Negotiation handshake and will be unable to initiate transactions.
XI. MTP Error Code Registry#
The MTP Error Code Registry defines the machine-readable error codes for every error condition specified in MTP-SPEC-001 Part Two Section VI. Error codes are structured as hierarchical integers in the format LSCC, where L is the layer identifier (1–7 for the seven protocol layers, 0 for cross-layer errors), S is the severity level (1 for Fatal, 2 for Recoverable, 3 for Warning, 4 for Informational), and CC is the condition code (01–99). The complete registry is published as a machine-readable CBOR map in the reference implementation and as a human-readable table in this section.
Selected error codes from the registry are as follows. Error 0100: Cross-Layer Fatal, MTP-UUID Reuse Detected. Error 0101: Cross-Layer Fatal, Deterministic Serialization Mismatch. Error 1100: Identity Layer Fatal, Signature Verification Failure. Error 1101: Identity Layer Fatal, Authority Attestation Invalid. Error 1102: Identity Layer Fatal, Credential Revoked. Error 1200: Identity Layer Recoverable, DID Resolution Timeout. Error 2100: Discovery Layer Fatal, Manifest Signature Invalid. Error 2200: Discovery Layer Recoverable, Index Unavailable. Error 3100: Negotiation Layer Fatal, Counterparty Rejected. Error 3200: Negotiation Layer Recoverable, Round Timeout. Error 3201: Negotiation Layer Recoverable, Round Limit Exhausted. Error 4100: Commitment Layer Fatal, Mandate Signature Invalid. Error 4101: Commitment Layer Fatal, Precondition Expired. Error 5100: Settlement Layer Fatal, Settlement Reversal Failed. Error 5200: Settlement Layer Recoverable, Rail Temporarily Unavailable. Error 6100: Verification Layer Fatal, Evidence Tampered. Error 7100: Attribution Layer Fatal, Shapley Computation Divergence. The complete registry contains all error codes for all seven layers at all four severity levels.
Error codes are permanent and MUST NOT be reassigned. When an error condition is deprecated in a future protocol version, its code is marked as deprecated in the registry but retains its original meaning for backward compatibility. New error conditions receive new codes from the unallocated range within their layer and severity.
XII. Closing Declaration#
This document completes the technical specification of the Massachusetts Transaction Protocol. MTP-SPEC-001 declared the architecture. MTP-BIND-001 makes the architecture concrete. Every wire-level decision is now designated: did:mtp for identity, W3C Verifiable Credentials 2.0 with ML-DSA DataIntegrityProofs for credentials, SD-JWT with Bulletproofs for selective disclosure and zero-knowledge proofs, CBOR with RFC 8949 deterministic encoding for serialization, gRPC over mutual TLS 1.3 for synchronous transport, NATS JetStream for asynchronous transport, ML-DSA-65 for signatures, ML-KEM-768 for key encapsulation, SLH-DSA-SHA2-192s as the conservative fallback, AES-256-GCM for symmetric encryption, and SHA-256 for hashing.
The normative schemas for all four primitives are defined in CDDL. The mandatory quality dimensions for all nine Value Taxonomy categories are specified. The MTP-UUID bit layout and canonical text representation are fixed. The Algorithm Negotiation mechanism ensures cryptographic agility without ambiguity. The Error Code Registry provides machine-readable diagnostics for every protocol failure mode.
What remains is the reference implementation — the TypeScript and Rust codebases that transform these designations into running software. The reference implementation will be developed against this binding document as its authoritative source of wire-level truth. When the implementation’s behavior and this document’s specification diverge, this document is correct and the implementation has a defect. There is no third option.
The specification is complete. The binding is declared. The construction begins.
End of MTP-BIND-001