Insights from Inside the Network

The Innovation Game is a decentralised network where algorithms compete to solve hard optimisation problems across seven challenge categories. The best algorithms earn $TIG tokens. Companies that want to use those algorithms commercially, without sharing their own data back to the network, pay a fee in $TIG. Post-Tranche 5, that fee revenue becomes the entire basis of the network's reward system for the participants who produce and run those algorithms.

There is a thought experiment worth sitting with.

A company running a logistics operation spends $2 million a year optimising delivery routes with proprietary software. Then an open, competitive protocol publishes an algorithm that solves the same vehicle routing problem better, faster, and demonstrably cheaper to run. The company wants to use it commercially. The protocol says: you can, for a fee, paid in $TIG.

That fee is not a one-time purchase. Based on how TIG's post-emission tokenomics are structured, it almost certainly recurs. And every time it recurs, the company's treasury needs to acquire $TIG first.

II. How the License Actually Works

TIG operates under a dual licensing model. The Open Data License is free: companies can use TIG algorithms provided they share their data and improvements back to the network. For organisations that cannot or will not disclose their data, the Commercial License offers full proprietary rights in exchange for a fee paid in $TIG.

If commercial license fees were a one-time payment, the reward mechanism would collapse after emissions end. The tokenomics require recurring flows. The protocol was designed with the implicit assumption that companies do not just pay once to use an algorithm and then own it forever. The license, structurally, functions more like an ongoing fee arrangement than a one-time purchase of perpetual rights.

TIG has not published a public fee schedule or confirmed a per-unit royalty structure. The exact mechanism is not yet documented at the level of detail that would allow precise financial modelling. This ambiguity matters and will be addressed directly in the section on risks.

III. The ARM Parallel

ARM's licensing model has two components, and the distinction is worth understanding precisely because most people conflate them.

The first is the upfront architecture license: typically $1 million to $10 million, paid once, which grants the licensee the right to implement an ARM design in their product. The second is the per-chip royalty: roughly 1 to 2% of the chip's sale price, paid on every unit that ships containing ARM IP. The upfront fee is one-time. The royalty is ongoing and perpetual, flowing for as long as the chip ships.

The reason the ARM parallel is not just instructive but precise is Phil David. He held the role of Senior Vice President of IP and Deputy General Counsel at ARM while the modern royalty infrastructure was being built and refined. He now holds the I.P. and General Counsel position at TIG Foundation. The team building TIG's licensing architecture is not modelling itself on ARM. It is led by someone who spent two decades inside the company that made that model work at global scale.

ARM's gross margins have historically run above 94%. Once the IP is created, the marginal cost of licensing it again is near zero. The royalty income compounds without meaningful additional R&D spend per licensee. This is the moat: better architecture, adopted early, embedded permanently in supply chains that take a decade to change.

TIG's model maps more closely to ARM's royalty leg than its upfront license leg. The value is not in selling access once and walking away. It is in generating recurring fee income from every company that continues to run TIG algorithms commercially, for as long as those algorithms remain the best available solution to the problem.

IV. The Flywheel Case

ARM's genius was a self-reinforcing adoption loop. More licensees meant more chips shipped, which meant more royalties, which funded R&D, which produced better IP, which attracted more licensees. The cycle became structurally very difficult to break once it had momentum.

TIG's theoretical equivalent runs through the OPoW mechanism. More commercially valuable challenges attract more Innovators, producing better algorithms. Better algorithms attract corporate licensees. Corporate license fees are paid in $TIG, which sustains Innovator and Benchmarker rewards, which attracts more participants, which produces better algorithms.

The current Tranche 3 phase (25 TIG per block, approximately 16 months to the next halving) is essentially a subsidy to build that IP base before commercial fee revenue needs to sustain the network independently. The Tranche schedule is a countdown, not a guarantee. It creates urgency for TIG Foundation to develop commercial licensing infrastructure and close early deals while the emissions subsidy still provides income for participants.

V. The Bear Case

This is where the thesis requires honest scrutiny. Several structural risks deserve direct engagement, not footnotes.

The most fundamental: no TIG commercial license has been publicly signed. Every element of the analysis above describes a mechanism that has been designed but not yet tested at scale. Having the right architect matters. It does not guarantee adoption. ARM is a 35-year-old company with a proven track record across hundreds of billions of chips. TIG is a protocol that launched in 2024. The distance between a compelling design and a functioning commercial IP business is measured in years, not months.

The enterprise adoption lag is real and should not be minimised. ARM documented that the typical timeline from obtaining a design license to the first revenue-generating product shipment runs 3 to 4 years. Commercial algorithm licensing will likely follow a similar cycle: budget approval, vendor qualification, legal review of license terms, integration engineering, internal pilots, production deployment. A company with genuine enthusiasm for a TIG algorithm and the budget to license it commercially could easily still take two to three years to generate a single fee payment. The commercial license revenue that post-Tranche 5 tokenomics depend on may not materialise before emissions decline significantly.

The token-as-payment mechanism introduces friction that ARM never faced. ARM's royalties are denominated in dollars. A chip manufacturer's CFO can model ARM royalty costs with precision across a multi-year product roadmap. A company paying commercial license fees in $TIG must first decide it is comfortable acquiring and holding a volatile token, managing the treasury implications, and explaining the purchase to a board that may have a policy against crypto exposure. For large, regulated enterprises, this is not a trivial obstacle. It does not make the model non-functional. It makes the sales cycle longer and more complex than a dollar-denominated license would be.

