MRWK portability and future claim design

[ramimbo]

This is a design discussion for MRWK portability and future claim paths. It follows the current-transfer Q&A in #389, where the current supported path was clarified: MRWK is native to the MergeWork ledger, GitHub balances can be claimed into linked mrwk1 wallets, and registered wallets can send signed wallet-to-wallet transfers.

There is no project-run public BTC, USDC, fiat, bridge, exchange, or off-ramp today. Please do not make price, investment, liquidity, payout, exchange-listing, or bridge-promise claims.

The goal here is to help maintainers decide what future work is safe and useful to bounty next. Useful discussion should make the maintainer decision clearer, not just add volume.

Useful angles:

• Snapshot eligibility rules: what ledger state should count, and when.
• Onchain claim design: how a future claim could be auditable without weakening the ledger/proof model.
• Security and abuse risks: replay, double-claim, Sybil, custody, compromised wallets, stale proofs, or misleading public claims.
• Operations and responsibility: who runs what, what must be automated, and what should stay out of scope.
• Legal/compliance risk: public concerns stated conservatively, without advice or speculation.
• Bounty policy: what future snapshot, bridge, claim, docs, tests, or research bounties should accept or reject.
• Synthesis: a fair summary of the best options, unresolved questions, and recommended next bounty issues.

Response rules for bounty eligibility:

• Post in this discussion.
• Start with Bounty response: <category> where category is proposal, risk analysis, prior art, bounty policy, or synthesis.
• One eligible top-level proposal per GitHub account.
• Up to two eligible follow-up replies per account.
• Link concrete prior art or project context when relevant.
• State assumptions and non-goals.
• Do not open a PR for this bounty unless a maintainer later opens an implementation issue.

A linked bounty issue will track awards. To claim consideration, post your discussion comment here, then comment on the bounty issue with /claim <discussion-comment-url>.

The bounty closes when a maintainer publishes a decision summary, not on a timer. The decision summary may choose a direction or defer with documented reasons. Follow-up implementation bounties should come from that summary.

[ramimbo]

Linked bounty issue: #403

Reward: 50 MRWK per accepted award. Max awards: 6.

To claim consideration:

1. Post your contribution in this discussion.
2. Start with Bounty response: <category> where category is proposal, risk analysis, prior art, bounty policy, or synthesis.
3. Comment on the bounty issue with /claim <discussion-comment-url>.

The bounty closes when a maintainer publishes a decision summary, not on a timer. Accepted responses should help maintainers decide future snapshot, claim, bridge, documentation, testing, or research bounties without making price, investment, liquidity, payout, exchange, or bridge-promise claims.

[aiautotool]

Bounty response: risk analysis

Assumptions:

• MRWK remains ledger-native for now.
• Current supported movement is GitHub balance claim into a linked mrwk1 wallet and signed mrwk1-to-mrwk1 transfers.
• Any future portability path should be designed as a claim/export mechanism first, not as a public bridge/off-ramp promise.

Recommended safe next path: define a read-only snapshot + claim-proof spec before any external settlement work. The next bounty should not ask for bridge code. It should ask for a deterministic snapshot artifact and verification rules that maintainers can audit independently.

Suggested snapshot rules:

• Snapshot input: ledger height, account balances, pending/held GitHub balances, accepted-but-unpaid awards, and wallet-link records at a named cutoff.
• Exclusions: rejected work, unaccepted claims, unpaid review comments, duplicate bounty claims, and any account under maintainer dispute.
• Output artifact: canonical JSON plus hash, e.g. snapshot_id, ledger_height, generated_at, accounts[], exclusions[], and source_proof_hashes[].
• Each account row should include account_id, account_type (github or mrwk1), balance_mrwk_units, eligibility_reason, and source ledger/proof references.
• The artifact should be committed or published with enough metadata that a third party can recompute it from public ledger data.

Claim-proof rules:

• Use a nonce/challenge per snapshot_id and account_id. A signature should be valid only for that tuple.
• GitHub accounts should claim only after OAuth login binds github:{login} to a wallet. The claim should move or mark eligibility once, not create a reusable proof.
• Wallet accounts should sign with the registered mrwk1 key. If a wallet key is compromised, maintainers need a documented pause/dispute process rather than silent reassignment.
• Every claim result should emit a public claim receipt containing snapshot_id, account_id hash or public account, destination identifier, claimed amount, nonce, claim proof hash, and status.

Primary risks:

