Planned — not live — not an offer
$BASIS is a planned work-request token for coordinating public verification demand. It is not live: no contract exists, no date is set, and nothing here is an offer — no solicitation or invitation to buy any asset in any jurisdiction, no financial or investment advice. Mechanics and parameters are provisional. By design, $BASIS can pay for, prioritize, request, challenge, or fund verification work — and can never buy labels, scores, corrections, source treatment, report outcomes, or favorable coverage.
Economic model · planned
A token that funds verification without corrupting it
Basis launched with a published commitment: no token, ever — reasoning that an auditor whose own asset depends on the audited ecosystem is structurally conflicted. That reasoning was correct, and we have revised the position anyway — publicly, in writing, the way Basis treats every correction. RFC-001 quotes the original commitment verbatim, grades our own reversal under our own taxonomy (where the old claim now reads as disputed — critics are right about that), and explains what changed: coordinating public verification demand at agent scale needs a permissionless rail, and the conflict is better carried openly and instrumented than avoided.
What survives unchanged is the constraint set. The design below is the only model that survived adversarial review by independent tokenomics, game-theory, legal, and audit-integrity analyses — alongside what those reviews rejected.
The constraint that governs everything
A token may pay for, prioritize, request, challenge, or fund verification work. It may never buy a favorable label, suppress an unfavorable one, alter the Claim Reliability Index, influence evidence grading, or give holders control over any audit outcome. Any mechanism that conflicts with that sentence is rejected — that sentence wins.
The planned model: a work-request token
Working shape (all parameters draft; candidate venue: Virtuals — staged path under preparation, see the conflict regime): a fixed-supply token whose entire utility surface is demand for verification work.
- Burn-to-request. Anyone could burn tokens to file a public audit request naming a project or topic — never an enumerated claim list; Basis selects the claims. The burn is an anti-spam filter and a public demand signal, not a payment for results. Requesting work would guarantee neither coverage, nor timing, nor any particular outcome.
- A public, capped queue. Requests would enter a fully public work queue with logarithmic, capped priority weighting — a whale's advantage is sublinear and can never outrank editorial priority. Per-project rate caps prevent both self-promotion flooding and harassment of rivals.
- A guaranteed free track. A hard-floored majority of analyst capacity (draft: ≥50%, reported publicly) would remain reserved for unrequested, editorially chosen coverage — so coverage is never gated and the registry never becomes a record of only what payers wanted examined.
- Disclosure on every funded record. Any dossier produced under a token-funded request would carry a permanent, hash-anchored disclosure: who requested, how it was funded, with the standard restatement that evidence standards are identical for requested and unrequested work.
- Corrections stay free, forever. The correction process never requires a token, a wallet, or an account. If challenge bonds are ever researched further, they could buy a faster review window — never a different standard, a different decision-maker, or a paywall in front of the free path.
- USDC remains the business. Token burns destroy value; they cannot pay an analyst. Serious diligence work would continue to be funded in USDC. The registry is designed to be indifferent to the token's price: if the token went to zero, every mechanism degrades to exactly the system that exists today.
What the research rejected
The rejections are the point — they are the firewall, published:
- Pay-per-label or any 'verified tier'rejected — sells the invariant
- Governance over findings, labels, CRI weights, or evidence gradingrejected — holder capture of outcomes
- Revenue routing to the token (fee share, buyback-burn, staking yield)rejected — value-accrual mechanics and securities-style risk
- Token-gated reports, API, or correctionsrejected — the registry is the public good; gating inverts the mission
- Airdrops or points to covered projectsrejected — makes audited parties holders on day one
- Prediction markets on forthcoming labelsrejected — turns unpublished findings into tradable information
- Transferable reviewer reputationrejected — credibility for sale
- Paid de-prioritization, delay, or private auditsrejected — buying silence
Studied launch path: Virtuals — research
The operator's working assumption under study is a launch through the Virtuals Protocol launchpad on Base — evaluated as a venue, not announced as a decision, and not a partnership. Two things must be said in the same breath. First, the staged path under research enters Virtuals before any token: a Basis agent profile performing claim-verification lookups against the existing API, then ACP service listings (diligence intake, evidence packets) — distribution and demand proof with no token conflict. Second, the conflict is named, not managed quietly: Basis audits Virtuals, and Virtuals's own headline metric is currently labeled unverified in this registry. Launching there would create an economic relationship with an audit subject. The research requires a permanent conflict-disclosure regime — on the Virtuals dossier, on every Virtuals-launched project's dossier, and on any Basis launch communications — plus Basis entering its own registry as a covered project, with its own launch metrics published sybil-adjusted under the same methodology as everyone else's. If those safeguards cannot hold, the venue fails the front-page test and the path is rejected.
Status
- RFC-001: public position change from no-token (versioned, original preserved)live
- $BASIS planned work-request token (no contract, no date, not an offer)planned
- Virtuals Stage 1 — agent profile (operator runbook ready)planned
- Virtuals Stage 2 — ACP service listings, USDC, corrections always freeplanned
- Stage 3 tokenization — gated on G1 demand evidence + counsel gatesresearch
Full analysis in the whitepaper and the public research document in the repository (docs/BASIS_TOKEN_MODEL.md). Critique is welcome and will be treated like any other evidence: corrections@basis.watch.