Розробка системи обліку вуглецевих кредитів на блокчейні

Розробка системи обліку вуглецевих кредитів на блокчейні

Вуглецеві кредити — це специфічний актив: один кредит = одна тонна CO2, яка була попереджена або поглинута. Проблема існуючих реєстрів (Verra, Gold Standard, American Carbon Registry) — інформаційна асиметрія та подвійний облік. Один і той же кредит можна продати двічі, «залежалі на полиці» кредити з проектів 2010 року продаються як свіжі, а верифікація реального впливу — це справа на розсуд акредитованих аудиторів з конфліктом інтересів.

Системи на блокчейні для вуглецевих кредитів вирішують технічну проблему подвійного обліку через унікальні on-chain ідентифікатори, але створюють нові виклики: як верифікувати реальне поглинання CO2? Як забезпечити взаємодію з існуючими реєстрами? Як не створити ще один інструмент «greenwashing»?

Стандарти токенізації вуглецевих кредитів

Перш ніж писати смарт-контракти, потрібно розуміти існуючі стандарти, інакше створені токени не будуть визнані ринком.

Toucan Protocol стандарт — TCO2 (Tokenized Carbon Offset). Прив'язує існуючі кредити з Verra VCS до ERC-20 токенів. Процес: кредит «спалюється» в реєстрі Verra → генерується TCO2 токен on-chain. Це міст між legacy реєстрами та блокчейном, але не вирішує проблему якості самих кредитів.

Moss Earth (MCO2) — аналогічний підхід, але тільки для проектів Амазонки.

Regen Network будує свій власний рівень верифікації на Cosmos з data modules для екологічних даних — найбільш просунута система з точки зору верифікації.

W3C Verifiable Credentials + DID для документів проектів — перспективний стандарт для цифрових сертифікатів, який починають використовувати передові реєстри.

Для нової системи рекомендуємо: сумісність зі стандартом Toucan для fungible кредитів + ERC-721 для проектних токенів (кожен проект унікальний) + власний рівень верифікації.

Архітектура даних і верифікація

Ієрархія даних вуглецевого кредиту

Один вуглецевий кредит несе значно більше атрибутів, ніж просто кількість тонн CO2. Для повноцінного обліку:

struct CarbonProject {
    bytes32 projectId;          // унікальний ID
    string methodology;         // VM0007, AR-ACM0003 тощо — методологія верифікації
    string registry;            // Verra, Gold Standard, ACR
    string externalId;          // ID у оригінальному реєстрі
    uint256 startDate;
    uint256 endDate;
    int256  latitude;           // координати проекту (в мікрастепенях)
    int256  longitude;
    ProjectType projectType;    // Forestry, Renewable, Methane тощо
    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) — не можна продати ще раз
}

Вихід (використання кредиту) — критична операція. Коли компанія компенсує викиди, вона «спалює» кредит. На блокчейні це повинна бути необоротна операція з публічною записом:

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 — це завдання оракула. Існуючі підходи:

Оракули супутникових даних. 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"

// Запит до API Planet Labs
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 сенсори. Для проектів захоплення метану — датчики потоку газу, підключені до блокчейну через Chainlink Direct Request або власний оракул. Кожна виміряна тонна CH4 (еквівалент 25 тонн CO2) → генерація кредиту на рахунок проекту.

Система довірених верифікаторів. Акредитовані верифікатори (аналог нотаріусів) підписують звіти про верифікацію. 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).

Взаємодія з legacy реєстрами

Для системи, яка претендує на серйозний ринок, обов'язкова інтеграція з Verra VCS або Gold Standard. Технічно це процес бриджингу:

1. Розробник проекту отримує кредити в реєстрі Verra.
2. Проходить KYC/AML верифікацію в системі.
3. Ініціює bridge: Verra через інтеграцію списує кредити зі рахунку та генерує сертифікат відзиву.
4. Сертифікат верифікується oracle-вузлом або довіреним верифікатором.
5. Смарт-контракт мінтить еквівалентну кількість on-chain токенів.

Проблема: Verra поки не надає API для автоматичного bridge. Процес вимагає ручної верифікації від Verra або використання акредитованого брокера. Очікується, що до 2026 року кілька крупних реєстрів випустять офіційні API для інтеграцій блокчейну.

Торгівля та інтеграція DeFi

Automated Market Maker. Пул вуглецевих токенів на Uniswap V3 або власний AMM з урахуванням специфіки активу: вуглецеві кредити не є активами, які знецінюються, але можуть мати сезонність та кореляцію з новинами про кліматичне регулювання.

Форвардні контракти. Продаж майбутніх кредитів — поширена практика на ринку вуглецю. Смарт-контракт для форвардів: покупець платить зараз, отримує кредити при верифікації майбутнього vintage. Escrow з умовами поставки.

Звітність та audit trail. Критично для корпоративних покупців: повна ланцюг власності від генерації до використання, експорт даних для ESG звітування, інтеграція з корпоративними ERP системами (SAP, Oracle) через API.

Нормативна сумісність

Системи обліку вуглецевих кредитів працюють у регульованому просторі. Ключові стандарти:

• UNFCCC Paris Agreement Article 6 — міжнародні правила торгівлі вуглецевими кредитами між країнами, включаючи вимоги щодо відповідних коригувань (уникнення подвійного обліку між країнами)
• ISO 14064 — стандарт для кількісного визначення та звітування про викиди
• CORSIA (авіаційна промисловість) — вимагає кредити тільки з затвердженої програми

KYC/AML обов'язковий для учасників ринку вище певних порогів — це не опціонально. Впроваджується через механізм whitelist з on-chain верифікацією особи.

Графік розробки

Повний цикл MVP (без bridge з legacy реєстрами): 4–5 місяців. З повноцінною інтеграцією в існуючу інфраструктуру ринку вуглецю — 8–12 місяців, з урахуванням часу на переговори з реєстрами.