Tokenomics for real products, not speculation

By Marco Lopes · July 3, 2022 · Blockchain & Web3

A token can help coordinate a network, distribute ownership or pay for a scarce resource. It can also distract us from the uncomfortable question every product must answer: why would anyone use this if its token never increased in price?

At Kordspace, we approach that question as a remote studio working across collaborative software, AI, Web3, hardware and design. We want the technology to serve a useful experience. A wallet connection, a smart contract or a token allocation is not a substitute for one.

With crypto markets under pressure in mid-2022, the distinction between product demand and speculative demand feels especially important. We should use this moment to design stronger systems, not simply more persuasive launch narratives.

Here is how we think about tokenomics when the goal is a working product rather than a trading opportunity.

Start with the job, not the token

Before discussing supply or exchange listings, we write down the job the product performs. Perhaps a network matches customers with independent compute providers. Perhaps a shared registry lets several organizations verify records without trusting one operator.

We then identify who contributes value, who consumes it and why those participants need a shared system. If we cannot explain that relationship without mentioning token price, the product definition is probably unfinished.

Our first deliverable should be a map of participants and value flows, not a distribution chart. We ask what participants already pay for, what they find difficult and what changes when the product exists.

That process also gives us a baseline: the simplest version we could build with conventional accounts, payments and a database.

Earn the right to introduce a token

Not every Web3 product needs its own token. We can use an existing blockchain for settlement or verification without creating another asset. Membership, permissions and usage credits may be better represented by ordinary application data.

We consider a token when it solves a specific coordination problem: securing contributions through collateral, transferring rights between independent systems or governing shared infrastructure with no single natural owner.

Even then, we compare alternatives. Could a subscription work? Could providers receive payment in an existing asset? Would non-transferable credits preserve the useful incentive while reducing speculation?

Creating a token introduces custody, accounting, security, liquidity and potentially regulatory responsibilities. We want a clear explanation of why those costs are worthwhile. If removing the token leaves the product equally useful and easier to operate, we should seriously consider removing it.

Separate utility, ownership and rewards

We often see one token asked to do everything: pay for usage, reward contributors, govern upgrades and capture the value of the whole network. Those roles can conflict.

A customer wants predictable costs. A contributor wants reliable compensation. A long-term participant may want influence over protocol rules. A trader may want volatility. We should not assume that placing everyone around the same asset aligns their interests.

We define each right explicitly. Does holding the token grant access? Does spending it consume a service entitlement? Does locking it provide collateral? What decisions can a holder actually influence?

We also separate technical behavior from marketing language. A governance token does not automatically represent equity or a claim on revenue. Our documentation and interface should describe the rights that genuinely exist, including their limits.

Connect incentives to useful work

Rewards should encourage behavior that improves the product. Paying for registrations, wallet connections or raw transaction counts can produce impressive dashboards while attracting little lasting demand.

For a compute network, we might reward completed jobs that meet a customer's requirements. For a data network, we might reward contributions that pass defined quality checks and remain useful over time.

But every reward rule invites attempts to game it. We need to ask whether one participant can create many identities, trade with themselves, submit duplicated work or manufacture apparent demand.

Where possible, we attach rewards to independently verifiable outcomes and delay final settlement until disputes can be resolved. Where verification requires human judgment or off-chain evidence, we make that dependency explicit. Calling a mechanism decentralized does not remove its trust assumptions.

Model sources, sinks and the actual budget

Our token model starts with a ledger of flows. Sources include contributor rewards, team allocations and ecosystem grants. Sinks might include payment for consumed services, required collateral or protocol fees.

We distinguish permanent removal from temporary restriction. Staking or vesting can reduce circulating supply for a period, but those tokens may return. Burning tokens changes supply; it does not create customer demand.

We also separate token accounting from operating cash flow. A treasury can hold a large token balance and still struggle to pay for cloud infrastructure, security reviews or salaries.

For every reward programme, we ask who ultimately funds it. If the answer is only future buyers, we have not established a sustainable business model. Subsidies can help a network start, but we need a credible path toward customers paying for something they value.

Treat supply and vesting as product decisions

A fixed supply is not automatically fair, and an inflationary supply is not automatically broken. We evaluate issuance against the work the network needs to fund and the burden placed on existing participants.

We document allocations, unlock conditions, administrative powers and treasury controls in plain language. A public schedule should make it possible to understand when additional tokens can circulate and who controls them.

