CGW — Technical and Product Design Paper#

#	Section
1	Regulatory Notice
2	Executive Summary
3	CoinGarden.World
4	Vision
5	Problem
6	Product Ecosystem
7	Why CGW Exists
8	CGW Utility
9	Plant & Garden Ecosystem
10	Contributor Economy
11	Marketplace Economy
12	Environmental Impact
13	Solana Architecture
14	Token Specification
15	Supply
16	Distribution
17	Circulating Supply
18	Vesting
19	Ecosystem Rewards
20	Treasury
21	Governance
22	Potential Garden Credits
23	Wallet Architecture
24	Identity Architecture
25	Plant Intelligence / AI
26	Data & Privacy
27	Security
28	Program Architecture
29	Auditing
30	Decentralization Roadmap
31	Product Roadmap
32	Token Roadmap
33	Sustainability
34	Risk Factors
35	Regulatory Framework
36	Transparency
37	Definitions
38	Technical Appendices

Sibling documents

• CGW_TOKENOMICS.md — the economic model in depth
• CGW_SOLANA_ARCHITECTURE.md — mint, programs, cluster separation
• CGW_GENESIS_CEREMONY.md — the proposed mint runbook
• CGW_REWARDS_ARCHITECTURE.md — verification, epochs, anti-Sybil
• CGW_TREASURY.md — vaults, multisig, disbursement, reporting
• GARDEN_CREDITS_RESEARCH.md — service-credit layer research
• CGW_MICA_REQUIREMENTS.md — EU regulatory analysis
• research/ — first-party research on JUP, JTO, PYTH, RENDER, HNT, BONK

---

Read this section before any other section.

1.1 What this document is#

This is a technical and product design paper. It records how the CoinGarden.World team currently proposes to design a token called CGW, why each design choice was made, and which choices remain undecided. It is a working engineering and product artefact published for transparency during a design phase.

1.2 What this document is not#

This document is not a crypto-asset white paper within the meaning of Article 6 of Regulation (EU) 2023/1114 (MiCA). No crypto-asset white paper for CGW has been drawn up under Article 6, notified to any competent authority under Article 8, or published under Article 9. Nothing in this document should be read as satisfying, attempting to satisfy, or substituting for those requirements.

No offer of CGW is being made. This document is not an offer to the public of a crypto-asset, an invitation to acquire a crypto-asset, a solicitation, a subscription document, or a prospectus under Regulation (EU) 2017/1129 or any other regime. There is no sale, no presale, no private round, no allowlist, no waitlist, and no mechanism by which any person can acquire CGW.

Nothing described here is deployed. There is no CGW mint on Solana mainnet-beta, on devnet, or on any local validator. There are no deployed programs, no vault addresses, no token accounts and no balances. Every address field in the canonical specification is null, and every deployment record is marked NOT DEPLOYED or PLANNED.

This document is not investment, legal, tax or financial advice. It has not been reviewed or approved by any competent authority in any Member State of the European Union or in any other jurisdiction. Readers must not act on it. Any person considering anything on the basis of this document should take their own independent professional advice.

1.3 No statements about value#

This document deliberately contains no assertion as regards the future value of CGW, no price projection, no return, yield or APY figure, no statement about liquidity or tradability, and no statement about any intention to seek admission to trading on any platform. Article 6(4) MiCA prohibits future-value assertions in a crypto-asset white paper; the project applies that prohibition to this design-phase document as an editorial standard, and to every public surface it operates.

1.4 Status labelling#

Every non-trivial claim in this document carries a status label. The vocabulary is fixed:

Label	Meaning
LIVE	Built, running, and verifiable in the repository today
IN DEVELOPMENT	Actively being built; behaviour may change
PLANNED	An agreed direction with no implementation
PROPOSED	A design position that has not been approved
RESEARCH	Explored, deliberately not a commitment
UNDER REVIEW	Awaiting an external input (legal, audit, product)
NOT DEPLOYED	Would exist on-chain, does not exist on any cluster

There is no CONFIRMED label in this document, because nothing about the token is confirmed.

1.5 The product works without the token#

The CoinGarden mobile application is designed to be fully useful with no wallet, no token and no crypto knowledge whatsoever. Identifying a plant, keeping a garden, recording care events and receiving reminders neither require nor benefit from holding CGW. The token is an optional layer on top of a product that must stand on its own. If that ever stops being true, the design has failed.

---

CoinGarden.World is a plant-care product. Its centre of gravity is a mobile progressive web app that lets a person photograph a plant, get an identification suggestion, correct it, save it to a garden, record watering and feeding, and receive care reminders. That product exists today in the repository and works without any blockchain component.

CGW is a proposed SPL token on Solana intended to sit beside that product as an optional layer, with one primary purpose: to recognise verified contributions to a shared plant knowledge commons. The people who correct a misidentified species, document a plant nobody has covered, or supply reliable care data for an under-represented region are creating the asset the product depends on. CGW is the proposed mechanism for recognising that work at scale.

The proposed specification, in one paragraph: a fixed maximum supply of 1,000,000,000 CGW with 9 decimals, minted once at genesis, with mint authority revoked afterwards and freeze authority set to null so the cap is mechanically enforced rather than promised. Supply is split six ways — 45% ecosystem and contributor rewards, 20% treasury, development and grants, 15% core team, 10% liquidity and integrations, 5% environmental impact, 5% early community. Rewards are released as a decaying emission over 120 months with a 0.945 annual decay factor, paying most where the data commons is thinnest. The team allocation vests on-chain over 48 months behind a 12-month cliff and cannot be accelerated by anybody. Treasury releases linearly over 48 months and environmental over 60 months, and both are counted as treasury-controlled rather than circulating until they are actually spent.

Under that model, circulating supply is 15.00% (150,000,000 CGW) at genesis, 24.47% (244,786,418 CGW) at month 12, 51.09% (510,924,800 CGW) at month 48, and 75.00% (750,000,000 CGW) at month 120. The residual 25% at month 120 is the treasury and environmental allocations, which remain treasury-controlled by definition.

Three design commitments are load-bearing and are stated here so they can be checked later:

1. No custom transfer logic. CGW would be a plain SPL token. No transfer tax, no reflection, no

rebasing, no blacklist, no permanent delegate, no administrative transfer path.

1. The backend never holds mint authority. Off-chain verification decides eligibility. It can

never create supply. The rewards program draws only from a pre-funded vault.

1. Rewards pay for measured outcomes, not claims. This is the direct lesson of six years of

Helium's proof-of-coverage history, which ended in retiring the mechanism entirely (see research/HNT.md).

The most important honest statement in this summary is that the token may never launch. Section 34 sets out that risk and twelve others in detail. The product roadmap does not depend on it.

---

CoinGarden.World is the project. World of Flowers is the name of the experience. The current repository contains four applications and a set of shared packages.

Surface	What it is	Status
apps/mobile	Mobile-first PWA — the plant-care product	LIVE in repository
apps/web	Marketing site and future desktop dApp surface	LIVE in repository
apps/api	Hono on Cloudflare Workers; the sole database boundary	LIVE in repository
apps/token	Public token design portal	PLANNED
packages/token-spec	The canonical numeric specification for CGW	LIVE in repository

The product's first complete user flow — capture, identify, confirm, save, care history, reminders, QR identity — is backed by real persistence in apps/api today. It has no token in it and needs none.

CoinGarden.World is a small team. It has no venture investors, no presale, no private round and no investor allocation, and this document states that positively rather than leaving it to be inferred. Several of the projects studied in research/ carry investor tranches that shape their entire allocation design; CGW does not have that constraint and should not import its machinery.

---

The vision is a plant knowledge commons that is genuinely useful to ordinary gardeners and is owned by nobody in particular.

Plant knowledge today is fragmented across botanical databases built for specialists, retail care labels written for liability rather than accuracy, forum threads with no provenance, and a handful of proprietary identification apps whose datasets are commercial assets. A person holding a wilting plant is poorly served by all of them.

CoinGarden's ambition is narrow and concrete:

1. A species catalogue with real provenance, in which every care claim can be traced to a source

and corrected by someone who knows better.

1. An observation layer — real plants, in real places, photographed over real time — that records

what actually happens to a species in a particular climate, rather than what a label says should.

1. A care engine that turns those two into an honest, deterministic recommendation, and admits

when it does not know.

1. A recognition layer — proposed, optional — that pays back some of the value to the people who

built the first three.

Only the fourth involves a token. The first three are the product, and the product comes first. The long-term test of this vision is whether a gardener who has never heard of Solana finds the app useful. If they do, the commons has value. If they do not, no token design rescues it.

---

5.1 The user's problem#

People kill plants they wanted to keep alive. The reasons are mundane: they do not know what the plant is; the care instructions they find are generic or wrong for their climate; they forget; and nothing in their life connects "the leaf looked like that three weeks ago" to "this is what happens next".

5.2 The data problem#

The information needed to solve the user's problem does not exist in a usable form. Specifically:

• Coverage is wildly uneven. Common houseplants are documented a thousand times over. Regional

cultivars, rare species, and unusual growing conditions are documented barely at all.

• Provenance is missing. Most online care advice has no attribution, no date, no climate context

and no way to correct it.

• Longitudinal data is almost nonexistent. Almost nobody records the same plant over years,

which is exactly the data a care engine needs.

• Correction has no reward. The person best placed to fix a wrong species identification — an

experienced grower who recognises it instantly — has no reason to bother.

5.3 Why this is an economic problem, not just a technical one#

The scarce input is attention from knowledgeable people applied to under-covered subjects. That is precisely the thing markets are bad at supplying for free and that proprietary datasets solve by paying salaries and keeping the result closed.

The proposition CGW tests is whether a small, transparent, contribution-gated recognition mechanism can direct that attention toward the gaps — and specifically toward the gaps, not toward volume. This is a real economic problem and it is also the point at which the design becomes vulnerable: every mechanism that pays for contribution attracts people who want the payment without the contribution. Section 10 and CGW_REWARDS_ARCHITECTURE.md address that directly, and section 34 records that the mitigations may not be sufficient.