• Double claim: same GitHub balance claimed once via github:{login} and again via a linked wallet row. Mitigation: canonical account normalization before snapshot and one claim state machine per source balance.
• Replay: a valid signature reused against a later snapshot or different destination. Mitigation: bind signatures to snapshot_id, account_id, destination, amount, and nonce.
• Stale proofs: old accepted-work proofs used after maintainer reversals or duplicate detection. Mitigation: snapshot should reference the current canonical ledger state, not raw issue comments.
• Misleading public claims: contributors may imply cash-out, peg, exchange listing, or bridge availability. Mitigation: docs and bounty templates should require “ledger-native / no public off-ramp” language until a maintainer decision changes it.
• Custody confusion: if any external asset is ever involved, users may assume MergeWork custody or redemption guarantees. Mitigation: defer external asset work until a separate maintainer-owned operations and policy doc exists.

Non-goals for the next bounty:

• No BTC, USDC, fiat, exchange, bridge, or off-ramp implementation.
• No price, liquidity, or redemption language.
• No private key custody, seed handling, or manual one-off payout process.
• No hidden allowlist maintained outside public snapshot evidence.

Useful next bounties:

1. Snapshot spec bounty: produce the canonical JSON schema, exclusion rules, and recomputation procedure.
2. Claim verifier bounty: implement a local verifier that checks snapshot hash, account eligibility, nonce uniqueness, and signature binding without moving value externally.
3. Docs/policy bounty: update public docs and PR templates to prevent misleading portability claims.
4. Abuse test bounty: table-driven tests for double-claim, stale proof, duplicate GitHub/wallet rows, replayed nonce, and disputed account states.

Decision this supports: maintainers can safely bounty snapshot and verifier work now, while explicitly deferring any external bridge/off-ramp work until the native ledger proof and claim model is auditable.

[bitdamii]

Bounty response: bounty policy

Assumptions and boundaries:

• This is a policy proposal for future MRWK bounties, not an implementation request.
• MRWK remains ledger-native unless maintainers later publish a separate decision.
• The policy should avoid wording that implies price, exchange listing, bridge availability, cash-out, fiat value, or guaranteed off-ramp.
• Future work should be accepted only when it produces reviewable artifacts that maintainers can audit against the current ledger and proof model.

Recommended bounty policy: use a staged "decision record -> snapshot -> verifier -> docs" ladder.

1. Decision record bounty

   • Accepted: a concise maintainer-facing decision record with assumptions, non-goals, open questions, and follow-up bounty recommendations.
   • Required evidence: links to the current ledger/account behavior, the current transfer paths, and the specific future decision the record supports.
   • Not accepted: broad essays, price/liquidity claims, bridge promises, or proposals that require private keys, seed material, custody, or unreleased operational details.

2. Snapshot-spec bounty

   • Accepted: a deterministic snapshot schema and fixture set that can be recomputed from public ledger/proof data.
   • Required evidence: snapshot id, ledger height/hash, account rows, exclusions, total-balance checks, and at least one stale/duplicate exclusion fixture.
   • Not accepted: mutable exports, hidden allowlists, manual spreadsheet states, or any result that changes balances while generating the snapshot.

3. Claim-verifier bounty

   • Accepted: verifier-only work that proves a claim packet is bound to one snapshot, one source account, one target, one nonce, and one amount.
   • Required evidence: replay rejection, stale snapshot rejection, GitHub-source claim handling, wallet-source signature handling, and idempotent retry tests.
   • Not accepted: external settlement, bridges, fiat/crypto redemption flows, or irreversible debit behavior before maintainers approve the snapshot policy.

4. Documentation and wording bounty

   • Accepted: public docs that clearly separate "supported today" from "future design under discussion."
   • Required evidence: updated copy for account balances, GitHub balance claims, wallet-to-wallet transfers, and future-work non-goals.
   • Not accepted: language suggesting a peg, listing, redemption guarantee, cash-out route, or maintainer-operated custody.

5. Abuse-test bounty

   • Accepted: table-driven tests or dry-run reports for double claim, stale proof, renamed GitHub account, compromised account, wallet rotation, and partial failure.
   • Required evidence: each test must state the source account, snapshot id, expected accept/reject reason, and expected invariant.
   • Not accepted: tests that require real fund movement, third-party account access, or private vulnerability details.

Suggested default acceptance rubric for future MRWK portability bounties:

