AdTAO SN21 makes its allocation curve tail switchable and dated

AdTAO SN21 has turned the decay of its ranked allocation tail into a published, switchable parameter with an effective date.

The September 9 code does not prove that a new value is active. If the operator leaves the configuration unset, the curve stays at its published 0.5 decay. An invalid value also falls back to 0.5. The repository tests a planned 0.8 curve and an announced September 15 switch date, but Tao Outsider has not verified either setting in production.

AdTAO also published a preview tool that runs the real allocation path against a copy of its ledger. The output compares each requested tail without writing to the live ledger.

This update belongs on the existing allocation-audit article because the mechanism, parameter record and daily vector form one system. The earlier work remains below.

Disclosure

Victor Lamenha and Tao Outsider have a professional relationship with AdTAO. That relationship receives no presumption of technical quality, production deployment or commercial performance. Repository behavior, project statements, subnet status and editorial interpretation remain separate throughout this article.

September 9 update: the tail becomes a dated control

AdTAO’s weight curve reserves fixed raw shares for the first three ranks, then applies a geometric decay to later positions. Under a decay of 0.5, each rank after third receives half the raw share of the position before it.

That curve becomes extremely thin near the bottom of a twenty-miner earning set.

The project’s test fixture calculates that rank one receives about 52.6% after normalization under the 0.5 tail. Ranks 11 through 20 share about 0.08%, and ranks 17 through 20 round to zero when translated to 16-bit chain weights.

The repository tests a 0.8 alternative on the same synthetic twenty-miner table. Rank one falls to about 40.29%, the top three share about 68.5%, ranks 11 through 20 share about 6% and all twenty positions retain a nonzero 16-bit chain weight.

Those numbers are code fixtures, not observed miner payouts. They isolate the effect of one curve parameter while holding the standing table constant.

The new environment fields are SN21_CURVE_TAIL_DECAY and SN21_CURVE_TAIL_EFFECTIVE_FROM. The validator assembles the curve in one function for the requested day. Before the effective date, it returns the published 0.5. On and after the date, it uses a valid configured value.

An important edge case is visible in the tests. A malformed date is treated as no date, so a valid configured decay applies immediately. That avoids a switch that silently never fires, but it also means operators need to validate the date before deployment. The code does not convert a bad date into a safe future hold.

The daily audit now records three fields: the tail in force, the configured value and the effective date. A later reader can identify which curve produced a day’s allocation instead of guessing from the current environment.

Previewing the vector without touching the ledger

The companion script accepts a day and a set of decay values. It copies the ledger, excludes bulky documents the allocation does not read and runs the same allocation function once for each requested tail.

Its table prints rank, hotkey, standing, share and the 16-bit chain weight. It also summarizes the top three, ranks four through ten, ranks 11 through 20 and the number of listed earners whose weight survives chain rounding.

The copy is deliberate. The allocation function persists promotion state and audit events, so running it directly against live data would turn a preview into a mutation. A copied ledger exercises the production code path while containing those writes.

That design reduces the chance that an operator evaluates one formula and deploys another. It still depends on the copied ledger, environment and code matching the production run.

The tool does not show that 0.8 is active, that a preview was reviewed by miners or that changing the tail improves prediction quality. It shows what the repository’s allocation code would produce from a specified ledger copy and parameter set.

A flatter tail changes who receives meaningful weight

Moving from 0.5 to 0.8 would distribute more of the normalized vector below the podium while preserving the raw ratios among the first three ranks.

That creates an explicit governance choice. A steep tail concentrates emission around the strongest standing. A flatter tail keeps more ranked miners above chain rounding and may give developing participants a longer earning runway.

Neither choice is automatically fair or productive. A flatter tail can pay more weak performers. A steeper tail can starve useful alternatives before the evidence is mature. The correct value depends on how noisy the scoring system is, how costly participation is and how much exploration the subnet wants to fund.

The code provides a controlled switch and an audit trail. It does not settle the policy question.

At TaoSwap block 9,032,783, AdTAO showed 15 active miners, 0.0213766% emission and 15.05455% miner burn. Those fields describe current subnet status. They do not reveal the tail parameter in force or prove that any September 9 code is deployed.

Two days later, the project fixed a related reporting error. On a day when the validator sets no new weights, the previous vector can remain active on chain. AdTAO’s report had treated that held day as if nobody were funded. The August 31 patch makes the report walk back to the most recent live allocation instead.

Together, the changes address a basic problem in Bittensor incentive systems. A leaderboard can show a miner that it received no new allocation without showing the group, control or previous vector that explains the result.

The repository now tries to expose that working.

The evidence comes from code and tests. Tao Outsider has not independently audited AdTAO production or verified that every daily document is complete, correct and publicly reachable.

September 6 update: one report was joining two different days

AdTAO published another correction on September 6 after its report could pair a prior live vector with newly recomputed control reasons from the current day.

The project recorded a concrete contradiction. Five of twenty rows could appear as both funded and excluded. The live vector still made those hotkeys eligible for subnet emission, while the attached note named a current-day control that would have removed them.

This was a reporting-state defect. The repository evidence does not show that the chain sent emission to the wrong hotkeys or that a weight vector was misallocated on chain.

The patch adds a live_allocation helper that selects one coherent source. If the current day has a non-empty vector, its earning set and control audit travel together. If the day is held, the report walks back to the most recent earlier vector that pays miners and uses the audit saved with that same vector.

