Design spec: subnet-level onboarding & registration flow (extends #4789's individual-customer pattern)

[JSONbored]

Problem

#4789 (Neuron/hotkey registration flow) specs how an individual customer's rented compute-time gets registered. A subnet funding its own pool for its own repo is a different registrant shape: a subnet, not an individual, and the thing being registered is a standing funded pool tied to a repo, not a one-off compute-time allocation.

Area

Product spec / gittensor economics. Extends #4789's pattern rather than replacing it.

Proposal

Define, at spec level, how a subnet-level registration differs from #4789's individual-customer flow:

• What identifies "this subnet" vs. "this repo" vs. "this pool" as distinct, related entities.
• Whether this reuses gittensor's existing repo-registration flow (gittensor.io/miners/repository) as the front door, with pool-funding as an added step, or needs its own entry point — read the existing flow's actual current shape before assuming either.
• What a subnet needs to provide to stand up a pool (repo identity, funding source, any scope constraints on what AMS is allowed to touch) — mirrors the kind of boundary Third-party autonomy & security governance spec #4782's governance spec already defines for third-party-repo autonomy generally; don't re-derive that here, reference it.
• How pool state (funded, active, exhausted, paused) is surfaced back to the subnet — read-only reporting shape, not the settlement mechanics themselves (#[settlement-interface issue]'s job).

Deliverables

• A written spec for subnet-level registration, cross-referencing Neuron/hotkey registration flow #4789 (individual pattern), Third-party autonomy & security governance spec #4782 (autonomy/governance boundary), and the settlement-interface issue (where pool state actually lives).

Resources

• Neuron/hotkey registration flow #4789 (individual customer registration, the closest existing precedent)
• Third-party autonomy & security governance spec #4782 (third-party autonomy & security governance spec — the boundary this must respect)
• The gittensor repo-registration flow (gittensor.io/miners/repository)

Boundaries

Spec only. Depends on the core-mechanism issue being roughly settled first (this issue defines the registration shape, that one defines what is being registered and why). No wallet/hotkey material.

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

[linear-code]

JSO-4201

[JSONbored]

Design spec (resolved 2026-07-16)

Grounded in the actual current registration data model, not a green-field design — checked RegistryRepoConfig (src/types.ts) and normalizeRegistryPayload (src/registry/normalize.ts) before proposing anything: registration today is entirely repo-keyed ({ repo: string, emissionShare, issueDiscoveryShare, labelMultipliers, maintainerCut, ... }, one flat entry per repo, no grouping entity above it). "Subnet" doesn't exist anywhere in the current schema — this spec's job is defining that new entity without breaking the existing flat structure everything else already depends on.

Entity model

• Repo — unchanged: RegistryRepoConfig.repo, the same key every registered repo already uses.
• Subnet — new: an identifier for the funding party, distinct from any one repo. A subnet may fund pools for more than one of its own repos; a repo stays registered exactly as it is today whether or not a pool ever attaches to it.
• Pool — poolId (Design spec: settlement-backend interface (gittensor-owned or self-built, pluggable either way) #6098's SettlementBackend interface already assumes this exists) — the entity that actually links a subnet to a repo: one subnet, one repo it owns, one funded balance. A repo can have at most one active pool at a time (no ambiguity about which pool a payout event draws against).

Front door: extend the existing flow, don't parallel it

Reuses gittensor.io/miners/repository's existing repo-registration entry point as the base — the registration unit stays "one repo," identical to today, because RegistryRepoConfig is already repo-keyed and a subnet registering its own repo is structurally the same operation any repo owner performs today. Pool-funding is an additional step attached to that same flow, not a second entry point: after the existing repo-registration fields, a subnet-funded registration adds the pool identity and initial funding commitment. This keeps the existing registration UI/data model the authoritative source of "this repo is registered" for every repo regardless of funding source — Wave 5.1 doesn't get a competing definition of registration, it adds one optional attachment to the one that already exists.

(This spec can describe the data-model extension precisely; it can't verify the actual current gittensor.io UI's literal field layout from here — that's a product/UX check for whoever implements the front-end step, not something to assume from this issue.)

What a subnet provides to stand up a pool

• Repo identity — the existing registration's own repo key, nothing new.
• Funding source — the pool's initial balance/commitment. Mechanism (how tokens/value actually move into the pool) is Design spec: settlement-backend interface (gittensor-owned or self-built, pluggable either way) #6098's SettlementBackend's job, not re-derived here.
• Scope constraints — reuses Third-party autonomy & security governance spec #4782's existing per-repo autonomy dial (AutonomyPolicy, AGENT_ACTION_CLASSES) exactly as any registered repo's owner already configures it today. A subnet funding a pool is not a new trust tier or a new autonomy mechanism — it's the same dial, set by the subnet instead of an individual repo owner. Default stays observe per Third-party autonomy & security governance spec #4782's own conservative-default rule.

Pool-state reporting

Read-only, surfaced from #6098's SettlementBackend.getPoolBalance(poolId) — { remaining, exhausted } — directly. No new reporting mechanics: whatever dashboard surface eventually exposes this to a subnet reads the same interface #4792's future ledger-persistence work (#6314) writes through. funded/active/paused states are derived, not separately stored: funded = pool exists with remaining > 0, active = the repo has at least one un-exhausted pool, paused = the repo's autonomy dial (above) is set to observe on every action class despite a funded pool existing (an explicit choice, not an error state).

Non-goals

• No UI/front-end implementation.
• No settlement mechanics (owned by Design spec: settlement-backend interface (gittensor-owned or self-built, pluggable either way) #6098, already resolved).
• No pricing/allocation numbers, wallet, or hotkey material.