When someone is first learning about Glow, they often ask why Glow has a token, and whether Glow would work better as a traditional business. To me, this always feels a bit like asking a sea turtle why they need to live in the sea instead of on land. The sea isn't just part of the turtle's name, it is fundamental to the animal's DNA.
Glow is like that as well. Glow was born as a token project, and every decision made while building Glow has been made with the intention of building the best possible token project. Removing the token from Glow would require rethinking nearly every aspect of the core business and the result would functionally be an entirely new company.
That said, Glow isn't magic. Its design decisions can be explained and justified, and I can give you a tour of all the features that make Glow work well as a token project. Before we dive in however, I would like to draw a distinction between 'token-native' projects and 'tokenization' projects, and to clarify that Glow sits comfortably in the token-native category.
Token-Native vs Tokenization
The blockchain offers developers a small but powerful set of new primitives for creating products that cannot easily be replicated outside of a blockchain environment. These primitives also come with unique sets of constraints, and token-native projects use first principles thinking to design new products using these primitives. Examples of token-native projects include Bitcoin, Ethereum, Filecoin, and Zcash.
Tokenization projects, on the other hand, look at concepts and ideas that already exist in the traditional business world and try to port these ideas into the blockchain ecosystem. Examples include most tokenized real-world assets, most tokenized lending, and even most blockchain prediction markets.
The difference is a matter of depth. Blockchain technology has a unique set of strengths and weaknesses, and that almost always means that doing something well on the blockchain requires completely rethinking the original product.
On-chain trading is a great example of this. In traditional finance, trading platforms almost always use order books. Blockchains however almost always use Uniswap-style AMMs. This is both because the automated nature of Uniswap allows it to be a better building block for more complex protocols, and also because Uniswap-style AMMs are more computationally efficient on-chain than order books.
The standard playbook for blockchain-based carbon credits is to tokenize existing carbon credits, bringing them on-chain as wrapped assets so that they can leverage the blockchain's natural ability to provide transparency and open market trading.
Glow however is a first principles re-imagining of what carbon credits could be, and leverages blockchain technology to make a new class of carbon credit that can't easily be replicated outside of the blockchain world.
Subsidizing Profitable Industries
Glow's most significant unique ability is that it can efficiently provide subsidies to industries that are already profitable. And before I explain how Glow does that, it's worth exploring why this is an interesting ability, and why that ability works better using tokens.
A common belief is that profitable industries do not need subsidies, because even without subsidies the industry will be able to sustain itself. And while that is true, an effective subsidy can improve the growth rate of that industry, which can be valuable if the industry has positive side effects.
For example, the solar industry is a profitable and growing industry that has the benefit of creating low-cost, highly sustainable energy. Once built, a solar installation can continue to produce energy for as many as 40 years with very little maintenance and upkeep costs. Especially as a growing compute industry puts strain on the electrical grid, a lot of people would like to see the solar industry grow faster.
Increasing the growth rate of a profitable industry is, however, easier said than done. To understand why, it can be helpful to imagine the solar industry as a world of potential solar projects with varying profitability. The vast majority of these potential projects are wildly unprofitable, and are therefore never pursued at all. Other projects are either almost profitable or barely profitable, and these are sometimes pursued. And the remaining set of potential projects are clearly profitable solar projects, which are widely pursued.
Almost axiomatically, nearly all of the solar projects that actually exist come from the pool of potential solar projects that are clearly profitable. This also means that if someone were to create a basic subsidy that rewards anyone who creates a solar project, the vast majority of that subsidy would be distributed to solar projects that are profitable even without financial help.
A better subsidy would exclusively target solar projects that are almost profitable, aiming to distribute just enough money to each project to bring it into the realm of barely profitable. This would maximize the number of net-new solar projects that the subsidy brings into existence, and would also increase the incentives for solar installers to think more deeply about potential solar projects on the edges of profitability.
When traditional platforms have attempted to restrict subsidies to only solar installations that are not independently profitable, the result has typically been a highly bureaucratic process that is vulnerable to complexity, delays, cheating, corruption, and often overlooks many ideal solar projects.
Glow on the other hand looks at the problem using a token-native perspective, asking how it might be possible to build a market-based solution where incentives naturally filter out clearly profitable solar projects and automatically distribute subsidies to the solar projects where the smallest amount of financial assistance can make the greatest net impact.
The Competitive Recursive Subsidy
The competitive recursive subsidy works by pairing two token-native ideas together, a "recursive" idea, and a "competitive" idea.
The competitive idea is drawn from Bitcoin. Glow uses a fixed pool of rewards and evenly distributes those rewards among everyone who constructs net-new solar, proportional to the amount of solar that they built.
This design works because it is fundamentally competitive, and it allows the market to set the rate at which rewards are distributed. If the rewards are generous, more solar installations will participate and that will automatically dilute the amount of rewards going to each installation. Conversely, if the rewards are stingy, fewer solar installations will participate and the amount of rewards going to each system will rise.
This design also has the result that every solar farm receives the same quantity of rewards, regardless of how expensive the solar farm was to build. This means that Glow not only targets solar farms on the fringes of profitability, it also disregards solar installations that could be profitable if the builders were more cost-efficient. Only the most cost efficient builders can effectively compete inside of the Glow protocol.
The recursive idea, as far as I'm aware, is completely novel to Glow. The recursive idea essentially says that Glow will distribute enough rewards to cover the cost of constructing a solar installation, however in return Glow receives all of the revenue that is generated by the solar installation.
This idea is highly effective in filtering out profitable solar farms. This is because Glow only pays just barely enough to cover the cost of construction, yet takes all of the revenue even if that revenue exceeds the cost of construction. This means that profitable solar farms automatically prefer not to participate in the Glow subsidy program, because they could make more money by keeping the revenue and profits that are naturally generated by their solar projects.
Both ideas are deeply token-native, especially when combined together. Within a token ecosystem, solar installers can onboard and compete permissionlessly, and the blockchain can efficiently collect revenues and distribute rewards according to a well defined and highly transparent set of rules.
I'm not even sure that it is feasible to build the competitive recursive subsidy outside of using blockchain, because the traditional finance system struggles when there are a large number of precise rules, and also when primitives need to be composed together.
Other Token-Native Advantages
Glow's core innovation is the competitive recursive subsidy, however tokens offer other advantages as well. For example, tokens tend to attract very high conviction users and community members, because the token gives people the ability to have ownership in the project in addition to using the product.
An adjacent benefit is that tokens give users the ability to participate simply because they believe in the vision, even if they don't need the product themselves. This is particularly beneficial for projects that solve societal problems such as global carbon dioxide emissions.
And, as a final example, Glow has really benefitted from the ability to start small and scale up over time. Glow's first solar installation was a relatively modest rooftop installation. If Glow had launched as a traditional subsidy product, it would have needed to land a large pilot using a highly novel product. Instead, the product can prove itself out at lower scales, build case studies, and pursue pilots with larger entities when the product is more proven.
Token Value
Though the exact mechanism that Glow uses to drive value to the GLW token is out of scope for this article, a common fear among people who are skeptical that the project needs a token is that the token will struggle to accrue long term value, and that it will collapse to zero as soon as people lose interest.
Glow has a straightforward answer to this problem. At the end of the day, Glow is essentially a factory that produces net-new solar installations. These solar installations are useful to people around the world, whether for improving grid stability, reducing grid congestion, reducing carbon emissions, or solving other energy related issues.
Glow collects revenue by selling the ability to control where its net-new solar installations are constructed, and also the ability to control the specific purpose that is targeted by the solar installations. The revenue is then used to increase the token value, using another deeply token-native technology called 'embedded liquidity'.
Does Glow Need a Token?
At this current point in time, I do not believe that Glow could be built as a traditional business. However, I have spent three years of my life thinking about Glow from a token-native perspective, and designing Glow to be a token-native product. The initial Glow product and the Glow product that exists today are worlds apart, and the journey was fundamentally a token-native journey.
If instead Glow had pursued its product as a traditional business, I don't know what would have happened or what innovations we would have come up with to move the product forward. All I know is that from the beginning, it felt clear that a traditional business product would substantially underperform a token product, and therefore Glow committed all the way to being token-native.