---

6.1 apps/mobile — the plant-care product · LIVE#

A mobile-first Next.js PWA. Detached rounded header and bottom navigation, rounded card surfaces, a raised centre scan action, light-first with dark mode, installable. The domain sequence is capture → identify → confirm → save → care history → reminders → QR identity.

Its internal seams are deliberate: a framework-free domain layer, an identification provider interface, an API client that talks only to same-origin route handlers, and an auth boundary that is default-deny. None of these seams contain blockchain concepts.

6.2 apps/web — the marketing site · LIVE#

The public CoinGarden.World site. Botanical green/teal/purple hero, light page, white floating cards, deep navy typography, coral calls to action. Its network section is deliberately truthful about which chains are supported and which are merely under consideration; it does not claim live rewards, token prices, staking, or marketplace availability.

6.3 apps/api — the data boundary · LIVE#

Hono on Cloudflare Workers. It is the only component with a database binding and the only component permitted to run SQL. It holds the species catalogue, identification records, gardens, flowers, care events, reminders and image metadata. Image bytes live in object storage, never in the database, and every read and write is ownership-checked server-side.

If CGW is ever built, this is also where contribution verification would live — and it is architecturally important that this component has no signing authority over any token.

6.4 apps/token — the token design portal · PLANNED#

A public surface for the token design work: the specification, the documents in this folder, and an illustrative supply model. It is designed under explicit constraints derived from CGW_MICA_REQUIREMENTS.md: no price axis, no fiat value axis, no return metric, no forecast language, assumptions stated on screen, and a permanent statement that no offer is being made and no token is available to acquire.

6.5 packages/token-spec — the canonical numbers · LIVE#

Every supply figure, percentage, cliff and duration in this document derives from packages/token-spec/src/spec.ts. The simulation maths is integer-exact (bigint base units, floor-per-period with the remainder settled on the final period), and is covered by unit tests. No number is restated anywhere in the repository as a literal.

---

A token needs to justify itself against a simple test: what does this do that a database column could not?

For most of CoinGarden's functionality, the honest answer is "nothing", and so those parts have no token in them. Care reminders do not need a token. Species records do not need a token. A garden does not need a token. The QR identity attached to a plant is explicitly an application-level identifier and explicitly not an NFT.

Three properties are what a token would actually add:

1. Portable recognition. A contribution record inside a company database is worth exactly as much

as the company's continued existence and goodwill. A token balance is held by the contributor, is verifiable independently of the project, and survives the project. That is a real difference, and it is the strongest argument in CGW's favour.

1. A committed, bounded budget. A vault holding a fixed allocation released on a published

schedule is a harder commitment than a line item in an annual budget. Contributors can verify what is left. The project cannot quietly expand it, because mint authority is revoked.

1. A shared instrument for community-directed spending. Environmental grant selection and

ecosystem grant selection are decisions the project would rather not make alone. A token provides a mechanism for widening those decisions over time.

Three properties CGW deliberately does not claim:

• It is not a payment rail. Ordinary plant care will never cost anything.
• It is not an investment, a store of value, or a claim on revenue. There is no revenue share, no

buyback, no profit participation and no redemption right.

• It is not a requirement. A user who never touches a wallet loses no product functionality.

The most sceptical reading is worth stating plainly: this test could still be failed. If the product never reaches enough scale for a contribution commons to matter, the token adds complexity, regulatory exposure and trust risk in exchange for nothing. That is why the token roadmap is gated on product milestones rather than the other way round, and why "do not launch" is a real, planned outcome rather than a rhetorical hedge.

---

Every utility below is proposed or planned. None of it exists. Under MiCA, describing not-yet-existing utility as if it existed would be both a fair-and-not-misleading problem under Article 7(1)(b) and the boundary of the Article 4(3)(c) exemption; more simply, it would be untrue.

#	Utility	Status	One-line description
1	Verified contribution rewards	PROPOSED	Accepted improvements to the plant commons can be recognised with CGW
2	Ecosystem service access	PROPOSED	Optional extras — deeper analysis, specialist reports — may be payable
3	Marketplace participation	RESEARCH	A future marketplace may accept CGW alongside ordinary payment
4	Environmental impact funding	PROPOSED	A dedicated vault funds verified environmental work
5	Progressive governance	PLANNED	Holders get a say in a narrow, widening set of decisions

8.1 Verified contribution rewards · PROPOSED#

In plain terms: if you help improve the shared plant knowledge base — correcting a misidentified plant, adding reliable care information, documenting a species nobody has covered — that work can be recognised with CGW.

In detail: contributions are validated off-chain against the existing identification and moderation pipeline. Accepted contributions accumulate into an epoch, which is published as a Merkle root. Claiming is an on-chain action against a deterministic PDA drawing from the ecosystem rewards vault. Rewards are weighted by contribution scarcity, so under-covered species and regions are worth more than the thousandth photograph of a common houseplant.

Rewards must be earnable by a user who holds zero CGW and has never staked anything. Any design that requires capital to participate is rejected — this is the explicit lesson taken from Pyth's stake-to-earn publisher model (see research/PYTH.md), where the accountability principle is worth copying and the mechanism is not.

8.2 Ecosystem service access · PROPOSED#

Optional extras may be payable in CGW. Ordinary plant care never costs anything and never requires a wallet.

Service consumption is deliberately not modelled as a per-action on-chain transaction. Whether consumption settles directly in CGW or through a non-transferable service-credit balance is an open design question, explored in GARDEN_CREDITS_RESEARCH.md and summarised in section 22.

8.3 Marketplace participation · RESEARCH#

No marketplace exists. Whether CGW is a settlement asset, a fee-discount mechanism, or simply irrelevant to the marketplace is undecided and depends on the outcome of a marketplace pilot that has not started. Section 11 records what is actually known.

8.4 Environmental impact funding · PROPOSED#

A dedicated 5% allocation funds verified environmental and biodiversity initiatives, disbursed against evidence rather than on announcement, with community input into selection.

CGW makes no claim that holding or acquiring the token has any environmental effect. Section 12 sets out why that distinction is drawn so sharply, and section 34 records the verification limits honestly.

8.5 Progressive governance · PLANNED#

Over time, CGW holders would get a say in ecosystem decisions — which environmental causes are funded, how grants are allocated, which community initiatives get support. Governance starts from a deliberately narrow scope. Security-critical parameters, program upgrade authority and user-data policy are explicitly outside governance control. See section 21.

---

9.1 The domain model · LIVE#

The plant-care domain is defined independently of any token concept:

Entity	Description
Profile	An account, created by ordinary sign-in. No wallet field.
Garden	A named collection of plants belonging to a user
Flower	A specific real plant, optionally linked to a species
Plant Species	A global, admin-managed reference record with aliases
Observation / Photo	An image plus metadata about a specific plant at a point in time
Care Event	A watering, feeding or other recorded action
Reminder	A scheduled prompt derived from species defaults and care history
QR Identity	A stable application-level identifier for a plant. Never an NFT.
Recognition Suggestion	An advisory identification result awaiting user confirmation

A flower references a species through a nullable foreign key. It never duplicates the species' care fields, which is what makes a later correction to a species record propagate rather than fossilise.

9.2 What a contribution is#

The proposed reward layer draws a hard line between activity and contribution. Activity is anything a user does. A contribution is a change to the shared commons that survives review. Candidate contribution types, all PROPOSED:

• correcting a species identification that was wrong;
• adding a species to the catalogue that was not covered;
• supplying care data for a species in a climate or region with thin coverage;
• confirming, independently, an observation another user submitted;
• moderating, reviewing or adjudicating other contributions.

Notably absent: photographing your own plant, opening the app, maintaining a streak, referring a friend, or posting about the project. Those are activity. Paying for activity is how a data commons gets poisoned.

9.3 Scarcity weighting#

The single most important economic property of the contribution layer is that the marginal value of a contribution falls sharply with coverage. The four-hundredth photograph of a monstera in a well-covered postcode adds close to nothing. The first documented observation of a regional cultivar adds a great deal.

This is not an original idea. Pyth expands reward caps for feeds with few publishers; Helium's HIP-17 scales rewards down where coverage density exceeds target, on the explicit reasoning that two topologies covering the same area can earn twenty times apart under naive rewards while providing no additional coverage. CGW proposes the same shape and cites both.

---

10.1 Principles#

1. Pay for accepted outcomes, never for claims. A submission earns nothing. A submission that

survives verification and is incorporated into the commons may earn.

1. Weight by scarcity, not volume. See 9.3.
2. Cap per contributor per epoch. A hard ceiling limits the payoff from industrialised farming

without banning genuinely prolific contributors.

1. Make the curve regressive. A contributor with a hundred accepted contributions should not

receive a hundred times a contributor with one. Jito's tiered airdrop is the precedent (research/JTO.md); the goal is breadth of participation, not concentration.

1. Exclude insiders explicitly. Team members, contractors and any wallet they control are

ineligible for contribution rewards. This rule is written down now, in design phase, so it cannot be quietly relaxed later.

1. No capital requirement. No staking, no minimum balance, no gas prepayment, no purchase.
2. Publish the rules before applying them. Any quality-penalty rule — reward forfeiture for

fabricated submissions, reputation down-weighting — must be published and versioned before the first epoch, not written in response to an incident.

10.2 What CGW explicitly will not do#

• No slashing. Financial confiscation from a gardener who misidentified a plant would be absurd

and would violate the requirement that the app stay non-threatening to non-crypto users. Reputation weighting and reward ineligibility are the mechanisms; confiscation is not.

• No rewards for holding. There is no passive distribution, no staking reward, no APY, and no

mechanism by which holding CGW produces more CGW. A reward for holding would make CGW a yield product with a gardening skin, which is both the wrong product and the wrong regulatory posture.

• No large forward-announced farmable programme. The distribution shapes that attract mercenary

participation are well documented in research/JUP.md and research/JTO.md. CGW's community allocation is deliberately small (5%) for this reason, and long-term distribution is intended to happen through years of verified contribution instead of one launch event.

