Разработка системы учёта углеродных кредитов на блокчейне
Углеродные кредиты — это специфический актив: один кредит = одна тонна CO2, которая была предотвращена или поглощена. Проблема существующих реестров (Verra, Gold Standard, American Carbon Registry) — информационная асимметрия и двойной учёт. Один и тот же кредит может быть продан дважды, «отставшие на полку» кредиты из проектов 2010 года продаются как свежие, а верификация реального воздействия — дело на усмотрение аккредитованных аудиторов с конфликтом интересов.
Блокчейн-системы для углеродных кредитов решают техническую проблему двойного учёта через уникальные on-chain идентификаторы, но создают новые вызовы: как верифицировать реальное поглощение CO2? Как обеспечить interoperability с существующими реестрами? Как не создать очередной «greenwashing» инструмент?
Стандарты токенизации углеродных кредитов
Прежде чем писать смарт-контракты, нужно понять существующие стандарты, иначе созданные токены не будут признаны рынком.
Toucan Protocol стандарт — TCO2 (Tokenized Carbon Offset). Привязывает существующие кредиты из Verra VCS к ERC-20 токенам. Процесс: кредит «сжигается» в реестре Verra → генерируется TCO2 токен on-chain. Это мост между legacy реестрами и блокчейном, но не решает проблему качества самих кредитов.
Moss Earth (MCO2) — аналогичный подход, но только для Amazon-проектов.
Regen Network строит собственный слой верификации на Cosmos с data modules для экологических данных — наиболее продвинутая с точки зрения верификации система.
W3C Verifiable Credentials + DID для документов о проектах — emerging стандарт для цифровых сертификатов, который начинают использовать прогрессивные реестры.
Для новой системы рекомендуем: совместимость с Toucan-стандартом для fungible кредитов + ERC-721 для проектных токенов (каждый проект уникален) + собственный слой верификации.
Архитектура данных и верификация
Иерархия данных углеродного кредита
Один углеродный кредит несёт значительно больше атрибутов, чем просто количество тонн CO2. Для полноценного учёта:
struct CarbonProject {
bytes32 projectId; // уникальный ID
string methodology; // VM0007, AR-ACM0003, etc. — методология верификации
string registry; // Verra, Gold Standard, ACR
string externalId; // ID в оригинальном реестре
uint256 startDate;
uint256 endDate;
int256 latitude; // координаты проекта (в microdegrees)
int256 longitude;
ProjectType projectType; // Forestry, Renewable, Methane, etc.
address projectDeveloper;
uint256 totalIssuable; // максимальный объём кредитов
uint256 totalIssued;
ProjectStatus status;
}
struct CarbonVintage {
bytes32 vintageId;
bytes32 projectId;
uint256 year; // год поглощения
uint256 quantity; // тонны CO2
string verificationReport; // IPFS CID отчёта верификатора
address verifier; // аккредитованный верификатор
bytes32 serialNumber; // номер в оригинальном реестре
bool retired; // использован (retired) — нельзя продать снова
}
Retirement (использование кредита) — критичная операция. Когда компания компенсирует эмиссии, она «сжигает» кредит. На блокчейне это должна быть необратимая операция с публичной записью:
event CreditRetired(
bytes32 indexed vintageId,
address indexed beneficiary, // кто компенсирует
string retirementReason, // "2024 Scope 1 emissions"
uint256 amount,
uint256 retiredAt
);
function retireCredits(
bytes32 vintageId,
uint256 amount,
string calldata reason,
address beneficiary
) external {
CarbonVintage storage vintage = vintages[vintageId];
require(!vintage.retired, "Already retired");
require(balanceOf(msg.sender, uint256(vintageId)) >= amount, "Insufficient balance");
_burn(msg.sender, uint256(vintageId), amount);
retiredAmounts[vintageId] += amount;
if (retiredAmounts[vintageId] == vintage.quantity) {
vintage.retired = true;
}
emit CreditRetired(vintageId, beneficiary, reason, amount, block.timestamp);
}
MRV: Measurement, Reporting, Verification on-chain
Верификация реального поглощения CO2 — это oracle задача. Существующие подходы:
Satellite data оракулы. NDVI (индекс растительности) из спутниковых снимков (Sentinel-2, Landsat) позволяет оценивать состояние лесных проектов. Сервисы типа Planet Labs или Verra's satellite-based monitoring дают данные, которые можно поставить on-chain через Chainlink Functions или кастомный оракул.
// Chainlink Function для получения NDVI данных
const projectId = args[0];
const coordinates = args[1]; // "lat,lon,radius"
// Запрос к Planet Labs API
const response = await Functions.makeHttpRequest({
url: `https://api.planet.com/data/v1/quick-search`,
method: "POST",
headers: { "Authorization": `api-key ${secrets.planetApiKey}` },
data: {
item_types: ["PSScene"],
filter: {
type: "AndFilter",
config: [
{ type: "GeometryFilter", field_name: "geometry", config: parseCoords(coordinates) },
{ type: "DateRangeFilter", field_name: "acquired",
config: { gte: startDate, lte: endDate } }
]
}
}
});
const ndviAverage = calculateNDVI(response.data);
return Functions.encodeUint256(Math.round(ndviAverage * 10000)); // 4 decimal places
IoT сенсоры. Для methane capture проектов — датчики потока газа, подключённые к блокчейну через Chainlink Direct Request или собственный оракул. Каждая измеренная тонна CH4 (эквивалент 25 тонн CO2) → генерация кредита на счёт проекта.
Trusted verifier система. Аккредитованные верификаторы (аналог нотариусов) подписывают отчёты о верификации. Multisig или threshold signature требует подписей нескольких независимых верификаторов. Менее децентрализованно, но соответствует существующим регуляторным требованиям.
Токенизация: fungible vs non-fungible
Дискуссионный вопрос в индустрии.
ERC-20 (fungible). Все тонны CO2 взаимозаменяемы. Удобно для торговли и DeFi (ликвидность в пулах). Проблема: «плохие» кредиты (старые vintage, сомнительные методологии) смешиваются с «хорошими». Toucan решил это через carbon pools: BCT (Base Carbon Tonne) — пул с минимальными требованиями, NCT (Nature Carbon Tonne) — только природные проекты после 2012 года.
ERC-1155 (semi-fungible). Кредиты одного vintage взаимозаменяемы между собой, но не с кредитами другого vintage. Более точное отображение реального рынка, но хуже ликвидность.
ERC-721 (non-fungible) для проектных токенов. Каждый проект — NFT с метаданными, историей верификации, ссылкой на документы. Торгуется отдельно от кредитов, представляет долю в потоке будущих кредитов.
Рекомендуемая архитектура: ERC-721 для проектов → ERC-1155 для vintages → ERC-20 пул для ликвидности (аналог Toucan pools).
Interoperability с legacy реестрами
Для системы, претендующей на серьёзный рынок, обязательна интеграция с Verra VCS или Gold Standard. Технически это процесс бриджинга:
- Проект-разработчик получает кредиты в Verra реестре.
- Проходит KYC/AML верификацию в системе.
- Инициирует bridge: Verra через интеграцию списывает кредиты со счёта и генерирует сертификат отзыва.
- Сертификат верифицируется oracle-нодой или trusted verifier.
- Смарт-контракт минтит эквивалентное количество on-chain токенов.
Проблема: Verra пока не предоставляет API для автоматического bridge. Процесс требует manual верификации от Verra или использования аккредитованного брокера. Ожидается, что к 2026 году несколько крупных реестров выпустят официальные API для блокчейн интеграций.
Торговля и DeFi интеграция
Automated Market Maker. Пул углеродных токенов на Uniswap V3 или кастомный AMM с учётом специфики актива: carbon credits не depreciating asset, но может иметь сезонность и корреляцию с новостями о климатическом регулировании.
Forward contracts. Продажа будущих кредитов — распространённая практика в carbon рынке. Смарт-контракт для форвардов: покупатель платит сейчас, получает кредиты при верификации будущего vintage. Escrow с условиями доставки.
Reporting и audit trail. Для корпоративных покупателей критично: полная цепочка ownership от генерации до retirement, экспорт данных для ESG отчётности, интеграция с корпоративными ERP системами (SAP, Oracle) через API.
Регуляторная совместимость
Системы учёта углеродных кредитов работают в зарегулированном пространстве. Ключевые стандарты:
- UNFCCC Paris Agreement Article 6 — международные правила торговли углеродными кредитами между странами, включая требования по corresponding adjustments (избегание двойного учёта между странами)
- ISO 14064 — стандарт для количественного определения и отчётности о выбросах
- CORSIA (авиационная отрасль) — требует кредитов только из одобренных программ
KYC/AML обязателен для участников рынка выше определённых порогов — это не опционально. Встраивается через whitelist механизм с on-chain верификацией identity.
Сроки разработки
| Фаза | Содержание | Срок |
|---|---|---|
| Архитектурное проектирование | Стандарты, token model, oracle strategy | 2–3 недели |
| Core контракты | Project registry, vintage minting, retirement | 4–6 недель |
| Oracle интеграция | Verifier система или Chainlink Functions | 3–4 недели |
| Bridge с legacy реестрами | API интеграция с Verra/Gold Standard | 4–8 недель |
| Trading layer | Carbon pool AMM, forward contracts | 4–6 недель |
| Reporting API + dashboard | ESG отчётность, публичный explorer | 3–4 недели |
| Аудит | Акцент на retirement integrity, double-spend | 4–6 недель |
Полный цикл MVP (без bridge с legacy реестрами): 4–5 месяцев. С полноценной интеграцией в существующую инфраструктуру углеродного рынка — 8–12 месяцев, с учётом времени на переговоры с реестрами.







