SimulationInteractive preview. Projects, balances and activity are simulated. No real funds, connected wallet or on-chain transactions.

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. Fork it, because every compliant deployment finds edge cases and the Standard only gets stronger for it.

Read every invariant below in the imperative. It is what a deployment must do, never a report of what one does. Nothing is deployed. No program implementing the Standard exists on mainnet or on a testnet, and no launch has ever run under 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 at all.
Bindings, chain-specific solana-v1 specified, not deployed: How the invariants are realised on a given chain. A binding may satisfy an invariant differently; it may not weaken it. Both the Solana and EVM bindings are written and neither is deployed, and both are rendered as specified rather than 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. Nothing more. Commitments beyond the goal are refunded in full, so a commitment is always either filled or returned, and silently retaining an unfilled one is a violation of this invariant rather than 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 the program enforces the cap. Policy does not.

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.

The cap is not a penalty. Nothing is confiscated. Nothing is fined. The transaction that would breach it simply does not execute.

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, not a review board, is the enforcement. K-6 sits in Bronze deliberately, because milestone gating is the floor of what makes a raise here legitimate rather than 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, then to show which rung it reached. That last part is the hard one. A system that labels its weak claims weak is more trustworthy than one calling everything proof.

AssertedThe team said so. Nothing more.
Where most of this industry operates. Nothing should stay here.
AnchoredA content hash committed on-chain at a known time.
Proves what existed and when. It does not prove the thing 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, because cryptography cannot prove a workshop was built or a well was dug.
VerifiedCheckable by anyone. 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, and it is a long way short of proof.

Commit volume, repository count and every other code-shaped productivity proxy are deliberately excluded from the accountability grade. They are trivially padded. 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. 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, the thing it was funded to build. Never with a distribution.

The Standard puts this in the program rather than in terms of service: a compliant deployment exposes no instruction that routes project treasury to token holders pro-rata. No such program is deployed yet, so today this is a requirement rather than a guarantee.

Honest answers

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