dev.cocore.compute.settlement
An exchange's signed proof of payment for a receipt. Published by the exchange in its own repo. Strong-refs both the receipt being settled and the requester's payment authorization, so the full chain is independently verifiable.
Details · record, key tid
| Kind | record |
|---|---|
| Record key | tid |
| Authority | compute.cocore.dev |
| Indexed |
Record
record · key tidProperties
Amount charged to the requester. MUST equal receipt.price for status=settled.
Strong-ref to the dev.cocore.compute.exchangeAttestation pinning the software / signing-key combination that produced this settlement.
Exchange's retained fee. amountCharged = providerPayout + exchangeFee.
policy
refStrong-ref to the dev.cocore.compute.exchangePolicy this settlement was computed under. Lets a verifier re-run the fee math against the same policy that produced the record.
Opaque processor transaction id (e.g. Stripe PaymentIntent id), encrypted to the involved parties (requester, provider, exchange) so the public record does not leak processor metadata. Verifiers without keys treat this as opaque.
maxLength: 1024
Amount paid out to the provider after fees.
Strong-ref to the dev.cocore.compute.receipt being settled.
refundOf
refWhen status=refunded, strong-ref to the prior settled settlement record this refund reverses.
Strong-ref to the dev.cocore.compute.paymentAuthorization in the requester's repo. Verifiers MUST check it names this exchange's DID and that ceiling >= amountCharged.
sig
stringES256 signature (base64url, no padding) over the canonical JSON of every other field. Verified against the verificationMethod publicKeyMultibase in the exchange's did document. Optional for v0.3.x exchanges that haven't enabled signing; required for trust-tier=hardware-attested exchanges.
maxLength: 256
Similar lexicons
semantic matchLexicons whose schemas describe something close to this one. Check them before publishing a new one that overlaps.
-
dev.cocore.compute.dispute
recordAn exchange-signed adjudication of a complaint about a settled receipt. Published in the exchange's repo. The exchange's DID is the only DID permitted to publish a record at this NSID for a given settlement; any record at this NSID outside the exchange's repo is invalid by construction. The dispute lifecycle is open->resolved (terminal); resolution carries the outcome the exchange has already enacted (e.g. a refund settlement) and a signed rationale. Verifiers reading a settlement see status=dis
-
An exchange's self-published statement of operating posture: software commit, public signing key fingerprint, fee policy in effect, audit posture. The provider/requester analog of `dev.cocore.compute.attestation` for the exchange role. Settlements MAY strong-ref the active attestation so verifiers can pin which exchange-software / signing-key combination produced the record.
-
Proof-of-payment receipt minted by the bidder in response to a successful x402-gated GET against the bids.x402 url. Returned (by AT-URI + CID) to the requester, which uses it as the payload of the higher-level com.publicdomainrelay.temp.market.accept so the bidder can verify payment before provisioning.
-
A requester's signed authorization permitting a named exchange to charge them up to a ceiling for a specific job. Published in the requester's repo before any work runs. Settlement records strong-ref this authorization to prove consent.
-
dev.cocore.compute.receipt
recordA signed receipt of a single completed compute job. Published by the provider in its own repo. Strong-refs the requester's job and the active attestation. Carries an additional Secure-Enclave-bound signature so it remains verifiable across PDS migrations.