Paid reveal

The kernel holds the price, dispatches, checks, then captures

The purchase coordinator reserves the buyer's budget and the seller's liability exposure before the sale is accepted. Neither the reservation nor the acceptance transfers the reveal price.

1. Hold. The kernel checks the purchase, requires an empty post-invocation pipeline so the seller's envelope reaches the finalizer unchanged, and authorizes the accepted price as a reversible Held payment through the payment adapter.
2. Dispatch. The pre-dispatch invocation quota capture commits. The seller's server resolves the finding identifier and returns its envelope to the kernel.
3. Check. evaluate_delivery compares the canonical JSON hash of the returned value with the committed digest, then strict-parses the envelope and compares its media type. The finalizer rechecks the finding against the authenticated status feed before capturing payment or releasing output.
4. Capture. The finalizer stages the validated output and the terminal plan durably, captures the hold once, signs the Allow carrying the delivery_contract and finding_delivery metadata blocks, and persists the signed receipt. The purchase coordinator checks the captured settlement and persists the signed chio.finding.purchase-record.v1 before returning the completed purchase.

The generic delivery contract supplies the output-digest comparison. A finding purchase adds the buyer and sale binding, the strict reveal format, the media-type check, and the current finding-status check.

A retried sale captures once, and a lost payload comes back under recovery

Because the material is staged before the capture, a crash after the capture resumes to the same signed Allow and captures nothing a second time.

• One key per sale. The purchase record's purchase_key derives from the accepted-bid envelope digest and the authoritative payment operation identifier, so a retry of one sale recomputes one key.
• A buyer crash. An Allow on read_finding records that the kernel accepted a value whose content hash equals the committed digest. A buyer that crashes between the Allow and its own write has paid for a payload it no longer holds.
• A recovery grant. The one-shot grant is spent, and a receipt is evidence, never invocation authority. The provider's recovery service checks the checkpointed original Allow and the buyer's proof of possession, then mints a RequireFindingRecovery grant.

The recovery grant carries no monetary ceilings and no authorization or capture path, keeps the same committed output digest, and allows as many invocations as the durable retry budget its recovery_id keys. Re-minting the same authority leaves that budget where it was. Recovery still passes current finding-status admission before the kernel reserves quota or dispatches the redelivery.

The commitment covers the payload and its media type

The seller commits to a two-field reveal envelope. The example below elides the payload.

{
  "media_type": "text/x-diff",
  "payload_b64": "<base64 of the sealed payload bytes>"
}

The digest comparison hashes the whole response value: receipt_content_for_output takes the SHA-256 of the canonical JSON bytes of the value, never of a sub-field. The finding's payload_sha256 is the digest of that envelope, computed by finding_payload_sha256, so the same payload under a different media type has a different digest. The envelope omits finding_id because finding_id is itself the digest of a body that already carries payload_sha256.

After the digest matches, check_reveal_envelope strict-parses the returned bytes, and the envelope type rejects unknown fields. An unknown field, an empty media_type, or a payload_b64 that fails standard base64 decoding is a malformed envelope. A parsed envelope whose media_type differs from the signed finding's payload_media_type is a media-type mismatch.

One grant authorizes one reveal at one price

The provider answers a bid with a signed AskResponse whose token_offer is the minted capability token, bound to the buyer under the provider's issuer key. The kernel admits it only against a closed profile, in purchase_marked_grant, and any violation refuses the call with a carrier error before nonce consumption, budget reservation, or dispatch.

• One marker. Exactly one RequireFindingPurchase marker; a second marker refuses.
• One settlement selector. FindingSettlementSelector is closed at two variants. LocalReversibleHold settles through the reveal-time hold and capture. CrossOrgEscrow settles a purchase between two organizations: its settlement_profile_sha256 pins the settlement-profile envelope, and a funded escrow with a proof-gated release replaces the hold and capture while every other check here stays.
• One digest. Exactly one OutputDigestSha256 constraint, carrying the digest the delivered value must hash to.
• Possession. dpop_required is true, so the buyer proves possession of the key the grant names.
• One use. max_invocations is 1: one reveal, and no replay of the token.

The captured repair sale ends in an Allow and a captured settlement

Set up the local venue and buyer credential with Run a Cognition Market, then run the buyer agent from examples/cognition-market-pilot against your finding on the local single-operator venue.

$ buyer_agent.py --credential market/buyer-client.json --chio chio \
    --finding "$FINDING_ID" --patch ./verified-fix.patch

{"baseRevision":"8ba43d4e022565634c03e83ac579b0498bc1c220","candidateRevision":"0ac3926063ef906937914686d6f88b9ea594c1ce","findingId":"889174058e27a9de2fa64ac6f7285a8cdfe6cb48cda571c576e973d3c10f90c3","patch":"~/chio/verified-fix.patch","settlement":"captured","verdict":"allow"}

You should see "verdict":"allow", "settlement":"captured", and the path of the decoded patch the buyer wrote after verifying the finding. Those fields report the kernel-mediated purchase on the local hold; a transfer on an external payment network is a separate fact that its rail records.

chio finding buy drives the same path from the command line. It requires --id, --max-price in minor units, and --currency. --payer names the buyer principal the purchase context binds, and --deadline-secs sets how long the buyer allows for delivery before the failed-delivery terminal applies.

A failed delivery withholds the payload and captures zero

Invalid purchase authority refuses before dispatch, and a transport failure is a separate outcome. A returned value that fails a delivery check gets a zero-charge Deny, and the evaluator records which check failed.

The digest check runs on the post-transform content hash. A status failure covers a retracted finding and an unavailable status verifier alike. All four take the same terminal: the admission operation moves to denied_after_delivery, a state legal only from finalizing, whose doc comment reads: The delivered output did not match a grant's committed output digest. A signed Deny is persisted; the open hold is released and zero is captured. Its settlement disposition, ContractualZeroCharge, releases the open hold, captures zero, and reconciles realized spend to zero.

The invocation capture committed before the tool ran and stays committed. The Deny receipt's financial.cost_charged is zero and financial.budget_remaining reports remaining monetary units, while the buyer has still used one unit of invocation quota. On a digest mismatch the receipt's observed_digest is a domain-separated commitment keyed by the expected digest, and the delivered digest stays in privileged durable outcome evidence, so a public Deny cannot test a candidate payload. A Stream output and a no-output Allow both refuse under a committed digest.

After the kernel signs and checkpoints the Deny, the dedicated failed-delivery authority signs chio.finding.failed-delivery.v1 over the buyer, the accepted bid, the reservation and payment operation, the exact hold attempt and its release terminal, and both halves of the deny evidence. It encodes realized_spend_units of zero and payout_eligible false, and it creates no purchase record.

Matching bytes prove delivery, and the evidence argues correctness

A matched delivery establishes that the returned content has the committed digest. Whether a repair is correct or useful rests on the finding's claim and supporting evidence, and a buyer who disputes it follows the challenge process.

The durable admission path runs these checks in finalize_durable_tool_return, and the replay path rebuilds the signed receipt from persisted state. In both market profiles the venue operator can see revealed content, and the market prices the risk of resale after a legitimate reveal; a buyer can still copy the payload. The threat model records these disclosure limits.

Next: contest a finding that fails its claim