buyer: no gate between delivery and payment — the delivery watcher is unconditionally armed and auto-settles, so an award IS an instruction to pay

[orveth]

Summary

There is no point between a delivery arriving and the buyer paying for it. The delivery watcher is armed unconditionally at daemon boot, and it accepts and settles on its own. A buyer therefore has exactly one decision point in the whole money path — the award — and an award is in effect a standing instruction to pay whatever arrives.

For testnut that is a design choice. For a buyer holding real sats it means there is no path where a human or an adjudicator sits between delivery and payment.

Observed

Live at main 9caa941, testnut. A job was posted with max_sats: 0 (held), then awarded manually on an explicit authorization. Nothing else was called — no collect, no accept, no pay.

Roughly two seconds after the delivery landed:

buyer: delivery watcher settled 38ed7862… — paid 10 sat for commit c411618a… (2 file(s))

get_job then showed accepted populated with an accept_event_id, and spent.jsonl had been written. Wallet balance moved. The operator's only action in the entire sequence was the award.

Cause

crates/mobee-core/src/buyer/mod.rs:249:

// Start watching for delivered results. Its own first action is a sweep of awarded-unsettled
// jobs, which is what collects a delivery that landed while this daemon was down.
spawn_delivery_watcher(context.clone());

Unconditional — no config field, no flag, no report-only mode. Grepping home.rs for auto_accept / auto_settle / manual_accept / any review-mode knob returns nothing.

The watcher's own sweep also collects deliveries that arrived while the daemon was down, so stopping the daemon defers settlement rather than preventing it. And accept_claim / authorize_pay are not independently callable (they return NOT_IMPLEMENTED; the documented path is collect), so there is no supported way to drive accept manually while declining to pay.

The design intent is explicit in-tree (mod.rs:1638):

"THE MONEY TOOTH for the delivery watcher. The watcher settles with no human in the loop, so the question that matters is whether its entry to the spend gate is as gated as the RPC's."

That framing is right as far as it goes, and the integrity protection is real and well tested — a forged seller co-signature costs nothing. But integrity is not review. The watcher guarantees you only pay for a delivery that is authentically from the awarded seller; it makes no provision for deciding whether what arrived is worth paying for.

Why this matters more than it looks

The natural reading of "award reserves funds" is that a reservation is reviewable — that the buyer commits funds and then decides. It is not. The correct mental model is:

post (free) → AWARD = the irrevocable decision to pay → delivery → accept → pay, all automatic.

Consequences for anyone building buyer-side policy on top of this:

• An acceptance specification is a pre-award document, not a post-hoc gate. Any criterion that can only be evaluated once the artifact exists cannot be load-bearing on the spend.
• A reviewer can decide whether to merge the work, but not whether to pay for it. Those are different powers and the API shape invites conflating them.
• The only real risk control is job size, since each award is an unbounded-quality bet with a bounded price.
• Pre-award filters (e.g. mcp: the harness field is a hard award filter, not a recorded preference #206's proposal to make harness a hard award filter) become disproportionately important, because they are the only gates that fire before the money decision.

Suggested direction

Not prescribing an implementation:

• A report-only / manual-accept mode for the watcher — it detects and surfaces the delivery, and settlement waits for an explicit collect. Even opt-in would be enough.
• Failing that, a config field that disarms auto-settlement for a given home, so a real-money buyer can choose review-before-pay.
• At minimum, document the model plainly where buyers will read it: an award is an instruction to pay on delivery. The current wording around reservations invites the opposite assumption.

Related

• buyer: post_job auto-awards by default — publishing an offer commits a spend, with no disable knob and a restart-surviving intent #240 — post_job auto-awards by default (same family: an automatic step where callers expect a decision point). This report is the more severe half: buyer: post_job auto-awards by default — publishing an offer commits a spend, with no disable knob and a restart-surviving intent #240's workaround is max_sats: 0; this one has no workaround at all.
• mcp: the harness field is a hard award filter, not a recorded preference #206 — hard harness award filter, which under this model is a pre-award money gate rather than a correctness nicety.

[orveth]

The seller end has the same gap — together they are the actual finding

This report covers the buyer end: no review between delivery and payment. The seller end was checked separately and has the mirror gap.

In seller_exec.rs, the only quality language in the file is prompt text sent to the agent — "Make one or more non-empty commits… Anything not committed to git will not be delivered." That is an instruction to a model, not an enforced predicate. To be precise about the limit of the claim: a commit must exist for the delivery oid to derive, so it is not literally zero checks — but beyond a commit exists to push, the seller asserts nothing about the work.

Chained end to end:

agent output → seller pushes it unexamined → buyer's delivery watcher settles in ~2s → paid

There is no review at any point in the path. The co-signature integrity guarantee holds throughout — and integrity is not review.

Why this matters for how the issue gets fixed

The natural reading of this issue alone is "add a buyer-side review mode." That would be a real improvement, but it is one of two ends, and fixing it alone would close the issue while leaving the path unreviewed by default for every buyer who does not opt in.

The structural point: because the buyer cannot gate pre-payment, a seller-side pre-delivery check is the only gate that can exist before money moves. It is also the one that can be adopted without a protocol change — a seller can refuse to deliver work that fails its own predicate, today.

Suggested framing for whoever picks this up: the two ends are complementary, not alternatives. A buyer-side manual-accept mode restores review for buyers who want it; a seller-side pre-delivery predicate raises the floor for everyone.

Credit: the seller-side half was traced by the seller-node lane.

[orveth]

Closing per gudnuf's decision (2026-08-14): no manual-accept gate. We keep the model where the award IS the payment decision and trust the agent to deliver what the job asks for. A post-delivery accept/veto fights the protocol — the award commits the spend, the watcher only times it — so this is a won't-do by design, not an oversight. The principled alternative (pre-award acceptance / escrow) is tracked separately in #511.