Massachusetts Transaction Protocol — Part Two
I. Normative Framework and Definitions#
This document is the normative architectural specification of the Massachusetts Transaction Protocol. Every statement in this document that uses the keywords defined below constitutes a requirement, a recommendation, or a permission that governs the behavior of conforming implementations. Informative text is clearly distinguished from normative text. Where ambiguity exists between informative and normative content, the normative interpretation prevails.
A. RFC 2119 KEYWORD DEFINITIONS#
MUST and MUST NOT indicate absolute requirements and absolute prohibitions respectively. A conforming implementation that violates a MUST or MUST NOT requirement is non-conforming regardless of all other behavior. These keywords define the boundaries of the protocol. An implementation that crosses them does not implement MTP.
SHALL and SHALL NOT carry identical normative force to MUST and MUST NOT. They are used in contexts where the requirement derives from the protocol’s institutional or legal framework rather than from its technical architecture. A conforming implementation SHALL comply with the Curtis License. A certified implementation SHALL NOT deploy to prohibited territories.
SHOULD and SHOULD NOT indicate recommendations. A conforming implementation that deviates from a SHOULD recommendation remains conforming but MUST document the deviation and its rationale. Deviations from SHOULD recommendations will be evaluated during certification and may affect certification outcome at LeMay’s discretion.
MAY indicates a permission. A conforming implementation MAY implement a feature or behavior described with MAY without obligation. The absence of MAY-permitted features does not affect conformance.
B. DEFINITIONS#
Agent. A software entity that acts on behalf of a Principal within the MTP protocol. An Agent possesses a verifiable identity, a delegated authority scope, and a constraint set. An Agent MAY represent a human, an organization, an autonomous system, or another Agent in a hierarchical delegation chain.
Principal. The human or organization on whose behalf an Agent acts. The Principal is the ultimate source of authority for the Agent’s actions. Every Agent MUST be bound to a Principal through the Identity Layer’s credential chain. An Agent whose Principal cannot be verified MUST NOT participate in MTP transactions.
Transaction. A complete lifecycle of value exchange between two or more Agents, traversing all seven protocol layers from Identity through Attribution. A Transaction begins when a Request matches an Offer and concludes when the Verification Layer produces a Receipt.
Transaction Mandate. The cryptographically signed agreement produced by the Commitment Layer, recording the exact Terms agreed upon by all parties. A Transaction Mandate is immutable once signed. It constitutes the binding contract between the transacting Agents and their respective Principals.
Capability Manifest. A structured declaration published by an Agent through the Discovery Layer, describing the Offers that Agent can fulfill. A Capability Manifest MUST conform to the schema defined in Section III-B of this specification.
Conforming Implementation. A software system that implements all seven protocol layers as specified in this document, satisfies all MUST and SHALL requirements, and has been certified by LeMay Inc. through the conformance testing regime defined in Part Three of MTP-SPEC-001.
Certified Implementation. A Conforming Implementation that has passed LeMay’s certification process and holds an active, non-revoked Production License. Only Certified Implementations MAY process live transactions on the MTP network and represent themselves as MTP-certified.
Value. Any transferable economic quantum that two Agents agree to exchange. Value is protocol-agnostic: it encompasses physical goods, digital goods, services, compute capacity, inference capability, information, communication, creative work, logistics capacity, compliance verification, and any other form of economic output. The protocol does not define what constitutes Value. It defines how Value is exchanged.
II. The Four Primitives — Normative Specification#
Every MTP transaction is expressed as an interaction between four primitives: Offers, Requests, Terms, and Receipts. A Conforming Implementation MUST implement all four primitives. Each primitive MUST conform to the schema and behavioral requirements defined in this section. An implementation that extends a primitive’s schema MUST do so through the Extension Specification process defined in Part Three; unauthorized schema extensions constitute a conformance violation.
A. OFFERS#
An Offer is a structured declaration of what an Agent can provide. Every Offer MUST contain the following mandatory fields: a globally unique Offer Identifier conforming to the MTP-UUID format defined in Section IX; the Agent Identifier of the offering Agent; a Value Type classifier drawn from the MTP Value Taxonomy; a human-readable and machine-parseable description of the offered Value; the terms under which the Offer is available, expressed as a Terms Template; a validity window specifying the temporal bounds within which the Offer may be accepted; and a cryptographic signature binding the Offer to the offering Agent’s verifiable credentials.
An Offer MAY contain optional fields including: geographic constraints specifying jurisdictions in which the Offer is available or prohibited; capacity constraints specifying maximum concurrent fulfillment volume; quality guarantees specifying measurable performance thresholds; prerequisite conditions specifying requirements that a requesting Agent must satisfy before the Offer can be matched; and metadata fields for domain-specific attributes not covered by the core schema.
An Offer MUST be cryptographically signed by the offering Agent at the time of publication. An unsigned Offer MUST NOT be indexed by the Discovery Layer and MUST NOT be matched against Requests. An Offer whose signature fails verification MUST be rejected by any receiving Agent. The signature algorithm MUST conform to the cryptographic requirements specified in Section VIII.
An Offer MUST be immutable once published. An Agent that wishes to modify the terms of a published Offer MUST revoke the original Offer and publish a new Offer with the modified terms. Revocation MUST be propagated through the Discovery Layer within the latency bounds specified in Section III. The revoked Offer’s identifier MUST be permanently reserved and MUST NOT be reused.
Informative Example. The following illustrates the structure of an Offer object. This example is informative, not normative; the authoritative schema definition is specified in the MTP Technical Binding.
{
"offer_id": "01-0018A3F29B7C4E01-7A3F2B9C1D4E-8F2A...",
"agent_id": "did:mtp:7a3f2b9c1d4e8f01a2b3c4d5e6f7...",
"value_type": "physical_goods.manufactured",
"description": {
"human": "Organic linen-blend pullover, sizes S-XL",
"machine": { "sku": "LMY-PLV-4471", "category": "apparel" }
},
"terms_template": {
"price": { "amount": 89.00, "currency": "USD" },
"delivery": { "earliest": "P2D", "latest": "P7D" },
"quality": { "condition": "new", "return_window": "P30D" }
},
"validity_window": {
"not_before": "2026-03-06T00:00:00Z",
"not_after": "2026-06-06T00:00:00Z"
},
"signature": { "algorithm": "ML-DSA-65", "value": "..." }
}
B. REQUESTS#
A Request is a structured declaration of what an Agent needs. Every Request MUST contain the following mandatory fields: a globally unique Request Identifier; the Agent Identifier of the requesting Agent; a Value Type classifier matching the MTP Value Taxonomy; a description of the required Value; the constraints under which the Request must be fulfilled, expressed as a Constraints Envelope; the authority scope of the requesting Agent, cryptographically attested by the Principal’s verifiable credential; and a cryptographic signature binding the Request to the requesting Agent’s identity.
A Request MAY contain optional fields including: a maximum budget ceiling denominated in the payment unit specified by the requesting Agent; preferred fulfillment timeline; preferred counterparty attributes; and fallback preferences specifying alternative Value Types or reduced quality thresholds that the requesting Agent would accept if the primary Request cannot be matched.
A Request MUST carry an Authority Attestation — a cryptographic proof that the requesting Agent’s Principal has authorized the Agent to transact within the scope and limits specified in the Request. The Authority Attestation MUST be verifiable by any counterparty Agent without requiring access to the Principal’s private credentials. The attestation mechanism is defined in Section III-A. A Request that lacks a valid Authority Attestation MUST NOT be processed by the Discovery Layer and MUST NOT be matched against Offers.
Informative Example. The following illustrates the structure of a Request object.
{
"request_id": "02-0018A3F29B8D5F02-9C1D4E8F2A3B-6D7E...",
"agent_id": "did:mtp:9c1d4e8f2a3b6d7e01f2a3b4c5d6...",
"value_type": "inference.text_generation",
"description": {
"human": "Product description generation, brand voice",
"machine": { "task": "text_gen", "max_tokens": 2048 }
},
"constraints": {
"max_latency_ms": 3000,
"accuracy_threshold": 0.92,
"budget_ceiling": { "amount": 0.12, "currency": "USD" }
},
"authority_attestation": {
"principal_did": "did:mtp:principal:lemay-inc-001...",
"scope": ["inference", "information"],
"max_transaction_value": { "amount": 500, "currency": "USD" },
"proof": { "type": "zero_knowledge", "value": "..." }
},
"signature": { "algorithm": "ML-DSA-65", "value": "..." }
}
C. TERMS#
Terms are the codification of a negotiated agreement between two or more Agents. Terms are produced by the Negotiation Layer and signed as a Transaction Mandate by the Commitment Layer. Every Terms object MUST contain: the identifiers of all participating Agents; references to the Offer and Request that initiated the negotiation; the agreed price, denominated in a unit recognized by both parties; the delivery specification, defining what constitutes fulfillment; the quality specification, defining measurable thresholds that the delivered Value must satisfy; the dispute resolution procedure, specifying the mechanism for resolving disagreements about fulfillment; the settlement method, specifying which payment rail will be used; and an expiration timestamp after which unexecuted Terms become void.
Terms MUST support the following price denominations: fiat currency identified by ISO 4217 code, compute credits denominated in a standardized unit defined in the MTP Compute Credit Specification, reciprocal service obligations specifying a counter-Offer that the receiving Agent commits to fulfill, data access grants specifying the scope and duration of data made available as payment, and custom units defined through the Extension Specification process. A Conforming Implementation MUST support fiat currency and compute credit denominations. Support for reciprocal service obligations, data access grants, and custom units is RECOMMENDED.
Terms MUST be deterministically serializable. Two implementations that receive the same negotiation output MUST produce byte-identical Terms serializations. This determinism is required because the Transaction Mandate’s cryptographic signature covers the serialized Terms, and any serialization variance would invalidate the signature on verification. The canonical serialization format is specified in the MTP Technical Binding document.
Informative Example. The following illustrates the structure of a Terms object as produced by the Negotiation Layer.
{
"terms_id": "03-0018A3F29BC7A103-7A3F2B9C1D4E-4F5A...",
"participants": [
{ "agent_id": "did:mtp:7a3f...", "role": "provider" },
{ "agent_id": "did:mtp:9c1d...", "role": "requester" }
],
"offer_ref": "01-0018A3F29B7C4E01-7A3F2B9C1D4E-8F2A...",
"request_ref": "02-0018A3F29B8D5F02-9C1D4E8F2A3B-6D7E...",
"price": { "amount": 0.08, "currency": "USD" },
"delivery": {
"method": "synchronous",
"max_latency_ms": 2500,
"format": "application/json"
},
"quality": {
"accuracy_threshold": 0.92,
"model_version": "claude-sonnet-4-20250514"
},
"dispute_resolution": "automated_arbitration",
"settlement_method": "compute_credits",
"expiration": "2026-03-06T23:59:59Z",
"signatures": [
{ "agent": "did:mtp:7a3f...", "algorithm": "ML-DSA-65", "value": "..." },
{ "agent": "did:mtp:9c1d...", "algorithm": "ML-DSA-65", "value": "..." }
]
}
D. RECEIPTS#
A Receipt is the verified record of transaction fulfillment produced by the Verification Layer. Every Receipt MUST contain: the Transaction Mandate identifier; the identifiers of all participating Agents; the verification outcome — either Fulfilled, Partially Fulfilled, Disputed, or Failed; the verification evidence, comprising the data or attestations that support the outcome determination; a timestamp recording the moment verification concluded; and a cryptographic signature binding the Receipt to the verifying Agent’s credentials.
A Receipt with outcome Fulfilled closes the transaction loop and triggers the Attribution Layer’s compensation distribution. A Receipt with outcome Partially Fulfilled MUST include a Partial Fulfillment Specification describing which elements of the Terms were satisfied and which were not; the Attribution Layer MUST adjust compensation proportionally based on this specification. A Receipt with outcome Disputed MUST include the Dispute Initiation Record and MUST trigger the dispute resolution procedure specified in the original Terms. A Receipt with outcome Failed MUST include the Failure Classification and MUST trigger the settlement reversal mechanism specified in Section VI.
Receipts are permanent and append-only. A Receipt MUST NOT be modified, revoked, or superseded after issuance. If a dispute resolution process produces a revised outcome, a new Receipt MUST be issued referencing the original Receipt’s identifier and specifying the revised outcome. The original Receipt remains in the transaction record. The complete chain of Receipts for a given Transaction constitutes the authoritative history of that Transaction’s fulfillment.
Informative Example. The following illustrates the structure of a Receipt object as produced by the Verification Layer.
{
"receipt_id": "04-0018A3F29BD8B204-7A3F2B9C1D4E-2C3D...",
"mandate_id": "05-0018A3F29BC9C205-COMBINED-HASH-REF...",
"participants": [
{ "agent_id": "did:mtp:7a3f...", "role": "provider" },
{ "agent_id": "did:mtp:9c1d...", "role": "requester" }
],
"outcome": "fulfilled",
"verification_method": "computation_based",
"evidence": {
"accuracy_measured": 0.947,
"latency_measured_ms": 1842,
"thresholds_met": true
},
"timestamp": "2026-03-06T14:22:07.391Z",
"attribution": {
"method": "direct_bilateral",
"distribution": [
{ "agent": "did:mtp:7a3f...", "share": 1.0 }
]
},
"signature": { "algorithm": "ML-DSA-65", "value": "..." }
}
III. The Seven Layers — Normative Specification#
Every MTP transaction traverses seven protocol layers in sequence. A Conforming Implementation MUST implement all seven layers. Each layer defines a set of operations, a set of state transitions, and a set of interface contracts that govern its interaction with adjacent layers. No layer MAY be bypassed, reordered, or collapsed into another layer. The separation of layers is a normative requirement, not an implementation suggestion.
A. THE IDENTITY LAYER#
The Identity Layer establishes the cryptographically verifiable identity of every Agent participating in an MTP transaction. The Identity Layer MUST implement the following capabilities: Agent identity creation and registration; Principal-to-Agent authority delegation; credential issuance, verification, and revocation; and constraint binding, whereby the Principal’s limitations on the Agent’s authority are encoded in a machine-enforceable format.
1. Agent Identity Model
Every Agent MUST possess a Decentralized Identifier conforming to the W3C DID Core specification. The DID method used MUST support sovereign identity without dependence on any single external registry. The specific DID method is designated in the MTP Technical Binding. An Agent’s DID MUST resolve to a DID Document containing the Agent’s public keys, authentication methods, service endpoints, and the delegation chain linking the Agent to its Principal.
An Agent MUST be capable of presenting Verifiable Credentials conforming to the W3C Verifiable Credentials Data Model. These credentials MUST attest to the Agent’s identity, its binding to a Principal, the scope of its delegated authority, and any constraints on its transactional behavior. Credentials MUST support selective disclosure — the Agent MUST be able to prove specific attributes of its authority without revealing the full credential. Credentials MUST support zero-knowledge proofs of transaction authority where the counterparty needs to verify that the Agent is authorized to transact above a certain threshold without learning the exact threshold.
2. Authority Delegation
The Principal delegates authority to the Agent through an Authority Delegation Certificate — a Verifiable Credential issued by the Principal that specifies the Agent’s operational boundaries. The Authority Delegation Certificate MUST contain: the Principal’s DID; the Agent’s DID; the scope of delegated authority expressed as a set of permitted Value Types, maximum transaction values, permitted counterparty classes, permitted jurisdictions, and permitted payment rails; temporal constraints specifying the delegation’s validity window; and revocation status information including a revocation registry endpoint that counterparties can query in real time.
Hierarchical delegation is permitted: an Agent MAY delegate a subset of its authority to a sub-Agent, producing a delegation chain of arbitrary depth. Every link in the delegation chain MUST be independently verifiable. The authority at each link MUST be a strict subset of or equal to the authority at the preceding link — no Agent MAY delegate authority it does not itself possess. A counterparty MUST verify the complete delegation chain before accepting a Transaction Mandate signed by a sub-Agent.
3. Credential Revocation
Credential revocation MUST take effect within the latency bound specified in the MTP Technical Binding. A revoked credential MUST NOT be accepted for any transaction initiated after the revocation timestamp. Transactions that were committed before the revocation timestamp but not yet settled MUST be evaluated under the dispute resolution procedure specified in the Terms. The Identity Layer MUST support both immediate revocation by the Principal and scheduled revocation through expiration timestamps encoded in the credential.
B. THE DISCOVERY LAYER#
The Discovery Layer enables Agents to find counterparties capable of fulfilling their Requests. The Discovery Layer MUST implement: Capability Manifest publication, indexing, and querying; Request-to-Offer matching based on Value Type, constraints, and counterparty attributes; and federated discovery across multiple indexes without dependence on a single centralized registry.
1. Capability Manifests
Every Agent that publishes Offers MUST publish a Capability Manifest describing its available Offers. The Capability Manifest MUST conform to a standardized schema that includes: the Agent’s DID; an enumeration of offered Value Types; capacity and availability information; geographic and jurisdictional constraints; quality guarantees and service-level commitments; supported payment rails; and a manifest version identifier enabling schema evolution.
Capability Manifests MUST be signed by the publishing Agent. A manifest whose signature fails verification MUST NOT be indexed or returned in query results. Manifests MUST include a freshness timestamp; discovery indexes SHOULD deprioritize manifests whose freshness timestamp exceeds a configurable staleness threshold.
2. Federated Discovery Architecture
The Discovery Layer MUST operate on a federated architecture in which no single entity controls the discovery index. Agents MUST be able to publish their Capability Manifests to multiple independent indexes simultaneously. Querying Agents MUST be able to query multiple indexes and merge results. The protocol MUST define a standard query interface that all indexes implement, ensuring that an Agent’s choice of index does not constrain the counterparties it can discover.
Federated discovery does not imply decentralized governance. LeMay maintains the authoritative index as the reference implementation of the Discovery Layer, and certified implementations MUST register their Capability Manifests with the LeMay index in addition to any other indexes they choose to publish to. The LeMay index serves as the canonical source for conformance verification and certification auditing.
3. Offer Revocation Propagation
When an Agent revokes an Offer, the revocation MUST propagate to all indexes that received the original Offer within the latency bound specified in the Technical Binding. An index that receives a revocation notice MUST remove the revoked Offer from its queryable catalog within one propagation cycle. A Request that matches a revoked Offer MUST NOT proceed to the Negotiation Layer. If a revocation occurs after a Request has matched but before the Negotiation Layer produces Terms, the Negotiation MUST be terminated and both Agents MUST be notified of the revocation.
C. THE NEGOTIATION LAYER#
The Negotiation Layer governs the process by which two or more Agents arrive at mutually acceptable Terms for a value exchange. This is the layer that distinguishes MTP from every existing protocol in the agent transaction space, because no existing protocol defines a structured, protocol-level negotiation mechanism. The Negotiation Layer MUST implement: single-round negotiation for commodity transactions where the Offer’s Terms Template is accepted without modification; multi-round iterative negotiation for complex transactions where terms are refined through proposal and counterproposal; conditional negotiation where agreement on one term is contingent on agreement on another; and multi-party negotiation where more than two Agents must reach consensus.
1. Negotiation Protocol
A negotiation session is initiated when the Discovery Layer produces a match between a Request and one or more Offers. The requesting Agent sends a Negotiation Initiation Message containing its Request, the matched Offer identifier, and an initial Proposal. The Proposal specifies the requesting Agent’s preferred terms across all negotiable dimensions. The offering Agent responds with one of: an Acceptance, indicating that the Proposal is accepted without modification; a Counterproposal, specifying modified terms on one or more dimensions; or a Rejection, indicating that the offering Agent declines to negotiate further.
Each round of negotiation MUST complete within the round timeout specified in the Negotiation Initiation Message. If either Agent fails to respond within the timeout, the negotiation MUST be terminated with status Timeout. The maximum number of negotiation rounds MUST be specified in the Negotiation Initiation Message; if the Agents have not reached agreement within the maximum rounds, the negotiation MUST be terminated with status Exhausted.
Every Proposal and Counterproposal MUST be signed by the proposing Agent. The signature serves two purposes: it authenticates the proposal’s origin, and it creates a non-repudiable record of the negotiation history that can be referenced in dispute resolution.
2. Negotiable Dimensions
The following dimensions are normatively negotiable in every MTP transaction: price, including base price, volume discounts, and dynamic pricing adjustments; quantity, including minimum and maximum fulfillment volumes; delivery timeline, including earliest delivery, latest delivery, and expedited delivery surcharges; quality thresholds, including accuracy guarantees for inference transactions, condition guarantees for physical goods, and performance guarantees for service transactions; payment terms, including payment rail, payment timing, and escrow requirements; dispute resolution procedure, including arbitration method, jurisdiction, and liability caps; and attribution methodology, including the Shapley value calculation parameters for multi-party transactions.
Additional dimensions MAY be added through the Extension Specification process. A Conforming Implementation MUST support negotiation on all normative dimensions. An implementation MAY support additional dimensions defined by approved extensions.
3. Game-Theoretic Optimization
The Negotiation Layer SHOULD support game-theoretic optimization as a native capability. Agents SHOULD be capable of identifying Pareto optimal outcomes — negotiation results where no dimension can be improved for one party without worsening it for the other — and SHOULD converge toward Nash equilibria in multi-round negotiations. The specific algorithms for game-theoretic optimization are not normatively specified; they are implementation decisions. However, a Certified Implementation that claims game-theoretic optimization capability MUST demonstrate convergence properties during the certification process.
D. THE COMMITMENT LAYER#
The Commitment Layer transforms negotiated Terms into a binding, cryptographically verifiable Transaction Mandate. The Commitment Layer MUST implement: Transaction Mandate generation from agreed Terms; multi-party signature collection; conditional mandate support; and mandate immutability enforcement.
1. Transaction Mandate Structure
A Transaction Mandate MUST contain: a globally unique Mandate Identifier; references to all originating Offers and Requests; the complete, serialized Terms as agreed in the Negotiation Layer; the signatures of all participating Agents; the delegation chain attestations proving each Agent’s authority to commit on behalf of its Principal; a commitment timestamp; and an expiration timestamp after which the Mandate becomes void if settlement has not been initiated.
The Transaction Mandate MUST be deterministically serialized before signing. The serialization MUST be canonical — there MUST be exactly one valid serialization for any given set of Terms. This canonicalization is required because the signature covers the serialized bytes, and any variance in serialization would produce a different signature. The canonical serialization format is defined in the MTP Technical Binding.
2. Conditional Mandates
The Commitment Layer MUST support conditional mandates — Transaction Mandates that become effective only when specified preconditions are satisfied. Preconditions MUST be expressed as machine-evaluable predicates. The Commitment Layer MUST monitor precondition status and MUST transition the Mandate from Pending to Active when all preconditions are satisfied. If any precondition expires before satisfaction, the Mandate MUST transition to Void and all parties MUST be notified.
Conditional mandates enable complex transaction structures: escrow arrangements where payment releases upon delivery confirmation; cascading transactions where one purchase is contingent on the successful completion of another; and multi-step procurement operations where each stage commits only after the previous stage is verified.
3. Mandate Immutability
A signed Transaction Mandate MUST NOT be modified after the final signature is applied. No field, no term, no condition may be altered. If the parties wish to modify the agreement, they MUST execute a new negotiation that produces a new Mandate referencing the original Mandate’s identifier as its predecessor. The original Mandate’s status transitions to Superseded. The complete chain of Mandates — original and successor — constitutes the authoritative record of the agreement’s evolution.
E. THE SETTLEMENT LAYER#
The Settlement Layer executes the movement of value between parties as specified in the Transaction Mandate. The Settlement Layer is payment-rail-agnostic by normative requirement: a Conforming Implementation MUST NOT hardcode assumptions about which payment rail will carry the settlement. The Settlement Layer MUST implement: settlement initiation based on Mandate activation; payment rail abstraction through a standardized Settlement Interface; settlement confirmation and receipt generation; and settlement reversal for failed or disputed transactions.
1. Settlement Interface
The Settlement Layer defines a Settlement Interface through which any payment rail can participate in MTP transactions. The Settlement Interface specifies the operations that a payment rail adapter MUST implement: Initiate Settlement, receiving the Mandate’s settlement parameters and returning a Settlement Initiation Confirmation; Confirm Settlement, called when the payment rail has completed the transfer and returning a Settlement Confirmation with a rail-specific transaction reference; Reverse Settlement, called when a dispute resolution or verification failure requires the transfer to be reversed; and Query Settlement Status, returning the current state of a pending settlement.
A Conforming Implementation MUST include at least one payment rail adapter. The reference implementation includes adapters for the LeMay payment rail and for standard credit card processing. Additional adapters — for ACH, stablecoin settlement, on-chain payment, and future payment infrastructure — MAY be implemented through the adapter interface without modification to the core protocol.
2. Settlement Atomicity
Settlement MUST be atomic with respect to the Transaction Mandate. The entire settlement amount specified in the Mandate MUST be transferred, or no amount is transferred. Partial settlements are not permitted except in the case of a Partially Fulfilled Receipt, where the settlement amount is adjusted proportionally to the verified fulfillment percentage. The adjusted amount MUST be deterministically calculable from the Terms and the Partial Fulfillment Specification.
3. Settlement Reversal
The Settlement Layer MUST support reversal of completed settlements when triggered by a Disputed or Failed Receipt. The reversal mechanism is payment-rail-specific — credit card chargebacks, ACH reversals, on-chain refund transactions, and other rail-specific mechanisms are abstracted behind the Settlement Interface’s Reverse Settlement operation. The protocol does not specify the reversal mechanism; it specifies the conditions under which reversal MUST be initiated and the state transitions that result.
F. THE VERIFICATION LAYER#
The Verification Layer determines whether the obligations specified in the Transaction Mandate have been fulfilled. It produces a Receipt that closes the transaction loop or initiates dispute resolution. The Verification Layer MUST implement: delivery confirmation for physical and digital goods; quality attestation against the thresholds specified in the Terms; SLA compliance measurement for service and inference transactions; and dispute initiation when verification fails.
1. Verification Methods
The protocol defines four normative verification methods, and implementations MUST support all four. Attestation-Based Verification relies on a signed statement from the receiving Agent confirming receipt and quality. This method is appropriate for transactions where the receiving Agent can directly evaluate fulfillment. Evidence-Based Verification relies on external evidence — shipping tracking data, sensor readings, automated test results — that independently confirms fulfillment. This method is appropriate for physical goods and logistics transactions. Computation-Based Verification relies on automated evaluation of the delivered Value against the quality thresholds specified in the Terms. This method is appropriate for inference transactions, where the output can be scored against accuracy, latency, and format requirements. Third-Party Verification relies on a designated verification Agent that independently evaluates fulfillment. This method is appropriate for high-value transactions where neither party is trusted to self-verify.
2. Dispute Initiation
When verification determines that the Transaction Mandate’s obligations have not been fully satisfied, the Verification Layer MUST initiate the dispute resolution procedure specified in the Terms. The Dispute Initiation Record MUST contain: the Transaction Mandate identifier; the specific Terms provisions that were not satisfied; the evidence supporting the determination; and the requesting Agent’s proposed resolution. The dispute resolution procedure itself is defined in the Terms and MAY include automated arbitration, human arbitration, or escalation to LeMay’s dispute resolution service.
G. THE ATTRIBUTION LAYER#
The Attribution Layer determines how value is distributed in multi-agent collaborative transactions. A transaction that involves only two parties — one offering Agent and one requesting Agent — does not require attribution; the settlement transfers value directly between the two parties. A transaction that involves three or more Agents contributing to the outcome MUST invoke the Attribution Layer to determine fair compensation for each participant.
1. Shapley Value Calculation
The Attribution Layer MUST implement Shapley value calculations for multi-party workflows. The Shapley value is the unique allocation method that satisfies efficiency (the total value is fully distributed), symmetry (agents making equal contributions receive equal compensation), dummy player (agents making zero marginal contribution receive zero compensation), and additivity (the allocation for a combined transaction equals the sum of allocations for its component transactions). These properties make Shapley values the theoretically optimal attribution method for cooperative multi-agent workflows.
For transactions involving more than ten contributing Agents, exact Shapley value computation becomes combinatorially expensive. A Conforming Implementation MUST support exact computation for transactions with ten or fewer contributors. For transactions with more than ten contributors, the implementation SHOULD use an approximation algorithm that produces attribution values within a configurable error bound of the exact Shapley values. The approximation algorithm and error bound MUST be documented in the implementation’s certification materials.
2. Attribution Records
The Attribution Layer MUST produce an Attribution Record for every multi-party transaction. The Attribution Record MUST contain: the Transaction Mandate identifier; the identifier of every contributing Agent; each Agent’s computed attribution share; the methodology used (exact Shapley, approximate Shapley with specified error bound, or an approved alternative); and a cryptographic signature binding the record to the computation. The Attribution Record MUST be included as an appendix to the Receipt and MUST be verifiable by every participating Agent.
IV. Transaction Lifecycle and State Machine#
Every MTP transaction follows a deterministic state machine. The states and transitions defined in this section are normative: a Conforming Implementation MUST implement this state machine exactly, and any transaction that enters an undefined state or executes an undefined transition MUST be terminated with an error.
A. TRANSACTION STATES#
The protocol defines the following transaction states. Initiated: the Discovery Layer has matched a Request with one or more Offers and has notified the relevant Agents. This is the entry state. Negotiating: the Negotiation Layer is active and the participating Agents are exchanging Proposals. Committed: a Transaction Mandate has been generated and signed by all parties. The Terms are binding. Settling: the Settlement Layer has initiated value transfer through the specified payment rail. Verifying: the delivered Value is being evaluated against the Terms’ quality and delivery specifications. Fulfilled: the Verification Layer has produced a Receipt with outcome Fulfilled. This is a terminal state for successful transactions. Disputed: the Verification Layer has produced a Receipt with outcome Disputed and the dispute resolution procedure is active. Resolved: a Disputed transaction has completed its dispute resolution procedure, producing a final Receipt. This is a terminal state. Failed: the transaction has failed at any layer and cannot be completed. This is a terminal state. Void: a conditional Mandate’s preconditions expired before satisfaction, or an active Mandate’s expiration timestamp was reached before settlement initiation. This is a terminal state.
B. STATE TRANSITIONS#
Every transition between states MUST be triggered by a defined event. The Initiated-to-Negotiating transition is triggered by the first Negotiation Initiation Message. The Negotiating-to-Committed transition is triggered by the final signature on the Transaction Mandate. The Negotiating-to-Failed transition is triggered by a Rejection, Timeout, or Exhausted termination. The Committed-to-Settling transition is triggered by Mandate activation, which occurs immediately for unconditional Mandates and upon precondition satisfaction for conditional Mandates. The Settling-to-Verifying transition is triggered by Settlement Confirmation from the payment rail adapter. The Settling-to-Failed transition is triggered by settlement failure. The Verifying-to-Fulfilled transition is triggered by a Receipt with outcome Fulfilled. The Verifying-to-Disputed transition is triggered by a Receipt with outcome Disputed. The Disputed-to-Resolved transition is triggered by the dispute resolution procedure’s final determination. The Committed-to-Void transition is triggered by Mandate expiration or precondition expiration.
Every state transition MUST be logged to the transaction’s audit trail with a timestamp, the triggering event, and the identifiers of the Agents involved. The audit trail MUST be cryptographically chained — each entry’s hash includes the preceding entry’s hash — ensuring that the transaction history cannot be retroactively modified without detection.
V. The MTP Value Taxonomy#
The MTP Value Taxonomy defines the classification system for types of Value exchanged through the protocol. The taxonomy is hierarchical: top-level categories define broad domains, and subcategories provide specificity. The taxonomy is extensible through the Extension Specification process, but the top-level categories are normatively fixed in this specification and MUST NOT be modified by any implementation.
The normative top-level categories are as follows. Physical Goods: tangible products that require physical fulfillment, including manufactured goods, raw materials, agricultural products, and any item that occupies physical space and requires logistics for delivery. Digital Goods: intangible products that are delivered electronically, including software licenses, digital media, digital documents, and cryptographic assets. Services: human or machine labor performed on behalf of the requesting Agent, including professional services, creative services, maintenance, and any form of work product. Compute: processing capacity allocated for the requesting Agent’s use, including CPU cycles, GPU hours, memory allocation, storage capacity, and bandwidth. Inference: the output of a machine learning model applied to the requesting Agent’s input, including classification, generation, analysis, translation, and any other model-produced output. Information: verified factual content, research findings, market data, regulatory intelligence, and any other knowledge product whose value derives from its accuracy and timeliness. Communication: the transmission of messages, signals, or coordination data between Agents, where the value lies in the content and reliability of the transmission. Logistics: the coordination of physical movement, including shipping, warehousing, customs clearance, and last-mile delivery. Compliance: the verification of regulatory, legal, or policy conformance, including auditing, certification, and regulatory filing.
Each top-level category defines a set of mandatory quality dimensions that the Terms MUST specify for transactions in that category. Physical Goods transactions MUST specify condition, dimensions, weight, and return policy. Inference transactions MUST specify accuracy threshold, maximum latency, output format, and model versioning. The mandatory quality dimensions for each category are enumerated in the MTP Technical Binding.
VI. Error Taxonomy#
The MTP error taxonomy defines the classification and handling requirements for every error condition that can occur within the protocol. Errors are classified into four severity levels, and each severity level mandates specific handling behavior.
Fatal errors terminate the transaction immediately with no possibility of recovery. A Conforming Implementation that encounters a Fatal error MUST transition the transaction to the Failed state, log the error with full diagnostic context, notify all participating Agents, and initiate settlement reversal if settlement has already been confirmed. Fatal errors include: cryptographic signature verification failure on a Transaction Mandate; Authority Attestation failure on a Request that has already been committed; and settlement confirmation from the payment rail followed by a settlement reversal failure.
Recoverable errors interrupt the current operation but permit retry or fallback. A Conforming Implementation that encounters a Recoverable error MUST retry the operation up to the retry limit specified in the Technical Binding before escalating to Fatal. Recoverable errors include: network timeout on a Discovery Layer query; temporary unavailability of a payment rail; and transient serialization failures.
Warning errors do not interrupt the current operation but indicate a condition that SHOULD be addressed. A Conforming Implementation that encounters a Warning MUST log it and SHOULD surface it to the Agent’s monitoring interface. Warnings include: a Capability Manifest approaching its staleness threshold; a credential approaching its expiration date; and a negotiation approaching its round limit without convergence.
Informational errors are diagnostic messages that assist in debugging and performance monitoring. They carry no normative handling requirements beyond logging.
Every error MUST include: a machine-readable error code drawn from the MTP Error Code Registry; a human-readable error description; the protocol layer in which the error originated; the transaction identifier if applicable; and a timestamp. The MTP Error Code Registry is maintained by LeMay and published as an appendix to the Technical Binding. Error codes MUST NOT be reused or reassigned.
VII. Transport and Serialization Requirements#
The transport and serialization requirements defined in this section establish the architectural constraints that the MTP Technical Binding MUST satisfy. The Technical Binding specifies the particular technologies that implement these requirements; this section specifies the requirements themselves.
A. TRANSPORT REQUIREMENTS#
The transport layer MUST support both synchronous and asynchronous message exchange. Synchronous exchange is required for real-time negotiation, settlement confirmation, and verification operations where latency is critical. Asynchronous exchange is required for Discovery Layer publication, Offer and Request dissemination, and operations where immediate response is not required.
The transport layer MUST provide cryptographic channel binding — every message exchanged between Agents MUST be transmitted over a channel that is authenticated and encrypted using the cryptographic families specified in Section VIII. The transport layer MUST support mutual authentication: both the sending and receiving Agents MUST verify each other’s identity before message exchange begins.
The transport layer MUST support message integrity verification. Every message MUST include a cryptographic hash that the receiving Agent can verify to confirm the message was not modified in transit. The hash algorithm MUST conform to the cryptographic requirements specified in Section VIII.
B. SERIALIZATION REQUIREMENTS#
The serialization format MUST support deterministic encoding. Two Conforming Implementations that serialize the same logical object MUST produce byte-identical output. This requirement is critical because Transaction Mandates are signed over their serialized representation, and any serialization variance would invalidate signatures on verification.
The serialization format MUST support schema evolution — the ability to add new fields to existing message types without breaking backward compatibility with implementations that do not recognize the new fields. Unknown fields MUST be preserved but MUST NOT affect the processing of known fields.
The serialization format MUST support compact representation for bandwidth-constrained environments and human-readable representation for debugging and auditing. The Technical Binding MAY specify a single format that supports both modes or two formats that serve the respective purposes.
VIII. Cryptographic Requirements#
The cryptographic requirements defined in this section are constitutional — they derive from the LeMay Security Standard and the Technology Constitution’s mandate for post-quantum readiness. These requirements are not recommendations. They are absolute requirements that a Conforming Implementation MUST satisfy without exception.
A. MANDATORY CRYPTOGRAPHIC FAMILIES#
Digital Signatures: ML-DSA (Module-Lattice Digital Signature Algorithm). All digital signatures within the MTP protocol — on Offers, Requests, Terms, Transaction Mandates, Receipts, Capability Manifests, and all other signed objects — MUST use ML-DSA. ML-DSA is the NIST-standardized post-quantum digital signature algorithm derived from CRYSTALS-Dilithium. The specific parameter set is designated in the Technical Binding. Implementations MUST NOT use RSA, ECDSA, EdDSA, or any other pre-quantum signature algorithm for MTP protocol objects. Legacy algorithms MAY be used in the Settlement Layer’s interaction with external payment rails that have not yet adopted post-quantum cryptography, but only within the payment rail adapter and only for communication with the external rail — never for MTP protocol-level signatures.
Key Encapsulation: ML-KEM (Module-Lattice Key Encapsulation Mechanism). All key exchange operations within the MTP protocol MUST use ML-KEM. ML-KEM is the NIST-standardized post-quantum key encapsulation mechanism derived from CRYSTALS-Kyber. The specific parameter set is designated in the Technical Binding. Implementations MUST NOT use Diffie-Hellman, ECDH, or any other pre-quantum key exchange algorithm for MTP protocol-level key establishment.
Stateless Hash-Based Signatures: SLH-DSA. SLH-DSA MUST be supported as an alternative signature algorithm for environments requiring the strongest possible assurance against quantum cryptanalytic attacks. SLH-DSA’s security relies solely on the properties of hash functions, providing a conservative fallback if lattice-based assumptions are ever compromised. Implementations MUST support SLH-DSA for credential signing and MAY use it for Transaction Mandate signing when the transacting parties agree to accept the larger signature sizes.
Symmetric Encryption: AES-256-GCM. All symmetric encryption within the MTP protocol — transport-layer message encryption, at-rest encryption of stored protocol objects, and session key material protection — MUST use AES-256-GCM. The 256-bit key length provides adequate security margin against Grover’s algorithm, which reduces effective symmetric key strength by half under quantum computation.
B. CRYPTOGRAPHIC AGILITY#
The protocol MUST support cryptographic agility — the ability to transition to new cryptographic algorithms without a breaking protocol change. The Technical Binding specifies an Algorithm Negotiation mechanism through which Agents declare their supported algorithms and agree on the algorithms to use for a given session. When LeMay designates a new mandatory algorithm, implementations MUST add support within the migration window specified in the designation notice. The previous algorithm MUST continue to be supported for verification of previously signed objects but MUST NOT be used for new signatures after the migration deadline.
IX. Identifier Specification#
Every object in the MTP protocol — Offers, Requests, Terms, Receipts, Transaction Mandates, Agents, Principals, Capability Manifests, and error records — MUST be assigned a globally unique identifier conforming to the MTP-UUID format.
The MTP-UUID format is a 256-bit identifier composed of: a 4-bit version field identifying the MTP-UUID version; a 4-bit type field identifying the object type (Offer, Request, Terms, Receipt, Mandate, Agent, Principal, Manifest, Error); a 64-bit timestamp recording the identifier’s creation time in nanoseconds since the Unix epoch; a 48-bit source identifier derived from the creating Agent’s DID; and a 136-bit random component generated by a cryptographically secure pseudorandom number generator. The combination of timestamp, source, and randomness ensures global uniqueness without requiring a centralized identifier registry.
MTP-UUIDs MUST be serialized as lowercase hexadecimal strings with hyphens separating the version-type, timestamp, source, and random components. The canonical text representation is sixty-seven characters: two characters for version-type, a hyphen, sixteen characters for timestamp, a hyphen, twelve characters for source, a hyphen, thirty-four characters for randomness. An identifier that does not conform to this format MUST be rejected as malformed.
MTP-UUIDs MUST NOT be reused. An identifier assigned to any object MUST be permanently reserved for that object, even if the object is revoked, expired, or deleted. Identifier reuse is a Fatal error that terminates any transaction in which the reused identifier participates.
X. Conformance Requirements#
This section defines the requirements that a software system MUST satisfy to qualify as a Conforming Implementation of the Massachusetts Transaction Protocol. Conformance is binary: a system either conforms or it does not. There is no partial conformance. There are no conformance levels. An implementation that fails any MUST requirement is non-conforming regardless of its compliance with every other requirement.
A. MANDATORY IMPLEMENTATION REQUIREMENTS#
A Conforming Implementation MUST implement all four primitives as specified in Section II. It MUST implement all seven protocol layers as specified in Section III. It MUST implement the transaction state machine as specified in Section IV. It MUST support all nine top-level Value Taxonomy categories as specified in Section V. It MUST implement the error taxonomy and error handling behavior as specified in Section VI. It MUST satisfy the transport and serialization requirements as specified in Section VII. It MUST use the cryptographic families and algorithms specified in Section VIII. It MUST generate and validate identifiers conforming to the MTP-UUID format specified in Section IX.
B. INTEROPERABILITY REQUIREMENTS#
A Conforming Implementation MUST be capable of transacting with any other Conforming Implementation without prior coordination between the implementing parties. This interoperability requirement means that two implementations, developed independently by two different licensees who have never communicated, MUST be able to execute a complete transaction — from Discovery through Attribution — if both implementations are conforming. The normative specifications in Sections II through IX, combined with the wire-level formats in the Technical Binding, are sufficient to achieve this interoperability. Any implementation that requires out-of-band agreements, custom extensions, or proprietary message formats to interoperate is non-conforming.
C. AUDIT TRAIL REQUIREMENTS#
A Conforming Implementation MUST maintain a complete, cryptographically chained audit trail for every transaction. The audit trail MUST record every state transition, every message exchanged between Agents, every signature verification result, every settlement operation, and every error encountered. The audit trail MUST be retained for the duration specified in the licensee’s Production License. The audit trail MUST be available for inspection during LeMay’s certification and recertification processes.
D. CERTIFICATION PROCESS#
Certification is the process by which LeMay verifies that an implementation conforms to this specification. Certification is required before any implementation MAY process live transactions. The certification process is defined in Part Three of MTP-SPEC-001 and includes: submission of the implementation for conformance testing against LeMay’s test suite; demonstration of interoperability with the reference implementation; review of the implementation’s cryptographic configuration; review of the implementation’s audit trail completeness; and review of the licensee’s compliance with the Curtis License.
Certification is granted at LeMay’s sole discretion. It is maintained through periodic recertification at intervals specified in the Production License. It is revocable at any time for cause, including conformance failures discovered in production, security vulnerabilities, unauthorized extensions, deployment to prohibited entities or territories, or violation of any provision of the Curtis License. Revocation of certification terminates the Production License and MUST result in the immediate cessation of live transaction processing.
XI. Extensibility Framework#
MTP is designed for a future economy whose dimensions cannot be fully anticipated. The protocol MUST be extensible without requiring breaking changes to the core specification. The extensibility framework governs how extensions are proposed, evaluated, approved, and implemented.
Extensions MAY add new subcategories to the Value Taxonomy, new optional fields to primitive schemas, new negotiable dimensions to the Negotiation Layer, new verification methods to the Verification Layer, new payment rail adapters to the Settlement Layer, and new quality dimensions to Value Taxonomy categories. Extensions MUST NOT modify or remove any normative requirement of the core specification. Extensions MUST NOT modify the four primitives’ mandatory fields. Extensions MUST NOT modify the seven layers’ interface contracts. Extensions MUST NOT introduce new transaction states or state transitions. Extensions MUST NOT weaken the cryptographic requirements.
The Extension Specification process is governed exclusively by LeMay. Third parties MAY submit Extension Requests describing the proposed extension, its motivation, its schema changes, and its impact analysis. LeMay evaluates each request for architectural consistency, security implications, and strategic alignment. Approved extensions are published as LeMay Extension Specifications and carry the same institutional authority as the core protocol. Unapproved extensions implemented in production constitute a conformance violation and result in certification revocation.
Every approved extension is assigned a unique Extension Identifier and a compatibility version. Conforming Implementations that support an extension MUST declare the extension and its version in their Capability Manifests. An Agent that does not support an extension required by a counterparty’s Offer or Request MUST decline the match at the Discovery Layer rather than silently ignoring the extension.
XII. Versioning#
MTP uses a three-component version identifier: Major.Minor.Patch. Major version increments indicate breaking changes that require implementation updates. Minor version increments indicate backward-compatible additions. Patch version increments indicate backward-compatible corrections.
When LeMay publishes a new Major version, all Certified Implementations MUST migrate within the migration window specified in the version release notice. The migration window MUST NOT be shorter than one hundred eighty days for Major versions. During the migration window, both the current and preceding Major versions MUST be supported for interoperability. After the migration window closes, Certified Implementations that have not migrated MUST cease live transaction processing until migration is complete.
Minor and Patch versions do not carry mandatory migration timelines. Certified Implementations SHOULD adopt Minor and Patch versions promptly. LeMay reserves the right to require adoption of specific Minor or Patch versions for security reasons, in which case the requirement and its timeline will be communicated through the certification channel.
Backward compatibility is a design goal, not a governance constraint imposed by implementers. If a Major version requires breaking changes because the protocol’s security model demands them, the breaking changes will be made. The protocol serves its purpose. It does not serve its implementers’ convenience.