• No referral or social-promotion rewards. Beyond the gaming problem, MiCA Article 4(3) second

subparagraph makes "non-monetary benefits received in exchange for the token" a live legal question; promotional tasks make that question worse rather than better.

10.3 Contributor classes · PROPOSED#

Separate, published, non-fungible budgets per class, so no class can cannibalise another:

Class	Description
Everyday contributors	Corrections, confirmations, care data from ordinary users
Depth contributors	Sustained, high-quality documentation of under-covered subjects
Reviewers and moderators	Adjudication and quality control work
Institutional partners	Botanical gardens, herbaria, nurseries, research institutions

Budget sizes per class are undecided. They are a governance and product question, not a number this document should invent.

10.4 Appeals#

Any automated eligibility decision that reduces or withholds a reward must be appealable by a human being to a human being, with a published response commitment. The mechanism is specified in CGW_REWARDS_ARCHITECTURE.md. A system that can silently down-weight a contributor with no route to challenge it is not acceptable, and Helium's rejection of HIP-107 — where the community voted against a proposal specifically because of the unilateral banning power it gave service providers — is the cautionary precedent.

---

Status: RESEARCH. No marketplace exists. No marketplace is being built.

The historic product intent describes turning flower photography into digital assets, selling flower photographs, and QR-linked real-world flower commerce. That intent is preserved as a possibility, not adopted as a plan.

What is decided:

• A marketplace pilot, if it happens, comes after the core plant-care experience is validated.
• Not every photo becomes an NFT. Minting by default is explicitly rejected.
• Ordinary payment methods must work. A marketplace that can only be used by people holding CGW would

contradict the entire product principle.

What is undecided:

• whether CGW is a settlement asset, a fee-discount mechanism, or irrelevant;
• whether any NFT standard is involved at all;
• what is on-chain versus off-chain;
• the entire legal and tax treatment of a consumer marketplace.

There is one regulatory constraint worth recording here because it directly shapes design: MiCA Recital 26 indicates that the "limited network of merchants" exemption should not apply to crypto-assets designed for a continuously growing network of service providers. An open marketplace is, by construction, a continuously growing network. That cuts against relying on Article 4(3)(d), and is routed to counsel in CGW_MICA_REQUIREMENTS.md §13.

---

12.1 What is proposed#

A dedicated 5% allocation (50,000,000 CGW) held in a separate Environmental Impact Vault, released linearly over 60 months with no cliff, and disbursed as grants to verified environmental and biodiversity initiatives.

Three properties are deliberate:

1. Separate vault, separate reporting. Not commingled with the treasury, so environmental

commitments can be audited as a distinct line rather than asserted in prose.

1. Disbursement against evidence, not announcement. Tokens are counted as treasury-controlled

until an actual grant is paid against verified milestone evidence. Announcing a grant does not move anything.

1. Community input into selection. Which causes get funded is one of the first decisions proposed

for governance, precisely because it is a decision the project would rather not make alone.

12.2 What is explicitly not claimed#

Acquiring, holding or transferring CGW has no environmental effect. The token is not an offset, not a carbon credit, not a donation, and not a claim on any environmental outcome. The environmental work is funded by a vault that the project set aside; a person's decision to hold CGW does not add to it, and their decision not to does not subtract from it.

This distinction is drawn hard for two reasons. The first is that it is true, and the alternative framing is a lie that consumer-facing environmental language slides into very easily. The second is regulatory: MiCA's sustainability RTS (Delegated Regulation (EU) 2025/422) requires gross energy and emissions figures with no netting of offsets (Article 6(6)), and its recitals name preventing greenwashing as a design objective. A project whose product story is explicitly environmental carries elevated greenwashing exposure and has to be correspondingly disciplined.

12.3 The verification limit, stated honestly#

The project cannot fully verify the environmental outcomes it would fund. Tree planting, habitat restoration and biodiversity work are notoriously difficult to verify at a distance; milestone evidence can be staged; and the project has no field capability of its own. The honest position is that milestone-gated disbursement makes fraud harder and slower, not impossible. This is recorded as a named risk in section 34.

---

Full detail: CGW_SOLANA_ARCHITECTURE.md.

13.1 Why Solana · PROPOSED#

The proposed network is Solana, and the proposed standard is SPL Token. The reasoning:

• Transaction cost. A rewards mechanism that pays small amounts to many people is only viable

where a claim transaction costs a trivial amount. This is the binding constraint.

• Mature, boring token primitives. SPL Token is widely deployed, widely audited, and widely

understood. CGW needs no token feature that SPL Token does not already have.

• Precedent for the exact problem. Every project studied in research/ —

including Helium, which migrated an entire physical-infrastructure reward network onto Solana — is a Solana deployment. The design questions CGW faces have been answered, sometimes badly, in public.

• Native support for deterministic program-derived accounts, which is what makes replay-proof

claim accounting cheap.

13.2 Open documentation inconsistency · UNDER REVIEW#

The repository's docs/ARCHITECTURE.md and docs/PRODUCT_VISION.md currently record a Base-first chain position, and docs/DESIGN_SYSTEM.md describes Solana as "under consideration". The token specification in packages/token-spec and this document propose Solana. These sources have not yet been reconciled. Until they are, the Solana position should be read as PROPOSED and the inconsistency treated as an open item, not as a silent supersession.

13.3 What CGW refuses to implement#

CGW would be a plain SPL token with no custom transfer logic of any kind. Explicitly refused:

Refused	Why
Buy/sell tax or transfer fee	Breaks composability; enriches the project on every transfer
Reflection / redistribution	Manufactures a return characteristic the token should not have
Rebasing	Changes balances without user action; incomprehensible to non-crypto users
Hidden or reserved mint path	Contradicts the fixed cap; mint authority is revoked
Confiscation / clawback	No party should be able to take a user's tokens
Blacklisting / freezing	Freeze authority is set to null at mint creation
Arbitrary admin transfer	No administrative path to move a user's balance
Permanent delegate	Same objection, via a different mechanism
Artificial APY or staking yield	Would make CGW a yield product; also a financial-instrument risk

13.4 Programs#

Two programs, both NOT DEPLOYED:

• cgw-vesting — enforces the team vesting schedule on-chain so it cannot be quietly changed.

Non-goals: no administrator acceleration, no clawback of vested tokens, no custom transfer logic.

• cgw-rewards — releases verified contribution rewards from the ecosystem rewards vault only.

Non-goals: the backend never holds mint authority, no unbounded claiming, no on-chain storage of plant photographs or personal data.

13.5 Cluster separation#

Localnet (PLANNED, not started) → devnet (NOT DEPLOYED) → mainnet-beta (NOT DEPLOYED). Mainnet requires legal review, final tokenomics approval and an external audit first. No mint exists on any cluster and no program ID exists on any cluster.

---

All values PROPOSED. Source: packages/token-spec/src/spec.ts.

Field	Value
Name	CoinGarden
Symbol	CGW
Network	Solana
Token standard	SPL Token
Decimals	9
Maximum supply	1,000,000,000 CGW
Supply model	Fixed maximum, minted once at genesis, never increased
Mint address	none — NOT DEPLOYED on any cluster
Specification version	0.1.0-draft
Specification status	PROPOSED

Why 9 decimals. It is the Solana and Anchor default, matches JTO, and leaves headroom for the very small per-contribution reward amounts the rewards model implies without forcing them to round to zero. It is deliberately not a low-decimal, high-unit-count design of the kind studied in research/BONK.md, where 5 decimals against a 100-trillion supply exists to make a unit price look small.

14.1 Authorities#

Authority	Intended end state	Status
Mint authority	Permanently revoked immediately after genesis, making the fixed supply enforceable on-chain rather than promised	PROPOSED
Freeze authority	Set to null at mint creation. CGW has no requirement that justifies freezing a user's balance	PROPOSED
Metadata update authority	Held by the treasury multisig so metadata can be corrected, with every change publicly logged. A candidate for later revocation	PROPOSED
Program upgrade authority	Treasury multisig during devnet and early mainnet, moving to a timelock and then to immutability once programs are audited and stable	PROPOSED

The distinction between a revoked mint authority and a live one is the single most consequential technical choice in the specification, and it is worth being precise about the trade-off. A live mint authority behind a circuit breaker — the Helium and Render pattern — is more flexible and permits perpetual emissions. A revoked mint authority is less flexible and permits nothing. CGW proposes revocation because its rewards model is a fixed, front-weighted, terminating budget rather than a perpetual one, and because "the cap is enforced by the chain" is a far stronger statement to a non-crypto user than "the cap is enforced by our governance process". Helium's own history — a hard cap defended by governance for six years and then raised by roughly 68% by governance (research/HNT.md) — is the argument against relying on a promise.

---

15.1 The proposed figure#

1,000,000,000 CGW, fixed, with 9 decimals (10^9 base units per token). Minted once. Never increased. No inflation, no rebasing, no hidden mint path.

15.2 The honest finding about supply denomination#

The specification was modelled at three denominations — 500,000,000, 1,000,000,000 and 10,000,000,000 CGW — holding the distribution, schedules and circulation policy constant. The result:

The circulating-supply percentage curve is byte-identical at all three. 15.00% at genesis, 24.47% at month 12, 51.09% at month 48, 75.00% at month 120 — the same at 500M, at 1B and at 10B. Only the absolute token counts scale.

This is arithmetically obvious in hindsight and is stated anyway, because supply denomination attracts a disproportionate share of attention in token design discussions. What actually determines whether a token model is sound is distribution, emission shape, unlock timing and how much the treasury controls — all of which are unchanged by the denomination. The choice of 1,000,000,000 is therefore a legibility decision, not a structural one: it is large enough that a per-contribution reward reads as a whole number rather than a decimal fraction, and small enough to avoid the cosmetic problems of very high unit counts.

Full scenario detail: CGW_TOKENOMICS.md §3.

---

Six allocations. All PROPOSED. Percentages sum to exactly 100.