The open-source displacement risk is structural. ARM's position has been challenged by RISC-V precisely because RISC-V is free and requires no license. TIG's Open Data License serves a similar function: it gives users a no-cost path in exchange for sharing data back to the network. The question is how many commercial applications genuinely require data privacy, which is the condition that drives companies from the free license to the commercial one. If the majority of TIG algorithm users can operate under the Open Data License terms, the commercial fee revenue pool is smaller than the total addressable market implies.

Algorithm quality is not guaranteed to remain competitive. TIG's commercial value depends entirely on its algorithms being the best available solutions to the problems in its challenge set. The OPoW mechanism is designed to ensure this through competitive benchmarking, but there is no guarantee that the best external researchers participate in TIG. A team that builds a superior vehicle routing algorithm but does not submit it to the protocol does not contribute to TIG's commercial licensing IP. The protocol creates incentives to participate. It cannot compel it.

VI. What the First License Changes

The question that converts this from theoretical to real is a specific one: which algorithm, used by which company, generates the first publicly disclosed commercial license fee paid in $TIG?

The answer does not have to be large to matter. ARM's first significant royalty was not from Apple or Qualcomm. It was from smaller-volume deals that proved the mechanism worked. A mid-size logistics company publicly disclosing it has licensed TIG's vehicle routing algorithm for its delivery fleet is, in terms of market signal, worth more than any amount of tokenomics documentation.

It changes the investor calculation from "this is how the model is designed to work" to "this is a company with a real budget that calculated TIG algorithms save them enough money to justify a recurring fee and the complexity of a token-denominated payment." That is a qualitatively different category of evidence.

The challenges where commercial licensing seems most plausible are those where the cost of suboptimal solutions is measurable and large. Vehicle routing is the obvious candidate: the global logistics industry spends tens of billions of dollars annually on routing optimisation. A 3 to 5% improvement in route efficiency at scale is worth millions to a large operator, which makes a five or six-figure annual TIG license fee economically rational. Job scheduling optimisation and knapsack-class supply chain problems are commercially viable in a similar way.

The challenges where commercial licensing is harder to monetise are those where the primary value is in running computations rather than owning the output. Vector search and hypergraph partitioning have strong enterprise software applications, but the licensing conversation is more abstract because the value is less directly measurable in operational cost savings.

VII. The Price Mechanics

Understanding why this comparison specifically favours $TIG token holders (as opposed to just protocol participants) requires being precise about the mechanism.

ARM earns royalties. Those royalties increase ARM's revenue and, over time, its valuation. An ARM shareholder benefits through share price appreciation and dividends. The analogy for investors is ARM the stock, not ARM the royalty itself.

TIG's structure is different. There is no company capturing the royalties. The commercial license fees paid in $TIG are distributed to network participants, sustaining the rewards that keep Innovators and Benchmarkers contributing. But the demand for $TIG that commercial license fees create is real and unconditional. A company that needs $TIG to pay a license fee must go to the open market and acquire it. If more companies are doing this simultaneously, and the token supply is fixed, the price rises.

This is, structurally, a stronger price mechanism than almost any other crypto token design. Most token demand is speculative or governance-related. TIG's commercial license demand is operational: companies acquire $TIG because they need it to run algorithms that save them money. That is not speculation. It is a cost of goods.

The caveat is scale. For this mechanism to materially affect $TIG price, commercial license revenue needs to be large relative to the token's market cap. At approximately $1.15 per token and a total supply cap of 131 million, the protocol's fully diluted valuation is modest. Even several hundred thousand dollars per year in commercial license fees would represent a meaningful demand signal at current scale. Meaningful, not transformative. Transformative requires tens of millions in annual recurring fees, which requires dozens of enterprise deployments, which requires the adoption cycle to have progressed significantly from where it is today.

VIII. The Long View

The standard crypto project promises that a token will appreciate as the network grows. The mechanism is usually vague: more users, more activity, more demand for the token. The connection between network activity and token demand is often tenuous in practice.

TIG's commercial licensing model, if it works as designed, offers something more specific. Every enterprise that licenses a TIG algorithm commercially creates a recurring demand obligation for $TIG. The obligation persists as long as the company uses the algorithm. It compounds as the company grows. It is not correlated with crypto sentiment cycles. It is correlated with whether the algorithms actually solve real problems well enough to justify the cost.

It is not making a bet that a token goes up. It is making a bet that algorithms produced by an open, competitive network, refined continuously through proof-of-work economics, will be commercially competitive with algorithms produced by proprietary R&D teams with significantly larger budgets. If that bet is right, the token becomes the mechanism through which that commercial value is captured.

ARM made a similar bet about hardware IP in 1990. The answer took 30 years to become fully visible. The person now building TIG's licensing infrastructure was inside ARM for much of that journey.

TIG's answer may arrive faster because the technology cycle in AI is compressed relative to the chip design cycle. Or it may arrive more slowly because enterprise software adoption has its own pace regardless of how fast the underlying technology moves. The timeline is genuinely uncertain.

What is less uncertain is the structure. The mechanism exists and was deliberately designed by someone who has built it before. The challenge now is execution: closing commercial deals, maintaining algorithm quality through competitive benchmarking, sustaining the Innovator and Benchmarker base through the transition from emission-funded to fee-funded rewards, and doing all of this in a market that will remain sceptical until the first license is publicly verifiable.