• Must identify the current supported path it relies on.
• Must state explicit non-goals.
• Must include at least one replay or duplicate-claim control.
• Must include deterministic evidence maintainers can independently review.
• Must fail closed when account ownership, snapshot freshness, or destination binding is ambiguous.
• Must not introduce custody, private-key handling, value promises, or external redemption claims.

Suggested claim template for future contributors:

Claim category:
Current MRWK path used:
Artifact produced:
Snapshot or ledger reference:
Replay/duplicate control:
Non-goals:
Validation evidence:
Maintainer decision this supports:

Suggested close condition:

• Close each future portability bounty only after a maintainer posts a short decision summary saying what was accepted, what remains deferred, and what bounty should come next.
• If the safe answer is "defer implementation," pay useful policy/snapshot/verifier analysis but explicitly defer external portability work.

This policy lets maintainers pay concrete decision-support and verification work now while keeping implementation, bridge, off-ramp, price, and custody claims out of scope until there is a separate maintainer decision.

[prettyboyvic]

Bounty response: synthesis

Assumptions and decision target:

• MRWK stays ledger-native unless maintainers publish a separate implementation decision.
• Current supported paths remain GitHub balance claim into a linked mrwk1 wallet and signed wallet-to-wallet transfers.
• The next useful decision is whether to bounty snapshot/verifier work first, not whether to promise a bridge, exchange, off-ramp, price, or external redemption path.

Synthesis of the strongest safe path:

1. Publish a short maintainer decision record that explicitly defers external portability and authorizes only snapshot/verifier/design work.
2. Bounty a deterministic snapshot dry run before any claim implementation. The artifact should name ledger height, generated_at, canonical totals, included rows, excluded rows, and source proof references.
3. Bounty a verifier-only claim packet next. A packet should be valid only for one snapshot_id, source account, destination identifier, amount, and nonce, with idempotent retry behavior.
4. Bounty read-only preview/docs after the verifier. Contributors should be able to inspect eligibility and failure reasons without moving value externally.

Concrete gates I would use for follow-up bounties:

• Snapshot schema must be recomputable from public ledger/proof state and include an exclusion report for disputed, duplicate, stale, rejected, or not-yet-accepted claims.
• Claim verifier must reject replay across snapshots, reused nonce, destination mismatch, amount mismatch, source-account mismatch, and stale snapshot ids.
• GitHub-source rows need an ownership rule that survives display-name/login ambiguity. If immutable GitHub ids are unavailable in current ledger rows, the limitation should be documented and treated as a snapshot risk.
• Wallet-source rows should require the registered public key and a fresh challenge. Wallet rotation or compromise should fail closed into a public dispute/freeze process rather than silent reassignment.
• Any public page or API wording must keep “supported today” separate from “future design under discussion.”

Unresolved maintainer choices:

• Snapshot cutoff: exact ledger height only, or ledger height plus accepted-but-unpaid awards in the admin queue.
• Disputes: who can freeze or exclude an account row, and how that exclusion is audited.
• GitHub identity: whether login strings are enough for the first dry run, or whether future wallet-link records should persist immutable GitHub ids.
• Reversals: whether later duplicate detection can void a claim preview before any external work is considered.

Recommended next bounty order:

1. Snapshot schema and fixture bounty.
2. Local verifier and replay/duplicate tests bounty.
3. Public eligibility preview API/page bounty.
4. Docs wording bounty that prevents portability, bridge, off-ramp, liquidity, or price misunderstandings.

Decision this supports: maintainers can safely pay concrete snapshot, verifier, preview, and documentation work now while deferring all external settlement or bridge implementation until the ledger-native proof model has a public, testable claim design.

[gamechangsu]

Bounty response: prior art

Assumptions:

• MRWK stays native to the MergeWork ledger until maintainers publish a separate implementation decision.
• The current supported flows remain GitHub balance claims into linked mrwk1 wallets and signed wallet-to-wallet transfers.
• This comment is decision support only; it does not propose a bridge, off-ramp, exchange path, price model, custody flow, or external redemption promise.

Prior art that seems useful:

1. Certificate Transparency v2 (RFC 9162): https://datatracker.ietf.org/doc/html/rfc9162

   • What applies: append-only transparency logs, signed tree heads, inclusion proofs, and consistency proofs are a good model for proving that a published snapshot or claim receipt was included in a public sequence and that later views extend earlier views.
   • What does not apply directly: CT proves log inclusion/consistency; it does not solve MRWK account eligibility, GitHub identity, wallet compromise, or dispute handling.
   • MRWK use: publish each snapshot manifest hash and each accepted claim receipt into an append-only public receipt stream, then let agents verify inclusion and monotonic extension before trusting preview or claim status.

