The economics modelled before a line of Solidity.
Tokenomics design decides what a token is for, how much of it exists, what removes it from circulation, and who holds it when. neoModel™ simulates supply schedules, sinks, vesting, distribution, and treasury policy across ten thousand runs against your own activity data, then builds the contracts and launch infrastructure through the neoForge™ pipeline. You are the issuer; we are the engineers.
Circulating supply · 36 months
10k runs48.2M
peak circulating
0.34
redemption velocity
€482k
booked liability
10k
Monte Carlo runs per model
36mo
Standard projection horizon
0
Token positions we hold
6
Stages from brief to launch
Six stages from brief to launch
Token designs fail for reasons visible before launch: no sink, an unlock schedule nobody modelled, or a token with no job. Each stage below exists to surface one of those.
Step 1
What is the token actually for?
A token needs a job that a database row cannot do: a credible claim, a transferable right, a supply rule the holder can verify. If it has no such job, the engagement ends here with that finding in writing.
Step 2
Supply, sinks, and the balance between them
Emission rate, total cap, and what removes tokens from circulation. A token that is only ever earned inflates until it is worthless, so sinks are specified in the same session as emission.
Step 3
Distribution and vesting
Who receives what, when, and under what release schedule. Cliffs and vesting curves are modelled for their effect on circulating supply.
Step 4
Simulation against real behaviour
Agent-based simulation across ten thousand runs, parameterised from your own activity data where you have it: earn rates, redemption propensity, holding periods, expiry. The output is a distribution of outcomes with confidence bands.
Step 5
Stress and adversarial testing
What happens under a demand shock, a whale exit, a farming attack, or a bug that mints unexpectedly. A design that only works when everyone behaves reasonably does not work.
Step 6
Implementation and launch infrastructure
Contracts, vesting schedules, treasury controls, distribution mechanics, and reporting, built through the neoForge™ pipeline with its audits and timelocks. You are the issuer throughout.
What goes into the model
A supply projection is only as good as the behaviour assumptions underneath it. These four are where projections most often go wrong, so they are modelled explicitly.
Participant models
Distinct agent types with different earn rates, redemption propensity, and holding behaviour, calibrated against your own cohort data.
Sink capacity
How much a sink can absorb. A redemption path nobody uses is not a sink, and modelling it as one is how supply projections go wrong by an order of magnitude.
Vesting & unlock cliffs
Release schedules modelled for their effect on circulating supply at each unlock, including the behaviour of recipients who have been waiting for it.
Liability accounting
Outstanding tokens expressed as a balance-sheet obligation across the projection, so finance sees the number before launch.
What you receive
The division of responsibility, stated up front
Token work goes wrong when a vendor drifts across the line between engineering and issuance. The line is written down before an engagement starts.
| Responsibility | Held by | Detail |
|---|---|---|
| Token design | aineobit | Modelling, simulation, parameter recommendation |
| Legal classification | Your counsel | We supply the technical description; counsel opines |
| Contracts & infrastructure | aineobit | Built, audited and handed over through neoForge™ |
| Issuance | You | You are the issuer of record, always |
| Authorisation | You | Any licence or registration is held by you |
| Distribution & marketing | You | We do not market, solicit or promote an offering |
| Holder relationship | You | Support, disclosure and obligations sit with the issuer |
What we build for the launch itself
Everything below runs through the neoForge™ pipeline (specification, invariants, three independent audits, timelocked deploy), because launch contracts hold other people's money on their busiest day.
Vesting & cliffs
Release schedules enforced by contract, with every recipient's position publicly verifiable against the published schedule.
Treasury controls
Multi-signature or MPC control over issuance and treasury movement, with policy limits, allowlists, and timelocks: the same neoVault™ machinery used everywhere else.
Supply reporting
Circulating supply, burn rate, redemption velocity, and booked liability, published on a fixed cadence so holders and finance read the same numbers.
The token work we turn down
The boundaries are explicit because this is the service where engineering and promotion are easiest to confuse.
We do not raise money for anyone
We design the economics and build the infrastructure. We do not market a sale, solicit investors, run a public offering, or introduce you to buyers. The client is the issuer of record and holds any authorisation the offering requires.
We take no token position
No allocation, no warrant, no advisory grant in what we help design. We are paid in currency for engineering work.
We do not design for price appreciation
If the brief is a mechanism whose purpose is to make the token's price rise, we decline it. Designs whose value proposition is a return are securities in most jurisdictions.
We will tell you not to launch
A meaningful share of these engagements conclude that a token adds nothing the client cannot achieve with a loyalty ledger and better product. We deliver that conclusion in writing.
What founders and CFOs ask
No. We design the token economy and build the contracts, vesting schedules, treasury controls, and reporting infrastructure behind a launch. You are the issuer of record, you hold any authorisation, and you run the distribution. We take no token position.
Find out if the token needs to exist
A working session with the people who build these: the job the token is meant to do, the sinks that would have to absorb it, and a first read on whether a loyalty ledger would serve you better.