The token is not a bet on that mechanism existing. The mechanism exists. The token is a bet on whether enterprises will choose to use it. That is a more specific, more honest, and ultimately more useful question to be asking about $TIG.

I. The Mechanics of OPoW

In TIG, participants called Benchmarkers run algorithms against benchmark instances, which are specific instances of the challenge problems. Each benchmark instance has a known difficulty, and the algorithm's solution is scored against a performance threshold. A solution that meets or exceeds the threshold is called a qualifier. Qualifiers are submitted to the network, verified, and entered into a weighted random draw for block rewards. Solutions that fall below the threshold earn nothing, regardless of how much hardware was consumed running them.

The word "Optimistic" in OPoW refers to verification: the network does not verify every solution cryptographically in real time. Instead, it accepts solutions optimistically and relies on economic incentives and spot-checks to deter fraud. This is how the system can process high volumes of benchmark submissions without becoming a verification bottleneck.

The fundamental difference from Bitcoin is this: in Bitcoin, difficulty is set so that finding a valid hash is computationally expensive but the hash itself has no extrinsic value. In TIG, the difficulty threshold is set against problem-solving quality. A solution that qualifies is genuinely a better solution to a genuine optimisation problem. The work produces something real, and the best work earns disproportionately more.

II. Why NP-Hard Problems, Specifically

All seven of TIG's current challenge categories are NP-hard problems. This is not an accident.

NP-hard problems are those for which no known polynomial-time algorithm exists. They get exponentially harder as their size grows. For practical purposes, this means that for real-world instances of meaningful size, exact optimal solutions are computationally infeasible. The question is not whether you can find the perfect answer. The question is how close you can get, and how fast.

This matters for two reasons. First, it means that algorithm quality genuinely determines output quality. A smarter algorithm on a mid-range GPU will consistently outperform a naive algorithm on the most powerful hardware available. The improvement ceiling is not set by hardware. It is set by the state of the art in algorithmic research. Second, it means the problems are not arbitrary. Vehicle routing, knapsack optimisation, graph partitioning: these are the canonical problems underlying logistics operations, supply chain management, chip design, and data infrastructure. Improvements to these algorithms have real commercial value, which is what makes TIG's licensing model viable.

III. The Qualifier Threshold System

Every challenge in TIG has a qualifier threshold: a minimum performance score that a solution must achieve before it is eligible for rewards. Below the threshold, the benchmark is submitted, recorded, and ignored for reward purposes. Above the threshold, the solution enters the reward draw. The draw is weighted, meaning higher-quality solutions have a greater probability of winning.

Thresholds are not static. As the network matures and better algorithms are deployed, the baseline performance of the participant pool rises. Thresholds are calibrated against the distribution of submitted solutions, which means a threshold that seemed challenging when the network launched may become straightforward as algorithmic progress compounds. This is intentional: the network is designed to keep raising its own floor.

For new entrants, the threshold system is the single most important thing to understand before committing hardware. A Benchmarker running an algorithm that consistently falls below the threshold is incurring real electricity and hardware costs while earning nothing. This happens more often than it should, because the submission process works regardless of whether you qualify. The benchmark goes in, the logs look fine, and the wallet balance does not move. Understanding where your solutions land relative to the threshold is the baseline diagnostic for any TIG operation.

IV. Comparison With PoW and PoS

Bitcoin's proof of work has one virtue above all others: it is objective. The difficulty target is a number. Your hash either meets it or it does not. There is no subjectivity, no committee, no governance vote. The cost is that the work is thermodynamically wasteful by design. The meaninglessness of the computation is a feature, not a bug: it prevents anyone from gaining an advantage by choosing the "right" kind of work.

Proof of stake solves the energy problem by replacing computation with capital lockup. If you stake more, you have a higher probability of producing the next block. This is efficient. It is also plutocratic: in a pure PoS system, wealth compounds into more wealth. The largest holders are the largest earners, and new participants must acquire existing tokens to participate meaningfully in consensus.

OPoW is neither. It requires real computation (like PoW) but computation directed at genuinely useful problems (unlike PoW). It does not require capital lockup (unlike PoS), but it does favour participants who invest in better algorithms, which creates a different kind of barrier to entry: intellectual rather than financial. Whether that barrier is more or less equitable than PoW or PoS depends on what you value.

The honest counter-argument is that intellectual barriers tend to consolidate over time just as hardware barriers do. A small number of highly skilled algorithm researchers producing the best solutions to all seven challenges, and deploying them proprietary rather than open-source, would capture a disproportionate share of rewards and create a competitive moat that is arguably harder to breach than buying better hardware. The Innovator royalty mechanism is designed to prevent this by making open-source algorithm contribution economically attractive, but the design intention does not guarantee the outcome.

V. The Seven Challenges: A Profile

TIG currently operates seven challenge categories. Each is a distinct NP-hard problem from computer science and operations research. They differ in their algorithmic characteristics, hardware requirements, and competitive difficulty.

c001 (Vector Satisfiability) is a variant of the Boolean satisfiability problem, one of the foundational NP-complete problems in computer science. It is primarily algorithm-sensitive rather than hardware-sensitive: raw compute power helps, but a clever approach to the search space matters more. This makes c001 one of the more accessible challenges for researchers with strong algorithmic intuition and modest hardware.

