Obligations & Chio Paper

The Obligation Atom

One obligation per unit of value. When a ChioReceipt finalizes as an allowed, priced call, the program records one immutable chio_credit::obligation::ObligationAtom keyed by a stable obligation_id. The atom binds the receipt digest, the debtor, the original_creditor (the receipt's payee), the amount, the currency, and the due date, and none of those fields is ever rewritten. No second atom is minted for the same value, so there is never a second economic claim on that receivable to settle twice.

// One immutable atom per obligation_id. Its bindings are fixed at
// mint time and never rewritten in place.
pub struct ObligationAtom {
    pub obligation_id: String,       // stable idempotency key
    pub receipt_digest: String,      // originating ChioReceipt, content-addressed
    pub debtor: String,              // who owes
    pub original_creditor: String,   // the receipt's payee
    pub amount: MonetaryAmount,      // face amount + currency
    pub due_at: u64,                 // maturity; a missing due date is ineligible
}

// The current creditor is NOT a field on the atom. It is resolved from
// a separate, authenticated disposition record kept beside the atom.
// Exactly one disposition is active at a time.
#[serde(rename_all = "snake_case")]
pub enum ObligationDisposition {
    PerCall,
    Assigned { agreement_id: String, creditor_id: String },
    Channelized,
    ClearingReserved,
}

The four dispositions are mutually exclusive, and only one is ever the active record beside a given atom:

• per_call : the default, paying the original_creditor on the per-call path. It is the only disposition a first assignment may start from.
• assigned : re-pointed to a buyer as assigned { agreement_id, creditor_id: buyer_id }, the only disposition that moves the creditor off the original payee, and what Chio Paper produces.
• channelized : reserved to a payment channel.
• clearing_reserved : reserved to a clearing run (see Clearinghouse).

Because the current creditor lives in that one authenticated record and not in a rewritable atom field, a single serialization point governs who owns the receivable, and the first-assignment path below turns it by compare-and-swap.

Chio Paper: First-Assignment Factoring

If an agent is owed money for a completed, receipt-backed tool call, it can sell that receivable to a buyer at a discount now instead of waiting for the due date, and the buyer collects the face value at settlement. That is factoring, and Chio Paper is the first-assignment case: one atom, one seller, one buyer, no resale. Bundled claims, fractional assignment, and secondary resale are out of scope for this path.

The receivable a seller offers is a ReceivableClaim (schema chio.factor.receivable-claim.v1) over exactly one atom, one receipt, and one IOU (the signed claim on the receipt from Credit Facilities & Bonds). It binds claim_id, seller_id, obligation_atom_digest, the receipt_id and its digest, the iou_id and its digest, a payee_binding_digest, a status_proof_digest, a face_value: MonetaryAmount, due_at, and built_at.

Assignment records

The bilateral deal is carried by two more chio_credit::factor records, both RFC 8785 canonical JSON:

• chio.factor.assignment-offer.v1 binds the claim digest, an asking_discount_bps: u16, a derived minimum_price: MonetaryAmount, issued_at, and expires_at. Validation requires asking_discount_bps <= 10_000 and issued_at < expires_at < due_at, so an offer can never outlive the obligation it sells.
• chio.factor.assignment-agreement.v1 binds the offer and claim digests, seller, buyer, the agreed discount and price, the buyer settlement destination, an assignment_authority_digest, the expected disposition and settlement-lifecycle versions, the normalized-assignment-request digest, the operation_id, effective_at, and due_at. Both the seller signature and the buyer signature are required. A signed agreement is still only proposed bilateral intent until the obligor acknowledges it, covered below.

Eligibility and the Status Proof

A receipt's settlement_status == Pending is immutable receipt-time evidence. It does not prove the obligation is still unpaid at sale time, so it cannot be the eligibility check on its own. Eligibility instead requires a fresh chio.obligation.status-proof.v1 signed by the configured obligor disposition authority, built from one transactional snapshot. It binds obligation_id, the atom digest, the resolved current creditor and settlement destination, the complete disposition value and its version, the settlement-lifecycle value and its version, due_at, issued_at, expires_at, and the authority id and key epoch.

An assignment is admissible only when, at the same authoritative version, every check below holds:

1. A fresh capability/policy decision authorizes factor.assignment_bind and binds the atom digest, seller, buyer, action nonce, expiry, the normalized-assignment-request digest, and an already-derived AdmissionOperationKind::GovernedEconomicMutation operation id.
2. The receipt and IOU signatures verify under trusted kernel keys and bind the same receipt_id, amount, currency, debtor, content hash, and policy hash.
3. The receipt's economic envelope carries a payee binding whose beneficiary_id equals seller_id. Neither issuer_key, tool_server, nor exposure context may be substituted for the payee.
4. At agreement time the status proof is unexpired, settlement_status == Pending, disposition == per_call, the current creditor is the seller, and effective_at < due_at. A missing or past due date rejects the claim.

The Compare-and-Swap Re-Point

Completion needs an authoritative disposition service owned or explicitly delegated by the obligor, supporting compare-and-swap. In one transaction the store compares the proof's version and state, then changes only that atom's separate disposition record from per_call to assigned { agreement_id, creditor_id: buyer_id }. Any intervening settlement, assignment, channel reservation, clearing reservation, or version change makes the compare-and-swap fail. A seller-local log is audit evidence only and can never satisfy this step.

A successful swap emits a versioned, obligor-signed chio.factor.assignment-acknowledgement.v1; a closed no-mutation outcome emits a signed chio.factor.assignment-not-applied.v1 instead. The assignment store keys on operation_id for idempotency, so a retry after acknowledgement loss returns the exact stored acknowledgement bytes rather than repeating the mutation. The compare-and-swap, not any private history the seller presents, is what prevents a double sale: of two concurrent agreements for one obligation_id, at most one can receive an acknowledgement.

The acknowledgement is the authoritative transfer record. It binds the fields below (rendered here in snake_case) and is immutable once signed; later settlement state is emitted as a separate reconciliation record, never as an edit to it:

{
  "schema": "chio.factor.assignment-acknowledgement.v1",
  "acknowledgement_id": "ack_9f2c...",
  "operation_id": "op_7b41...",
  "obligation_id": "obl_a83d...",
  "agreement_digest": "b3:5c1e...",
  "normalized_request_digest": "b3:2af0...",
  "assignment_authority_digest": "b3:91be...",
  "status_proof_digest": "b3:04d7...",
  "prior_disposition": { "per_call": {} },
  "new_disposition": {
    "assigned": { "agreement_id": "agr_11c8...", "creditor_id": "did:chio:buyer-6d2f..." }
  },
  "prior_disposition_version": 7,
  "resulting_disposition_version": 8,
  "resource_fence": 8,
  "beneficiary_id": "did:chio:buyer-6d2f...",
  "settlement_destination_ref": "dest:buyer-escrow-01",
  "authority_id": "did:chio:obligor-disposition-authority",
  "authority_key_epoch": 3,
  "effective_at": 1752160000,
  "due_at": 1752246400
}

Pricing the Discount

Every rate on this path is an integer basis-point value in the range 0..=10_000, with no floating-point rates. The quoted price of a claim is a floor over a checked u128 intermediate:

quoted_price.units = floor(face_value.units * (10_000 - discount_bps) / 10_000)

The arithmetic never wraps or saturates. Overflow, an out-of-range rate, currency drift between the discount and the face value, or a result that cannot convert back to u64 rejects the quote outright. A discount of 0 bps prices at full face value; 10_000 bps prices at zero; 10_001 is rejected. Risk inputs may raise the discount monotonically, but a Deny, StepUp, Critical, or Restricted risk outcome produces a refusal instead of a price.

The resolved figure is carried on a chio.factor.discount-quote.v1, which binds the claim, underwriting-decision, and scorecard digests, a resolved_discount_bps, the quoted price, and an optional refusal reason.

Settlement Pays the New Owner

Settlement reads the current disposition, not the original receipt. Once the atom's disposition is assigned, WS1 settlement may pay only the buyer creditor and destination bound by the acknowledgement, and the per_call, channelized, and clearing_reserved paths must every one skip an obligation whose disposition is assigned. Settlement emits a separate reconciliation record and advances the settlement lifecycle beside the atom; it never mutates the immutable atom, the original receipt, the agreement, or the acknowledgement. See Settlement Rails and Reconciliation & Watchdog for how that money movement is dispatched and reconciled.

The buyer pays the seller for the claim outside this path, and WS2 records no claim that the payment occurred unless separate payment evidence verifies. The acknowledged re-point and the buyer-to-seller payment are two independently evidenced facts, not one assumed transaction.

See Also

• Credit Facilities & Bonds for the IOU, facility, bond, and exposure-ledger accounting the obligation atom aggregates into.
• Clearinghouse for the multilateral netting path and the clearing_reserved disposition that Chio Paper deliberately does not touch.
• Reconciliation & Watchdog for how the reconciliation record that settlement emits closes the loop against the exposure ledger.
• Settlement Rails for the rails that actually move the face value to the acknowledged buyer destination.