Allocation	%	CGW	Release	Circulation treatment
Ecosystem & contributor rewards	45%	450,000,000	Decaying emission, 120 months, 0.945 annual decay	Circulating on release
Ecosystem treasury, development & grants	20%	200,000,000	Linear 48 months, no cliff	Treasury-controlled on release
Core team	15%	150,000,000	12-month cliff, then linear to month 48	Circulating on release
Liquidity & ecosystem integrations	10%	100,000,000	Unlocked at genesis	Circulating on release
Environmental impact initiatives	5%	50,000,000	Linear 60 months, no cliff	Treasury-controlled on release
Early community & launch distribution	5%	50,000,000	Unlocked at genesis	Circulating on release
Total	100%	1,000,000,000

16.1 Rationale in brief#

Ecosystem & contributor rewards — 45%. The largest allocation goes to the people who create the product's actual value. Pyth reserves a comparable named allocation (22%) purely for data publishers; CGW's share is larger because it has no publisher-side commercial relationships to fall back on and no other route to distribute the token over time.

Treasury — 20%. Released linearly rather than unlocked at genesis, so it cannot be spent down quickly and so the published circulating figure is not inflated by tokens sitting in a project wallet.

Core team — 15%. A 12-month cliff followed by 36 months of linear vesting. Deliberately below the 24.5% core-contributor allocation seen in a venture-backed infrastructure protocol (research/JTO.md), which is calibrated for competing on engineering compensation and is not defensible for a consumer product with a small team. 15% is still a concentration risk and is named as such in section 34.

Liquidity — 10%. Modelled as fully released at genesis so the circulating-supply chart shows the honest worst case rather than a flattering one. No listing is planned, approved, or announced, and nothing in this document should be read as an intention to seek admission to trading anywhere.

Environmental impact — 5%. Separate vault, separate reporting, five-year release, disbursed only against verified evidence.

Early community — 5%. Deliberately small. The research on large retroactive airdrops shows they mostly attract mercenary participation; CGW's long-term distribution is meant to happen through the rewards allocation over years, based on verified contribution, not through one launch event.

16.2 What is not in the table#

There is no investor allocation, no presale, no private round, no strategic tranche and no advisor bucket — because there are no investors, no presale and no private round. This is stated positively rather than left as an absence, because an empty or reserved-for-later investor bucket is a permanent overhang and a permanent trust question.

---

17.1 Definition#

Circulating supply is the quantity of CGW that has been released from its vault under its schedule and is held by parties other than the project.

Tokens released into the treasury vault or the environmental impact vault are counted as treasury-controlled, not circulating, until they are actually disbursed. That is a deliberately conservative definition and it makes the published circulating figure smaller, not larger.

The reasoning: a token sitting in a project-controlled wallet is not in anybody's hands. Counting it as circulating overstates distribution and understates project control. Jupiter's approach — publish the wallet addresses so that anyone can compute circulating supply as "everything not in these wallets" — is the mechanism CGW proposes to copy, at appropriate scale (research/JUP.md).

17.2 Trajectory#

Circulating supply under the proposed model:

Month	Circulating %	Circulating CGW
0 (genesis)	15.00%	150,000,000
12	24.47%	244,786,418
24	33.64%	—
36	42.50%	—
48	51.09%	510,924,800
60	55.66%	—
120	75.00%	750,000,000

Absolute counts are given only where they have been computed and verified; the remaining rows are reported as percentages rather than restated approximately.

Released supply reaches 100% at month 120. The residual 25% at that point is treasury-controlled by definition — the treasury allocation (20%) and the environmental allocation (5%) — not locked. That distinction matters: at month 120 nothing is under a vesting schedule any more; a quarter of supply simply sits in vaults the project's multisig controls until it is spent against a published policy.

17.3 What drives each step#

• Genesis 15% is liquidity (10%) plus early community (5%), both unlocked at genesis by design.
• Month 0 → 12 adds the first year of rewards emission and the first year of team accrual, which

becomes claimable at the 12-month cliff.

• Month 12 → 48 is dominated by continued rewards emission plus linear team vesting.
• Month 48 → 120 is rewards emission only; every other schedule has completed.

---

18.1 The core commitment#

Vesting must be enforced on-chain and must not be accelerable by anybody. A published schedule that an administrator can override is not a vesting schedule; it is a statement of intent. The cgw-vesting program exists solely to make the team schedule mechanically true.

18.2 Schedules#

Allocation	Cliff	Duration	Shape
Core team	12 months	48 months	Linear accrual from month 0; nothing claimable before the cliff; fully vested at month 48
Treasury	none	48 months	Linear
Environmental impact	none	60 months	Linear
Liquidity	none	none	Unlocked at genesis
Early community	none	none	Unlocked at genesis
Ecosystem rewards	none	120 months	Decaying emission, 0.945 annual decay

18.3 Program guarantees · PROPOSED#

cgw-vesting is specified to provide:

• deterministic vesting accounts derived from beneficiary and allocation;
• linear accrual from start with a cliff gate on claimability;
• exact claimed/remaining accounting with no double-claim path;
• floor-rounded releases with the remainder settled on the final period.

And explicitly to provide no:

• administrator acceleration of any schedule;
• clawback of vested tokens;
• custom transfer logic — SPL Token moves the tokens.

18.4 Rounding#

Every period floors; the final period of a schedule receives the accumulated remainder. A schedule therefore always releases its allocation exactly — never one base unit more or less. This is implemented in integer base units with bigint arithmetic in packages/token-spec, so a chart can never disagree with this document by a rounding error.

---

19.1 The emission#

450,000,000 CGW over 120 months, decaying at a 0.945 annual factor. The decay applies per year; months within a year share that year's budget evenly.

Year	Rewards emission (CGW)
1	57,286,418
2	54,135,669
3	51,158,207
4	48,344,504
5	45,685,555
6	43,172,848
7	40,798,344
8	38,554,434
9	36,433,940
10	34,430,076

Annual figures are floor-rounded per the rule in 18.4; the schedule releases exactly 450,000,000 CGW across the full 120 months, with the remainder settled in the final period.

19.2 Why it decays#

CGW should pay most where the data commons is thinnest, which is at the start. In year one almost every species is under-covered and almost every observation is marginal coverage. By year eight the common cases are well documented and the marginal contribution is narrower and more specialised.

A flat emission would pay the same for the ten-thousandth well-covered observation as for the first, which is the mistake scarcity weighting exists to avoid — applied at the wrong level. A steeply front-loaded emission would exhaust the budget before the product had the users to spend it well.

The 0.945 factor is borrowed directly from Render's RNP-001 growth-phase damping coefficient (research/RENDER.md). It is a gentle decay: it does not halve the budget, it erodes it. The choice of that specific number over any nearby number is not defended on first principles — it is a documented precedent from a production network rather than a figure invented here, and that is the entire argument for it. It remains open to change before any launch.

19.3 What the emission does not do#

• It does not create supply. It releases from a pre-funded vault against a revoked mint authority.
• It is not a yield. Nobody earns it by holding.
• It is not guaranteed to be fully distributed. If contributions do not materialise, tokens remain in

the vault. The unclaimed-and-unemitted rule is an open decision recorded in section 32.

19.4 Delivery mechanism#

Off-chain verification → epoch aggregation → published Merkle root → deterministic claim PDA → transfer from the ecosystem rewards vault. Per-epoch and per-claimant caps are enforced on-chain, not in the backend. Full design: CGW_REWARDS_ARCHITECTURE.md.

---

Full detail: CGW_TREASURY.md.

200,000,000 CGW (20%), released linearly over 48 months with no cliff, held in a dedicated Treasury Vault under a proposed 3-of-5 multisig.

Purpose: long-term development funding, ecosystem grants, integrations, audits and operational runway.

Five signer categories are proposed — founder hardware wallet, company treasury hardware wallet, independent technical signer, recovery/security signer, and independent/community signer. No signer identities have been assigned and no addresses exist. The categories are published now precisely so that the shape of the arrangement is a design commitment rather than something decided quietly at deployment time.

Reporting commitments (PROPOSED):

• every production vault address published before it holds meaningful value;
• treasury movements reported on a regular published cadence;
• an advance-notice period before any material movement out of a reserve vault;
• grants published as line items — recipient, amount, purpose, destination — not as narrative.

The last point is taken from Jito's liquidity-mining disclosure table and Pyth's constitutional revenue-split reporting; the counter-example is a treasury action executed "via multisig vote" with no published proposal, threshold or record, which is not governance CGW could defend to a regulator or to its own users (research/BONK.md).

A reporting commitment that lapses is worse than one never made. CGW should therefore commit only to a cadence it can sustain indefinitely, and automate it where possible.

---

Status: PLANNED. No governance mechanism exists.

21.1 Model#

Progressive decentralisation. Governance begins with a deliberately narrow scope — ecosystem grant selection and environmental cause selection — and widens only as the process proves itself.

21.2 Explicitly out of scope#

Permanently, or at minimum until a much later stage:

• program upgrade authority;
• user data and privacy policy;
• security-critical program parameters;
• anything that could unilaterally move user funds.

These are excluded because a governance vote is the wrong instrument for a security decision, and because a governance body with the power to change privacy policy over users who are not token holders would be an accountability failure. The overwhelming majority of CoinGarden users will never hold CGW; they must not be governed by people who do.

21.3 Design constraints#

• Thresholds expressed as percentages computed from on-chain supply, never hard-coded constants.

Jito's Constitution defines a threshold as "3% (30,000,000 JTO) of the 1,000,000,000 JTO total token supply" — a figure that no longer matches the on-chain supply. CGW must not repeat that.

• Locked and unvested allocations carry no voting weight. Pyth permits locked tokens to be staked

for governance, which gives allocation holders voting power long before their tokens are liquid. CGW rejects that.

• Start with non-binding signalling. Escalate to binding votes only when participation justifies

it.

• No security council with veto power over community votes. Importing an emergency-veto body at

launch centralises before it decentralises, and the on-chain surface under management does not justify it.

• No foundation delegation of large voting blocks to hand-picked delegates. If participation is a

problem, the correct answer is to narrow the scope or lower the threshold, not to manufacture voting power.

