Programmable EVM token economics

Token economics, in closed form.

Authorized revenue enters an isolated vault, verified rules decide, and bounded contracts execute — every step simulated first, every limit written down.

  • Ethereum· configured, not live
  • Base· configured, not live
  • BNB Chain· configured, not live
  • Arbitrum· configured, not live
Fee sourcePolicyRisk gateRouterReceiptTreasuryvaultx=sin(t+π/2) · y=0.56·sin(2t)

01 · The problem

Fees pile up. Policy should decide what happens next.

Static model

  1. 01Trading activity
  2. 02Revenue
  3. 03Passive treasury

Programmable model

  1. 01Authorized revenue source
  2. 02Vault
  3. 03Verified rules
  4. 04Controlled actions

Important: none of this happens automatically. Revenue only reaches a vault if the token, pool or owner is wired to send it there. An existing immutable ERC-20 cannot gain a transfer tax — quantumOS detects what is actually possible and falls back to a voluntary treasury route.

02 · Architecture

Eleven parts. Click any of them.

Select a node to read what it does, what it needs, the math inside it and how it can fail. Then send a simulated transaction through the graph.

Token / PoolFee CollectorIsolated VaultPolicy EngineRisk ControllerExecution RouterTreasuryLiquidityBuybackBurnRewards
simulation only — nothing is sent on-chain

03 · Economic playground

Change a number. Everything recomputes.

Real calculations from your inputs — no canned values. Revenue is hypothetical until a real fee source is connected.

Inputs

Share of fees actually routed to the vault.

Gas for the day's operations.

Manual input — no live feed connected.

Allocation (must total 100%)

Σ = 100%

Revenue → budgets hypothetical model

Rgross=V τ cR_{gross}=V\,\tau\,c
$1,000,000.00 × 0.02 × 0.75 = $15,000.00
Rnet=max⁡(0, Rgross−C)R_{net}=\max(0,\,R_{gross}-C)
$14,820.00
Smax=T−TminS_{max}=T-T_{min}
$70,000.00
  • Buyback 30%$4,446.00
  • Liquidity 25%$3,705.00
  • Treasury 35%$5,187.00
  • Rewards 10%$1,482.00

Rounding: largest-remainder in micro-USD; residual = 0 µUSD. Real revenue depends on the token's fee mechanism and the pool integration — nothing here is observed on-chain.

Buyback against a constant-product pool

Quote in Δx
1.482 ETH
Tokens out Δy
14,560.4022
P_spot = x/y
0.0001 ETH
P_exec = Δx/Δy
0.00010178 ETH
Impact incl. LP fee
1.7829%
Impact excl. LP fee
1.4776%

Valid for Uniswap V2-style pools only. V3/V4 concentrated liquidity needs tick-level math and is not approximated here.

Monte Carlo treasury path

800 paths, seed 42, log-normal volume, liquidity shocks on. Band = empirical 5th–95th percentile.

Simulated treasury value over time: 5th to 95th percentile band, median line, and reserve floor.$30k$103k$177k$251k$325kday 30
P5 end
$243,433
Median end
$271,227
P95 end
$304,321
Floor breach
0%

Outcome distributions follow from the assumptions above. They are not predictions and not a guarantee of any return.

04 · Strategy constructor

Rules with limits, not scripts.

Conditions and actions come from a fixed list. Every action needs a percentage and a hard USD cap. There is no arbitrary-call action.

Weekly buyback

IF (all of)

hours
USD

THEN

% of net, hard cap $
Defend liquidity

IF (all of)

USD

THEN

% of net, hard cap $
High-volatility reserve

IF (all of)

% ann.

THEN

% of net, hard cap $

Policy check

Policy valid · every action has a % share and a hard USD cap

Dry-run against a market state

  • Weekly buybackfires · $4,446
    ≥ 24h since last run → true · treasury > $60000 → true
  • Defend liquidityfires · $3,705
    liquidity < $80000 → true
  • High-volatility reservefires · $5,187
    volatility > 80% → true

Dry-run only. Nothing is signed or sent; on-chain execution would re-check every limit.

Policy JSON

{
  "version": 1,
  "reserveFloorUsd": 50000,
  "maxSlippagePct": 0.5,
  "rules": [
    {
      "id": "r1",
      "name": "Weekly buyback",
      "when": [
        {
          "type": "interval_elapsed",
          "value": 24
        },
        {
          "type": "treasury_gt",
          "value": 60000
        }
      ],
      "then": {
        "type": "buyback",
        "pctOfNet": 30,
        "maxUsd": 5000
      }
    },
    {
      "id": "r2",
      "name": "Defend liquidity",
      "when": [
        {
          "type": "liquidity_lt",
          "value": 80000
        }
      ],
      "then": {
        "type": "add_liquidity",
        "pctOfNet": 25,
        "maxUsd": 4000
      }
    },
    {
      "id": "r3",
      "name": "High-volatility reserve",
      "when": [
        {
          "type": "volatility_gt",
          "value": 80
        }
      ],
      "then": {
        "type": "allocate_treasury",
        "pctOfNet": 35,
        "maxUsd": 10000
      }
    }
  ]
}
Import policy JSON

05 · Intelligent systems

Four systems. One rule: AI proposes, code decides.