New tests cover a paying day, a held day, earlier empty days and future-dated records that must not be borrowed. The fix makes the report describe one allocation state instead of combining the miners funded by one day with the reasons calculated on another.

Here, funded means eligible under the live Bittensor weight vector. It does not mean advertiser-funded, fiat-paid or backed by customer revenue.

The correction follows a September 5 standing amendment. AdTAO’s public artifacts now separate absolute accuracy from relative standing and rank. The daily curve can reach twenty placements after lineage and second-seat controls remove duplicates, so every hotkey with positive weight must appear as a funded row even when it falls outside a named tier roster.

Those changes improve the consistency of a public allocation report. Merged repository code does not prove that every production validator has run the new path or that every published report now matches live chain state.

The audit names who kept the seat

AdTAO’s validator applies controls before producing a daily allocation. The repository describes lineage grouping, a one-coldkey-one-seat rule and a minimum-tenure gate among those controls.

Until the August 29 commit, part of the audit existed inside the operator’s store and part appeared as a miner-specific line. A miner could learn that a rule had acted on its hotkey without seeing the full group or the hotkey that retained the earning seat.

The new /v1/daily/{day}/allocation-audit document is designed to close that gap.

For each detected group, it can publish the group type, the hotkey that kept the seat, the excluded hotkeys, the group size and the evidence recorded by the control. The document also carries the parameter version, whether a reference exemption was configured and the receipt from which the audit was derived.

The wording in the code is careful. It describes evidence, not accusation. A grouping result says a control detected a relationship under a named rule. It does not establish fraud, common ownership or malicious copying by itself.

That distinction matters when scoring rules act on identity and prediction similarity. A false grouping can remove a miner from the earning set. A public record gives the affected operator something concrete to contest.

The receipt is part of the claim

The audit points to the same day’s receipt.

That link makes the document more than a policy summary. A reader should be able to connect the published grouping to the predictions and controls used for the allocation.

The code also mirrors the allocation audit alongside the receipt. Its own comment explains that a grouping without the underlying daily evidence would expose an assertion rather than a checkable trail.

The tests pin several properties. The hotkey that retained the seat must appear beside the excluded hotkeys. Larger groups appear first. The parameter version and reference-exemption state remain visible. Missing controls should publish as missing rather than crash the entire document.

Those are useful software guarantees. They do not prove the underlying grouping model is accurate. A transparent rule can still be poorly calibrated, and a reproducible result can still be wrong.

A held vector can keep directing emission

The August 31 fix addresses a different but connected ambiguity.

AdTAO can hold a day when the available basket is too small to score a new allocation. In that situation, the validator publishes no new weight vector. The previous vector can remain in force and continue directing the subnet’s miner emission.

The report builder originally derived the earning set only from the current day’s intended weights. If that object was empty, the report showed an empty funded set.

That representation was misleading. It confused two conditions:

No new vector was created today.
No miner is funded by the vector currently active.

The patch searches backward through prior intended-weight files and finds the most recent non-empty allocation. On a held day, the report uses that set and explains that the previous vector remains live.

This does not prove a fiat payment. In this article, paid means eligible under the Bittensor weight vector that continues to govern emission. It does not mean a bank transfer, revenue share, profit or customer-funded payout.

The distinction affects what a miner sees. Deciding whether income stopped requires the current allocation state, while a log of the day’s transaction says only whether a fresh vector was sent.

Transparency is not the same as performance

AdTAO applies Bittensor competition to advertising-intelligence work. The project’s current X posts discuss Google Ads account patterns and future integration of miner predictions into its product.

The team also stated that Bittensor had not contributed revenue at the time of its August 30 post. It said existing products and services generated the current revenue, with miner value expected to enter the product later in September.

That statement prevents a common leap. A detailed validator audit does not prove customer adoption or product-market fit. It can improve confidence in how miners are selected while saying nothing about whether their predictions improve advertising outcomes.

The new endpoint should be judged first as incentive transparency. Does it let a miner reconstruct why a group was collapsed? Are parameter changes versioned? Can an operator dispute a false lineage match? Does a held-day report agree with the vector actually on chain?

Commercial value is a separate test. It requires evidence that the selected outputs change decisions and produce outcomes buyers will pay for.

A more contestable subnet

A subnet does not become accountable because it publishes a dashboard. Accountability begins when a consequential decision can be traced to a rule, input and version.

AdTAO’s allocation-audit code moves in that direction. The held-day correction is equally important because a transparent report that describes the wrong live state can create false confidence.

A TaoSwap snapshot captured at 10:04 BRT on August 31 showed 13 active miners for AdTAO SN21 and an emission_value of 0.000132936. The snapshot confirms active subnet status only. It provides no evidence that the audit works in production, that miners are profitable or that AdTAO has current subnet-derived revenue.

At block 9,009,564 on September 6, TaoSwap showed 15 active miners and an emission_value of 0.000103322. The later snapshot is another status checkpoint, not proof that the reporting correction ran across production validators.

The next proof is operational. Daily audit URLs should resolve, match receipts, match the live weight vector and survive disputed cases. Until that evidence accumulates, AdTAO has published a useful verification design and corrected one reporting mistake in public.

Publishing the correction gives readers more evidence than leaving the earlier report unexplained.

For earlier commercial context, read AdTAO SN21 puts revenue claims into Bittensor news.

Market map: DeMkt on Bittensor: AdTAO, Bitcast and Leadpoet