ArchitectureSolana architecture
A standard SPL mint, two small purpose-built programs, and a hard rule that nothing custom sits in the transfer path.
Architecture, not deployment. Every component below is a design. None has been deployed to localnet, devnet or mainnet-beta.
Decision
Why Solana
The simple version
APPROVED FOR IMPLEMENTATIONCoinGarden expects a very large number of very small reward claims. On many networks the fee to claim a small reward would exceed the reward itself, which makes the whole idea pointless. Solana's transaction costs are low enough that a small claim is still worth making.
How it actually works
The rewards model only works if claiming is economically rational at the low end of the distribution. A contributor who earns a modest reward for documenting an uncommon species must not lose most of it to fees. Solana’s fee structure and throughput make per-user claims viable, and the SPL token program provides everything CGW needs without custom token logic.
Technical specification
Claims are individual transactions against a deterministic PDA. At Solana’s base fee plus rent-exempt claim-record overhead, per-claim cost stays low enough that epoch-batched claiming remains practical for a broad contributor base. Merkle-proof verification fits comfortably within compute budget for realistic tree depths.
This decision supersedes the previous Base/EVM direction. Earlier project documentation described a Base-first, EVM-standard token and a Solidity contract in packages/contracts. That work is retained as historical context and is not the CGW token. The current direction is Solana.
Components
How the pieces fit together
CGW SPL mintFixed supply, mint authority revoked after genesis, freeze authority null. APPROVED FOR V1 — NOT DEPLOYED.
Ecosystem Rewards Vault → cgw-rewardsThe only account the rewards program may draw from. Epoch Merkle roots, deterministic claim PDAs. NOT DEPLOYED.
Treasury Vault → Squads multisig3-of-5 threshold. Development, grants, audits, operations. NOT DEPLOYED.
Team Vesting Vault → cgw-vestingOn-chain schedules, beneficiary-claimed, non-accelerable. NOT DEPLOYED.
Liquidity, Community, Environmental vaultsMultisig-controlled, disbursed against published lists or verified evidence. NOT DEPLOYED.
Future: marketplace, governance, impact, World of FlowersNo design committed. FUTURE.
Programs
Custom programs and their limits
cgw-vesting
NOT DEPLOYEDEnforces 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
Program ID: none — not deployed
cgw-rewards
NOT DEPLOYEDReleases 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
Program ID: none — not deployed
No custom transfer contract. CGW does not reimplement token transfers. Moving CGW is an ordinary SPL Token instruction. The two programs above only handle CGW-specific release logic — when tokens may leave a vault, and to whom.
Environments
Cluster separation
Localnet, devnet and mainnet-beta are kept strictly separate: separate keypairs, separate configuration, and no shared authority. A devnet mint is never presented as the CGW token.