Measures what can be measured: returns, realized volatility, TWAP. It does not predict price or identify bot owners.

synthetic seeded sample — not market data

Obs.
31
σ annualised
74.1%
TWAP (equal Δt)
0.8427
Last / TWAP
0.86%
Mean log-ret
-0.542%
A used
365

Historical volatility estimates the past. It does not predict price, and A must match the true sampling interval.

06 · Real execution

From proposal to receipt.

This pipeline is a simulation. A simulated step is never shown as confirmed on-chain.

  1. 01
    Proposal
    idle
  2. 02
    Simulation
    idle
  3. 03
    Validation
    idle
  4. 04
    Authorization
    idle
  5. 05
    Execution
    idle
  6. 06
    Receipt
    idle

transaction hash: — none · no transaction is broadcast from this page

Pick a failure point or run the happy path.

07 · Mathematical laboratory

Every formula, with units and a live example.

Captured fee revenue

Rgross=V τ c[USD/day]=[USD/day]⋅[1]⋅[1]R_{gross}=V\,\tau\,c\qquad [\text{USD/day}]=[\text{USD/day}]\cdot[1]\cdot[1]

Volume times fee rate times the fraction of fees your vault actually receives. If c is zero, so is revenue — capture depends entirely on the integration.

1,000,000 × 0.02 × 0.75 = $15,000 / day

Limits: A hypothetical accounting model. Real revenue is the measured balance delta at the collector.

Constant-product swap

Δy=y Δx(1−f)x+Δx(1−f),Pspot=xy,;Pexec=ΔxΔy\Delta y=\frac{y\,\Delta x(1-f)}{x+\Delta x(1-f)},\quad P_{spot}=\tfrac{x}{y},; P_{exec}=\tfrac{\Delta x}{\Delta y}

You receive slightly less than the spot price implies, because your own trade moves the pool, and the LP fee is taken off the input first. The two effects are shown separately.

Δy = 1,000,000·0.997 / (100+0.997) = 9,871.58 tokens
impact incl. fee 1.3009% · excl. fee 0.997%

Limits: Uniswap V2-style pools only. V3/V4 concentrated liquidity needs tick-level math.

Gas, exactly

costwei=GasUsed×EffectiveGasPricewei/gas,1 native=1018 wei\text{cost}_{wei}=\text{GasUsed}\times\text{EffectiveGasPrice}_{wei/gas},\quad 1\,\text{native}=10^{18}\,\text{wei}

Computed with BigInt so no precision is lost. Gas price is entered in gwei (10⁹ wei).

wei = 185000 × 80000000 = 14800000000000
native = 0.0000148
USD ≈ $0.0444

Limits: On L2s (Base, Arbitrum) total cost also includes an L1 data fee, which this calculator does not include. Prices here are manual inputs — no live source is connected.

Reward split with explicit residual

Rewardj=⌊R wjW⌋,residual=R−∑jRewardj\text{Reward}_j=\left\lfloor\frac{R\,w_j}{W}\right\rfloor,\quad \text{residual}=R-\sum_j \text{Reward}_j

Integer division rounds down, so a few base units are left over. quantumOS tracks that residual instead of losing it.

shares = [33, 33, 33] · residual = 1 base units

Limits: Real distributions use snapshots and a Merkle root so holders claim — looping over all holders on-chain is impractical.

Binary encoding for QUBO

ai≈∑k=0K−12kzi,kM,M=2K−1,;z∈{0,1}a_i\approx\frac{\sum_{k=0}^{K-1}2^k z_{i,k}}{M},\quad M=2^K-1,; z\in\{0,1\}

Each allocation weight becomes K bits. The more bits, the finer the grid, but the more variables the optimizer must search.

resolution 1/15 = 6.667% · 4 actions → 16 binary variables · 65536 bit strings

Limits: Penalty terms do not guarantee feasible output. Every solver result must pass deterministic validation.

08 · Trust and transparency

What exists, and what doesn't.

This page lists what is a design target and what is simply not there yet.

Smart contractsNot written or deployed yet. No addresses are shown because none exist.not available
Independent auditNone. Nothing on this site should be read as audited or safe.not available
Contract verification linksWill appear here per chain once real deployments exist.limitation
Permission modelDesign target: project, platform, governance, emergency and keeper roles kept separate; no single admin over all funds.design target
Treasury limitsDesign target: per-action budgets, daily caps and a reserve floor enforced in the vault, not only in the UI.design target
TimelocksDesign target: loosening limits or changing adapters is delayed; tightening and pause can be immediate.design target
Emergency pauseDesign target: scoped to halting execution. It must not grant a way to withdraw other people's funds.design target
Chain limitationsEthereum, Base, BNB Chain and Arbitrum differ in fee accounting, finality and available infrastructure. L2 costs include L1 data fees.limitation
Existing tokensImmutable ERC-20s cannot be given transfer taxes. They can only use a voluntary treasury route.limitation
Uniswap V4Hooks are fixed at pool initialization and cannot be attached to an existing pool. Dynamic LP fees are not token taxes.limitation
ReturnsNo yield, price support or return is promised. Simulations depend on stated assumptions.not available

Define it.
Simulate it.
Bound it.

Frontend preview. No wallet, contract or chain is connected yet.