Counterparty terms

Everything else in these docs is the payer's side: your mandate, your terms, your decision. This is the missing half. A service publishes a signed card, and the payment is checked against it and bound to it.

The card

{
  issuer:        string        // must equal the signing key
  price:         { amount, unit }
  acceptedRails: RailId[]
  authModel:     string
  rateLimit?:    { maxRequests, perSeconds }
  validFrom:     string
  validUntil:    string
}

unit is what is being priced: call, token, item, request or second. The card is self-certifying: issuer must be the public key that signed it, or issuing throws. There is no shared secret and nothing to register with us.

What is checked

The predicate emits allow or deny and never confirm, and it composes with your existing decision by taking the stricter of the two. It can tighten a decision and can never widen one.

terms_signature_valid

The card is signed by the issuer it names.

terms_price_well_formed

The price parses.

terms_price_asset_matches

Same asset. Cross-asset comparison is refused, never converted.

terms_rail_accepted

Your terms.rail is in their acceptedRails.

terms_price_covers_amount

You are not paying more than the published price for the quantity.

terms_within_per_tx_cap

Their price is inside your per-payment cap.

terms_within_per_period_cap

And inside your period cap.

The direction nobody else covers

The last two checks run against their published price and your mandate. So a counterparty whose own card would push you past your limits is refused before you transact, rather than after they invoice you. A seller cannot induce an overpayment by publishing a price you cannot afford.

A payment is also outside the window if now falls outside validFrom to validUntil. An expired card is not a slightly stale price, it is a refusal.

Bound to the exact card

The authorised payment is bound to a hash of the exact signed envelope, card and signature together, and the receipt carries that binding. Swap the card afterwards and the binding no longer verifies.

• Agreed price and rails, signed by the party charging them.
• Checked against your own limits, not just against the invoice.
• The receipt provably belongs to that exact set of terms.