SimulationNothing here touches a chain. Every figure is generated by the in-browser engine.

31 Jul 2026

Specification · v1 draft

The $KOINK Standard

Six invariants, each stated as something testable rather than as a value. A chain that implements them correctly is compliant. The Standard is CC0 and fork-ready — every compliant deployment finds edge cases, and the Standard only gets stronger for it.

Two layers, kept separate

Core — chain-neutral: The six invariants, the parameter schema, the attestation format and the tier definitions. No chain-specific concept appears here.
Bindings — chain-specific solana-v1 live: How the invariants are realised on a given chain. A binding may satisfy an invariant differently; it may not weaken it. An EVM binding is specified but not deployed, and is rendered as specified — never as live.

The six invariants

K-1

Fair launch by verifiable randomness

During a launch's opening window, purchase intents are accepted as sealed commitments. Execution order is determined by randomness that no participant, no deployer, and no operator can predict or influence at commit time, and that any observer can verify after the fact.

Testable: Given the commitments and the published randomness, an independent party recomputes the fill order and gets the same answer. Given the state at commit time, no party can predict that order better than chance.

Not satisfied by: First-come-first-served, priority fees, block ordering, or any randomness derived from data known at commit time — slot hashes, blockhashes and timestamps are all influenceable by a block producer.

A raise takes what it asked for. Commitments beyond the goal are refunded in full — a commitment is always either filled or returned, and silently retaining an unfilled one is a violation of this invariant, not an edge case.

K-2

Community allocation is always the largest

No single allocation may exceed the community allocation. The deployer's allocation is capped and enforced by the program, not by policy.

Testable: The sum of non-community allocations at launch is less than the community allocation, checked on-chain at initialization. A launch that violates it cannot be created.

K-3

Anti-whale is structural, not punitive

Accumulation beyond the per-address cap during the launch window is impossible, not penalised. After the window, exit routing is a function of holding duration.

Testable: A transaction that would push an address over the window cap fails. Post-window, exit routing is a pure function of amount and holding duration, with no discretionary input.

This is not punishment. This is physics. A physical system does not punish water for flowing downhill — it routes the flow.

K-4

Governance weight from contribution, not balance

Voting weight over a project's milestone approvals, parameters and treasury is a function of contribution and conviction, not of balance alone. Balance alone cannot produce governance dominance.

Testable: Doubling an address's balance does not double its weight; weight is bounded above as a function of balance. Long-duration holding and verified contribution increase it, to a ceiling of 3× at twelve months.

K-5

Treasury is community-governed and legible

A fixed share of launch and exit flow accrues to a treasury that the community governs under K-4. Every outflow is on-chain and attributable.

Testable: The treasury inflow share is a program constant. No address can move funds without a passing vote. Every historical outflow is reconstructible from chain state.

K-6

Raised capital is milestone-gated

A funded project does not receive its raise. It receives a tranche when holders approve, under K-4, the deliverable that tranche was raised against. Unreleased capital is withdrawable by no party, including the protocol. A rejected tranche returns to backers, not to the team.

Testable: At any point, withdrawable(project) = the sum of tranches whose milestone is approved. No instruction transfers unreleased treasury to the deployer. A rejection credits backers pro-rata and cannot credit the team.

Not satisfied by: Releasing the full raise at launch, a team-controlled multisig holding the treasury, or milestones a team can add, reweight or reword after backers have committed against them.

This is the invariant the category does not have, and it is the one that turns “trust the team” into “the money is not there to take”.

Compliance tiers

A tier is asserted by the deployer and verified by an on-chain attestation anyone can recompute from chain state. A false claim is publicly falsifiable — that is the enforcement mechanism, and it is a better one than review. K-6 sits in Bronze deliberately: milestone gating is the floor of what makes a raise here legitimate, not an advanced feature.

Bronze

K-2, K-3, K-6

Listed in the registry

Silver

Bronze + K-1 + K-5

Registry placement and ecosystem grant eligibility

Gold

Silver + K-4 + published audit + open-source deployment

Registry, grants, featured placement and a treasury match

The proof ladder

Every claim starts at the bottom. The job is to push each one as high as it goes — and to show which rung it is on. A system that labels its weak claims weak is more trustworthy than one that calls everything proof.

AssertedThe team said so. No verification of any kind.
Where most of this industry operates. Nothing here should stay.
AnchoredA content hash committed on-chain at a known time.
Proves what existed and when — not that it is any good. Git is already content-addressed, so a commit SHA anchored at submission means a later force-push no longer matches what was approved.
AttestedAn independent party with something at stake signed a finding.
Trust-minimised rather than trustless. This is the permanent ceiling for physical-world claims — cryptography cannot prove a workshop was built or a well was dug.
VerifiedDeterministically checkable by anyone, with no trusted party.
A reproducible build whose digest matches, an on-chain balance, a zero-knowledge proof.

Anyone claiming end-to-end cryptographic proof of real-world impact is lying. What can be made provable is the chain of custody around a claim: who attested, when, what they staked, and whether they have been wrong before. That is the honest target.

Commit volume, repository count and every other code-shaped productivity proxy are deliberately excluded from the accountability grade. They are trivially padded, and rewarding them would bias the platform toward software against the physical, resource and intelligence work it also exists to fund.

What a project token is never

A project token confers governance over tranche release, and nothing else. It is never a claim on project revenue, never a share of profit, never a buyback target, never a dividend, and never a redemption right against the project treasury.

Tokens are freely tradable — an illiquid position helps nobody, and conviction is bound to the wallet rather than the token, so trading does not weaken it. What is ruled out is the token becoming a claim on someone else's output. A project that wants to reward its backers does it with what it makes: access, goods, standing, the thing it was funded to build. Never with a distribution.

This is enforced in the program, not in terms of service. No instruction routes project treasury to token holders pro-rata.

Honest answers

The weaknesses, stated plainly. A fairness claim that hides its own limits is not one.