2. Sigstore Rekor: https://docs.sigstore.dev/logging/overview/

   • What applies: Rekor-style transparency for signed metadata is a close fit for auditable claim receipts. The useful pattern is “the signed object is public, indexed, and independently verifiable,” not “trust a private admin export.”
   • What does not apply directly: Rekor’s software supply-chain identity model is not MRWK’s ledger identity model; MRWK still needs its own canonical source account, destination, amount, nonce, and snapshot binding rules.
   • MRWK use: define a claim_receipt object whose canonical bytes are hashed and logged. Minimum fields: snapshot_id, ledger_height, source_account, destination, amount_microunits, nonce, verifier_version, status, reason, and source_proofs.

3. The Update Framework snapshot/timestamp separation: https://theupdateframework.io/

   • What applies: separate “what is in this snapshot” from “is this the current/fresh snapshot.” MRWK should not make clients infer freshness from a filename or comment timestamp.
   • What does not apply directly: TUF is for secure update metadata; MRWK does not need to copy its role hierarchy wholesale.
   • MRWK use: every snapshot dry run should have immutable content metadata plus freshness metadata: snapshot_id, ledger_height, ledger_entry_hash, generated_at, expires_at or superseded_by, generator_version, accounts_root, exclusions_root, and total-balance checks.

Concrete recommendation for the next maintainer decision:

• Bounty a “snapshot manifest + public receipt log” dry run before any claim implementation.
• Require two artifacts: snapshot.json and snapshot_receipt.json.
• snapshot.json should be deterministic and sorted, with account rows, exclusions, source proof hashes, totals, and generator version.
• snapshot_receipt.json should bind the snapshot hash to a ledger height and publication time and later support inclusion/consistency checks.
• A claim packet should not be accepted unless it binds to exactly one snapshot id, one source account, one destination, one amount, and one nonce.
• Public docs should call this a verifier/snapshot design until maintainers explicitly decide otherwise.

Suggested acceptance tests for a future bounty:

• Recompute the snapshot hash from fixture ledger/proof rows.
• Reject a claim packet with a different snapshot id.
• Reject replay of the same nonce for the same source account.
• Reject destination or amount mismatch.
• Reject stale or superseded snapshot ids.
• Verify that every included account row maps back to public ledger/proof evidence or an explicit exclusion reason.

Decision this supports: choose a transparency-first snapshot and receipt design as the next safe bounty path, while deferring any external portability implementation until maintainers have a public, replay-resistant, auditable claim model.

[campersurfer]

Bounty response: proposal

Proposal: add an explicit identifier taxonomy to any future MRWK claim packet, snapshot manifest, verifier, and public docs before maintainers bounty implementation work.

Assumptions:

• MRWK remains ledger-native unless maintainers publish a separate decision.
• Current supported flows are still GitHub balance claim into a linked mrwk1 wallet and signed wallet-to-wallet transfers.
• Future snapshot or claim work should be auditable against public ledger/proof state and should fail closed when an identifier is ambiguous.

Context from current project behavior:

• MergeWork already has at least two valid bounty identifiers: the source GitHub issue number, such as ramimbo/mergework #411, and the internal bounty id used by /bounties/<id> and /api/v1/bounties/<id>.
• PR submission rules currently ask contributors to reference Bounty #<issue> or Refs #<issue>, while ledger/proof/account pages link the internal bounty id for public explorer navigation.
• That split is reasonable, but future claim designs should make it impossible for clients, agents, or reviewers to accidentally treat one identifier as the other.

Recommended taxonomy:

1. source_repo and source_issue_number
   • Human-facing bounty source, used in PR bodies, GitHub issue links, and maintainer discussion.
   • Example: ramimbo/mergework, 411.
2. bounty_id
   • MergeWork internal bounty row id, used for API lookups, reserve accounts, accepted-work rows, and explorer URLs.
   • Example: /api/v1/bounties/71.
3. source_account
   • The account whose existing ledger balance or accepted work creates eligibility.
   • Example: github:alice or mrwk1....
4. destination_account
   • The wallet/account that receives a claim result or transfer.
   • Example: linked mrwk1... address.
5. ledger_sequence and proof_hash
   • Immutable evidence pointers, not user input selectors.
   • Used to audit how a balance or accepted-work row entered the snapshot.