c002 (Vehicle Routing Problem) is the classic logistics optimisation problem. Given a set of delivery locations and a fleet of vehicles with capacity constraints, find the routes that minimise total distance or time. VRP is one of the most heavily studied NP-hard problems in operations research. In real-world TIG benchmarking, Intel CPU architectures have demonstrated characteristics that suit certain VRP algorithm approaches, making hardware choice non-trivial for serious operators.

c003 (Knapsack) is one of the most accessible NP-hard problems algorithmically. Given a set of items with weights and values, find the maximum-value subset that fits within a weight constraint. Dynamic programming works on smaller instances, and the problem has a rich set of approximation algorithms. c003 is often cited as a reasonable starting point for new Benchmarkers.

c004 (Hyper-dimensional Vector Store) involves high-dimensional vector operations where GPU memory bandwidth is the primary performance lever. High-memory-bandwidth GPUs maintain a structural advantage. The commercial relevance is clear, as vector search underlies most modern embedding-based retrieval systems in AI applications.

c005 (Hypergraph Partitioning) requires partitioning a hypergraph into balanced components while minimising cut size. Applications span circuit design, parallel computing, and data distribution. It is algorithmically competitive, and leading approaches combine spectral methods with local search refinement.

c006 (Capacitated Clustering) is a clustering problem with capacity constraints on each cluster. Applications include logistics hub assignment, telecommunications coverage zoning, and cloud resource allocation. Hardware requirements are moderate, making it a reasonable secondary challenge for operators with spare compute.

c007 (Capacitated VRP) is a harder variant of c002 with explicit capacity constraints on each vehicle. Many c002 algorithmic approaches transfer but need modification for the tighter feasibility constraints. The platform sensitivity patterns observed in c002 carry over broadly.

VI. Algorithm Quality vs Hardware: The Real Competitive Dynamic

The hardware arms race narrative that dominates PoW mining discourse applies to TIG only partially. Raw compute does matter: more GPU cores can explore more of the solution space per second. But the relationship between hardware investment and earned rewards is not linear, because the threshold system creates a hard floor below which hardware investment generates nothing at all.

A Benchmarker running a high-quality algorithm on consumer-grade hardware will consistently beat a Benchmarker running a naive algorithm on server-grade hardware, provided the consumer hardware is powerful enough to generate solutions above the qualifier threshold. The qualifier is a binary gate. Once you are through it, additional compute helps. Before you are through it, compute is irrelevant.

The Innovator layer is where this dynamic becomes commercially interesting. Innovators develop and submit algorithms to the TIG protocol. They do not run hardware. When a Benchmarker uses an Innovator's algorithm and earns rewards, the Innovator receives 2.5% of those rewards automatically, across every machine running their algorithm simultaneously. A single excellent algorithm, adopted by hundreds of Benchmarkers, generates passive income for its author at network scale.

VII. The Bear Case for OPoW

The strongest bear case for OPoW as a consensus mechanism is network capture by a small algorithmic elite. If two or three research groups produce algorithms substantially better than everything else in the field, and those groups are unwilling to publish open-source, the reward distribution becomes highly concentrated. Unlike PoW, where hardware monopoly requires visible capital expenditure, algorithmic monopoly can be maintained invisibly: the code exists, it is not published, and there is no obvious signal to the outside world that the competitive environment has collapsed.

The second bear case is threshold inflation. As better algorithms raise the performance floor, Benchmarkers running older algorithms fall below the threshold. They either upgrade their algorithms or exit. If the pace of algorithmic improvement consistently outstrips the pace of algorithm dissemination through the Innovator system, the accessible earnings pool shrinks faster than new entrants can adapt.

The third bear case is hardware specialisation. If specific challenges develop hardware-specific advantages that are well-understood and concentrated in expensive supply chains, the theoretical accessibility of OPoW erodes in practice. c002's observed Intel architecture characteristics are a mild early signal of this. They are not yet problematic. If they compound, they could become structural.

None of these risks are unique to TIG. They are the standard failure modes of any incentive-based competition system as it matures. The OPoW design addresses them imperfectly, as all designs do. The honest position is that the mechanism is elegant and the problems it directs computation toward are genuinely valuable, and the question of whether it produces a durable, distributed competitive ecosystem is one that markets will answer over the next three to five years.

I. How the Tranche System Works

TIG distributes tokens through five tranches of emissions, each approximately half the size of the previous one. Tranche 1 had the highest per-block reward. Tranche 5 will have the lowest. The total across all five tranches sums to 131 million $TIG. The schedule is deflationary by design: as the network matures and commercial adoption is meant to grow, the subsidy required to sustain participant incentives decreases.

Within each tranche, rewards are distributed to three groups: Benchmarkers (who run the algorithms against benchmark instances), Innovators (who write the algorithms), and Protocol (which funds development and operational infrastructure). The exact split is defined in TIG's governance documentation. Benchmarkers receive the largest share, as they provide the computation. Innovators receive a cut via the 2.5% royalty mechanism that compounds across all machines using their algorithms.

