Parked/speculative: tempo-level weight-setting as an external reward component

[JSONbored]

Problem

An alternative, deeper version of the subnet-funded model: instead of a separate settlement/pooling layer, fold the reward directly into a subnet's own tempo-level weight-setting as an external reward component. Tracked here explicitly so the idea isn't lost or silently re-invented later, and so it stays clearly separated from the buildable-now track.

Area

Product spec / protocol-adjacent. This is NOT the same kind of decision as the other three issues in this milestone — it touches actual Bittensor consensus/weight-setting mechanics, not just gittensor's own application-level infrastructure.

Proposal

No engineering proposal at this stage. This issue exists to record the idea and its status: explicitly more speculative and higher-risk/higher-reward than the pooling/settlement version, would need its own separate protocol-level conversation and alignment (likely with the gittensor subnet's own core team, possibly beyond just "sign off on a spec" the way #4781 frames it), and should not be started, scoped further, or estimated until that conversation happens independently of this milestone's other work.

Deliverables

• None yet. This issue's only job is to exist as a parking spot so the idea is discoverable and doesn't get silently dropped or rediscovered from scratch in six months.

Resources

• The core-mechanism issue in this same milestone (the non-protocol-level version of the same underlying idea)

Boundaries

Do not start work here. No spec, no design, no code, until an explicit separate green-light. This is the single highest-scrutiny item in this milestone — flag it to the user before any further movement, even scoping.

maintainer-only — parked/deferred, not itself a build task.

[linear-code]

JSO-4202

[JSONbored]

Problem

#6100 was parked with an explicit "do not scope this without a separate green-light." That green-light has now been given directly by the maintainer, specifically to research — not design or build — what tempo-level weight-setting as an external reward component would actually require, mirroring the spec-level treatment #6097 gave the pool-based approach. This is that research. It exists to inform a maintainer decision about whether to pursue this further, not to authorize any implementation, and it does not replace or supersede #6100's own parked/deferred status.

Area

Same as #6100: product spec / protocol-adjacent. Unlike #6097/#6098, this touches actual Bittensor consensus/weight-setting mechanics, not just gittensor's application-level infrastructure.

1. How this differs mechanically from #6097/#6098's pool model

#6097/#6098 describe a subnet funding a reward pool that AMS/ORB settle against through a separate settlement layer — money moves beside the subnet's existing weight-setting, after work is done and verified, and that settlement can be paused or corrected before it clears. "Folding the reward directly into weight-setting" is structurally different: instead of a separate payout, a validator's own scoring function — the code that produces the weight vector it submits via set_weights — gets extended with a term for "did this miner do gittensor-relevant work," and that term directly raises the miner's on-chain rank, which determines its TAO emission share for that tempo. There is no separate pool and no separate settlement transaction. The "payment" is the miner ranking higher in that tempo's Yuma Consensus epoch — and once emissions clear, it cannot be undone.

2. Can gittensor's own code do this, or does it need Bittensor-core involvement?

Split, and the split is the whole finding. Extending a validator's own scoring function to weight in an external signal before calling set_weights needs no protocol change — several live subnets already fold arbitrary off-chain signals into their own weight vectors this way, and "tempo" is just the chain-level epoch cadence, not a technical wall. So if the signal-holder already is (or becomes) a registered, staked, permit-holding validator on the gittensor subnet, gittensor's own validator/scoring code could plausibly encode this without touching Bittensor core.

But set_weights is a permissioned extrinsic — only staked, validator-permit holders can call it, enforced by the Subtensor pallet itself. No precedent exists for a genuinely external, non-validator party writing into the weight matrix directly. Getting that — an outside funder bypassing validator status entirely — would need a mainnet runtime change through Opentensor-level governance. So: "a validator adopts an external signal into its own weights" is gittensor-code-only; "an external party writes weights directly" is a Bittensor-core ask.

3. Honest risk assessment

This is meaningfully riskier than the pool model on three fronts:

• Gaming the weight signal. Once "did gittensor-relevant work" is a scoring input, it becomes a target for sybil or low-effort submissions optimized to trip the signal, with the payoff being ongoing emission share rather than a one-time bounty.
• Consensus/Yuma interaction effects. Yuma clips outlier weights to the stake-weighted median and tracks validator bonds over time; one validator overweighting this signal alone gets clipped and loses bond standing, while multiple validators encoding it inconsistently risks destabilizing consensus for the whole subnet — a correctness bug here doesn't just misprice one reward, it can distort real emissions.
• Irreversibility. A pool payout can be paused, clawed back, or corrected pre-settlement. A weight change that clears a tempo is final; there is no on-chain undo for emissions already distributed.

4. What a reasonable next step looks like

Not a technical spike, and not a spec. The dependency this research surfaces — validator-permit stake, bond dynamics, and the need for stake-weighted convergence — makes this a coordination question before it's an engineering one: a single validator encoding this alone just gets clipped into irrelevance by Yuma's median. The concrete next action is a scoping conversation with the gittensor subnet's own core team and validator operators (real stake, not gittensor's application layer) to gauge whether there is any appetite for a validator set to adopt a shared external signal at all. That conversation, not a testnet spike or a written spec, is the right-sized next step given what feasibility here actually depends on.

Boundaries

This is research, not a spec — no proposal, no deliverables, no implementation path, and no recommendation to build. #6100 remains parked; this writeup exists solely to give the maintainer a grounded picture for deciding whether the core-team conversation in §4 is worth having.

[JSONbored]

Hardening the boundary already stated above: this repo (and any gittensor-labeled work in it) never modifies third-party code directly — not Bittensor core, not the gittensor subnet's own codebase. Anything we build here can only ever be on our side of the integration (reading chain state, computing/reporting signals, calling existing subnet APIs) — never a change to consensus or weight-setting logic itself. That holds even if a future conversation with the subnet's core team green-lights the idea in principle: the deliverable would be our own integration code, not a patch to their repo.

Still parked per the boundary above — no scoping, no spec work, until that separate conversation happens.