How the lab works.
Everything a result depends on, written down: the actors and their rules, the pool math, how a seed fixes a run, what the contract stores, and what none of it can tell you.
The model (nexrun-sim 1.0.0)
One run is a market around one launch, in steps that read as hours. The pool starts as you configure it. Then, every step:
- Snipers (step 0 only) buy a fixed ETH amount each, and sell everything at a target multiple of their entry or after a set number of steps.
- A shock, if you set one, happens at its step: a holder sells a share of supply at once, or a share of the pool's liquidity is withdrawn.
- New buyers arrive at a Poisson rate that fades by a factor each step. Each buys a log-normal ETH amount, with a chance that falls in a straight line from 100% at the launch price to 0% at a ceiling you set.
- Holders check their rule: panic sellers sell everything after a drop from their own peak; profit takers sell at a multiple of their entry; every holder also leaves with a small chance each step for reasons outside the price.
- Allocations (team, airdrop, whatever you list) sell a share of their balance each step after their unlock, while the price is above a floor you set.
Everyone who may act in a step is shuffled with the run's own random stream and acts in that order, checking its rule at its own turn. A run fails when it ends below a multiple of the launch price, falls more than a percentage from its peak, or a trade cannot fill because a v3 range ran out. You set the first two.
Reproducibility
All randomness comes from a 32-bit stream seeded by a hash of the seed text and the run number, and the model uses only +, −, ×, ÷ and square roots (its own exp and log are written that way), which every JavaScript engine rounds the same. So the same inputs, seed and run number give the same run in every browser and in Node. Run #n of a batch can be replayed alone. The report's result hash is the keccak-256 of the per-run results in canonical JSON (keys sorted, numbers rounded to 10 significant digits). The unit tests freeze one such hash; changing the model changes the version tag.
The pool math
- v2: constant product with the fee taken from the input,
out = in·(1−fee)·R_out / (R_in + in·(1−fee)), in integers. Equal to the Uniswap v2 router on Robinhood Chain to the wei for every captured vector. - v3, one range: the pool's own SqrtPriceMath steps (next price from amount, then the amount delta) in integers. Equal to the v3 QuoterV2 to the wei for every captured trade that stays between the nearest initialised ticks. A swap that crosses one changes the active liquidity, which this does not model; the Stress Test then shows the quoter's figure as the one to use.
- Inside a simulation the same formulas run in floating point for speed; a unit test keeps them within 1e-12 of the integer math.
Test vectors: scripts/capture-pool-vectors.mjs reads a v2 pair and two v3 pools on Robinhood Chain and the router's and quoter's answers for a ladder of trade sizes, all at one pinned block, into src/lib/fixtures/pool-vectors.json.
The contract: NexrunTrialRegistry
Not deployed yet. Until it is, the report page keeps practice records in your browser only.
- Labs: a namespace with admins and runners. The creator is the first admin; a lab can never be left without one.
- Models: a version tag and a code hash, registered once.
- Records: written by a lab's runner: config, scenario, result and report hashes, model, seed, run and failure counts, a link to the report file.
- Checks: a wallet other than the recorder re-runs the report and sends the result hash it got. Match: Reproduced. Any mismatch: Disputed, for good.
- Withdraw / supersede: the recorder or a lab admin can withdraw a record, or point a newer record at it. The old one stays readable.
It holds no funds and no tokens, has no owner, fee, pause or upgrade, and every function refuses ETH. Its tests cover the role rules, the state machine, input limits, fuzzed inputs and invariants (a lab always has an admin; checks are counted once; a withdrawn record stays withdrawn).
Limits
- A simulation does not create market demand. It can show where a launch design is weak; it cannot promise volume, a market cap or a community.
- Actors follow fixed written rules (rule-based agents). They are not people and not a forecast of how people will act.
- Results depend on the inputs. A scenario chosen to look good will look good: compare several scenarios, including harsh ones.
- The v3 pool is one liquidity range. Real pools may hold many positions; read a real pool on the Stress Test page instead.
- Gas, MEV, multi-hop routes and price oracles are not modelled. Fees inside the pool are counted, not paid out.
- Actors trade only against this one pool; arbitrage from other pools is not modelled.
Planned, not built
- AI-driven simulated agents, added only after the rule-based base is shown to be useful. planned
- Batch testing at scale on a server, an API with quota, simulation credits. planned
- $NEXRUN as a way to pay for those, priced by compute cost. The token is not needed for anything on this site, and its utility is unproven. planned
Questions
What does Nexrun do?
It runs a token launch design many times in a simulated market before any real money is used. You set supply, allocations, the starting pool and its fee, and a market scenario; Nexrun runs it hundreds of times with a seed and shows the range of outcomes, the runs that failed and why, and what large trades do to the pool.
Can a good simulation make my launch succeed?
No. A simulation does not create market demand. It can show where a design is weak (a pool too thin for the expected sells, an unlock that lands on a fading market), but it cannot promise volume, a market cap or a community. Treat every result as a range under the assumptions you chose.
Who are the simulated traders?
Rule-based actors: snipers at launch, buyers who arrive at a rate you set, holders who panic, take profit or simply leave, allocation holders who sell after their unlock, and an optional shock. Each follows one written rule, shown next to every action in the replay. No language model is used. AI-driven agents are planned, after the base math is proven useful.
Why ranges and not one chart?
One run is easy to pick so that it looks good. Nexrun runs the same inputs many times with different random draws and reports percentiles: the middle 50% and 90% of runs, the median, and how many runs failed the rules you set. Compare puts several designs under the same seed so they meet the same luck.
Is the pool math right?
The constant-product math is checked to the wei against the Uniswap v2 router on Robinhood Chain, and the one-range v3 math against the v3 quoter for trades that stay inside the active range. Those test answers were read from the chain at a pinned block and ship with the code. On the Stress Test page, real pools show our figure next to the chain's own answer, live.
Can someone else check my results?
Yes. A report carries the inputs, the model version and the seed. Anyone can re-run it and get the same result hash. Anchor the report on chain and a second wallet can record whether its re-run matched.
Do I need $NEXRUN to use it?
No. Everything on this site works without the token and without a wallet; a wallet is only needed to write a record on chain, which costs gas. Using $NEXRUN for simulation credits, batch testing or API quota is planned and unproven, and any such price would follow compute cost.
Is this financial advice?
No. Results describe a model under inputs you chose. They are not a forecast, not advice and not a recommendation to launch, buy or sell anything.