Design spec: subnet-funded reward-pool model (candidate answer to #4781)

[JSONbored]

Problem

No spec exists for a subnet-funded (rather than customer-funded) version of Rent-a-Loop: a Bittensor subnet funds a reward pool for its own GitHub repo, AMS discovers and does the work, ORB reviews/merges it. This is a candidate answer to #4781's open "reuse existing subnet emission/registration mechanics vs. separate escrow layer" question — this spec is the "reuse existing mechanics" branch, made concrete.

Area

Product spec / gittensor economics. Directly informs #4781's eventual decision; does not replace it.

Proposal

Define, at spec level:

• How this differs from gittensor's existing per-contributor reward flow (an individual miner earns for a PR on a registered repo) — here the funder is a subnet's own treasury/emissions, not gittensor's central pool, and the work is done autonomously by AMS rather than relying solely on human miners.
• What "registers with loopover" means concretely for a subnet (vs. an individual customer's registration in Neuron/hotkey registration flow #4789) — likely an extension of the existing repo-registration flow, not a parallel system.
• How AMS's existing discovery/claim/submit loop (Miner Wave 3 mechanics) applies unmodified to a subnet-funded repo, vs. what (if anything) needs to change.
• How ORB's existing review/merge authority model applies unmodified.
• Where this mechanism's settlement need meets the interface defined in the companion settlement-interface issue (don't re-derive settlement mechanics here — this issue is the funding/discovery/work model, not the money-movement design).

Deliverables

• A written spec covering the funding model, the extended-registration shape, and how it maps onto AMS/ORB's existing mechanics vs. what's net-new.

Resources

• gittensor rental economics spec #4781 (the open question this is a candidate answer to)
• Neuron/hotkey registration flow #4789 (individual customer registration flow, the closest existing precedent)
• The gittensor "register your repo, contributors earn" flow (gittensor.io/miners/repository)
• Miner Wave 3 (AMS discover→claim→code→submit loop mechanics)

Boundaries

Spec only — no infrastructure, no pricing/reward figures (business decision, downstream of this and #4804-equivalent), no wallet/hotkey material. Requires eventual gittensor subnet-side sign-off before any implementation, same bar #4781 itself sets.

maintainer-only — planning/decision issue, not itself a build task.

[linear-code]

JSO-4199

[JSONbored]

Core-mechanism spec (resolved 2026-07-15)

A candidate answer to #4781's open question, not the binding decision — #4781 stays the actual sign-off issue. Grounded in what already exists rather than a green-field design.

How this differs from gittensor's existing per-contributor reward flow

Today's registration model (RegistryRepoConfig: emissionShare, issueDiscoveryShare, maintainerCut) is entirely per-repo, with no pool or funder entity above it — a repo's contributors earn a share of ongoing subnet emission, funded passively by the subnet's own emission schedule, not by an explicit deposited balance. This track adds a standing funded pool as a new entity above the existing per-repo config: a subnet deposits/commits a reward budget for a specific repo it owns, and that pool — not raw emission share — is what AMS's completed work draws against and what #6098's SettlementBackend.recordPayout decrements. The existing emission-share mechanism is untouched; this is an additive funding source layered on the same repo, not a replacement.

What "registers with loopover" means for a subnet

Extends the existing repo-registration front door (gittensor.io/miners/repository) rather than building a parallel entry point — read the existing flow's real shape before assuming this holds; if the current registration UI has no natural extension point for "attach a funded pool to this registration," that's the one thing this spec doesn't get to assume and #6099 (subnet-onboarding spec, blocked on this issue) resolves it. What's new is a pool identity (poolId, per #6098) tied to the existing repo registration — the subnet is the funder/owner of the pool, the repo stays the same registration unit it already is today.

AMS's discovery/claim/submit loop applies unmodified

Discovery (opportunity-fanout.js) operates purely on {owner, repo} targets via GitHub's public APIs — it has no concept of, and needs no concept of, who funds the repo's rewards. A subnet-funded repo is discoverable, claimable, and submittable through the exact same mechanics Miner Wave 3 already ships (soft-claim ledger, portfolio queue, submission gate) with zero code change. The funding model is orthogonal to discovery/claim/submit by construction — the only new step is after a PR merges: the payout-eligible event (#6098) fires against the repo's pool instead of (or alongside) organic emission share.

ORB's review/merge authority model applies unmodified

ORB reviews and merges PRs against a subnet-funded repo through the same per-repo gate/autonomy configuration every other registered repo uses (RepositorySettings, the autonomy dial). A subnet-funded repo is not a special trust tier — the review bar that decides whether a PR merges is identical regardless of what pays for it. #4782's third-party-autonomy governance spec's conservative-default rule still applies if the subnet delegates any acting autonomy; nothing here loosens it.

Where this meets the settlement interface

On PR merge against a subnet-funded repo, the resulting LoopConsumptionEntry (#4792, unmodified) is wrapped into a PayoutEligibleEvent (#6098) carrying the pool's poolId, and handed to whichever SettlementBackend is live. This spec does not re-derive settlement mechanics — #6098 owns that boundary.

Non-goals

• No pricing, reward-formula, or emission-share numbers (inherits gittensor rental economics spec #4781's boundary).
• No wallet/hotkey material.
• No decision on gittensor-owned vs. self-built settlement backend (Design spec: settlement-backend interface (gittensor-owned or self-built, pluggable either way) #6098's interface stays agnostic to that; this spec doesn't pick a side either).
• No implementation — spec only, per this issue's own scope.

Next step

#6099 (subnet-level onboarding & registration flow) is the natural follow-on now that this mechanism is roughly settled — wiring it as blocked-by this issue, matching #6101's own stated sequencing.