6. snapshot_id
   • Hash or stable name for one deterministic snapshot; all claim packets must bind to it.
7. claim_nonce
   • Per-source-account nonce/challenge scoped to the snapshot and destination.

Concrete claim packet shape for future verifier-only bounties:

{
  "snapshot_id": "<snapshot hash or stable id>",
  "source_repo": "ramimbo/mergework",
  "source_issue_number": 411,
  "bounty_id": 71,
  "source_account": "github:alice",
  "destination_account": "mrwk1...",
  "amount_microunits": 75000000,
  "claim_nonce": 1,
  "source_proofs": ["<proof_hash>"],
  "ledger_sequences": [672]
}

Verifier rules I would require:

• Reject a packet when source_issue_number does not match the issue recorded on bounty_id in the snapshot.
• Reject a packet when source_repo is omitted for issue-number selectors, because issue numbers are only unique within a repo.
• Reject a packet when source_account and destination_account are the same field or are normalized through the wrong validator.
• Reject a packet when proof_hash or ledger_sequence points to a different bounty, account, or amount than the claim packet states.
• Reject replay when snapshot_id, source_account, destination_account, amount, and nonce do not all match the signed payload exactly.
• Treat display labels like Bounty #71 or ramimbo/mergework #411 as presentation only; canonical JSON fields should drive verification.

Suggested follow-up bounties:

1. Identifier taxonomy docs: document these fields in API, MCP, and agent guidance, with examples showing source issue vs internal bounty id side by side.
2. Snapshot fixture tests: include rows where the GitHub issue number differs from the internal bounty id and assert verifier rejection on swaps.
3. Claim-packet verifier: validate repo+issue, internal bounty id, source account, destination account, amount, nonce, ledger sequence, and proof hash bindings without moving funds.
4. Public UI copy pass: keep explorer labels clear, e.g. Bounty #71 for internal explorer links and ramimbo/mergework #411 for source issues.

Non-goals:

• No bridge, exchange, off-ramp, fiat, price, liquidity, redemption, or external settlement claim.
• No private-key custody or seed handling.
• No hidden allowlists or manual spreadsheet eligibility.
• No implementation that mutates balances before snapshot and verifier rules are accepted.

Decision this supports: maintainers can safely bounty snapshot/verifier work with a stable vocabulary and testable failure cases, reducing the chance that future agents or clients build against the wrong bounty identifier or claim-account field.

[adliebe]

Bounty response: risk analysis

Risk focus: public wording and claim-state drift.

Most of the technical risk in a future MRWK portability design is already visible in the snapshot/verifier comments above: replay, duplicate claims, stale snapshots, source/destination binding, and identifier ambiguity. The overlooked operational risk is that MergeWork can implement a safe verifier while still creating unsafe expectations through public UI text, API field names, bounty templates, or contributor comments.

A future portability bounty should therefore include a small machine-testable "wording contract" before any user-facing preview, claim page, or docs change is accepted.

Recommended wording contract:

• Separate current state from future state everywhere. Current state is ledger-native MRWK, GitHub balance claim into linked wallet, and signed wallet-to-wallet transfer. Future design remains only snapshot/verifier research until maintainers publish otherwise.
• Use state labels that describe evidence, not value movement: eligible_in_snapshot, claim_preview_ready, verifier_passed, excluded_with_reason, superseded_snapshot, disputed_account, already_claimed.
• Avoid public verbs that imply external settlement unless that path exists: redeem, cash out, withdraw, bridge, swap, exchange, convert, liquidate, payout, claim dollars, guaranteed value.
• Avoid ambiguous nouns in API responses and pages: portable balance, redeemable token, cash value, off-ramp, bridge claim, external withdrawal.
• Every future preview page should include the snapshot id, ledger height, generated_at, verifier version, and explicit status reason. A user should know whether they are seeing eligibility evidence, a local verifier result, or an accepted maintainer decision.

Concrete acceptance tests for a future docs/UI/API bounty:

1. A restricted-wording test scans changed docs, API labels, UI strings, issue templates, bounty templates, and public help text for forbidden settlement/price/off-ramp language.
2. A positive fixture test proves the allowed vocabulary is still usable: snapshot, verifier, eligibility, preview, receipt, source account, destination account, nonce, proof hash, ledger height, exclusion reason.
3. Status-copy fixtures cover at least five cases: eligible GitHub account, eligible wallet account, stale snapshot, duplicate source claim, and disputed account. Each fixture must state what the UI/API should say and what it must not imply.
4. PR templates for future portability work require an explicit Non-goals section and a Public wording checked checkbox.
5. Any /claim or bounty response about portability should reject or request edits when it uses bridge/off-ramp/price language before a maintainer decision permits it.

