Skip to main content

Tokenization System

Overview​

On CO2 TRUST, every carbon credit offered through the platform is a CO2T credit. We refer to one tonne of that platform credit as a 1TON credit. Tokenization turns that inventory into digital representations so credits can be tracked, traded, listed, retired, and (where supported) bridged from registries with clear audit trails.

Underlying removal or avoidance may be verified by different bodies; the product you interact with on our platform is always the same class of thing: a CO2T (1TON) credit.

Where credits come from​

Credits may originate from:

  • Puro.earth — Puro issues removal certificates it brands CORC (CO₂ Removal Certificate). On our platform those become CO2T 1TON credits; we still use internal labels that align with that lineage.
  • Isometric — Credits verified under Isometric’s registry and naming; represented on-platform as CO2T 1TON credits.
  • Carbon Standard International (CSI) — Credits verified under CSI’s standard (their public naming differs from Puro’s); represented on-platform as CO2T 1TON credits.
  • CO2True direct issuance — Credits issued for partner programs (for example Woodchuck or other partners) where CO2True is the issuing path; these are also CO2T 1TON credits.

You do not need to learn each registry’s trademarked name to use the marketplace: one consistent platform credit type, with provenance recorded (registry, project, methodology, etc.).

CORC, FORC, and MORC (why the names can confuse)​

In software and smart contracts, we categorize tokens with three values: CORC, FORC, and MORC. That is an implementation taxonomy for lifecycle and trading rules, not a claim that every registry uses those words.

  • Puro.earth also uses the term CORC for its removal certificates. Our CORC token type is aligned with that lineage when the underlying inventory is Puro-linked; the same code label does not mean “only Puro” in every listing—it means “this token follows the CORC-style lifecycle in our stack.”
  • CSI, Isometric, and other partners use their own certificate and product names off-platform. We do not mirror every registry’s naming in code; we map verified inventory into our CO2T / 1TON model and the CORC / FORC / MORC types where the contract and backend require it.

For partner integrations, treat 1TON / CO2T credit as the root concept; use registry-specific names only when explaining provenance to end users or in compliance copy.

Retirement and bridging​

Retirement (what holders do): a simple prompt at CO2True.com—you provide in whose name the credit is retired; CO2True processes within the stated window and communicates the outcome across registry partners (Puro, Isometric, CSI, CO2True issuance, etc.) as each one requires. You are not asked to run separate registry portals yourself. See Retirement.

Bridging (getting inventory onto the platform): you work through CO2True-led flows (including CO2True.com and onboarding)—CO2True coordinates Puro, Isometric, CSI, CO2True issuance, and other partners as needed so verified credits become CO2T credits on-platform; you are not asked to stitch registry portals yourself. Under the hood, integrations remain per operator (not one generic bridge API). See Bridging.

External marketplaces (directional)​

We expect CO2T 1TON credits to be compatible over time with distribution and retirement on other venues (for example tokenized carbon marketplaces such as Toucan.earth), subject to legal, technical, and registry rules. That work is roadmap; the documentation here describes the platform-native credit and token model.

Basic flow​

  1. Credits are verified through the relevant registry or CO2True partner issuance.
  2. Inventory is represented as CO2T (1TON) credits for listing, purchase, and lifecycle actions.
  3. Credits move through listing, transfer, retirement, and (as integrations land) bridging and external marketplace connectivity.

For technical details​

Conclusion​

Tokenization makes CO2T 1TON credits traceable and operable in one system, while registry and partner provenance stay explicit. Internal names like CORC/FORC/MORC exist for engineering consistency, not to duplicate every registry’s public branding.