Problem
RepoPoolAssociation (src/types.ts:447) requires a subnetId and is scoped to Wave 5.1's subnet-funded pool model (#6099/#6320). A Wave 5 customer-funded pool (any project, not necessarily a Bittensor subnet, per #4778's "two demographics" framing) has no data-model representation — subnetId is meaningless for a paying customer that isn't itself a subnet. Both pool types pay out to gittensor-registered contributors as emissions (confirmed 2026-07-21 — a funded pool's payout mechanism is inherently gittensor-native regardless of funding source); this is purely a data-representation gap, not an economics question.
Area
src/types.ts, #6098/#7573's cluster.
Proposal
Add a separate type for customer-funded pools, parallel to RepoPoolAssociation rather than overloading it with an optional subnetId — keeps subnet-funded and customer-funded pools structurally distinct (different funding source, same payout mechanism) rather than conflating two conceptually different things in one type.
⚠️ Required pattern — read src/types.ts:447's RepoPoolAssociation/RegistryRepoConfig.poolAssociation and #6320's PR diff before starting. The new type and its threading must mirror that exact convention (optional, absent = today's behavior byte-identical, same null-safety style). A PR that overloads RepoPoolAssociation with an optional subnetId instead of adding a separate type does not satisfy this issue.
Deliverables
Resources
Boundaries
Data-model/type work only — no settlement mechanism, no reward figures.
Contributor-eligible. Mirror #6320's exact pattern — this is type/plumbing work with a proven precedent, not open economics design.
Problem
RepoPoolAssociation(src/types.ts:447) requires asubnetIdand is scoped to Wave 5.1's subnet-funded pool model (#6099/#6320). A Wave 5 customer-funded pool (any project, not necessarily a Bittensor subnet, per #4778's "two demographics" framing) has no data-model representation —subnetIdis meaningless for a paying customer that isn't itself a subnet. Both pool types pay out to gittensor-registered contributors as emissions (confirmed 2026-07-21 — a funded pool's payout mechanism is inherently gittensor-native regardless of funding source); this is purely a data-representation gap, not an economics question.Area
src/types.ts, #6098/#7573's cluster.Proposal
Add a separate type for customer-funded pools, parallel to
RepoPoolAssociationrather than overloading it with an optionalsubnetId— keeps subnet-funded and customer-funded pools structurally distinct (different funding source, same payout mechanism) rather than conflating two conceptually different things in one type.Deliverables
RepoPoolAssociation.RepoPoolAssociationalready touches, mirroring Extend the repo-registry data model to support subnet-funded pool association #6320's own precedent.Resources
src/types.ts:447(RepoPoolAssociation, the subnet-funded precedent)RepoPoolAssociation— use its call-site list as the checklist)Boundaries
Data-model/type work only — no settlement mechanism, no reward figures.
Contributor-eligible. Mirror #6320's exact pattern — this is type/plumbing work with a proven precedent, not open economics design.