Bankr, Akash and the Internet Computer show why buying a useful service, funding a network and holding its token are three different decisions.

Independent editorial analysis. Research checked October 17, 2026 (Eastern Time).

Imagine a team building an AI assistant for a repair company. Customers want accurate answers and appointments booked correctly. The team needs model access, somewhere to run software and a way to pay the bills. None of those requirements, by itself, tells us whether the product needs its own token.

The better question is: what would stop working if this particular token disappeared? Would execution fail under the existing protocol? Would a funding program lose its reward asset? Or would only the payment option change?

Those are different answers. So are these two statements: the customer does not need to hold a token; the underlying network does not use one. Confusing them makes both pro-token and anti-token arguments weaker.

Four jobs that should not be confused

For this evaluation, separate four possible roles:

  • Technical dependency: the chosen protocol requires the asset for a defined operation. Removing it means changing that protocol, not toggling a checkout option.
  • Payment or settlement: the asset pays a bill or settles an obligation. Ask whether alternatives are supported and who performs any conversion.
  • Incentives: tokens recruit participants, fund activity or reward particular behavior. That is an economic design choice, not proof the software cannot run otherwise.
  • Governance: tokens allocate decision-making power. Evaluate which decisions and whose votes matter, rather than assuming a token guarantees meaningful shared control.

These are analytical categories, not quality rankings. A useful incentive mechanism need not be technically indispensable. Conversely, a mandatory token inside an existing protocol does not prove that protocol is the best architecture for a particular customer.

Bankr: a service can work without requiring its native token

Bankr combines agent-directed financial actions, wallet infrastructure, token launches and an LLM Gateway for accessing models.[13] For our hypothetical repair assistant, the gateway is the relevant product: the team buys model access through a common interface, not a Bankr-trained model.[1]

The gateway accepts funding in USDC, USDT and other supported assets; BNKR is not a mandatory gateway payment asset.[1] Usage draws on gateway credits, which are separate from the trading-wallet balance and must be funded.[1] That is a concrete answer to the customer question: buying this service does not require keeping BNKR merely to make inference requests.

BNKR nevertheless has documented economic connections. For the current Doppler launch structure, Bankr lists a 0.2375% share of trading volume for BNKR buybacks and protocol-owned BNKR liquidity; older launches retain their own schedules.[3] Its staking page separately says 30% of Bankr’s launch revenue buys BNKR for stakers.[4]

Do not add those percentages. One uses trading volume as its denominator; the other uses Bankr’s launch revenue. The reviewed descriptions do not reconcile them into two independent cash flows. Nor does an allocation establish that every purchase and distribution occurred as described.

The current staking program rewards participants, not every passive holder.[2] It is distinct from the legacy vault, which closed to new deposits on April 8, 2026.[2] Calling staking discontinued would therefore be as misleading as treating staking rewards as an unconditional benefit of simply holding BNKR.

There is another separation worth preserving: creator fees from trading an agent’s launched token can fund inference after being claimed.[1] That measures a funding route, not necessarily customers’ willingness to pay for the agent’s output. Trading interest and useful work are not interchangeable evidence.

Counterfactual analysis: a gateway with wallet-funded credits could retain its core customer service without BNKR, while losing or redesigning BNKR buybacks and staking. That is an assessment of substitutable functions—not proof that Bankr intends such a change, or that its surrounding incentive system has no value. It also concerns BNKR specifically, not every underlying blockchain asset.

Akash: the checkout can hide a protocol dependency

Akash’s customer buys compute from a provider; an accepted lease runs on that provider’s infrastructure.[9] For an AI team, the practical purchase is capacity to run a workload—not a promise that a token improves its model.

Managed Akash Console accepts dollar-denominated account credits, including card-funded credits, and converts them into ACT behind the scenes.[5] The customer need not personally buy or hold crypto through that route.[5] The self-managed command-line route is different: its documentation tells operators to retain AKT for gas, the fee for network transactions, even when using ACT.[7]

ACT is the network’s dollar-pegged compute credit; AKT has staking, governance and gas roles.[9] The documented burn-mint mechanism converts AKT into ACT and allows the reverse conversion from ACT into minted or reminted AKT.[7] In plain language, an ordinary-looking compute balance sits above a token conversion system.

Payment steps matter. Current architecture documentation says normal escrow payments accrue in ACT and providers withdraw ACT; it also documents an AKT fallback when minting is halted.[6] That is not the same as saying every provider automatically receives AKT for each unit of compute. The earlier BME proposal describes AKT settlement, so it should not replace the more specific current escrow description.[8][6]

