The Deal Flow

The chain

Click the chain or use the buttons below

Lightning escrow example: signed records bind identities, terms and reported outcomes through hashes. Changing a bound field breaks verification.

5 provider signaturesDescriptor, offer, quote, invoice bundle, and receipt come from the provider.

1 requester signatureThe deal is the requester’s cryptographic commitment to the quoted terms.

1 terminal recordThe receipt is the provider’s signed report of the outcome, verifiable later.

The artifact chain is both the protocol flow and the audit log. The same objects used during execution are the objects you verify afterwards.

The diagram shows Lightning escrow, including its InvoiceBundle after the Deal. A free exchange uses five artifacts: Descriptor, Offer, Quote, Deal and Receipt (four provider signatures and one requester signature). Prepaid exchanges also omit the InvoiceBundle. A signature authenticates the provider’s reported outcome; it is not proof that arbitrary computation was performed.

Message exchange

Requester ↔ Provider message flow

Watch the four-step exchange that turns a quote into a verifiable receipt.

⏸ Pause

Key insight: who signs what

Artifact	Signed by	Why
Descriptor	Provider	Declares identity
Offer	Provider	Commits to pricing
Quote	Provider	Prices specific workload
Deal	Requester	Accepts quoted terms
InvoiceBundle	Provider	Lightning escrow payment instructions, when applicable
Receipt	Provider	Signed reported outcome

The Deal is the only artifact signed by the requester — it accepts the Quote’s terms, including payment when applicable. Everything else is signed by the provider.

What the receipt establishes

Anyone holding the receipt can verify: the provider signed it, the result hash matches what the provider committed to, the recorded settlement state is internally consistent (on Lightning, attested by the payment preimage), and the chain is unbroken. What it does not prove is that the result is correct — a receipt makes outcomes attributable, not infallible. Disputes on the hosted marketplace go through an operator-adjudicated arbiter; the math fixes the evidence, not the verdict.

The signed artifact envelope

Every artifact in the chain is a JSON envelope with identity and integrity proof built in:

{
  "artifact_type": "offer",
  "schema_version": "froglet/v1",
  "signer": "02a8d6...public_key",
  "created_at": 1700000000,
  "payload_hash": "sha256_of_canonical_payload",
  "hash": "sha256_of_canonical_signing_bytes",
  "payload": { ... },
  "signature": "bip340_schnorr_signature"
}

Verification: canonicalize the payload (RFC 8785 JCS), hash it with SHA-256, rebuild the signing bytes, verify the BIP340 Schnorr signature against the signer key. If it passes, the payload is untampered and the artifact came from the holder of the private key.