Tokenomics & Ecosystem Design
Token models that hold under their own incentives
Where utility, demand and product logic are one system — modelled as a queryable graph, not a spreadsheet, and stress-tested before a line of the contract is written.
Most token designs are a spreadsheet of allocations and a vesting chart. That can't answer the questions that decide whether an economy survives: which holder clusters could collude to reach a governance threshold, where an incentive loop feeds back into itself, or whether insiders still control the vote a year after unlock. We model the ecosystem as a graph — holders, contracts, treasuries and governance paths as nodes and edges — so those become a single query, then simulate the dynamics before launch.
The token is bolted on
Utility gets designed after the product, so the token has no job the product actually needs — and no reason for anyone to hold it.
Structure is invisible
A cap-table lists who holds what. It can't show which holders could combine to control a vote, or where an incentive loop feeds itself.
Untested under real dynamics
Allocation tables look fine statically. Nobody simulates the unlock cliffs, emissions and sell pressure interacting over the first year.
Launched on a calendar, not a signal
The TGE date is set before the product has demand, so the economics have to be defended rather than demonstrated.
What we build
Graph-based token modelling
Holders, contracts, treasuries, incentive loops and governance paths modelled in Neo4j + Cypher and rendered with @xyflow — a queryable model, not a static spreadsheet.
Governance-capture analysis
Collusion reachability, whale concentration and quorum stress-tests run as graph traversals and GDS algorithms — surfacing capture risk a flow model can't see.
Simulation & scenario testing
radCAD Monte-Carlo seeded from the live graph — unlock schedules, emissions and sell pressure run across hundreds of scenarios, written back as auditable results.
Utility & incentive design
Token utility, vesting/unlock schedules and incentive alignment designed as one system with the product — with a TGE gate tied to real product metrics, not a calendar.
What you walk away with
Deliverables, not a slide deck.
- A queryable Neo4j model of your ecosystem — holders, contracts, treasuries, incentive loops, governance paths
- Allocation, vesting and emissions schedules designed against the product, not a template
- A governance-capture analysis: who could reach quorum, and when
- radCAD Monte-Carlo results across hundreds of unlock/emission/sell-pressure scenarios
- Machine-checked invariants (zero-row Cypher assertions) you can run in CI
- A written design rationale — and a TGE gate tied to real product metrics
How we engage
Discovery
We map the ecosystem, the incentives, and where structure decides the outcome.
Model & simulate
We build the graph, run governance-capture traversals and Monte-Carlo simulation.
Recommend
A scored design and a go/no-go — including 'delay the launch' when the model says so.
Where it matters most
The situations this is built for.
Pre-TGE design
You have a product and need a token model that survives contact with its own incentives — before the allocation is public.
Fixing a live economy
The token launched and the incentives aren't behaving. We model what's actually happening and where the loop breaks.
Raising, and being asked hard questions
Investors and exchanges probe governance concentration and unlock pressure. A queryable model answers with evidence, not assertion.
RWA / permissioned tokens
Compliance constraints are part of the economics. We model eligibility and transfer rules as graph structure, not prose.
Proof
DevGuild's $GUILD economy, modelled as a graph and stress-tested with Monte-Carlo simulation — the model showed insiders would still hold a majority of the float a year after launch, far above the 5% quorum. We recommended delaying the launch.
Questions
Model it. Prove it. Then launch.
Tell us what you're building. We'll come back with a tailored proposal.
Book a technical call