21.4 The participation problem, stated in advance#

Jito's DAO could not reach quorum with a small float and a disengaged holder base. CGW would have a far smaller crypto-native population than Jito — most of its users will hold no tokens and want none. Governance apathy is the expected default, not a tail risk. Section 34 records it as such. The realistic design response is to keep binding governance narrow enough that a small number of engaged participants can legitimately exercise it, rather than to build an apparatus that cannot be filled.

---

Status: RESEARCH. This must not be implemented unless the product demonstrably needs it.

Full exploration: GARDEN_CREDITS_RESEARCH.md.

The question is how a non-crypto user pays for an optional premium service without being forced through a token purchase. Two production precedents were studied:

• Helium Data Credits — a non-transferable, USD-pegged credit produced only by burning HNT. The

peg is credible because the credits cannot be traded; a non-transferable credit cannot have a secondary market, so its stated price is its only price.

• Render's Burn-and-Mint Equilibrium — jobs priced in USD, RENDER burned to buy non-transferable

Render Credits, and node operators paid from an emission that is deliberately not a function of the burn.

The direction the research points to is a non-transferable, euro-denominated service-credit balance, purchasable by card by default, with CGW as one optional route in — not a second SPL token.

Two pieces of evidence drive that:

1. Helium tried a second tradable token and reversed it. HIP-138 unwound the IOT/MOBILE subDAO

token architecture, citing user confusion and value leakage, while leaving non-transferable Data Credits untouched. The lesson is not "no second layer" — it is "the second layer must be non-transferable accounting, never a tradable token."

1. **Forcing a card-paying customer through a token purchase is a product failure and a regulatory

escalation.** It converts a simple consumer transaction into a crypto-asset acquisition, and an in-app fiat-to-crypto path is squarely within the MiCA service perimeter (Article 3(1)(16)(c)).

Nothing here is decided. It is recorded so the option is properly understood if the product ever needs it, and so that a future decision to build it has to argue against this document rather than start from a blank page.

---

Status: PLANNED. No wallet integration exists in the product today.

23.1 Principles#

1. A wallet is never required. Sign-in, plant care, gardens, reminders and QR identity work

entirely without one. The mobile profile screen already states plainly that a crypto wallet is not connected and is separate from ordinary sign-in.

1. The project does not custody user keys. Holding user keys, or operating an in-app balance a

user cannot self-custody, would be custody and administration of crypto-assets on behalf of clients within MiCA Article 3(1)(16)(a) and would require authorisation. CGW is not designed around that.

1. No in-app swap, no fiat on-ramp, no order routing. Each of those is a separately licensable

service. If any of them ever becomes a product requirement, it goes through an authorised third party, not through CoinGarden.

1. Wallet connection is an explicit, reversible, user-initiated action whose only consequence is

the ability to claim rewards.

23.2 Proposed shape#

Standard Solana wallet-adapter connection from the product surface, used exclusively to (a) prove control of an address for reward eligibility and (b) sign a claim transaction. The wallet address is stored as a claim destination and nothing else. No spending approval, no delegation, no session key with transfer authority.

23.3 Recovery#

There is no recovery. If a user loses their wallet, the project cannot restore their tokens and will not pretend otherwise. This is one of the strongest arguments for keeping the token layer strictly optional and for never letting product functionality depend on it.

---

24.1 What exists today · LIVE#

Google SSO via Auth.js v5, identity-only OIDC scopes, per-origin JWT sessions. apps/web and apps/mobile run independent Auth.js instances with independent cookie sessions, because they are different origins and a genuinely shared session would require a common parent domain and production HTTPS. Route protection is server-side and default-deny: anything not on an explicit public allowlist requires a session.

Roles (USER / MODERATOR / ADMIN) and status (ACTIVE / DISABLED) are persisted, and every authorisation decision is a live database lookup — never a cached token claim and never an email comparison.

24.2 The separation rule#

Product identity and wallet identity are never linked automatically. The authenticated user shape has no wallet field. The wallet provider is mounted independently of the session provider with no bridging code. The mobile profile screen discloses the separation to the user in plain language.

If reward claiming is ever built, the link between an account and a claim address must be an explicit, revocable, user-initiated association — and it must be possible to use the product forever without creating one.

24.3 Why this matters beyond privacy#

Under MiCA Article 4(3), second subparagraph, a crypto-asset is not "offered for free" where purchasers are required to provide personal data to the offeror in exchange for it. The core CGW reward mechanic — a user submits plant data and receives CGW — sits directly on that provision. The architectural response is to keep data submission and token receipt as separable as the product permits, and to document that separation as a factual record. This does not resolve the legal question, which is routed to counsel; it makes the eventual answer defensible rather than accidental.

---

25.1 Identification is advisory, never authoritative · LIVE#

Identification returns a structured result — best match, confidence, alternatives — and a flower's identification is only persisted once the user confirms the suggestion or corrects it. A flag records which happened. The model never silently creates authoritative botanical data.

Identification runs through the Flower Recognition Agent against a general-purpose vision model from whichever AI provider (OpenAI or Anthropic) an administrator has configured — not a purpose-built botanical classifier, and choosing one of those is an explicitly separate decision. If no real provider can answer, the request fails closed (503, a friendly retry message) rather than returning a fabricated result; there is no mock/local fallback in production.

25.2 Care recommendations are deterministic · LIVE#

The care engine is a pure function set: species defaults plus a plant's recorded care history plus optional overrides produce a next-suggested date and advisory guidance text. There is no model call for ordinary date arithmetic. Derived values such as last-watered are always computed from the care event history at read time, never duplicated onto a row where they could drift.

This is a deliberate anti-pattern avoidance: dressing up date arithmetic as AI is common, unhelpful, and makes the system harder to debug and impossible to explain to a user.

25.3 The relationship to rewards#

The identification and moderation pipeline is what makes contribution verification possible at all. A correction is only valuable if the system can tell that it is a correction and that it survived review. This creates a dependency worth naming: the reward layer's integrity is bounded by the verification pipeline's integrity. If identification quality is poor, reward quality is poor. Section 34 records the dependence on off-chain verification infrastructure as a named risk.

25.4 What AI will not be used for#

• Deciding reward amounts without a human-reviewable rule.
• Making a final, unappealable eligibility determination about a contributor.
• Generating botanical facts presented as authoritative.

---

26.1 Current posture · LIVE#

• apps/api is the sole database boundary. Browsers never talk to it directly.
• Image bytes live in object storage; the database holds metadata only. There is no public bucket

URL, and every image read and write is ownership-checked server-side.

• Plant images and location data are treated as user data.
• An administrative insights view over identifications shows aggregate statistics and lists —

never raw images.

26.2 Commitments for any token layer · PROPOSED#

• No personal data on-chain, ever. Not photographs, not location, not account identifiers, not

email addresses. A Merkle leaf commits to a claim address and an amount, and nothing else.

• No on-chain storage of plant photographs, which is an explicit non-goal of cgw-rewards.
• Contribution data is not sold. Not to identification providers, not to advertisers, not to data

brokers. If the commons ever has an open-data licence, that is a published product decision with its own consultation, not a quiet term change.

• A privacy and retention model must exist before production handling of images and location.

This is already recorded as a production boundary in the repository architecture and is not satisfied yet.

26.3 Open questions#

• What exactly is published when an epoch's Merkle tree is published, given the tree must be

independently verifiable while the leaves must not identify a person.

• Whether contribution history should be publicly attributable at all, and if so, under what

user-controlled setting.

• How deletion requests interact with an immutable on-chain claim record. The proposed answer is that

nothing personal is on-chain in the first place, so deletion applies to off-chain records and the on-chain record contains nothing to delete — but this needs to be tested against a real GDPR analysis, not asserted.

---

27.1 The properties that matter most#

1. Mint authority revoked after genesis. After that point no party — not the team, not a

compromised key, not a compromised backend — can create CGW.

1. Freeze authority null from creation. No party can freeze a user's account.
2. The backend never holds mint authority. This is stated as a hard architectural rule and is the

single most important boundary in the system. Off-chain verification produces eligibility. Supply is fixed and pre-allocated.

1. The rewards program draws from exactly one vault. A compromise of the rewards path cannot

reach the treasury, the team vesting vault, or the environmental vault.

1. On-chain caps. Per-epoch and per-claimant maximums are enforced by the program, not by the

service that computes eligibility. A backend that goes wrong hits a ceiling.

1. Deterministic claim PDAs. Replay protection is structural rather than bookkeeping.

27.2 Key management · PROPOSED#

• Hardware wallets for every multisig signer category.
• Geographic and organisational separation of signers.
• A documented, rehearsed signer-rotation procedure that does not require the cooperation of the

signer being rotated out.

• A dedicated recovery/security signer category whose sole purpose is that scenario.
• Genesis ceremony keys handled per CGW_GENESIS_CEREMONY.md, with a

documented destruction step for any ephemeral authority.

27.3 What is not solved#

Key management is a people problem with a technical veneer, and 3-of-5 is a compromise between resilience and coordination cost. It is not a solution to a determined insider, to a coordinated compromise of three signers, or to the loss of three keys simultaneously. Section 34 records key-management risk explicitly rather than treating a multisig as an answer.

27.4 Operational security today · LIVE#

Secrets live only in deployment secret stores. Server-only variables never appear in public client-side configuration, in client components, in git history, or in documentation — only empty placeholders are committed. Centralised exception monitoring captures unexpected failures with a correlation identifier, and the correlation identifier is the only thing ever returned to a caller.

---

Full detail: CGW_SOLANA_ARCHITECTURE.md.

28.1 cgw-vesting · NOT DEPLOYED#

Purpose: enforce the team vesting schedule on-chain so it cannot be quietly changed.

Responsibilities:

• deterministic vesting accounts derived from beneficiary and allocation;
• linear accrual from start with a cliff gate on claimability;
• exact claimed/remaining accounting with no double-claim path;
• floor-rounded releases with the remainder settled on the final period.

Explicit non-goals:

