payment=none shipped in v0.5.7 (#965, #967). A free trade runs offer -> claim -> award -> result -> verify -> accept and publishes no RECEIPT.
That part is correct and should stay. §6.8 marks ["mint", mint_url] cardinality 1 required, ["amount", sats, "sat"] required, and requires both co-signatures over the payment bind. A free trade settles at no mint and signs no payment, so a conformant receipt cannot be constructed — and relaxing those fields to emit one would mean a priced receipt with its mint tag stripped also reads as valid. That is the wrong direction on the one artifact whose whole job is proving money moved.
The gap that leaves. For a paid job the co-signed kind-3400 receipt is the only artifact a third party can check to say "this seat did this job and it settled". A free job's public trail ends at the buyer-authored kind-3406 ACCEPT, which:
- carries no seller signature — it is one party's word;
- names no result (§6.5: the join is job-level, and a reader MUST NOT infer which result an accept settles when the job carries more than one).
So a seat can complete fifty free jobs and its public settlement history is unchanged. docs/specs/free-job-lane.md §6 names this as a known exposure: "A free job leaves the seat's public settlement history unchanged, which is a real cost to a seat building a track record."
Free seats are the on-ramp for newcomers, so this is exactly the population with nothing to show for the work.
The question to settle before any code: should a free trade produce a public, co-signed completion record at all? If yes, the shape is a new small event — or a seller co-signature over something that already exists — and explicitly not a receipt with its required fields made optional.
Second-order note, not a live bug: the receipt is also what gives an open-pool seat a permanent Settled suppression (#541, "terminal forever"). A free job's ACCEPT yields only TakenElsewhere, which binds until the offer's own deadline; after that the offer is skipped as lapsed anyway, so the practical window is narrow.
payment=noneshipped in v0.5.7 (#965, #967). A free trade runsoffer -> claim -> award -> result -> verify -> acceptand publishes noRECEIPT.That part is correct and should stay. §6.8 marks
["mint", mint_url]cardinality 1 required,["amount", sats, "sat"]required, and requires both co-signatures over the payment bind. A free trade settles at no mint and signs no payment, so a conformant receipt cannot be constructed — and relaxing those fields to emit one would mean a priced receipt with its mint tag stripped also reads as valid. That is the wrong direction on the one artifact whose whole job is proving money moved.The gap that leaves. For a paid job the co-signed kind-3400 receipt is the only artifact a third party can check to say "this seat did this job and it settled". A free job's public trail ends at the buyer-authored kind-3406
ACCEPT, which:So a seat can complete fifty free jobs and its public settlement history is unchanged.
docs/specs/free-job-lane.md§6 names this as a known exposure: "A free job leaves the seat's public settlement history unchanged, which is a real cost to a seat building a track record."Free seats are the on-ramp for newcomers, so this is exactly the population with nothing to show for the work.
The question to settle before any code: should a free trade produce a public, co-signed completion record at all? If yes, the shape is a new small event — or a seller co-signature over something that already exists — and explicitly not a receipt with its required fields made optional.
Second-order note, not a live bug: the receipt is also what gives an open-pool seat a permanent
Settledsuppression (#541, "terminal forever"). A free job'sACCEPTyields onlyTakenElsewhere, which binds until the offer's own deadline; after that the offer is skipped as lapsed anyway, so the practical window is narrow.