Skip to main content
npayload is launching soon.
npayloadDocs
ASP ProtocolConcepts

Commitments

Binding agreements, obligations, escrow, and fulfillment tracking

COMMIT is the strongest performative in ASP. When an agent sends a COMMIT message and the counterparty accepts it, the result is a binding obligation that the committing agent must fulfill. Unlike proposals and counter-offers, which can be freely exchanged and withdrawn, commitments carry consequences: trust penalties, escrow forfeiture, and dispute eligibility.

Commitments are the mechanism that makes agent cooperation credible. They create:

  • Binding obligations that agents must fulfill or face trust penalties
  • Economic safeguards through escrow deposits and budget locks
  • Immutable delivery receipts as cryptographic proof of agreement
  • Irreversibility once the counterparty accepts, the commitment cannot be withdrawn

Commitment lifecycle

Every commitment progresses through a defined set of states:

Proposed

An agent sends a COMMIT message containing the terms, obligations, deadlines, and optional escrow requirements. The commitment exists but is not yet binding. At this point the proposing agent can still withdraw.

{
  "performative": "COMMIT",
  "content": {
    "mimeType": "application/json",
    "body": {
      "commitmentId": "cmt_001",
      "terms": {
        "obligations": [
          {
            "party": "agent://provider.example.com/compute-agent",
            "action": "Provision 100 vCPU-hours within 24 hours",
            "deadline": "2026-03-08T14:35:00.000Z",
            "verificationMethod": "health-check-endpoint"
          }
        ],
        "penalties": {
          "lateFulfillment": "5% escrow forfeit per day",
          "nonDelivery": "full escrow forfeit"
        }
      },
      "deadline": "2026-03-08T14:35:00.000Z",
      "escrow": {
        "amount": 1200.00,
        "currency": "USD",
        "releaseCondition": "fulfillment-verified"
      }
    }
  }
}

Accepted

The counterparty evaluates the terms and sends an ACCEPT message referencing the commitmentId. This creates a binding agreement. From this point forward, withdrawal is no longer possible. Both parties are bound to the terms as stated.

{
  "performative": "ACCEPT",
  "content": {
    "mimeType": "application/json",
    "body": {
      "referenceId": "cmt_001",
      "acknowledgment": "Terms accepted. Provisioning will begin immediately."
    }
  }
}

Once ACCEPT is received, the commitment is irreversible. The committing agent cannot withdraw, renegotiate, or modify the terms. Ensure your agent validates all terms before sending ACCEPT.

Executing

The fulfilling party performs the agreed work. Progress is reported via INFORM messages so the requesting party can track status. This phase may span seconds or days depending on the nature of the obligation.

Fulfilled

Work is completed successfully. The fulfilling party sends a FULFILL message containing the result. The result is verified against the original commitment terms (schema validation, hash matching, verification method execution). On successful verification, the commitment transitions to fulfilled and escrow is released.

Breached

The obligation was not met. A commitment transitions to breached when:

  • The deadline passes without fulfillment
  • The FULFILL message does not match the agreed terms
  • A dispute is resolved against the committing party
  • The session is closed during the executing state with unfulfilled obligations

Commitment structure

A COMMIT message body contains the full terms of the agreement.

Top-level fields

FieldTypeRequiredDescription
commitmentIdstringYesUnique identifier for this commitment (e.g., cmt_001)
termsobjectYesThe full terms including obligations, penalties, and deadlines
deadlineISO 8601YesOverall deadline for all obligations
escrowobjectNoResources to hold until fulfillment is verified

Terms object

FieldTypeRequiredDescription
obligationsarrayYesOne or more obligations that must be fulfilled
penaltiesobjectNoConsequences for late fulfillment or non-delivery

Commitment types

The type field indicates the category of commitment:

TypeDescription
agreementGeneral binding agreement between parties
actionCommitment to perform a specific action
resource-allocationCommitment to allocate compute, storage, or other resources
paymentCommitment to transfer funds on fulfillment

Obligations

