Spec: external-subnet-funded development-incentive pools (alternate to per-customer Rent-a-Loop payment)

[JSONbored]

Problem

Today, the Rent-a-Loop model (this epic, #4778) frames external value flowing into gittensor development purely as a single customer paying (fiat or stake) for allocated compute-time — see #4781/#4790's payment-to-compute-time conversion. A structurally different mechanism is worth designing alongside it: an external Bittensor subnet (not an individual paying customer) contributing a portion of its own native subnet-token emissions to fund a dedicated development-incentive pool, in exchange for that subnet's own GitHub repositories becoming eligible development targets for gittensor miners.

This is a different economic shape than #4781/#4790's per-customer payment model — it's a recurring, token-denominated inflow from a subnet's own emissions rather than a one-time payment or stake conversion — and needs its own mechanism-level spec, informed by but not identical to the existing rental-economics work.

Area

Product spec / gittensor economics (same category as #4781) — mechanism design, not implementation.

Proposal

Define, in collaboration with the gittensor subnet side (not as a solo engineering decision, matching #4781's own stated collaboration requirement), the mechanism by which:

• An external subnet's own token emissions can be routed into a dedicated development-incentive pool for gittensor miners.
• That subnet's repositories become eligible/prioritized development targets in exchange.
• The pool's distribution to miners follows the same underlying scoring/reward mechanics gittensor already uses for its native emissions, rather than inventing a second parallel reward system.

Keep the spec at the level of mechanism and process — this issue is not the place to fix concrete allocation splits, specific subnet partners, or reward formulas; those are downstream business decisions made elsewhere (informed by, but not contained in, this spec — matching #4781's own boundary).

Deliverables

• A written spec covering: how an external subnet's token contribution is received/custodied, how it's converted into a miner-facing incentive pool, and how eligible repos get identified/prioritized as a result.

Acceptance criteria

• Spec has explicit sign-off from the gittensor subnet side, not gittensory engineering alone (same requirement as gittensor rental economics spec #4781).

Boundaries

• No hardcoded allocation splits, specific subnet/partner names, wallet addresses, or hotkey material belong in this spec or its issue thread — any such detail lives in the private planning project only, not here.
• This is a cross-team decision — do not begin implementation until this has explicit subnet-side agreement, matching gittensor rental economics spec #4781's own precedent.

---

Part of #4778.

[linear-code]

JSO-4318