Tokenomics work starts with operating assumptions, not spreadsheets
Most tokenomics engagements lose value before the first model is built. The failure point is usually simple: the project has not made the business, governance, and jurisdictional decisions that the token model is supposed to express. Token engineering is explicitly a systems discipline that spans mechanism design, implementation, and legal, organizational, and business contexts, not just emissions math.
A consultant can help you test trade-offs. A consultant cannot responsibly invent your business model, guess your regulatory perimeter, and reverse-engineer your operator privileges from a pitch deck. If those inputs are missing, the engagement turns into paid discovery. That is expensive. It also tends to produce a token design that is flexible in the wrong places and under-specified where accountability matters.
At FinDaS, the best pre-engagement preparation looks less like a marketing brief and more like a decision pack. Founders who arrive with documented assumptions get sharper answers on utility, emissions, treasury policy, governance scope, and launch sequencing. Founders who arrive with loose narratives usually get multiple rounds of reframing before the real design work starts. If you need a baseline before that process, start with understanding tokenomics.
What you should have ready before the first call
| Document or input | Why it matters | What happens when it is missing |
|---|---|---|
| Business model | Defines what the product does, who pays, what value is created, and whether a token is even economically necessary | The consultant ends up modeling incentives around an undefined product or defaulting to generic token utility |
| Target users | Determines which behaviors you want to attract, reward, or restrict | Emissions, staking, referrals, and governance rights get designed for the wrong actors |
| Revenue streams | Clarifies where value accrues and whether the token should capture, direct, govern, or ignore that value | The design confuses protocol activity with token value capture |
| Competitive landscape | Shows which adjacent models are working, failing, over-incentivizing, or hiding control risk | The engagement drifts into copy-paste tokenomics from unrelated peers |
| Fundraising goals | Sets constraints around allocation, unlocks, liquidity, runway, and investor expectations | Distribution gets backsolved from financing pressure instead of protocol needs |
| Existing token concepts | Lets the consultant evaluate what you already believe instead of rediscovering it from fragments | Early workshops are spent extracting scattered ideas rather than stress-testing them |
| Legal jurisdiction | Changes entity requirements, disclosure obligations, offering structure, and go-to-market options | You may model a launch that is unusable in the markets you actually care about |
| Control surface map | Documents admin keys, upgrade paths, pause rights, treasury permissions, oracle control, and multisigs | The token model ignores the most important source of discretionary risk |
If you do not have final answers, that is fine. A serious prep package can still use TBD entries. The key is to mark each unknown with an owner, a date, and the decision that depends on it.
Document the business model, target users, and revenue logic first
The business model is the first filter for whether a token should exist at all. A token cannot repair weak demand, low margins, or a product that nobody needs. It can only reallocate rights, obligations, and incentives around those facts.
Your business model memo should answer five things in plain language. What does the product do. Who uses it. Who pays. What triggers payment. Why does blockchain infrastructure improve the product rather than decorate it. If those questions are still abstract, any token economy design will be mostly speculative.
Revenue streams matter because different protocols capture value in structurally different ways. Uniswap Labs states that its interface fee is separate from the Uniswap Protocol fee switch, which is governed separately. That separation is a reminder that product revenue, protocol revenue, and tokenholder economics are not automatically the same thing.
dYdX makes a different design choice. The dYdX Foundation says staking rewards on the dYdX Chain are derived from protocol activity and frames DYDX as a Layer 1 utility token rather than a pure governance asset. Maker documents yet another structure, where MKR holders vote on protocol risk and business logic, and governance can enable surplus auctions tied to protocol fees.
Those examples matter because they show how business logic drives token function. If you have not documented your own revenue logic, a consultant cannot tell you whether the token should govern fees, receive emissions, serve as collateral, gate access, or stay completely outside the cash flow path.
Target users are equally important. Reward design is behavior design. You should identify your primary user groups, the actions you want from each group, the behaviors you want to discourage, and the friction each group will tolerate. Optimism’s OP documentation is a useful illustration of explicit segmentation: it separates community allocations, ecosystem funding, user airdrops, core contributors, and investors, and links different distribution programs to different types of participation.
When this material is missing, the usual result is overbroad utility. The token ends up trying to be governance, rewards, access, collateral, referral credit, and treasury instrument at the same time. That makes the system harder to explain and easier to manipulate.
Bring a competitive map that compares mechanisms, not just narratives
A useful competitive landscape is not a list of projects with similar branding. It is a comparison of mechanism choices under similar business constraints. The consultant needs to know which peers monetize at the interface layer, which monetize at the protocol layer, which direct value to treasury, which use staking for security, which use governance only, and which still rely on operator discretion despite decentralization claims.
The comparison should include at least four to eight relevant protocols and a short note for each on token utility, value capture, emissions, governance scope, upgradeability, and lockup structure. The point is not to copy them. The point is to understand what design problem each model is solving.
This is where many teams discover that “our competitor has a token” is analytically useless. Uniswap, dYdX, Maker, and Optimism all use tokens, but the rights attached to those tokens are materially different. The result is that copying a surface feature from one of them can import a completely different control structure than the one your business can tolerate.
The competitive map should also note where peers rely on discretionary bodies. A DAO with a timelock and narrow upgrade power is not equivalent to a multisig that can rewrite implementation contracts, pause transfers, or redirect treasury spend on short notice. From an operator-risk perspective, those are different assets.
If you skip this work, the engagement often gets trapped in imitation. That is how projects inherit emissions schedules, staking schemes, and governance rituals that were rational for another protocol and structurally wrong for their own.
Be explicit about fundraising goals, supply assumptions, and your first distribution plan
Fundraising goals are not a side note. They are one of the hard constraints on token design. Before meeting a tokenomics advisor, you should document how much capital you want to raise, on what timeline, from which buyer types, using which instrument, and with what expectations for liquidity and lockups.
That document does not need to be public-ready. It does need to be numerically coherent. Include current runway, treasury composition, planned raise size, use of proceeds, desired post-raise operating horizon, and any hard constraints around vesting schedules, float, treasury retention, or exchange liquidity.
Official token allocation disclosures show how much these choices shape the system. dYdX documents a 1,000,000,000 DYDX mint and a split across community, past investors, founders and staff, and future employees, with governance able to modify parts of the community allocation over time.
Optimism documents an initial supply of 4,294,967,296 OP, with allocations across ecosystem funding, RetroPGF, user airdrops, core contributors, and investors. Optimism also states that core contributor and investor allocations are subject to lockups and that the Foundation’s annual distribution budget is ultimately subject to tokenholder voting after the first year.
The lesson is not that one split is correct. The lesson is that allocation categories, unlock sequencing, and governance over reserves are first-order design variables. They are not formatting choices to be filled in after fundraising closes.
Bring your existing token concepts too. Even rough sketches are useful if they are written down. Include any views you already hold on supply cap, inflation, emissions, staking, burns, fee redirection, vesting, airdrops, liquidity incentives, and governance rights. A good consultant would rather critique a flawed draft than spend the first week extracting half-formed assumptions from meetings.
What usually goes wrong when this is missing is familiar. The token model gets forced to satisfy too many capital-market demands at once. Early investors want liquidity. The team wants runway. Users want incentives. The treasury wants reserves. Governance wants decentralization optics. Without a documented fundraising priority stack, the design becomes a negotiation artifact rather than a coherent operating system.
Set the legal perimeter and the control surface before discussing emissions
Legal jurisdiction changes the design space. In the European Union, MiCA has applied generally since December 30, 2024, with rules for asset-referenced tokens and e-money tokens applying since June 30, 2024. The EUR-Lex summary states that offerors of crypto-assets other than those categories must be legal persons and must publish a crypto-asset white paper and marketing communications on their website.
In the United States, the SEC issued an interpretation on March 17, 2026, effective March 23, 2026, addressing how federal securities laws apply to certain crypto assets and transactions. The SEC said the release provides a token taxonomy and explains how a non-security crypto asset may still become subject to, and later cease to be subject to, an investment contract analysis. The release also addresses airdrops, protocol mining, staking, and wrapping.
That is why jurisdiction belongs in the prep package. A consultant needs to know where the issuing entity sits, which markets you intend to target, whether counsel has already scoped restrictions, and whether your token concept assumes rights that create legal friction in your chosen markets. No tokenomics firm should be asked to solve that blind.
The control surface deserves equal priority. Admin rights, upgrade authority, pause rights, mint permissions, oracle replacement powers, and treasury keys are economic variables. They determine who can change the rules after users enter the system.
OpenZeppelin’s documentation is blunt on the point. Transparent proxies have an admin with upgrade rights, and the AccessControl docs warn that the DEFAULT_ADMIN_ROLE carries significant risk because it can manage every other role unless the system is restructured. OpenZeppelin even recommends extra controls such as delayed, two-step admin transfers.
Compound is a good example of what it looks like when control is mapped explicitly. Compound v2 documents governance through COMP, Governor Bravo, and a Timelock, with a minimum one-week change path. Compound III documents that the Timelock controls proxy upgrades and parameter changes, while a designated Pause Guardian can pause key protocol functions.
If you do not bring this map to a tokenomics engagement, you create a predictable blind spot. The model may look decentralized on paper while a small set of operators can still upgrade contracts, freeze flows, or redirect treasury assets. That is not a cosmetic detail. It changes how users price risk.
What to send before the first workshop
- A 2-5 page business model memo with product, customer, payer, pricing logic, and core unit economics
- A target user map with segments, desired actions, and the behaviors you want to reward or suppress
- A revenue memo showing current and planned revenue streams, including whether value accrues to protocol, company, treasury, or tokenholders
- A peer comparison sheet covering token utility, value capture, emissions, governance scope, upgradeability, and discretionary controls
- A fundraising brief with capital targets, timing, instruments, lockup expectations, and runway objectives
- A token concept note with any existing ideas on supply, emissions, staking, burns, vesting, airdrops, liquidity incentives, and governance
- A jurisdiction memo covering entity structure, priority markets, counsel status, and any known launch constraints
- A control map showing multisigs, admins, proxy ownership, pause roles, treasury permissions, oracle powers, and upgrade paths
That package is enough for a strong first pass. Once those inputs exist, a tokenomics consulting engagement can focus on mechanism quality, distribution efficiency, control minimization, and launch sequencing instead of basic extraction. That is the point where FinDaS-style token economy consulting becomes materially more useful: the conversation moves from “what are you building” to “which rights should exist, who should hold them, and which powers should be removed before users are asked to trust the system.”
If you prepare only one extra item beyond the standard checklist, make it the control surface map. Founders routinely treat admin and upgrade authority as implementation details. They are not. They are part of the asset.