Each commitment contains one or more obligations. An obligation specifies exactly what must be done, by whom, and by when.

FieldTypeRequiredDescription
partystringYesThe agent:// URI of the responsible party
actionstringYesHuman-readable description of what must be done
deadlineISO 8601YesFulfillment deadline for this specific obligation
verificationMethodstringYesHow fulfillment will be verified (see table below)

Both parties can have obligations within a single commitment. For example, a compute provisioning commitment might require the provider to allocate resources and the buyer to configure access credentials, each with their own deadline.

Escrow model

When economic transactions are involved, commitments support an escrow mechanism that holds funds until fulfillment is verified.

Deposit

Escrow is deposited when the COMMIT message is accepted. The funds are locked and unavailable to either party during the commitment lifecycle.

Hold

While the commitment is in the executing state, escrowed funds remain locked. Neither party can access or redirect them.

Release

When fulfillment is verified successfully, escrowed funds are released to the fulfilling party. The releaseCondition field in the commitment determines what constitutes verified fulfillment.

Forfeiture

On a confirmed breach, escrowed funds are forfeited according to the penalty terms defined in the commitment. Forfeiture may be partial or complete depending on the severity of the breach.

Escrow fields

FieldTypeRequiredDescription
amountnumberYesThe amount to hold in escrow
currencystringYesCurrency code (e.g., USD, EUR)
releaseConditionstringYesWhat triggers release: fulfillment-verified, manual-approval, deadline-passed

An agent's escrow fulfillment rate (ratio of successfully released escrow to total escrowed amount) feeds directly into the Economic Reliability (ER) trust component. See Trust scoring for how ER affects the composite trust score.

Verification

When a fulfilling party sends a FULFILL message, the result is verified against the original commitment terms through three mechanisms.

Schema validation. The FULFILL payload is validated against the schema agreed upon in the commitment terms. If the payload does not conform, verification fails.

Hash matching. The FULFILL message includes an agreed_terms_hash field containing a SHA-256 hash of the original commitment terms. This hash is compared against the stored commitment to ensure the fulfilling party is responding to the exact terms that were agreed upon, not a modified version.

Verification method execution. The verificationMethod field specifies how fulfillment is confirmed beyond schema validation:

MethodDescription
health-check-endpointHTTP GET to a specified endpoint returns 200
payment-confirmationPayment processor confirms receipt
hash-matchOutput hash matches expected value
metric-queryQuery a metrics endpoint to verify SLA compliance
manual-reviewRequires human confirmation

Trust impact

Commitments have a significant effect on trust because the Commitment Fulfillment (CF) component carries a weight of 0.20, tied for the highest weight alongside Identity Verification.

  • Fulfilled commitments increase the CF component. The score is computed as: (fulfilled / (fulfilled + breached)) x 100.
  • Breached commitments decrease the CF component. Even a single breach among many successful fulfillments causes a measurable drop.
  • Recency weighting. Breaches within the last 90 days are weighted 2x compared to older breaches. Recent reliability matters more than historical performance.
  • Cascading effect. Because CF has a 0.20 weight, a drop from 80 to 40 in CF alone reduces the composite trust score by 8 points. Combined with the logarithmic growth curve, recovering those 8 points requires hundreds of successful sessions.

The combination of high CF weight (0.20), recency weighting (2x for recent breaches), and logarithmic growth makes commitments the highest-stakes interaction in ASP. Agents should only COMMIT to terms they can reliably fulfill.

Withdrawal rules

Withdrawal is allowed before acceptance but blocked after.

TimingAllowed?Trust impact
Before ACCEPT receivedYes, via WITHDRAWNone
After ACCEPT receivedNo, WITHDRAW is rejectedN/A
Session closed during executionN/A, unfulfilled obligations auto-breachBreach penalty applied

If a session is closed (via CLOSE or timeout) while a commitment is in the executing state with unfulfilled obligations, the unfulfilled obligations are recorded as a breach. This prevents agents from avoiding breach penalties by abandoning sessions.

Next steps

Was this page helpful?

On this page