The Data-Density Reserve.
CRINKL transforms verified commerce density into a public economic signal.
CRINKL is a fixed-supply token driven by a single measurement: Verified Commerce Density (VCD) — cryptographically verified, identity-free evidence that real-world commerce occurred. As VCD grows, a 70,000,000-token reserve depletes on a deterministic schedule. Tokens leave that reserve in exactly two ways: earned by the users whose receipts created the evidence, or permanently burned. Nothing is minted, nothing unlocks on a clock, and no one holds a lever over the schedule.
Run to completion, the mechanism does two things. It leaves the majority of all supply held by the users who proved its commerce. And it leaves brands one way to reach them: campaigns are funded in CRINKL, acquired from the users who earned it. This paper specifies the allocation, the density index, the depletion schedule, the reward mechanism, the commercial-capacity benchmark, and the invariants that hold it all together.
The asset
Commerce data today comes in two kinds — and both are broken in opposite ways.
Accuracy independent parties cannot audit, and data that cannot be reused, combined, or carried by the user to any other service.
Real purchase data exists — locked inside retailers and processors, bound to identity.
A receipt qualified by the CRINKL network is a third kind:
Raw receipts stay private. What becomes publicly verifiable is what they produce: proof validity, aggregate Verified Commerce Density, and settlement artifacts. Verification services interpret receipts and issue signed spend proofs; proof validators check admissibility, proof integrity, uniqueness, and settlement. PriceChain Labs operates the current reference verification service, and the network is designed to admit additional independent providers and proof validators. The protocol measures commerce that already exists and converts the measurement into token state.
Verified receipts accumulate into Verified Commerce Density — a single dollar-denominated measure of proven commerce.
Rising VCD advances a bounded depletion schedule D(VCD), releasing a tranche from a finite 70M reserve.
Every tranche resolves into exactly two outcomes: user rewards or permanent burn.
Verified commerce becomes deterministic pressure on a fixed supply. The schedule reads the measurement; no one reads the schedule to anyone.
One number: VCD
Everything downstream — how much of the pool depletes, how much burns, how much is emitted — is a function of one scalar, denominated in dollars:
The gross merchandise value of every receipt users have submitted and proof validators have proven. It is built bottom-up rather than assumed:
users(t) follows a logistic adoption path — growth compounds rather than being assumed.
Revenue is a far scarcer signal than GMV: it requires a paid settlement artifact, not merely a proven receipt. A dollar of settled revenue represents vastly more committed economic activity than a dollar of pass-through GMV, and the multiplier prices that difference. Settled revenue contributes zero to VCD until paid settlement goes live; at that moment the index kinks sharply upward.
The two algebraic forms are equivalent — multiplier: VCD = GMV × (1 + λ·takeRate); additive: VCD = GMV + λ·revenue. The additive form is the one charted against the depletion schedule.
Fixed supply and allocation
CRINKL has a hard cap of 100,000,000 tokens, minted once at genesis. No minting function exists; there is no protocol path to additional supply under any condition. Rewards move tokens from the pool into circulation, burns remove them from existence, and buybacks (when funded) return them. Supply is monotonically non-increasing for the life of the protocol — it can only stay flat or fall.
The issuer's allocation is a line item on the same receipt as everyone else's: 10%, disclosed, and never replenished. Seventy percent of all supply that will ever exist is reserved for the two exits — earned by users or burned.
Where the 70M comes from. The Shared Reward–Burn Pool is the published 80M rewards-and-conversion escrow minus 10M carved out for proof validators. Consolidating the rewards budget and the burn reserve into one number is deliberate: the burn and the reward share the same index and the same curve, so they can never become two competing schedules. They are two outflows from one tank.
Verify it yourself
Every allocation above corresponds to an address you can inspect on Solscan without asking us for anything. The mint is fixed at 100,000,000 with mint authority revoked.
Most supply is non-circulating and enters circulation only as users convert earned rewards. Holding an address does not make its balance liquid — the release curve in §04 governs what becomes claimable.
The machine
A single bounded, concave curve maps Verified Commerce Density to cumulative pool depletion. It is the canonical schedule that governs both exits at once.
The constants are not free — two calibration anchors pin the curve end to end:
One pool, two exits
Each epoch, the schedule releases a tranche. The tranche is split rewards-first; the burn is whatever remains.
emission = min(reward demand, tranche) · burn = tranche − emission
Tokens permanently destroyed, reducing total supply forever. The burn is the residual of each depletion tranche after rewards are paid.
Tokens paid to users for verified receipts at a fixed USD value, entering circulation as an earned incentive rather than an unlock.
This is the central mechanism-design choice. A burn from a sealed, never-spendable reserve is a costless signal. A burn from the same budget that funds rewards is a costly one: every burned token is a reward the pool could have paid. Because emission is paid first and burn is the residual, the two exits compete for one fixed budget — heavy receipt volume emits more of each tranche, light reward demand burns it nearly whole.
The entire machine is publicly recomputable. The proofs are verifiable, VCD is published, the curve is closed-form, and the split rule is mechanical. Anyone can independently derive the burn trajectory from the commerce proofs — and no one, including the issuer, can accelerate it, pause it, or point it somewhere else.
The reward
Verification services set the reward per verified receipt — currently $0.10, denominated in USD regardless of token price. The rate is service policy, priced to the market's demand for receipts, not a protocol constant. The CRINKL required to deliver it is converted at the token's prevailing price, so emission per receipt falls as the token appreciates. Reward tokens enter circulation only when earned against proven commerce — there is no time-based vesting, no cliff, no unlock. Emission is work made liquid.
Users choose the currency of their $0.10 reward, and that single election governs the burn/emit mix:
The consequence is structural: D(VCD) depends only on VCD, so the election never changes how much of the pool depletes — only which exit the depletion takes. Every receipt that elects BTC is a receipt whose pool slice burns instead of emits.
At the $1B half-retirement milestone (~year 4 on default drivers): ~17.3M receipts, ~$866M GMV, token at its $0.10 launch price. As BTC election rises, burn rises and emission falls one-for-one, while the treasury absorbs a growing hard-currency liability that the pool charts do not show.
Commercial capacity
Verified commerce is the network's economic substrate, but verification alone does not produce revenue. Revenue arises when services use that proof supply for paid campaigns, affiliate commerce, measurement, attribution, and settlement.
Not every qualified receipt will be monetized. Some paid outcomes may generate substantially less than 1% of their GMV; others, including affiliate transactions and performance campaigns, may generate substantially more. Across those uses, the model applies 1% of Qualified GMV as an illustrative mature-network revenue equivalent.
This is not revenue automatically earned from every receipt. It is not a guaranteed take rate or a forecast. It is a commercial-capacity reference for what a sufficiently utilized verified-commerce network could support across multiple paid uses.
Where the tokens end up
The allocation table in §03 describes the network at genesis. The depletion schedule describes what it becomes. Run the machine to full retirement on default drivers and the arithmetic settles as follows:
The expected end state, under default drivers, is a network whose largest holders are the users who proved its commerce, with the issuer as one holder among several. The pool admits no other path out, and the dynamics are reflexive: higher BTC election shifts the split toward burn, shrinking circulating supply for every holder — which makes sustained high BTC election increasingly unlikely as CRINKL grows scarcer and brand demand grows. Under any election path, the issuer's share only moves the way anyone's does: by buying and selling.
The return flow
Emission answers how tokens reach users. Campaign settlement answers why anyone needs them back.
Campaign escrow and settlement on the protocol are denominated in CRINKL. A brand that wants what the density offers — acquisition, targeting, measurement, attribution, settlement against verified purchases — may pay through the service layer in familiar USD or USDC, but the protocol escrow behind its campaign is funded in CRINKL, acquired on the open market. The sellers on the other side of that market are, in the expected end state, the users and proof validators who earned the tokens by building the density in the first place.
Verification services sit at the loop's intake, ingesting receipts and campaign spend into the network for validation. The role is open: any service that can produce qualifying proofs can operate one. The token is the loop's only settlement medium — demand for CRINKL is demand to use the network, in proportion to the commerce it can prove.
Worked scenario
The half-retirement milestone — Verified Commerce Density of $1B, reached around year 4 on default drivers — traces how commerce becomes supply reduction.
Settled revenue switching on partway through — a small take rate on a large GMV — contributes only a few million dollars of revenue, but at 33× it adds hundreds of millions to VCD and visibly bends the depletion curve upward. A modest revenue signal moves the supply reduction more than a large GMV signal does, because the model prices committed economic activity above pass-through volume.
Risks & considerations
Rewards are fixed in USD, so the lower the token trades, the more CRINKL each receipt emits — and pool emission accelerates exactly when the project is weakest. Emission scenarios should be stress-tested against sustained low market prices, not just against activity.
Every BTC election converts a pool slice from emission to permanent burn, paid for in hard currency by the treasury. The cost sits off the pool charts and should be budgeted as an acquisition line: users will rationally elect BTC more in a downturn, making this draw largest precisely when the treasury can least fund it.
The burn figure is only legible alongside total depletion, reward election, emitted CRINKL, and BTC-paid rewards. Together those fully explain any burn rate; alone, the burn is not a standalone health signal.
Once revenue is live, the 33× multiplier dominates VCD. The burn path is highly sensitive to this single constant; small revisions to λ materially reshape the supply trajectory.
Parameter reference
All figures and curves are generated from the CRINKL tokenomics engine (v8). Scenario numbers are illustrative projections under stated default drivers and are not forecasts. This specification describes protocol mechanics only and is not financial advice or an offer of any security or token.