The network is currently in Tranche 3, with a per-block reward of 25 $TIG and approximately 16 months remaining before the next halvening. Tranche 4 will follow at approximately 12.5 $TIG per block, and Tranche 5 at approximately 6.25 $TIG per block. Tranche 5 is estimated to close sometime in 2027 or 2028. After it, the block reward drops to zero and the network transitions entirely to fee-funded rewards. At current tranche progression rates, that transition is roughly 18 to 30 months away.

II. The Fee Mechanism: How Commercial Licenses Fund Rewards

TIG's commercial license fee is paid in $TIG. An enterprise that wants to use a TIG algorithm commercially, under proprietary terms (without contributing their data back to the network), must acquire $TIG and pay the fee. Those tokens flow into the reward pool and are distributed to Innovators and Benchmarkers proportionally.

The mechanism has an elegant self-reinforcing quality: better algorithms attract more commercial licensees, which generates more fee revenue, which increases rewards, which attracts better Innovators and more Benchmarkers, which produces better algorithms. The flywheel works in both directions. A network that fails to attract commercial licenses generates insufficient rewards, which reduces participation, which degrades algorithm quality, which makes commercial adoption less likely.

The specific fee structure has not been publicly documented in detail. TIG has not published a standard fee schedule or confirmed whether fees are structured as one-time license payments, annual subscriptions, or per-use royalties. This ambiguity matters significantly for modelling post-Tranche 5 reward flows. The scenarios below use reasonable assumptions based on available information, flagged explicitly where they involve estimates.

III. Three Scenarios for Post-Tranche 5

The post-Tranche 5 reward environment depends on a single variable: the annual volume of commercial license fees paid in $TIG. Everything else follows from that number. Here is what three plausible outcomes look like.

Bear scenario: no enterprise licenses by Tranche 5 close. The network exits Tranche 5 with zero or near-zero commercial license revenue. Block rewards drop to zero. Innovators and Benchmarkers face a sudden and steep reduction in earnings with no replacement income stream. The rational response for most participants is to exit: shut down hardware, withdraw algorithms from the registry, redirect compute to other networks. A smaller participant base produces weaker algorithm competition, which makes it harder to sign commercial licenses, which perpetuates the cycle. This is not a catastrophic collapse necessarily. It is a slow contraction into a network that persists at a fraction of its prior scale, serving a niche commercial use case for participants who can sustain operations at low reward levels while waiting for license revenue to grow.

The bear scenario requires no fraud, no technical failure, and no malicious actors. It simply requires that enterprise sales cycles are slower than the emission schedule. That is not an unlikely outcome. It is the default outcome unless TIG Foundation executes aggressive commercial development well ahead of the Tranche 5 cliff.

Base scenario: three to five medium enterprise licenses. Assume TIG signs three to five commercial licenses with mid-size enterprises (logistics operators, software companies, supply chain analytics firms) before Tranche 5 closes. Each license generates annual fee revenue equivalent to $200,000 to $500,000 in $TIG at current token prices, for a total annual pool of $600,000 to $2.5 million. At current network scale, this partially but not fully replaces Tranche 3 emission rewards. The network stabilises but shrinks. It remains functional, continues improving its algorithm quality through competition, and is positioned to grow commercial adoption if additional licenses are signed. This is the most likely outcome if TIG Foundation executes reasonably well on business development.

Bull scenario: ten or more licenses, fee income exceeds peak emissions. Assume TIG reaches a state where annual commercial license fee volume exceeds the annual emission value of any single tranche. This requires either a large number of medium licenses or a small number of large ones. In this scenario, the token becomes structurally deflationary. More $TIG is required to pay license fees each year than is being newly distributed through the remaining emission tranche rewards. Combined with the hard supply cap, this creates persistent buy-side demand pressure from commercial licensees against a fixed and non-growing supply. The network is self-sustaining and growing, with fee income attracting better Innovators, which attracts more licensees, which drives more fee income.

IV. The Timing Risk: Why the Cliff Matters

The most underappreciated structural risk in the $TIG thesis is not whether commercial licensing works. It is whether commercial licensing works on a timeline that aligns with the emission schedule.

Enterprise software sales cycles are long. The typical path from initial contact to a signed commercial agreement runs 12 to 24 months for mid-size enterprises and 18 to 36 months for large enterprises. That timeline includes: initial evaluation (3 to 6 months), procurement approval (2 to 4 months), legal review of license terms (1 to 3 months, extended if the token-denominated payment mechanism requires legal counsel unfamiliar with crypto), integration engineering (3 to 6 months), internal pilot (3 to 6 months), and production rollout (1 to 3 months).

If TIG Foundation begins serious commercial outreach in mid-2026, the first enterprise license fee payments under optimistic assumptions might arrive in late 2027 or 2028. Tranche 5 is estimated to close in roughly the same window. The margin for error is thin.

V. Fixed Supply vs ARM's Pricing Flexibility

ARM's commercial model has a flexibility lever that TIG does not: it can adjust royalty rates. When RISC-V began gaining traction as a free alternative, ARM had the option to reduce royalty rates on certain product categories to maintain competitiveness. The rates are a negotiated business term, not a protocol parameter.

TIG cannot adjust the supply of $TIG. The 131 million token ceiling is a protocol constant. This has a significant upside: if commercial demand grows faster than expected, the fixed supply means the price absorbs the demand signal rather than the protocol diluting it through new issuance. There is no governance mechanism by which a well-connected insider can vote to mint additional tokens and reduce existing holders' share of future fee flows.

