Discovery — service_market

Search date: 2026-09-22 Objective: a decentralized service marketplace — providers register services, customers purchase with on-chain payment, completed work is resolved, and escrowed payment is released to the provider only after successful resolution. Must resist unauthorized settlement, double payment, and stuck funds.

This record follows docs/DISCOVERY_AND_REUSE.md. It is the gate, not a summary written afterwards.

1. What was searched

The chain listing exceeds the query tool's single-response budget, so step 3 was run as an alphabet slice — gno.land/p/{a..z}, gno.land/r/{a..z}, and gno.land/r/g1{0..9,a..z} for the address-namespace bulk. No prefix was left unqueried. vm/qpaths is HEAD-only, so this is a snapshot at that height.

Two properties were treated as the decisive filter, because they are the heart of the objective:

1. Real coin custody — a chain/banker and an OriginSend envelope, versus accounting that only moves integers.
2. A resolution step gating payout — value that stays immobile across transactions until a separate resolving act releases it.

2. Relevant implementations found

Cosmic Bull's own portfolio

External, live on pearl-1

Public ecosystem

r/demo/defi/atomicswap (HTLC, hashlock-gated rather than acceptance-gated), p/demo/subscription, r/jjoptimist/eventix (instant delivery, and carries an in-source SECURITY XXX note that its paymentToken any is unvalidated) — all RELATED, and none of the three is deployed on pearl-1.

3. The delta

No package found combines all four of: provider registration, an open catalog a customer purchases against, real coin custody, and an acceptance-gated release.

• escrow_v3 has custody and resolution, but no provider registry and a non-rotatable third-party arbiter over funds.
• service_registry has registration, but holds nothing — and its own INTEGRATOR CONTRACT forbids routing a payment off one of its resolutions.
• market has purchase and custody, but Buy credits the seller in the same transaction as payment (market.gno:203-207) and goes terminal, so value never enters an escrow pool.

Stated precisely: every existing Cosmic Bull escrow realm escrows funder-first — the party who will later decide escrows their own money and then solicits work. This objective requires customer-first escrow against a standing provider offer. Four consequences follow, and they are the new work:

1. A standing offer that survives N orders. market's listing is single-shot (Active → Sold is terminal), so one listing is one sale. A service offering must be purchasable repeatedly.
2. Escrow on the purchase path. No existing package has both pay-against-a-pre-existing-offer and hold-pending-resolution.
3. A per-order state machine — Purchased → Delivered → Released, with escrow immobile until the acceptance edge.
4. Valve polarity inverts. Existing valves refund the funder on inaction. Here, after delivery, customer silence must eventually release to the provider — otherwise a non-responsive customer traps completed work. Copying an existing valve unchanged would ship a live griefing vector.

4. Reuse decisions

Imported as-is:

All four confirmed present on pearl-1 by live enumeration. A §7a closure check proves byte equivalence separately; path existence is not byte equivalence.

Adopted as a pattern, with credit, not as a dependency:

• escrow_v3.ClaimDisputeTimeout — resolving a timeout according to the pre-timeout status rather than always refunding. This is the correct answer to delta point 4 and was arrived at independently by that realm first.
• grants maxFeeBps ceiling (audit Y1) — a provider's published offer carries the maximum fee it consents to, so an admin fee change cannot retroactively alter an in-flight offer's economics.
• market / bounty_panel rejectStraySend, fee snapshotting, two-step admin handover, and the H == … conservation identity.

Considered and not used:

5. Novelty statement

"No relevant existing implementation was found in the searched sources."

This is bounded by §6 and is deliberately not a claim that nobody has built this.

6. Search-confidence limits

Exhaustive: pearl-1 package paths at height 626979 (500 packages, every prefix queried); the pinned examples tree by filename and by content keyword; the coin-custody set in that tree (banker.NewBanker/SendCoins/OriginSend, 28 files) enumerated and reviewed by path.

Sampled, not exhaustive: GitHub code search — escrow extension:gno alone reports ~980 results; roughly 40 were read by relevance and 6 in full. GitHub code search indexes incompletely and ranks opaquely. gnolang/tx-exports was searched by keyword, not enumerated.

Not searched at all: AmozPay/gbnty (GitHub API rate limit exhausted before it could be read — an unresolved gap); non-GitHub hosts; the Gno Playground corpus; forum- and chat-posted code. Other chains — sapphire-1 and local — were not enumerated; this is pearl-1 only.

Depth limit: most external classifications rest on outlines plus targeted full reads. Per the skill's own warning, an outline is navigation, not evidence; names and doc comments are realm-authored claims. escrow_v3, g16m0r7…/escrow, and market were read in full because they were load-bearing.

A correction recorded against this search's own reliability. One search strand reported samcrew/escrow_v3 as existing only on topaz, and its dependency memba_market_config as absent from pearl-1. Both claims were wrong — a direct gno_packages query on gno.land/r/samcrew/ returns both. Had that gone uncorrected, the closest functional neighbour on the target chain would have been dismissed as not deployed. The lesson is the standing one: a negative deployment claim is only as good as the query that produced it, and the query is cheap enough that it should always be run.