Discovery — bounty_panel

Mandatory discovery gate (docs/DISCOVERY_AND_REUSE.md) for the application-factory objective:

Build a Gno application that allows people to create public bounties with a reward, contributors to submit work, a designated resolution process to determine the winning submission, and the reward to be paid on-chain to the winner. The application should support the lifecycle from bounty creation through completion and payout, while preventing unauthorized claims, double payouts, and stuck funds.

Run 2026-09-21, before any code was written. This document records what was searched, what was found, how each hit was classified, and what was decided.

The headline finding is a near-duplicate of Cosmic Bull's own live work. It is stated first, because it is the finding that should change what gets built.

1. Headline finding

gno.land/r/g1ut6uspuh73e02yauxpmyt8g3wwddaq8utagvm3/grants — live on pearl-1 at height 584731 — already satisfies most of the objective as literally written. It is Cosmic Bull's own realm.

Six of the seven clauses are already implemented, audited, deployed, and verified live, with the conservation identity H == G + U + F + S proven on-chain.

Rebuilding that is duplication, and the gate exists to stop it.

The one clause that is not satisfied

"a designated resolution process to determine the winning submission"

In grants the resolver is the funder, implicitly and unavoidably:

func SelectWinner(cur realm, id int64, winner address) {
	caller := cur.Previous().Address()
	g := mustGetGrant(id)
	if caller != g.creator {
		panic("only the grant creator may select a winner")
	}

The funder is the party with a financial interest in the outcome. On a public bounty with open submissions that is a real problem, not a cosmetic one: the funder sees every submission before deciding, and can award to an address they control, or simply not decide and reclaim the escrow through the expiry valve, having harvested the work.

grants is a grant programme — a funder choosing among pitches is the intended process there, and the realm is correct for what it is. It is the wrong trust model for an adjudicated public bounty.

The delta between the objective and existing work is therefore exactly one thing: resolution authority that is separate from funding authority, designated at creation, and immutable thereafter.

2. Sources searched

Source 3 keyword sweep terms: bount, escrow, reward, grant, quest, task, job, arbit, judge, jury, dispute, review, submi, milestone, hackathon, prize, vote, poll, dao.

Note on drift: the enumeration returned 631 packages against 624 recorded at an earlier audit. The chain grows; discovery is re-run per build and its result is not reusable across builds.

3. Classified findings

COSMIC BULL EXISTING PRIMITIVE — reuse as-is

Both are live on pearl-1 and are consumed by bounties, grants, vault, coindemo and market. No new value-handling primitive is required, and none will be written.

EXACT DUPLICATE — none

No package found implements the objective including a designated resolver distinct from the funder.

RELATED IMPLEMENTATION — examined, not reused

GENUINELY NEW

The resolution layer: a set of resolvers designated at bounty creation, voting on competing submissions under an M-of-N threshold fixed at creation, with the escrow released only by that threshold.

Two properties make this new rather than a re-skin of existing voting code:

1. The tally selects among N candidates, it does not approve one proposal. Every voting package found — commondao, daocond, polls, nsvote, the archived committee — tallies YES/NO against a single subject. A bounty resolution asks which submission, and the winner is the first submission to reach the threshold. That is a different tally shape.
2. The tally is directly coupled to value release. No package found combines an on-chain restricted electorate with real coin custody in the same trust boundary.

No relevant existing implementation was found in the searched sources.

Per the standing rule, that sentence is a statement about the searched sources. It is not a claim of ecosystem-wide uniqueness, and "not found" is not "does not exist."

4. Decisions

1. Build, but build only the delta. The escrow, fee, pull-payment, conservation and expiry mechanics are reused from coinio + feeledger and from patterns already proven live in bounties and grants. New code is confined to the resolution layer and the state it needs.
2. No new /p/ primitive. The M-of-N tally is per-bounty integer counting over an AVL tree — on the order of fifty lines. Extracting it would be speculative: a primitive is extracted when two audited realms repeat it, which is how coinio and feeledger were born. One use is not two.
3. Do not reuse daocond or commondao. Recorded above with reasons. The substituted code is smaller, integer-only, closure-free, and address-keyed.
4. Do not touch bounties or grants. Both are live and frozen. This is a new realm at a new path. Sibling [addpkg] heights will be re-read after deployment to prove it.
5. Separate the submission window from the resolution window. Submissions close at a deadline; the panel then has a bounded resolution window; only after that window closes can anyone trigger the refund. This bounds the harvest-and-stall attack in time.
6. Resolvers may not submit. A resolver voting for their own work is the obvious attack and it is cheaply enforceable, since the resolver set is fixed at creation.
7. The funder is not barred from the resolver set. Barring them would be security theatre — a funder can name an address they control regardless — and it would give false assurance. The resolver set is public on-chain at creation, so a self-resolved bounty is visible to every contributor before they spend effort. Disclosure beats an unenforceable prohibition.
8. No forfeit on failed resolution. A refund on panel deadlock returns the escrow to the funder, which leaves a residual griefing path: fund, harvest submissions, stall, reclaim. The obvious mitigation — forfeiting the escrow to the submitters — creates a worse incentive, to spam submissions in order to farm forfeits. Accepted as a documented limitation rather than half-fixed. See §5.

5. Known limitations, recorded before implementation

• Harvest-and-stall is mitigated but not eliminated. A funder who names a colluding panel can obtain submissions and recover the escrow after the resolution window. The chain cannot distinguish a colluding panel from an honest one that found no submission worth paying. What the design does provide is disclosure: the panel and the threshold are on-chain and immutable from creation, so contributors can price that risk before submitting.
• Submission content is a string on-chain. The realm can prove when a submission was recorded and by whom; it cannot judge quality, verify authorship, or detect plagiarism between submissions. Off-chain content should be referenced by hash.
• Nothing prevents a resolver from being bribed off-chain. The threshold raises the cost; it does not remove the possibility.
• The reward is a single fixed amount paid to one winner. No splits, no runners-up, no milestones. That is the objective as stated.

6. Evidence

Chain reads were performed against pearl-1 through the Gno MCP tools (vm/qpaths for enumeration, vm/qfile via gno_read for source). GitHub searches were performed with gh api search/code. Every classification above rests on source that was read, not on a package name or a doc comment — outlines were used for navigation and whole files for anything a decision turned on.