• no administrator acceleration of any schedule;
• no clawback of vested tokens;
• no custom transfer logic — SPL Token moves the tokens.

28.2 cgw-rewards · NOT DEPLOYED#

Purpose: release verified contribution rewards from the ecosystem rewards vault only.

Responsibilities:

• epoch-scoped Merkle distribution roots published before claiming opens;
• deterministic claim PDAs providing replay protection;
• per-epoch and per-claimant maximum limits enforced on-chain;
• draws exclusively from the ecosystem rewards vault.

Explicit non-goals:

• the backend never holds mint authority and can never create new supply;
• no unbounded or open-ended claiming;
• no on-chain storage of plant photographs or personal data.

28.3 What deliberately has no program#

There is no token program, because SPL Token is sufficient. There is no governance program yet, because governance is PLANNED and starting with non-binding signalling requires no on-chain component. There is no marketplace program, because there is no marketplace. There is no staking program, and there is not intended to be one.

Every program that does not exist is a program that cannot be exploited, cannot be mis-upgraded, and does not need an audit.

---

Status: PLANNED. No audit has been commissioned, scheduled or performed.

29.1 The gate#

No mainnet deployment without a completed external audit. This is stated as an absolute precondition alongside legal review and final tokenomics approval, and it is recorded in the deployment table of the canonical specification, not only in prose.

29.2 Proposed scope#

Area	What an audit must cover
cgw-vesting	Accrual maths, cliff gating, double-claim resistance, rounding, absence of any acceleration or clawback path
cgw-rewards	Merkle verification, PDA derivation and collision resistance, replay protection, cap enforcement, vault isolation
Mint configuration	Mint authority revoked, freeze authority null, decimals, supply, metadata authority
Vault topology	That each vault's authority is what the documentation says it is
Ceremony transcript	That the genesis runbook was followed and every verification step passed
Off-chain pipeline	Epoch construction, root publication, and the boundary that prevents the backend from acquiring signing authority it should not have

29.3 Commitments · PROPOSED#

• The audit report is published in full, including unresolved findings.
• Findings are published with their status — fixed, accepted, or disputed — and with reasoning.
• Any material change to an audited program requires a re-audit before it reaches mainnet.
• Program upgrade authority moves to a timelock and then toward immutability once programs are

audited and stable.

29.4 What an audit does not do#

An audit examines the code that was submitted, at a point in time, against the threat model that was agreed. It does not verify the off-chain verification pipeline's judgement, the economics, the legal position, or the honesty of the operators. It is a necessary gate, not a warranty, and treating a completed audit as a safety guarantee would be exactly the misreading section 34 warns about.

---

CGW is not decentralised, and this document does not claim it is. At every stage described below, a small team controls the critical paths. The purpose of this section is to describe an intended direction and to be precise about what has and has not changed at each step.

Stage	What changes	What the project still controls	Status
0 — Today	Nothing on-chain exists	Everything	LIVE
1 — Genesis	Supply becomes fixed and mechanically enforced; freeze authority null	Every vault; both programs; the verification pipeline	PROPOSED
2 — Multisig	Treasury and vault control moves to a 3-of-5 multisig including independent signers	Programs; verification; epoch construction	PROPOSED
3 — Published process	Vault addresses, disbursement policy, grant line items and epoch roots published on a fixed cadence	The same, but observably	PROPOSED
4 — Signalling governance	Non-binding community votes on environmental causes and ecosystem grants	Execution of every vote	PLANNED
5 — Binding narrow governance	Binding votes on cause and grant selection within a bounded budget	Programs, security parameters, privacy policy — permanently out of scope	PLANNED
6 — Timelock	Program upgrade authority behind a timelock, so changes are visible before they take effect	Ability to upgrade, with delay	PROPOSED
7 — Immutability	Program upgrade authority revoked once programs are audited and stable	Nothing about the programs	PROPOSED

Two honest observations about this table:

• Stages 1 to 3 are transparency, not decentralisation. Publishing what you control does not

reduce what you control. It is worth doing and it should not be described as something it is not.

• Stage 7 may never be reached, and reaching it has a real cost: an immutable program with a

latent bug cannot be fixed. The trade-off is genuine and the decision is not made.

---

The product roadmap does not depend on the token, and is deliberately listed first.

Stage	Content	Status
Mobile MVP	Capture → identify → confirm → save → care history → reminders → QR identity	LIVE
Plant Intelligence Core	Species catalogue, server-side identification, deterministic care engine, persistence	LIVE
Accounts and roles	Sign-in, roles, admin surface, audit logging, exception monitoring	LIVE
Identity and account depth	Backend-persisted multi-device account data	IN DEVELOPMENT
Garden history	Observation timeline, media storage strategy, weather integration with privacy controls	PLANNED
Production identification provider	A purpose-built botanical classifier, replacing today's general-purpose vision model	PLANNED
Privacy and retention model	Required before production handling of images and location	PLANNED
Marketplace pilot	Validate digital photo licensing and QR-linked commerce	RESEARCH
Environmental impact pilot	Cause creation, verification, milestone disbursement — legal review before any real funds	RESEARCH
World of Flowers	Personal world derived from real garden state	RESEARCH

---

Every item is gated on the item above it. Any gate can end the programme, and "do not launch" is a supported outcome at every stage.

Stage	Content	Gate	Status
T0	Research: comparable token designs; EU regulatory analysis	—	LIVE (complete)
T1	Canonical specification with tested maths	T0	LIVE
T2	This design paper and its siblings	T1	IN DEVELOPMENT
T3	Public token design portal with no offer surface	T2	PLANNED
T4	Legal review of classification, distribution mechanics and offer structure	T3	UNDER REVIEW
T5	Program implementation on localnet	T4	PLANNED
T6	Devnet deployment and end-to-end rehearsal, including a full ceremony dry run	T5	NOT DEPLOYED
T7	External audit; published in full	T6	PLANNED
T8	Final tokenomics approval; every open decision below closed	T7	PROPOSED
T9	Genesis ceremony on mainnet-beta	T8	NOT DEPLOYED

32.1 Open decisions that must close before T8#

• Final maximum supply and whether the six-way allocation stands.
• Whether the 0.945 decay factor is retained, and whether 120 months is right.
• The definition of an epoch and its cadence.
• Per-epoch and per-claimant caps as concrete numbers.
• Contributor class budgets.
• The rule for unclaimed rewards — return to vault, roll forward, or forfeit — which must be decided

before the first distribution, not after.

• The rule for rewards that are never emitted because contributions did not materialise.
• Whether Garden Credits are built at all.
• Legal entity, jurisdiction and offeror structure.
• Whether an EU offer is possible at all under MiCA, and if not, what that means for the whole

programme.

---

33.1 The disclosure obligation#

If a MiCA crypto-asset white paper is ever produced, Article 6(1)(j) requires disclosure of the principal adverse impacts on the climate and other environment-related adverse impacts of the consensus mechanism used to issue the crypto-asset. Commission Delegated Regulation (EU) 2025/422 sets the fields and methodology.

For an SPL token, the consensus mechanism is Solana's proof-of-stake consensus with proof-of-history sequencing — not a CGW-specific mechanism. The mandatory fields would describe Solana's consensus, its validator incentive structure, the SOL transaction and priority fee model, and network-level annual energy consumption in kWh covering both transaction validation and maintenance of ledger integrity.

Solana's aggregate network figure is above the 500,000 kWh threshold at which the supplementary table becomes mandatory, so renewable share, energy intensity per transaction, scope 1 and scope 2 emissions and GHG intensity per transaction would also be required, on an ESRS-aligned basis.

33.2 The methodology problem, stated openly#

CGW cannot measure Solana's validator fleet. Any disclosure would therefore rest on estimates flagged as estimates with a documented methodology, on reuse of another Solana white paper's figures with the source named, or on a named third-party data provider. Which of those three is correct is an open question for counsel.

33.3 The netting prohibition#

Figures must be gross. Offsets may be described separately but must never be netted off. This is directly relevant to CGW because the product story is environmental: the environmental impact vault must never appear anywhere near an energy or emissions figure, and no marketing surface may imply that funding environmental work offsets the network's footprint. Preventing greenwashing is a stated design objective of the RTS, and a project like CGW is exactly what it has in mind.

33.4 The product-level position#

The token layer's energy footprint is a function of Solana, which exists regardless of CGW. Claiming credit for that is not available, and neither is disclaiming responsibility for it. The defensible position is: disclose gross figures with a documented method, fund environmental work from a separately-reported vault against evidence, and never connect the two rhetorically.

---

This section is written to be useful rather than protective. Each risk is stated as plainly as possible, with the mitigation and — importantly — the limit of the mitigation.

34.1 The token may never launch#

This is the most likely single outcome to plan for. Every gate in section 32 can terminate the programme: legal review may conclude that no compliant EU offer is available; an audit may surface an unfixable design problem; the product may not reach the scale that makes a contribution commons meaningful; or the team may simply decide the token is not worth the complexity and exposure. Nothing in this document creates any obligation to launch CGW, and no person should rely on the expectation that it will exist.

Mitigation: the product roadmap is independent of the token roadmap, so a decision not to launch costs the product nothing. Limit: this does not help anyone who has formed an expectation from reading this document, which is why the expectation is disclaimed here rather than in a footnote.

34.2 The described utility does not exist#

Every utility in section 8 is PROPOSED, PLANNED or RESEARCH. Contribution rewards, ecosystem service access, marketplace participation, environmental funding and governance have not been built. A token whose stated utility never materialises has converted a description into an unfulfilled promise, which is the single most damaging thing a utility token can do.

Mitigation: status labels on every claim; a roadmap that gates the token behind the product; refusal to launch before utility exists. Limit: status labels do not make a plan real, and readers routinely discount them.

34.3 Contribution rewards may be gamed despite mitigations#

This is the deepest technical risk in the design. Any mechanism that pays for contribution attracts people optimising for the payment. Photographs can be reused, scraped, generated, or taken from other sources. Accounts can be created in bulk. Confirmations can be manufactured by colluding accounts. Scarcity weighting itself creates an incentive to fabricate rare-species observations, which are the hardest to verify and the most damaging to the commons if wrong.

