A buyback announcement is an easy post to like. Someone used money to buy your subnet’s alpha. Then they burned it.
So when Tao Outsider questioned Bittensor’s enthusiasm for buyback and burn on September 26, I agreed with the uncomfortable part: a burn tells us very little about whether a business can keep its customers.
This is a response to Victor’s commentary on Tao Outsider, the publication carrying this column.
But I think the community deserves a better hearing, too. If a subnet builds a successful product, holders want to know how that success reaches the token they supported. Asking for that connection is reasonable. A promise to reinvest everything can become just as convenient as a burn announcement.
My question is where the next dollar does the most useful work, and who gets to check the answer.
Lium gives the argument something concrete
On May 4, Lium, the GPU marketplace on Bittensor SN51, said it had bought back and burned more than $150,000 of SN51 tokens using money from platform credit purchases. The team described buying the tokens with those funds and then burning what it bought.
That is a specific, attributable business claim. It connects a customer payment to a token purchase and a subsequent burn. Readers can ask for evidence at each step. Lium’s announcement.
I understand why holders like this arrangement. Buying alpha and removing it means those particular tokens cannot later become a treasury sale. It also gives the team a public commitment against which people can judge its behavior.
The question I would add is what happens before that money becomes available. Credit purchases bring cash in, while fulfilling GPU demand consumes resources. How much service remains to be delivered? Who covers the hardware, electricity and support? How much depends on emissions?
These are questions about the economics, not allegations about Lium. A customer payment and a sustainable margin tell different parts of the story.
There is another useful detail in Lium’s reward documentation. It describes a burn pool whose share changes with activity in the unrented pool. As that activity increases, the burn allocation can shrink.
In that mechanism, a smaller burn can accompany more eligible unrented capacity receiving rewards. It does not by itself establish greater rental demand. Imagine judging it through a leaderboard where the largest burn automatically wins.
Bitcast makes the allocation visible
Bitcast, Bittensor SN93, publishes a revenue dashboard separating revenue, buybacks and their ratio, alongside transaction entries.
These are project-reported figures, rather than audited earnings. The dashboard does not establish what happened to the repurchased alpha. Showing revenue and buybacks separately gives readers a starting point for examining capital allocation.
How do the reported receipts reconcile with spending, obligations and reserves?
Subtracting buybacks from revenue does not establish what remains available or where it went. I want teams to explain their operating costs and retained capital with the same enthusiasm they bring to the repurchases.
Our earlier Bitcast coverage examined its application infrastructure. For me, that product work belongs in the same conversation as token policy. A better product may bring tomorrow’s paying customer. Burning today’s receipts cannot substitute for that work.
Please stop putting every burn in the same bucket
A buyback purchases tokens. A burn removes tokens. A project can do either without doing both.
Using customer receipts to acquire alpha has a different funding source from using a treasury balance or emissions. Redirecting emission rewards into a burn mechanism is another decision again. Locking tokens restricts access to them; it does not destroy them.
Vanta’s SN8 documentation offers a further example: its miner scoring description sends excess weight to a burn address after calculating rewards. That mechanism should not be presented as evidence that outside customers funded a market purchase. Vanta’s miner documentation.
Even a recorded burn leaves several questions open. Where did the tokens come from? What funded their purchase? What else is being issued? Can the business repeat the exercise without weakening its operations?
I would rather understand those answers than compare dollar totals produced with different methods and prices.
Where I push back on Tao Outsider
Victor’s original post argues that teams need enough trust to retain money and build. I agree. But the case for reinvestment needs specifics.
Hiring whom? Building what? With how much runway? What result should we expect, and when will the team explain whether it worked?
Holders should be able to ask those questions without being dismissed as impatient. Equally, a developer salary should not become suspicious merely because the same money could have bought alpha.
My preference is a published capital policy with room to change: what funds operations, what stays in reserve, what goes toward growth and what triggers buybacks. Then report what actually happened. A young subnet and a mature service will reasonably make different choices.
I like a burn I can trace. I also like a team that can explain why this month’s cash is paying for something more valuable than a burn announcement. Both need receipts.
About this analysis
This column discusses disclosed mechanisms and capital allocation. The Lium example is a dated team statement; Bitcast’s figures are its own dashboard totals. Neither establishes audited profitability, and this article does not independently reconcile their full cash flows. Documentation describes mechanisms, rather than proving every current on-chain setting. No price outcome is implied.
Sources
- Tao Outsider’s September 26 commentary
- Lium’s May 4 buyback and burn announcement
- Lium subnet emission documentation
- Bitcast revenue and buyback dashboard
- Vanta miner scoring documentation
Was this article useful?
One tap feedback helps us improve each post.