Team and contributor vesting should support sustained work rather than reward a brief launch campaign. We also examine concentration: who could dominate voting, influence available liquidity or coordinate changes against other users' interests?

For any adjustable parameter, we specify the change process. We should not advertise predictable supply while leaving an administrator free to rewrite issuance without meaningful notice or oversight.

Stress-test behavior, not just spreadsheets

A model that works only while usage and token price rise together is not robust enough. We run scenarios that deliberately break those assumptions.

What happens if demand stalls while rewards continue? What if providers sell their entire reward allocation to cover expenses? What if a large holder exits, transaction fees spike or an external price feed stops updating?

We model the product under those conditions, not merely the token balance. Can customers still complete tasks? Can providers cover costs? Can the treasury maintain essential services?

Spreadsheets help us inspect flows. Small simulations help us explore participant behavior and parameter sensitivity. Neither proves that a market will behave as predicted. We record assumptions clearly and use early operating evidence to challenge them rather than presenting a model as a guarantee.

Design governance for decisions people can make

Governance should begin with a list of decisions, not a voting interface. We separate routine operations from changes that affect ownership, security or participant rights.

Not every deployment needs a token vote. Conversely, changes to issuance, treasury spending or protocol permissions deserve a transparent process with clear authority and sufficient review time.

We consider proposal requirements, delegation, quorum, execution delays and conflicts of interest. Token-weighted voting can concentrate influence, so we examine the distribution of effective voting power rather than assuming that participation is broad.

Emergency controls may be necessary, especially early on. We disclose who holds them, what they can do and how their actions are reviewed. If decentralization is a staged goal, we describe the stages and the criteria for transferring control.

Make the experience useful before making it crypto-native

We should not require users to understand issuance schedules just to complete a normal task. Product design can explain costs, transaction status and permissions without turning every screen into a trading terminal.

Where possible, we express service prices in terms customers understand. If payment uses a volatile asset, we explain how quotes are calculated and when they expire. We do not imply that a displayed conversion guarantees future purchasing power.

Wallet onboarding deserves particular care. We explain custody, recovery options, network selection and transaction approvals. We avoid broad permissions when narrower ones will work.

For collaborative products, we also need team roles, spending limits and understandable activity records. A company using a shared workspace should not have to share one private key among colleagues to get work done.

Put only the necessary work on-chain

Our architecture follows the trust model. We reserve on-chain execution for state and rules that participants need to verify independently, such as settlement, ownership or collateral conditions.

Search, notifications, analytics and much of the application experience can remain off-chain. Large datasets, personal information and hardware telemetry usually require more careful storage choices than a public ledger allows.

Google Cloud is our preferred starting point for application infrastructure, with AWS or Azure also appropriate when project requirements call for them. Managed services can support APIs, queues, databases and observability, but they do not make the overall system decentralized.

We document those dependencies, including indexers, RPC providers, administrator keys and external data sources. For hardware-connected products, we also ask how the system knows a physical event really happened. A blockchain preserves submitted records; it cannot independently establish that a sensor told the truth.

Launch with limits and measurable questions

Before a public rollout, we want independent security review, contract tests, access-control checks and a plan for responding to incidents. Audits reduce risk; they do not eliminate it.

We prefer staged exposure with explicit limits over an unrestricted launch justified by urgency. Where practical, we test the economic rules in a controlled environment before introducing transferable rewards.

We also seek qualified legal and tax advice in the jurisdictions involved. Token labels alone do not settle questions about securities, payments, consumer protection or reporting obligations.

Our success measures stay close to the product: completed useful work, repeat usage, service reliability, dispute rates and revenue relative to ongoing rewards and costs. We examine whether participants return when incentives decline. Token price may affect operations, but it should not become our only measure of progress.

A short checklist before we commit

Before approving a token design, we check that we can answer these questions clearly:

• What useful job does the product perform without price appreciation?
• Why is a new token better than simpler alternatives?
• What rights and obligations does each participant receive?
• What funds rewards after launch subsidies decline?
• How can participants exploit the incentive rules?
• Who controls upgrades, treasury assets and emergency actions?
• Can the product operate through falling demand and rising costs?
• Are security, legal review and user support funded?

An unanswered question is not always a reason to stop. It is a reason to investigate before creating irreversible commitments.

Tokenomics works best when we treat it as part of product engineering: connected to customer needs, constrained by real costs and tested against unfriendly conditions. At Kordspace, we bring software, AI, Web3, hardware and design together around those practical questions. If we can help turn an idea into a useful, durable product, start a project with us or explore our related services.