Mitigation: pay only for accepted outcomes; scarcity weighting; per-epoch and per-claimant caps enforced on-chain; regressive curves; many weak signals combined rather than one trusted signal; human adjudication with appeals; retrospective, window-closed distributions where possible.

Limit — and this is the honest part: Helium spent six years, roughly fifteen governance proposals, hardware whitelisting, denylists, trust scores, external geolocation cross-checks and modelled coverage trying to make a physical-contribution reward un-gameable, and then retired the mechanism entirely (HIP-149) in favour of paying only for measured, delivered outcomes. CGW's problem is structurally the same and CGW has vastly fewer resources. The mitigations reduce the payoff from gaming; they do not eliminate it, and it would be dishonest to suggest a small team has solved a problem a well-funded network could not.

34.4 Regulatory classification is unresolved and may prevent an EU offer entirely#

CGW's classification under MiCA is an open legal question, not a settled one. Several specific issues are live:

• Whether contribution rewards constitute a "free" distribution under Article 4(3)(a), given that the

second subparagraph removes the exemption where recipients provide personal data or where the offeror receives non-monetary benefits in exchange. The CGW reward mechanic sits directly on both limbs.

• Whether any planned feature makes CGW a MiFID financial instrument under Article 2(4)(a), which

would remove it from MiCA and into a much heavier regime. Governance rights are the feature that most commonly pulls a token toward that boundary.

• Whether any exemption is reachable at all, given that the described utility does not yet exist —

which blocks Article 4(3)(c) and imposes the Article 4(6) 12-month cap on any white-paper route.

• That drawing up a MiCA-format white paper voluntarily for an otherwise-exempt offer makes the

whole of Title II apply (Article 4(8)). The document you are reading is deliberately not that.

Mitigation: a completed regulatory analysis (CGW_MICA_REQUIREMENTS.md), legal review as a hard gate before any deployment, and an editorial standard applied now to every public surface.

Limit: the honest possible outcome is that no compliant EU offer is available for a design of this shape, and that the token programme ends there. That is a real risk, not a formality, and it is not within the project's control.

34.5 The environmental allocation funds work the project cannot fully verify#

Environmental and biodiversity outcomes are difficult to verify at a distance. The project has no field capability, no independent monitoring apparatus, and no ability to distinguish reliably between a well-documented project and a well-documented fiction. Milestone-gated disbursement raises the cost of fraud; it does not prevent it. There is also a subtler failure mode: a grantee may be entirely honest and the intervention may simply not work.

Mitigation: separate vault; separate reporting; disbursement only against evidence; published grant line items so third parties can scrutinise them.

Limit: the project may fund work that does not deliver, and may report it as delivered because the evidence it received said so. It will not claim otherwise, and it will not claim that holding CGW produces an environmental outcome.

34.6 Solana network risk#

CGW would inherit every property of the network it lives on: outage risk, congestion, fee-market behaviour, validator concentration, client bugs, and governance decisions taken by parties with no relationship to CoinGarden. Solana has experienced network halts. Helium's own migration documentation explicitly recommends batching and avoiding real-time on-chain dependencies so that chain downtime cannot block work.

Mitigation: no product functionality depends on the chain; claims are batched by epoch rather than real-time; the product works fully when the chain does not.

Limit: if the network is unavailable, claiming is unavailable. If the network fails permanently, the tokens are gone. There is no fallback and the project cannot create one.

34.7 Smart-contract risk, pre-audit#

Neither program has been written to production standard, deployed, or audited. Merkle verification, PDA derivation, cap arithmetic, rounding at schedule boundaries, and vault authority configuration are all places where a defect could permanently misallocate tokens.

Mitigation: deliberately minimal surface area (no token program, no governance program, no staking program, no custom transfer logic); tested integer maths in the specification package; audit as a hard gate; a rehearsed devnet deployment before mainnet.

Limit: an audit examines submitted code against an agreed threat model at a point in time. It is not a warranty. Audited programs have failed.

34.8 The team allocation is a concentration risk#

15% — 150,000,000 CGW — to a small group of people is a meaningful concentration. Even with a 12-month cliff and vesting to month 48, at month 48 the team holds a substantial share of circulating supply, and their interests are not automatically aligned with contributors'.

Mitigation: on-chain, non-accelerable vesting; a 12-month cliff; a share deliberately set below the comparable venture-backed precedents; insider exclusion from contribution rewards; no locked-token governance weight.

Limit: vesting controls timing, not intent. It does not prevent coordinated selling after vesting, does not prevent influence over governance, and does not change the fact that a small group holds a large share. Nothing in the design solves this, and it should not be presented as though it does.

34.9 Governance may be captured or apathetic#

Both failure modes are live and they pull in opposite directions. Apathy is the more likely one: most CoinGarden users will hold no CGW and have no interest in voting, and a governance system that cannot reach quorum is a governance system in name only — Jito's DAO demonstrated exactly this. The opposite risk is that a small number of large holders, plausibly including the team, effectively decide every vote.

Mitigation: progressive scope starting from non-binding signalling; thresholds computed from on-chain supply rather than hard-coded; no voting weight for locked or unvested allocations; no foundation delegation of voting blocks; security and privacy decisions permanently out of scope.

Limit: these reduce the damage each failure mode can do. They do not produce legitimate participation, which cannot be engineered.

34.10 The product may not reach the scale the model assumes#

The rewards model implicitly assumes enough contributors, across enough species and regions, over enough years, for a decaying ten-year emission to be spent meaningfully. If CoinGarden reaches a few thousand users rather than a few hundred thousand, the entire contribution-commons argument weakens: rewards concentrate among a handful of people, scarcity weighting has little to weight, and the token's justification largely disappears.

Mitigation: the token roadmap is gated on product milestones; the emission is a ceiling rather than a commitment, so unspent budget stays in the vault.

Limit: there is no mitigation for the underlying possibility, which is that the product does not find enough users. In that scenario the correct decision is not to launch, and the project should be willing to make it.

34.11 Treasury mismanagement#

200,000,000 CGW plus 50,000,000 CGW environmental would be controlled by a small multisig for years. The risk is not only theft — it is ordinary mismanagement: spending on the wrong things, spending too fast, funding work that does not deliver, or letting reporting lapse until nobody knows what happened.

Mitigation: linear release rather than a genesis unlock, so the treasury cannot be spent down quickly; a 3-of-5 multisig with independent signers; separate vaults so environmental funds cannot be repurposed silently; published addresses; line-item grant reporting; advance notice before material movements.

Limit: a multisig constrains unilateral action by one person; it does not constrain a group that agrees with itself. Reporting commitments are only as good as the discipline that sustains them, and lapsed transparency commitments are common — a commitment that lapses is worse than one never made.

34.12 Dependence on off-chain verification infrastructure#

The entire reward layer depends on a centralised, project-operated pipeline that decides what counts as an accepted contribution and computes each epoch's distribution. If that pipeline is wrong, biased, compromised, or simply unavailable, rewards are wrong, biased, compromised or unavailable. There is no decentralised alternative in the design and no independent party currently able to reproduce its output.

Mitigation: the pipeline can only determine eligibility, never create supply; on-chain caps bound the damage from a bad epoch; roots are published before claiming opens so a distribution is inspectable before it executes; an appeals path exists for individual determinations.

Limit: publishing a root does not make it verifiable unless the inputs are also verifiable, and the inputs include user data that cannot be published. This is a genuine and unresolved tension in the design: full auditability of rewards and full privacy of contribution data are partly in conflict, and the current answer — aggregate transparency plus individual appeal — is a compromise rather than a solution.

34.13 Key-management risk#

Loss or compromise of signing keys is a permanent, unrecoverable failure mode. Three lost keys deadlock a 3-of-5 multisig. Three compromised keys control the vaults. A user who loses their own wallet loses their tokens, and the project cannot restore them.

Mitigation: hardware wallets; geographic and organisational separation of signers; a dedicated recovery/security signer category; documented and rehearsed rotation procedures; a genesis ceremony that destroys ephemeral authority keys.

Limit: every one of these is a procedure executed by people, and procedures decay. The design does not solve key management; it distributes it.

34.14 Documentation and communication risk#

A design document published during a design phase can be quoted later, out of context, as if it were a commitment — or can drift out of date and become misleading through neglect rather than intent. Under MiCA a public communication about a crypto-asset can itself constitute a marketing communication or, if it presents sufficient information about terms, an offer to the public.

Mitigation: version-controlled in the repository so every historical claim is recoverable and diffable; status labels on every claim; an explicit regulatory notice; an editorial standard prohibiting future-value statements everywhere.

Limit: readers skim. The regulatory notice in section 1 is the most important part of this document and the least likely to be read.

---

Full analysis: CGW_MICA_REQUIREMENTS.md. This section states only the constraints that shape the design.

35.1 Applicable regime#

CGW as conceived does not purport to maintain a stable value by reference to an official currency or to any other value or right, so on the face of the definitions it does not read as an asset-referenced token or an e-money token. Any EU public offer would therefore fall under Title II of MiCA. This is a preliminary technical reading of the definitions, not a legal classification, and it must be confirmed by counsel — including a properly conducted assessment of whether any planned feature makes CGW a financial instrument under MiFID II, which would take it outside MiCA entirely.

35.2 Constraints applied to this document and every public surface#

Constraint	Source	How it is applied
No assertions about future value	Art. 6(4)	No price, no projection, no return metric, anywhere
Fair, clear, not misleading	Art. 6(2), 7(1)(b)	Status labels; explicit statements of what is undecided
Not-yet-existing utility described honestly	Art. 4(3)(c), 7(1)(b)	Every utility labelled; no present-tense claims
No statement of intent to seek admission to trading	Art. 4(4)	No listing language in any repository document, roadmap, or public surface
Marketing rules apply to social channels	Recital 24	A communications policy covering site, socials and team accounts is PLANNED
A voluntary white paper opts into the full regime	Art. 4(8)	This document is deliberately not a MiCA-format white paper
Conduct duties apply even to exempt offers	Art. 4(1)(g), Art. 14	Honest, fair, professional conduct; conflicts disclosed; equal treatment