The downside is symmetric: if commercial demand is lower than expected and the network needs to sustain participants through a period of low fee revenue, there is no token dilution lever available. The protocol cannot print its way through an adoption shortfall. It can only wait for commercial adoption to catch up, while hoping the participant base does not contract too severely in the interim.

This is a deliberate design choice. The founders chose hard-cap tokenomics because the upside of the fixed-supply demand mechanism is worth the downside of having no dilution backstop. Whether that trade-off is correct will be determined by the commercial execution quality of the next two years.

VI. What the Numbers Require

Working backward from the reward replacement requirement is instructive. At Tranche 3 levels, the network distributes roughly 13 million $TIG per year. At Tranche 5 levels, that drops to approximately 3.3 million $TIG per year. Replacing Tranche 3 reward levels entirely from commercial license fees requires generating approximately 13 million $TIG worth of fee revenue annually.

At $1.15 per token, that is roughly $15 million in annual commercial license fee revenue, which would require substantial enterprise deployment. A more modest target, one that sustains a functional but smaller network, might be replacement of 25 to 30% of peak emission reward value. That requires approximately $3.75 to $4.5 million in annual fee revenue at current token prices, achievable with three to five mid-size enterprise licenses paying meaningful annual fees.

VII. The Bear Case: Explicit and Direct

The bear case should be stated plainly rather than buried in caveats. TIG's entire post-emission economic model depends on a commercial licensing revenue stream that does not yet exist in meaningful volume. The emission schedule is a countdown. The commercial sales effort needs to produce signed, fee-paying enterprise customers before that countdown reaches zero.

If it does not, the network faces an extended period of near-zero rewards, which will trigger participant attrition. Participant attrition degrades algorithm quality. Algorithm quality degradation makes commercial adoption harder, not easier. A network that exits Tranche 5 without established license revenue is fighting a momentum problem, not just a revenue gap.

The token is not worthless in this scenario. The hard supply cap and the design quality of the protocol mean the network can recover if commercial adoption eventually arrives. But the participant base would likely contract significantly, and the recovery period could be years rather than months. Holders who bought during the emission phase expecting a smooth transition to fee-funded rewards would face a period of significant price pressure.

The honest question for anyone holding $TIG is not "does the model make sense?" The model makes sense. The question is: "can TIG Foundation close commercial license deals before Tranche 5 closes?" That is an execution question about a specific sales pipeline, and it is not one that can be answered from tokenomics documents or protocol architecture alone.

VIII. Signals Worth Watching

The first publicly disclosed commercial license is the most important signal by a large margin. It does not need to be large. It needs to be real. A named enterprise, a confirmed fee amount paid in $TIG, and a specific algorithm licensed: that combination converts the model from theoretical to demonstrated. Until it exists, the entire commercial licensing thesis is based on design documents and management intentions.

The pipeline disclosure is the second signal. If TIG Foundation begins publicly reporting on commercial conversations, pilot programs, or proof-of-concept deployments, that is directional evidence of progress even before signed licenses. Silence on commercial development activity as Tranche 5 approaches is a negative signal.

Algorithm quality benchmarks are the third signal. If TIG's best algorithms in vehicle routing or knapsack optimisation are demonstrably competitive with or superior to proprietary alternatives on commercially relevant problem instances, the commercial licensing value proposition is real. If they are not, the licensing story does not hold regardless of how well the tokenomics are structured.

The timeline is compressing. Tranche 5 is not a distant abstraction. It is a deterministic outcome of the current emission schedule, arriving whether or not commercial licensing is ready. The network that exists on the other side of that transition will look quite different depending on how the next 18 to 30 months unfold.

I. The Architecture Underlying All Seven Challenges

Every challenge in TIG is an NP-hard combinatorial optimisation problem. NP-hard means there is no known algorithm that solves all instances optimally in polynomial time. As problem instances grow larger, the difficulty scales faster than any polynomial function of the input size. For practical purposes, this means you cannot solve them exactly at meaningful scale. You can only find good approximate solutions.

This is precisely why these problems are valuable for TIG's purposes. If there were a known efficient exact algorithm, the competitive landscape would collapse: everyone would run the same algorithm and hardware would be the only differentiator. Because there is no exact algorithm, researchers with different approaches produce genuinely different quality solutions, and the best approaches provide durable competitive advantages until someone develops something better.

The qualifier threshold system captures this. Your solution earns rewards if it is good enough relative to the threshold. Better solutions earn more weight in the reward draw. The threshold itself moves over time as the competitive field improves. You are not competing against a fixed standard. You are competing against the current state of the art among active participants.

Understanding this dynamic is essential before investing in hardware or algorithm development. The right question is not "what hardware do I need to run TIG?" The right question is: which challenge has a competitive gap that my capabilities can exploit, and what is the minimum hardware required to earn above the qualifier threshold in that challenge at current competitive levels?

II. c001: Vector Satisfiability

c001 is TIG's implementation of a satisfiability variant. Satisfiability (SAT) is the ur-problem of computational complexity, the first problem proven to be NP-complete, sitting at the foundation of theoretical computer science. TIG's c001 is a vector version of SAT, working over floating-point or integer vectors rather than pure Boolean variables. The problem structure is similar: find an assignment satisfying a set of constraints, where the constraints are vector-valued rather than Boolean.