Because conversion runs in both directions, “AKT is burned” is not enough to establish permanent net supply reduction.[7] An assessment needs burns, remints, outstanding credits and the relevant conversion prices over the same period. More compute spending alone does not resolve that accounting question.

Counterfactual analysis: the same customer workload could, in principle, be supplied by a marketplace with another payment and governance design. But removing AKT from Akash as documented would require changing more than the checkout: conversion, transaction fees and participation rules would need replacements. Whether those replacements preserve the properties a buyer values is the real comparison.

Internet Computer: users can avoid gas while applications still pay

The Internet Computer is a general-purpose application platform, not an AI-exclusive network. Its canisters combine executable code with persistent state and can serve web content.[12] An AI application is one possible use, not the definition of the infrastructure.

Its reverse-gas arrangement puts infrastructure payment at the application level: canisters consume cycles for resources, and developers or other sponsors can replenish their balances.[11] An end user need not acquire ICP simply to pay network gas for an app interaction.[11] That does not make resources free or prevent the application from charging a subscription.[10]

ICP is burned to create cycles. The documented accounting relationship is one trillion cycles to one XDR, the IMF’s Special Drawing Right unit of account—not one US dollar.[10] This separates resource accounting from ICP’s market price; it does not promise an unchanging total application bill.[11] Workload and resource consumption still matter.

Unlike Akash’s documented ACT-to-AKT conversion, cycles cannot be converted back into ICP.[11] But that does not make the whole ICP supply automatically deflationary: node-provider compensation creates new ICP, and governance maturity produces newly minted ICP when converted.[10] Burn and issuance must be examined together.

Counterfactual analysis: a repair assistant could deliver similar answers on another hosting system. It would not thereby reproduce the Internet Computer’s replicated execution and state model. Within the documented network, removing ICP means redesigning cycles creation, governance participation and node compensation—not merely offering customers a different payment button.[10][12]

The customer’s lack of a token balance therefore tells us little about the application’s underlying dependency.

A compact comparison

Question Bankr gateway / BNKR Akash / AKT Internet Computer / ICP
What is bought? Access to models through a gateway.[1] Provider-hosted compute.[9] Application execution and storage funded with cycles.[11]
Must the customer hold the native token? Not for gateway funding through supported alternatives.[1] Not through managed Console; self-managed use retains gas requirements.[5][7] End users need not hold ICP for app gas; the application needs funding.[11]
Where is the token connection? Documented launch-fee buybacks and staking rewards.[3][4] ACT conversion, gas, staking and governance.[7][9] Cycles creation, governance and node compensation.[10]

These are documented mechanisms, not independently verified adoption or payment-execution results. Multiple pages from one project’s documentation do not become independent corroboration just because they have different URLs.

Use a decision checklist, not a token score

For a product you are evaluating, write down answers to these questions before deciding whether its token belongs in the design:

  1. What does the customer buy? Name the output: completed inference, hosted compute, stored state or an executed action. A token purchase is not a substitute for specifying the product.
  2. Who must acquire what? Separate the end user, application operator, payment intermediary and infrastructure provider. Mark mandatory holdings, temporary conversions and optional participation separately.
  3. Where does the money go? Trace customer payment, credits, fees, supplier compensation and any token purchase. Keep percentages tied to their denominators. Identify who can actually claim a reward.
  4. What breaks without the token? Specify whether removal changes execution rules, payment accounting, incentives or governance. Compare alternatives against the same requirements—not merely the same user interface.
  5. What has been demonstrated? Ask for completed service delivery, repeat paying use and reconciled transactions. Documentation explains a mechanism; it does not establish sustained demand or successful execution.
  6. Who can change the arrangement? Identify upgrade authority, fee-setting power and funding responsibility. A token label does not answer those control questions.

For the hypothetical repair assistant, success starts with correct answers, dependable bookings and a sustainable operating bill. If a token-dependent network contributes a needed capability, test that capability. If the token only changes how incentives are distributed, evaluate that narrower role on its own merits.

The conditional answer

An AI product needs a particular token within its chosen design when removing that token breaks a required function or property that the team cannot acceptably replace. It does not need a new token merely because it uses AI. And a customer’s ability to pay without crypto does not prove the network underneath is token-free.

Bankr, Akash and the Internet Computer point to different answers because the asset sits in different places. The useful discipline is the same: identify the service, locate the dependency, trace the payer and test the evidence. Product usefulness, token demand and benefits to token holders remain separate conclusions.

Read more from AITI

These are related AITI explainers, not independent corroboration of the sources below.

Sources