35.3 The specific issue the design has to live with#

MiCA Article 4(3), second subparagraph, provides that a crypto-asset is not considered to be offered for free where recipients are required to provide personal data to the offeror in exchange for it, or where the offeror receives fees, commissions, or monetary or non-monetary benefits in exchange for it.

The CGW reward mechanic is: a user submits verified plant data — photographs, species identification, care history, in many cases location and device metadata — and receives CGW. Both limbs are arguable on a plain reading. The design cannot be built on the assumption that "we never sell tokens, so this does not apply".

The architectural response is to keep data submission and token receipt as separable as the product allows, to avoid referral and promotional reward mechanics entirely, and to document the data flows as a factual record for counsel. The response is not a conclusion that the exemption is available.

35.4 Service perimeter#

An in-app swap, a fiat on-ramp, an order book, or a custodial balance a user cannot self-custody would each engage the MiCA crypto-asset service perimeter and require authorisation. The wallet architecture in section 23 is designed to stay outside that perimeter, and any future feature that approaches it requires a service-perimeter analysis before it is built.

35.5 Parallel obligations#

MiCA is not the only regime. At minimum, GDPR (the plant-data mechanic is the same fact pattern as the Article 4(3) question), Regulation (EU) 2023/1113 on transfers of funds, AML/CFT obligations, consumer-protection and unfair-commercial-practices law, and national tax treatment of contribution rewards all apply in parallel. None has been analysed to conclusion.

---

36.1 What is committed#

Commitment	Status
The canonical specification is version-controlled in the repository, so every historical claim is recoverable and diffable	LIVE
Every number in every document derives from one source file; no figure is restated as a literal	LIVE
Supply and unlock data published as tables and machine-readable data, never as images only	LIVE
Research on comparable projects published in full, including what could not be verified	LIVE
Regulatory analysis published in full, including unresolved questions	LIVE
Every production vault address published before it holds meaningful value	PROPOSED
Treasury movements reported on a fixed published cadence	PROPOSED
Grants published as line items, not narrative	PROPOSED
Audit report published in full, including unresolved findings	PROPOSED
Epoch distribution roots published before claiming opens	PROPOSED
Insider exclusion from contribution rewards, written down in design phase	PROPOSED

36.2 What is deliberately not committed#

• A reporting cadence the project cannot sustain. A lapsed commitment is worse than no commitment,

and the pattern of quarterly transparency reports that stop after one is common enough to be a design warning.

• Publication of individual contribution records. Aggregate transparency plus individual appeal is

the current position; per-user public attribution has privacy consequences that have not been worked through.

• Any figure this document does not already have. Where a number has not been computed and tested,

the design paper describes the property qualitatively rather than inventing a value.

36.3 The self-criticism standard#

The research documents in research/ each contain an explicit "what I could not verify" section, and each includes a "what CGW must explicitly NOT copy" section that argues against the project's own instincts. The regulatory analysis routes fifteen unresolved questions to counsel rather than concluding in the project's favour. This document names fourteen risks including the possibility that the whole programme ends. That standard is the point, and it should be applied to every future document in this folder.

---

Term	Definition
CGW	The proposed SPL token described in this document. Not deployed.
GRDN	The token name used in legacy CoinGarden documentation. Superseded by CGW. Legacy GRDN tokenomics are not carried over.
World of Flowers	The name of the CoinGarden user experience.
Allocation	A named share of maximum supply with a stated purpose, vault and release schedule.
Vault	A token account holding one allocation, with a stated controller.
Release schedule	The rule determining how much of an allocation has left its vault by a given month.
Cliff	A period during which nothing is claimable, even though accrual has begun.
Linear vesting	Accrual at a constant rate over a stated duration.
Decaying emission	A release schedule whose annual budget falls by a fixed factor each year. Here, 0.945.
TGE / genesis	Token generation event — the single moment the fixed supply is minted. NOT DEPLOYED.
Circulating supply	Released tokens held by parties other than the project. Excludes treasury-controlled vaults.
Treasury-controlled	Released from a schedule but still held in a project-controlled vault; not circulating.
Released supply	Everything that has left its vault under its schedule, whether circulating or treasury-controlled.
Epoch	A bounded period over which accepted contributions are aggregated into one distribution. Cadence undecided.
Merkle root	A commitment to an epoch's full distribution list, published before claiming opens.
PDA	Program-derived address — a deterministic account address controlled by a program rather than a private key.
Claim PDA	A per-claimant, per-epoch account whose existence proves a claim has already been made.
Mint authority	The account permitted to create new tokens. Proposed to be permanently revoked after genesis.
Freeze authority	The account permitted to freeze token accounts. Proposed to be null from creation.
SPL Token	The standard Solana token program. CGW proposes to use it with no custom transfer logic.
Multisig	An arrangement requiring multiple independent signatures to authorise a transaction. Proposed: 3-of-5.
Garden Credits	A researched, non-transferable, euro-denominated service-credit balance. RESEARCH only.
Contribution	A change to the shared plant commons that survives verification. Distinct from activity.
Scarcity weighting	Paying more for contributions in under-covered species, regions or conditions.
MiCA	Regulation (EU) 2023/1114 on markets in crypto-assets.
Title II	The MiCA regime for crypto-assets other than asset-referenced and e-money tokens.
Crypto-asset white paper	The specific document required by MiCA Article 6. This document is not one.

---

Appendix A — Canonical sources#

Artefact	Path	Role
Token specification	packages/token-spec/src/spec.ts	Single source of truth for every number
Tokenomics maths	packages/token-spec/src/tokenomics.ts	Integer-exact simulation
Supply scenarios	packages/token-spec/src/scenarios.ts	The 500M / 1B / 10B comparison
Status vocabulary	packages/token-spec/src/status.ts	The label set used throughout
Validation	packages/token-spec/src/validate.ts	Invariants enforced in tests

Appendix B — Arithmetic conventions#

• All token quantities are computed in integer base units using arbitrary-precision integers.

Floating point is used only to derive an emission weight, never to hold a token amount.

• One token = 10^9 base units (9 decimals).
• Every period floors; the final period of a schedule receives the accumulated remainder, so a

schedule releases its allocation exactly.

• Allocation percentages are validated to sum to exactly 100, compared in hundredths of a percent to

avoid binary floating-point drift.

• The largest allocation absorbs any remainder from splitting total supply, so allocations sum to

total supply exactly.

Consequence: any two runs of the model produce identical output, and no chart can disagree with this document by a rounding error.

Appendix C — Allocation reconciliation#

Allocation	%	CGW	Released by month 120	Circulating at month 120
Ecosystem & contributor rewards	45%	450,000,000	100%	Yes
Core team	15%	150,000,000	100%	Yes
Liquidity & integrations	10%	100,000,000	100% (at genesis)	Yes
Early community	5%	50,000,000	100% (at genesis)	Yes
Ecosystem treasury	20%	200,000,000	100% (by month 48)	No — treasury-controlled
Environmental impact	5%	50,000,000	100% (by month 60)	No — treasury-controlled
Total	100%	1,000,000,000	100%	75.00% (750,000,000)

The four circulating allocations sum to 75% of supply — 450,000,000 + 150,000,000 + 100,000,000 + 50,000,000 = 750,000,000 — which is exactly the month-120 circulating figure in section 17. The two treasury-controlled allocations sum to the residual 25%.

Appendix D — Vault topology#

Vault	Holds	Proposed controller	Status
Ecosystem Rewards Vault	450,000,000 CGW	Rewards program PDA, funded per epoch under a multisig-approved budget	NOT DEPLOYED
Treasury Vault	200,000,000 CGW	Treasury multisig	NOT DEPLOYED
Team Vesting Vault	150,000,000 CGW	Vesting program PDAs; beneficiaries claim, nobody can accelerate	NOT DEPLOYED
Liquidity Vault	100,000,000 CGW	Treasury multisig	NOT DEPLOYED
Environmental Impact Vault	50,000,000 CGW	Treasury multisig, disbursed against verified milestone evidence	NOT DEPLOYED
Community Vault	50,000,000 CGW	Treasury multisig, disbursed against a published distribution list	NOT DEPLOYED

No vault address exists on any cluster. Every address field in the canonical specification is null.

Appendix E — Deployment status#

Cluster	Status	Mint	Note
localnet	PLANNED	none	Local validator development has not started
devnet	NOT DEPLOYED	none	No devnet mint has been created
mainnet-beta	NOT DEPLOYED	none	Requires legal review, final tokenomics approval and an external audit first

Appendix F — Research corpus#

Document	Subject	Primary relevance to CGW
research/JUP.md	Jupiter	Wallet transparency, on-chain vesting locks, batched community distribution, why not to run a mega-airdrop
research/JTO.md	Jito	Retrospective window-closed distribution, regressive tiers, insider exclusion, claim deadlines, quorum failure
research/PYTH.md	Pyth	Named data-contributor allocation, paying more for under-served data, published penalty rulebooks, domain-separated governance
research/RENDER.md	Render	Burn-and-mint mechanics, the 0.945 damping coefficient, emissions decoupled from burn, published proposal process
research/HNT.md	Helium	Data Credits, non-transferability as the load-bearing constraint, the full anti-Sybil history, why a governance-defended cap is not a cap
research/BONK.md	Bonk	Cautionary case — strong on-chain hygiene, near-absent allocation disclosure and governance record

Appendix G — Document control#

Field	Value
Version	0.1.0-draft
Date	9 August 2026
Status	DRAFT — NOT AN OFFER
Supersedes	Nothing. This is the first version.
Canonical location	docs/token/CGW_WHITEPAPER.md in the CoinGarden.World repository
Change policy	Every substantive change is a versioned commit; history is recoverable and diffable via git

This document is not a crypto-asset white paper within the meaning of Article 6 of Regulation (EU) 2023/1114. No offer of CGW is being made. Nothing described here is deployed. This is not investment, legal or tax advice.