Lexicon Garden

com.publicdomainrelay.temp.market.receipt

Receipt for acceptance of a bid on an RFP

Repository @johnandersen777.bsky.social did:plc:5svqtrhheairglgiiyvutzik namespace authority
Details · record, key tid
Kindrecord
Record keytid
Authoritymarket.temp.publicdomainrelay.com
Indexed
Compare Edit in builder → Fork →

Record

record · key tid

Properties

accept

requiredref

Strong reference to the accept record (for example a com.publicdomainrelay.temp.market.accept.x402).

Reference

bid

requiredref

Strong reference to the bid record (for example a com.publicdomainrelay.temp.market.bid.x402).

Reference

cid

requiredstring · cid

badge.blue attestation CID over the referenced accept record, making this receipt a remote attestation proof: computed from the accept record (signatures stripped), this receipt's metadata (cid/signatures stripped, repository = accept's repo DID added) as $sig, via DAG-CBOR + SHA-256 + CIDv1. Binds the receipt to the accept's exact content in the requester's repository.

payload

ref

Strong reference to the receipt record if there is anything to note about the receipt (for example a com.publicdomainrelay.temp.market.receipt.x402).

Reference

rfp

requiredref

Strong reference to the rfp record (for example a com.publicdomainrelay.temp.market.rfp).

Reference

signatures

requiredref

badge.blue attestations over this receipt. Must include the provider's inline signature, attached at creation.

Reference

submitEvent

string

Service DID reference (did:web:HOST#compute_event) of the provider's compute-event service, scoped to this receipt's strongRef. The requester calls com.publicdomainrelay.temp.market.submitEvent via PDS service-proxying using this value as the atproto-proxy target, to report lifecycle events the provider cannot observe itself (e.g. compute.events.vm.delete when a workflow finishes or its policy engine never comes up), since the provider treats provisioned resources as a black box.

Similar lexicons

semantic match

Lexicons whose schemas describe something close to this one. Check them before publishing a new one that overlaps.

  • com.publicdomainrelay.temp.market.accept

    record

    Acceptance of a bid on an RFP

  • com.publicdomainrelay.temp.market.bid

    record

    A bid on an RFP

  • com.publicdomainrelay.temp.market.receipts.x402

    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.

  • com.publicdomainrelay.temp.market.rfp

    record

    Top-level Request For Proposal (RFP). Envelope that strongRefs a domain-specific payload (e.g. compute.vm).

  • com.publicdomainrelay.temp.market.submitAccept

    procedure

    Submit the AT-URI and CID of an accept record directly to the bidder named in the winning bid's payload, settling the contract: the bidder resolves accept->bid->rfp->vm, provisions the resource, mints a market.receipt record, and returns a strong reference to it plus its submitEvent service DID reference. Must be called via PDS service-proxying (atproto-proxy); the receiver verifies the inter-service auth JWT and requires its issuer to be the DID that authored the referenced accept record. The r