Algorithm approach matters more than hardware for c001. The problem is not primarily memory-bandwidth-bound or floating-point-throughput-bound. It is search-space-bound: the key challenge is navigating a high-dimensional constraint space efficiently. Approaches that work well include local search with random restarts, simulated annealing, and evolutionary algorithms, but the specific formulation of the search operator has a larger impact on qualifier rate than GPU tier.

c001 is one of the more accessible challenges for new algorithm writers. The problem structure is well-studied in academic literature, there is extensive open-source SAT solver code to learn from, and the algorithmic intuition required is not hardware-specific. A researcher comfortable with constraint satisfaction and search algorithms can develop a competitive c001 approach without needing to understand GPU memory hierarchies.

III. c002: Vehicle Routing Problem

c002 is the Vehicle Routing Problem (VRP). Given a depot, a set of customer locations, and a fleet of vehicles with capacity constraints, find the set of routes that serves all customers at minimum total distance or time. VRP is one of the most heavily studied problems in operations research and has been for more than 60 years.

VRP is commercially significant in a direct way that most of the other challenges are not. Every parcel delivery company, logistics operator, field service firm, and public transit planner works with versions of this problem daily. The gap between a good VRP solution and a mediocre one translates directly into fuel costs, driver hours, and delivery reliability. This is why VRP is one of the most commercially plausible challenges for TIG's licensing model.

c002 has shown hardware platform sensitivity in real-world TIG benchmarking. Specifically, Intel CPU architectures have demonstrated characteristics that translate to better qualifier rates on certain c002 algorithm approaches, compared to equivalent-tier AMD or ARM hardware. The exact mechanism relates to how different CPU microarchitectures handle the branch-heavy, memory-access patterns common in VRP local search algorithms. This does not mean Intel is always better for c002. It means that if you are optimising hardware allocation across challenges, c002 may favour Intel where other challenges do not.

Algorithm approaches for VRP that perform well in competitive settings generally combine a construction heuristic (to generate an initial feasible solution quickly) with a local search improvement phase (to iteratively swap, relocate, or reroute to improve solution quality). The specific neighbourhood operators used in the local search phase, and the order in which they are applied, have a large impact on solution quality within a fixed time budget.

IV. c003: Knapsack

c003 is the Knapsack problem, and it is the most accessible challenge in TIG for new entrants to algorithmic development. The formulation is simple: given a set of items each with a weight and a value, select the subset of items that maximises total value without exceeding a weight constraint. The constraint is binary per item: each item is either included or excluded.

The simplicity of the problem statement conceals non-trivial difficulty at scale. For small instances, dynamic programming finds the exact solution efficiently. For large instances, the DP table grows too large, and approximation algorithms are required. The competitive landscape in TIG's c003 uses approximation approaches, and the key algorithmic challenge is finding the best feasible solution within the computation time budget the benchmark system allows.

c003 is hardware-agnostic to a greater degree than the other challenges. The bottleneck is algorithmic search quality rather than memory bandwidth or floating-point throughput. Consumer-grade hardware running a good approximation algorithm will consistently outperform enterprise hardware running a naive one. This makes c003 the recommended starting challenge for new Benchmarkers who want to understand the qualifier system and validate their infrastructure before committing to more demanding challenges.

V. c004: Hyper-Dimensional Vector Store

c004 involves operations on hyper-dimensional vectors, a framework derived from brain-inspired computing and cognitive architectures. Hyper-dimensional computing represents data as very high-dimensional binary or bipolar vectors (commonly 10,000 dimensions or more) and performs operations like similarity search, encoding, and retrieval using vector arithmetic.

The practical application is vector similarity search at scale, which is foundational to modern AI retrieval systems. Embedding-based search is essentially a high-dimensional nearest-neighbour problem, and this is the class of computation c004 benchmarks.

Hardware matters more for c004 than for almost any other challenge. The bottleneck is GPU memory bandwidth: moving large vectors through the compute pipeline quickly enough to search effectively within the time budget. High-memory-bandwidth GPUs (NVIDIA A100, H100, and their consumer equivalents) maintain a structural advantage in c004 that algorithmic cleverness can partially but not fully compensate for. The algorithm design space for c004 is less about search heuristics and more about data layout, memory access patterns, and parallelism. The key skills are GPU programming and high-performance computing rather than traditional combinatorial optimisation knowledge.

VI. c005: Hypergraph Partitioning

c005 is Hypergraph Partitioning. A hypergraph is a generalisation of a standard graph where edges (called hyperedges) can connect more than two nodes simultaneously. Partitioning a hypergraph means dividing its nodes into balanced groups while minimising the number of hyperedges that cross between groups.

The application landscape is broad and technically significant: VLSI circuit design (where wires connect many pins simultaneously), parallel computing task scheduling (where tasks share data dependencies), and database query optimisation (where operations share data across partitions).

c005 is algorithmically competitive. The best approaches combine spectral methods (using the eigenvectors of the hypergraph Laplacian matrix to find initial partitions) with local search refinement (using moves like FM refinement to improve partition balance and cut size iteratively). Both phases require non-trivial implementation skill. The hardware profile for c005 is mixed: the spectral phase benefits from GPU acceleration, while the local search phase is often memory-access-bound and runs efficiently on CPU. Operators who can pipeline GPU spectral computation with CPU refinement tend to produce better results than those running the entire pipeline on either device exclusively.

VII. c006: Capacitated Clustering

