Business model comes first because token utility only routes value that already exists
Token utility fails when it is asked to invent demand that the business model never created. Our framework at FinDaS starts upstream. We ask who pays, to whom, for what, under which conditions, and why that payment repeats. If a product cannot attract fiat or stable-asset demand on its own, adding a token does not solve the problem. It adds another tradable surface, more design constraints, and another source of volatility.
This is the core distinction. A token is infrastructure. It can be a payment rail, a cash-flow rail, a utility access rail, or a coordination rail. Rails move value. They do not create it. That is why we treat the business model as the first hard gate in token economy design. If the project cannot describe recurring economic exchange without leaning on token appreciation, the token is being used as a substitute for strategy rather than an extension of it.
Public crypto systems make this visible. Ethereum’s fee market works because users already need blockspace. EIP-1559 then routes that pre-existing demand through ETH by requiring a base fee in ETH, burning that base fee, and leaving only the priority fee to validators. The token is tied to a real service and a real payment obligation. The burn is downstream of usage, not a narrative layered on top of it.
Celestia shows the same principle in a different form. TIA is not presented as a generic community chip. It is used for staking, governance, and paying for blobspace, while transaction inclusion is mediated by a gas-priced prioritized mempool. That means usage demand, issuance, and validator ordering incentives all meet in the same market. Utility is connected to execution conditions, not just branding.
P&L is the gate before tokenomics, because a token cannot rescue a broken unit model
A viable token economy starts with a viable operating model. After the business model is defined, we build a basic P&L structure around it. The point is not accounting theater. The point is to test whether customer acquisition cost, lifetime value, gross margins, and the breakeven timeline actually support a self-sustaining system.
Breakeven matters because it defines capital need. A model that breaks even in one to two years is workable. Three years can still be manageable. Beyond that, the project is usually trying to finance operating weakness with narrative strength. That is where teams start asking a token to do funding, marketing, and retention work that the product itself has not earned.
Our working abstraction is blunt on purpose: a token is not revenue. Economically, it behaves more like a claim on future system value than present-day income. That is why we treat token issuance as a liability layer unless the underlying business can already survive its own P&L. Incentives can subsidize CAC for a time, but if token price weakens, the subsidy disappears and the real unit economics reappear immediately.
This sequencing is also consistent with how value-capture mechanisms work in production systems. Maker’s surplus auctions burn MKR only when the protocol has actually accumulated surplus Dai from stability fees above the configured buffer. If the system is in deficit, Maker can move the other way and mint MKR through debt auctions. The token outcome follows protocol cash flows and risk conditions. It does not override them.
Most projects do not need a token, and fundraising alone is not a sufficient reason
Most projects do not need a token. The main clean exception is a permissionless, trustless base-layer system that needs a native incentive asset to coordinate validators, secure the network, and preserve liveness without central control. Outside that category, a token is usually optional.
The decision rule we use is simple. A token should improve at least one of three things in a measurable way: user experience, customer acquisition, or profit margins. If it does none of those, it is usually unnecessary complexity. Governance by itself rarely clears that bar unless governance rights control parameters that matter economically and are exercised with enough participation to be credible.
Fundraising does not fix this. Teams often reach for a token because they do not want to sell equity or cannot raise capital on other terms. That may explain the choice, but it does not justify it. If the token’s primary purpose is to pull forward capital while promised utility sits in the future, the project is effectively borrowing against execution it has not yet delivered.
That structure also creates regulatory pressure. The SEC’s digital asset framework highlights factors that push an asset toward investment-contract analysis, including emphasis on secondary-market liquidity, reliance on managerial efforts, selling before functionality exists, selling in quantities beyond reasonable use, and marketing centered on appreciation rather than consumptive use. The same framework points the other way when functionality is immediate, use is real, and transferability is constrained by purpose rather than speculation.
Arbitrum is a useful contrast case. When the Arbitrum Foundation announced the token on March 16, 2023, it framed ARB as a governance instrument for DAO control over the network and distributed 12.75% of supply via a March 23, 2023 airdrop, while investor and team tokens were subject to four-year lockups with the first unlocks after one year and monthly unlocks thereafter. That is a governance-first design, not a direct fee-claim design. The token’s economic meaning therefore depends heavily on governance relevance and on how later unlocks interact with market liquidity.
From business model to token utility means mapping real cash flows into specific economic rails
The useful question is not “what utilities can we add.” The useful question is “which economic rail matches the business model we already have.” Different rails produce different buy-side, hold-side, and sell-side behavior.
| Business primitive | Token rail | How value reaches the token | What can break | Reference case |
|---|---|---|---|---|
| Users must pay to consume scarce blockspace | Payment rail | Core service demand requires the token for transaction validity or settlement | If payment demand is weak, the token becomes mostly speculative | ETH base fee must be paid in ETH and is burned. |
| Network security depends on bonded capital and validator incentives | Security and coordination rail | Staking, delegation, slashing, and governance tie token demand to network operation | Issuance can outrun organic demand, especially if rewards immediately hit liquid supply | TIA supports staking and governance, and staking rewards are unlocked upon receipt. |
| Protocol earns surplus or fee income | Cash-flow rail | Fees, auctions, burns, or buybacks route realized surplus back to the token | If surplus is absent, buffers are mis-set, or participation is poor, value capture stalls | MKR burns on surplus auctions only after system surplus conditions are met. |
| Community needs formal control over protocol parameters and treasury | Governance rail | Voting rights determine upgrades, budgets, and parameter changes | Utility becomes episodic if governance has little economic consequence or supply is too concentrated | ARB was launched to put governance power in the DAO. |
This mapping matters because each rail implies a different market structure. Payment rails create repeated transactional demand. Security rails create bonded demand but also reward emissions. Cash-flow rails create conditional sinks, often through burns or treasury accrual. Governance rails mostly create event-driven demand around votes, grants, and control disputes. Lumping these together under “utility” hides the actual trading mechanics.
Uniswap is a strong reminder that utility is not static. Uniswap v2’s whitepaper included a protocol fee design from the start, but the fee was initially off and could be turned on later. As of March 6, 2026, Uniswap governance had executed a proposal to expand protocol fees across multiple chains and activate fees on every v3 pool through a tier-based adapter, with fees routed into TokenJar infrastructure and burned into UNI on mainnet. Utility here was not a launch-day constant. It was a governance-activated change in economic routing years later.
Market structure decides whether utility survives contact with trading
A token utility model is only credible when the demand it creates can absorb the supply the system itself produces. This is where many token narratives break. They describe rights, access, or governance in static terms, but ignore the live sell-side created by unlocks, staking rewards, market-maker inventory, treasury distributions, and incentive programs.
Celestia’s documentation is unusually clear on this point. It distinguishes between circulating supply and available supply, notes that all locked or unlocked tokens may be staked, and states that staking rewards are unlocked upon receipt and add to circulating supply. It also publishes category-level unlock schedules. That is the right analytical posture. Locked supply still matters if it can generate liquid rewards or convert into available inventory on known dates.
The exact schedule matters because liquidity events are timed. Celestia’s genesis supply was 1,000,000,000 TIA. Public allocation was fully unlocked at launch. Early backers and initial core contributors had one-year cliffs, and the docs specify that yearly intervals occur on October 30, including the year-one unlock on October 30, 2024. That does not make the design good or bad by itself. It means price behavior around those windows cannot be analyzed with a static FDV story alone.
Arbitrum shows the same principle from a governance-token angle. Team and investor tokens were locked with first unlocks after one year and monthly releases thereafter. For a governance token without hard protocol-level payment demand, those releases are not background noise. They are central market events because they change who can sell, who can delegate, and who can accumulate influence.
Even value-capture designs depend on microstructure. Maker’s burn only happens if surplus exists and auction parameters are attractive enough for keepers to participate. The docs explicitly note that poor parameter settings can prevent surplus auctions from happening or make them unprofitable, which means no MKR burn occurs. Narrative stability does not survive if the mechanism cannot clear in real market conditions.
This is why we are skeptical of static supply narratives disconnected from actual trading conditions. The relevant questions are concrete. When does new liquid inventory appear. Who receives it. Are those holders natural sellers, stakers, or strategic governors. Is utility continuous or episodic. Does the token create a sink strong enough to offset emissions and unlocks. If the answer depends on “bull market demand,” the framework is incomplete.
How we operationalize the framework at FinDaS
Our token economy work is collaborative by design because good tokenomics cannot be assembled from a cap table alone. Some clients arrive at ground zero. Others arrive with legal constraints, fundraising history, community promises, and partially built mechanics. We use a standard token economy questionnaire to structure the starting point, align expectations, and identify the real constraints before design begins.
Near the start date, we run kickoff calls to solidify our understanding of the project, collect any missing data, and discuss the direction of the token economy. From there, communication stays open through the channels that actually move a project forward, including Telegram, WhatsApp, and Slack. Regular check-ins can be added when the design process needs tighter iteration.
| Phase | What we do | Why it matters |
|---|---|---|
| Discovery | Questionnaire, initial materials review, kickoff calls | Defines the real business model, constraints, and decision surface before utility design begins |
| Blueprint | We prepare a token blueprint | Creates a shared reference for the detailed deliverables so everyone is aligned before drafting |
| Drafting | We build first drafts of the agreed deliverables | Translates business model, P&L logic, and market-structure assumptions into full token design |
| Revision | We run as many revision sessions as needed | Allows open questions to be resolved and the documents to be tuned to the client’s operating reality |
| Post-delivery support | Up to two hours per month for six months within the original fixed price, limited to the scope of our deliverables; more support is available at standard hourly rates | Helps teams handle implementation friction after the documentation is finalized |
The practical output of this process is straightforward. We move from business model, to P&L, to the “do you even need a token” decision, and only then to token utility. After that, we stress-test supply creation, unlocks, emissions, treasury policy, and launch liquidity. In tokenomics consulting, that sequence matters more than any isolated mechanic. A token that looks elegant in a static diagram but cannot survive real secondary-market flows is not finished design. It is unfinished risk management.
