Problem
Neither Wave 5's (#4778) tradfi-rental scope nor Wave 5.1's (#6101) subnet-funded-pool scope currently has an issue defining how loopover/gittensor actually take a cut of a funded pool. #4804 (rate card) sets what a customer pays; this is a different question — how much of any given pool's funds/emissions the platform retains versus what flows to miners.
Area
Product spec / gittensor economics. Cross-cutting both funding tracks — filed against the parent Wave 5 epic since it isn't specific to either track's funding mechanism, with a cross-reference on #6101.
Proposal
Define, at spec level: whether the cut is taken from deposits (upfront, before any work happens) or from payouts (trailing, only on realized emissions/merged work), how it splits between the gittensor treasury and loopover, whether the percentage is fixed or configurable per-pool, and how it interacts with #4791's refund/partial-completion scenarios (does a refunded/cancelled pool return the cut too, or is it earned on deposit). Keep this at the mechanism/formula level, matching #4790's own precedent — the actual number is a business decision requiring explicit sign-off, not invented in this engineering/spec issue.
Deliverables
- A written spec covering: fee trigger point (deposit vs. payout), gittensor/loopover split mechanism, refund interaction, and whether/how the percentage is configurable.
Acceptance criteria
Resources
Boundaries
No concrete percentage, reward value, or wallet/hotkey material belongs in this issue — spec/mechanism only, matching #4781's and #6101's own boundary convention.
maintainer-only — cross-team economics decision, not a build task.
Problem
Neither Wave 5's (#4778) tradfi-rental scope nor Wave 5.1's (#6101) subnet-funded-pool scope currently has an issue defining how loopover/gittensor actually take a cut of a funded pool. #4804 (rate card) sets what a customer pays; this is a different question — how much of any given pool's funds/emissions the platform retains versus what flows to miners.
Area
Product spec / gittensor economics. Cross-cutting both funding tracks — filed against the parent Wave 5 epic since it isn't specific to either track's funding mechanism, with a cross-reference on #6101.
Proposal
Define, at spec level: whether the cut is taken from deposits (upfront, before any work happens) or from payouts (trailing, only on realized emissions/merged work), how it splits between the gittensor treasury and loopover, whether the percentage is fixed or configurable per-pool, and how it interacts with #4791's refund/partial-completion scenarios (does a refunded/cancelled pool return the cut too, or is it earned on deposit). Keep this at the mechanism/formula level, matching #4790's own precedent — the actual number is a business decision requiring explicit sign-off, not invented in this engineering/spec issue.
Deliverables
Acceptance criteria
Resources
Boundaries
No concrete percentage, reward value, or wallet/hotkey material belongs in this issue — spec/mechanism only, matching #4781's and #6101's own boundary convention.
maintainer-only — cross-team economics decision, not a build task.