Key Concepts

Carbon Pools — What you need to know

Once a project's carbon credits have been tokenized — i.e. transferred onto the Toucan Registry using using the Carbon Bridge — these credits are represented as BCO2 tokens (Buckmint carbon tokens).

A BCO2 token still contains all the project-specific attributes, such as the project's country or methodology. This means tokens from one project are not interchangeable with tokens from another project, even if they are very similar.

Bundle logic

Each bundle has a unique configuration and carries a certain logic that dictates which BCO2 tokens can be deposited into it. This logic is based on two filters:

1. Is the token to be deposited a BCO2 Buckmint carbon token?

   This check guarantees that only whitelisted token contracts are accepted and prevents somebody from depositing a custom token into a carbon pool.

2. Do the BCO2 token attributes satisfy the bundle's requirements?

   When a bundle is deployed, it needs to specify gating attributes. Any BCO2 token deposited in the pool must contain at least these attributes — otherwise the deposit transaction will revent.

A few examples of gating attributes a carbon reference pool might have:

• type = removal — a bundle that only accepts carbon removal credits.

• vintage = >2018 — only accepts credits from 2018 and later.

• country = India — only accepts BCO2s from India.

For example, we could create a carbon removal bundle, with a token called CRT (carbon removal token). This specific bundle would only carry one defining attribute: type = removal. In this case, the carbon removal reference token could be called CRT.

Of course, bundles could also use a combination of gating attributes, meaning we can create liquid carbon reference tokens backed by bundles of similar tokenized credits.