Why this matters:

• A correct verifier can still create support and trust problems if users read "claim" as external redemption.
• Contributor comments can become de facto public documentation if they are linked from bounty issues.
• Future agents may scrape field names and page labels literally; ambiguous labels can propagate into wrong integrations faster than maintainer docs can correct them.
• A wording contract is cheap to test, easy to enforce in CI, and keeps the project from accidentally promising more than the current ledger supports.

Recommended follow-up bounty:

• Build a public wording/status fixture suite for MRWK snapshot and verifier work.
• Scope it to docs, API response labels, UI strings, issue templates, and claim templates.
• Acceptance should require deterministic tests plus before/after examples for the five claim-state fixtures above.

Decision this supports: maintainers can safely authorize snapshot/verifier/preview bounties while adding a CI-enforced public-communication guardrail that prevents accidental bridge, off-ramp, liquidity, price, or redemption promises.

[yannickvilleneuve-hash]

Bounty response: bounty policy

Policy focus: acceptance criteria for a future snapshot/claim verifier test bounty.

Assumptions:

• MRWK stays ledger-native unless maintainers publish a separate implementation decision.
• Current public truth is the MergeWork ledger, proof rows for bounty payments, account accepted-work summaries, and signed mrwk1 wallet actions with nonce protection.
• This policy does not propose a bridge, off-ramp, exchange path, price model, custody service, or external redemption promise.

Decision this supports:
Before bountying any portability implementation, maintainers can safely bounty an offline verifier/spec package. The artifact should prove that future claim eligibility can be audited from public MergeWork state without choosing any external settlement target.

Recommended acceptance criteria for that future verifier bounty:

1. The submission must define one canonical snapshot manifest shape. Required fields should include snapshot_ledger_sequence, snapshot_entry_hash, snapshot_created_at, source_api_base_url, export_tool_commit, claim_domain, account normalization rules, and an ordered list/hash of eligible claim rows.

2. The verifier must run offline against fixture files, not a live mutable API call. Live endpoints such as /api/v1/ledger, /api/v1/accounts/{account}, /api/v1/accounts/{account}/accepted-work, and /api/v1/proofs/{hash} can be used to build fixtures, but the accepted verifier result should be reproducible from checked-in JSON fixtures.

3. Every eligible row should bind the source account, destination identifier, amount in integer microunits, bounty/payment proof reference, and a deterministic nullifier such as a hash over claim_domain, snapshot hash, source account, destination identifier, and amount. The exact formula can change, but the bounty should require one stable formula and tests for it.

4. Required negative fixtures should include: proof after cutoff, non-bounty_payment proof, duplicated nullifier, amount mismatch, missing proof hash, account case/whitespace ambiguity, destination identifier ambiguity, stale manifest with the same sequence but a different entry hash, and replay of the same claim row.

5. Required positive fixtures should include: an unpaid github:* balance row, a linked mrwk1 wallet row, and an account with multiple accepted-work proofs whose total must equal the exported claim amount.

6. The verifier output should be a deterministic pass/fail report with row-level reasons. It should not require private keys, wallet signatures, OAuth cookies, deployment credentials, or maintainer-only database access.

7. Docs submitted with the verifier should use conservative wording: "snapshot eligibility" or "claim proof" is acceptable; wording that implies spendability outside MergeWork, guaranteed conversion, bridge availability, exchange listing, price, or cash-out should fail review.

What to reject:

• Verifiers that trust GitHub comments, issue labels, or contributor prose over ledger/proof state.
• Verifiers that fetch live state during validation without pinning a ledger sequence/hash.
• Artifacts that cannot produce the same result twice from the same fixtures.
• Any design that requires maintainers to accept external custody, external token deployment, or legal/compliance assumptions as part of a test bounty.

Why this is useful:
This gives maintainers a low-risk next bounty that improves auditability regardless of the eventual portability decision. If the future decision is "defer external portability," the fixtures and verifier still document the ledger invariants. If maintainers later choose a snapshot or claim path, the hard replay/cutoff/normalization cases are already pinned before any value-bearing integration work starts.