Verifiable tokenomics: commit your design, prove it later

A vesting schedule is a promise. But a promise you can quietly change isn’t worth much — and in 2024–25 plenty of teams did exactly that, pausing or reshaping their unlocks mid-flight when the market pushed back. The problem isn’t that tokenomics change. It’s that there’s usually no way to prove what was promised in the first place.

Every other tokenomics tool stops at a chart. We added the missing step: a way to commit a design and prove it later. Here’s what that means and how to use it.

What a commitment is

A commitment is a SHA-256 fingerprint of your tokenomics — taken at a point in time. We don’t hash the pretty picture; we hash a canonical form of the design: allocations, percentages, vesting, cliffs, supply, liquidity — normalized so that the same economics always produce the same fingerprint, regardless of colours, notes, ordering, or drafting metadata.

Change one number — team from 20% to 21%, a cliff from 12 months to 6 — and the fingerprint changes completely. That’s the whole point: the hash is a tamper-evident seal. Publish it, and anyone can later check whether a design still matches it.

How to commit a design

In the visual studio, it’s one click: Commit in the workspace bar produces a certificate — the hash, a health-score and float summary, a timestamp, and the canonical design itself. Download it, or copy the hash to publish in your docs, your data room, or a disclosure filing.

Through an AI agent, it’s one tool call:

{
  "name": "commit_design",
  "arguments": { "design": { /* your tokenomics */ } }
}
// → { hash: "cab3d1ba…", summary: { healthScore: 88, … },
//     committedAt: "…", canonical: { … } }

The record is self-verifying: because it carries the canonical design, anyone can re-derive the hash and confirm it — offline, with no server, and no need to trust us.

How anyone proves it

Send someone the record (or just the hash) and they can check it in two ways at /verify:

• Integrity — recompute the hash from the record’s canonical design and confirm it hasn’t been altered since it was committed.
• Match & drift — paste the project’s current design and confirm it’s the exact one that was committed. If it isn’t, you get a field-by-field list of what changed.

Agents do the same with one call:

{
  "name": "verify_design",
  "arguments": { "design": { /* … */ }, "expectedHash": "cab3d1ba…" }
}
// → { match: true, computedHash: "cab3d1ba…" }

What it proves — and what it doesn’t

A commitment proves which tokenomics a project disclosed, and lets anyone detect if it later changed. That’s a real accountability primitive: a founder can show investors exactly what they signed up for, a community can hold a team to the design it launched with, and a disclosure can point to a fingerprint anyone can check.

It does not enforce the schedule on-chain — that’s execution, a separate layer (the vesting contracts). And it is not legal or regulatory advice. We’re the disclosure-and-provenance layer: you commit, you prove, you own the record. An independent on-chain time anchor is the next step on our roadmap.