c006 is Capacitated Clustering, which extends standard clustering with capacity constraints on each cluster. The problem combines the continuous optimisation character of k-means with the combinatorial constraint-satisfaction character of bin packing.

Commercial applications include logistics hub assignment (assign delivery zones to depots while respecting depot capacity), telecommunications cell tower coverage (assign subscribers to towers within signal range), and resource allocation in cloud infrastructure (assign workloads to servers within compute budget).

c006 algorithm approaches generally follow an iterative two-phase structure: first assign points to clusters using a heuristic that respects capacity constraints, then improve the assignment using local swaps between clusters. Hardware requirements for c006 are moderate. The algorithm is not primarily memory-bandwidth-bound, and most of the computation runs efficiently on a single GPU without requiring the highest-tier hardware. c006 is a reasonable secondary challenge for operators primarily focused on c002 or c003 who have spare compute capacity to deploy.

VIII. c007: Capacitated Vehicle Routing

c007 is the Capacitated Vehicle Routing Problem (CVRP), a harder variant of c002. Where c002's VRP formulation focuses on finding minimum-distance routes, c007 adds explicit capacity constraints to each vehicle in the fleet. A vehicle cannot serve more customers than its capacity allows without returning to the depot to reload.

The additional constraints tighten the feasible solution space significantly. Many routes that are optimal in c002 terms become infeasible in c007 because they exceed vehicle capacity. The algorithm must jointly optimise route distances and capacity allocation, which makes the search space navigation considerably harder.

The algorithmic approaches that work for c002 are a reasonable starting point for c007, but they need modification to handle the capacity constraint efficiently. The most competitive c007 algorithms use hybrid approaches that combine capacity-aware construction heuristics with local search operators specifically designed to handle capacity violations gracefully (for example, ejection chains that restructure routes to remove capacity violations while preserving or improving route quality). The hardware platform sensitivity patterns from c002 carry over to c007 broadly.

IX. The Innovator Ecosystem: Passive Income at Network Scale

The seven challenges described above are the arena for Benchmarkers: participants who run hardware to execute algorithms against benchmark instances. But there is a parallel participation layer that receives significantly less attention: the Innovator layer, where algorithm developers write and submit algorithms rather than running them.

The Innovator royalty mechanism is structurally powerful. When a Benchmarker uses an Innovator's algorithm and earns rewards from qualifiers, the Innovator automatically receives 2.5% of those rewards. The Innovator does not need to run any hardware. They receive 2.5% from every machine running their algorithm, simultaneously, in perpetuity, for as long as their algorithm remains in use.

Innovators can submit algorithms as open-source (available to all Benchmarkers via the public algorithm registry) or proprietary (run only on hardware controlled by the Innovator themselves, or licensed privately). Open-source algorithms earn 2.5% from every Benchmarker who uses them. The risk is that competitors can study the algorithm and develop improved variants. Proprietary algorithms earn 100% of the rewards generated by the hardware running them, but those rewards are limited to that hardware. Most mature TIG operators run a hybrid approach: publish algorithms that are good but not state-of-the-art, capturing the 2.5% royalty from broad adoption, while running their best algorithms proprietary on their own hardware.

The Innovator opportunity is most attractive in challenges where algorithmic innovation provides durable competitive advantages. c001 and c003 are good entry points for algorithm writers because the problem structures are well-studied, the literature is accessible, and a motivated researcher can develop competitive approaches without GPU programming expertise. c002 and c007 have the highest commercial licensing relevance, meaning strong algorithms here are most likely to be adopted by operators optimising for earnings longevity.

X. Strategy for a New Benchmarker: Where to Start

The most common mistake new Benchmarkers make is choosing a challenge based on hardware they already own rather than on competitive qualifier rates relative to their hardware tier. The second most common mistake is submitting benchmarks without confirming they are generating qualifiers.

The recommended approach for a new entrant with a mid-range GPU is to start with c003 (Knapsack). The qualifier threshold in c003 is achievable with good open-source algorithms on consumer hardware. The problem is well-studied, the literature is accessible, and the feedback cycle between algorithm changes and qualifier rate changes is relatively fast. Starting on c003 lets you validate your infrastructure, understand the qualifier system, and develop an intuition for the TIG competitive environment before committing to more demanding challenges.

The second challenge to add, for an operator with validated c003 earnings, is typically c001 (Vector SAT) or c002 (VRP), depending on hardware. If you are running Intel CPU compute alongside your GPU, c002 may generate stronger qualifier rates. If you are running a GPU-primary setup, c001 is a better fit for the additional compute capacity.

c004 (Vector Store) is best deferred until you have enterprise-tier GPU hardware with high memory bandwidth. Running c004 on consumer hardware with limited memory bandwidth typically produces sub-threshold solutions and generates zero earnings while consuming significant power and compute resources.

c005, c006, and c007 are intermediate challenges that benefit from experience with the simpler variants first. An operator who has developed strong c002 algorithms has a natural path to c007. An operator who understands c003 has relevant background for c006. Start simple, build algorithm intuition, and migrate to harder variants as competitive positioning and hardware justify the move.

The Innovator path is entirely separate. If your background is in algorithms, operations research, or combinatorial optimisation research rather than GPU operations, the highest-return contribution to TIG is developing algorithms rather than running them. The 2.5% royalty scales with network adoption in a way that individual hardware scaling never can.