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

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

Токенізація вуглецевих квот — це перетворення верифікованих кредитів вуглецю в блокчейн-токени зі збереженням всього ланцюга верифікації, унікальності та механізму вилучення. Ринок добровільних вуглецевих кредитів (VCM) історично страждав від відсутності прозорості, подвійного обліку та складності доступу. Блокчейн вирішує ці проблеми, але додає свої технічні виклики.

Приклади реальних проектів: Toucan Protocol (TCO2 токени), KlimaDAO (KLIMA як резервна валюта), Moss Earth (MCO2), C3 Protocol. Все вони зіткнулися з однією фундаментальною проблемою: як зберегти верифіковуваність off-chain сертифіката при переведенні on-chain.

Архітектура: від сертифіката до токена

Структура вуглецевого кредиту

Кожен верифікований кредит має унікальний набір атрибутів:

Токенізація повинна зберегти всі ці атрибути on-chain для верифікації.

Механізм мостування

Ключове питання: хто гарантує, що on-chain токен відповідає реальному кредиту в реєстрі? Це принципово неможливо зробити повністю децентралізовано — реєстри (Verra, Gold Standard) — централізовані організації. Чесна система вимагає:

1. Верифікований оператор мосту — організація з прямим API-доступом до реєстру, яка може вилучати кредити та видавати токени. Це централізований компонент з максимальним ризиком.

2. Доказ вилучення — при переведенні на ланцюг оператор бере кредит з реєстру (вилучення на ім'я контракту мосту) та надає верифіковуваний доказ вилучення. Токен видається тільки після підтвердження.

3. Multisig + timelock на оператора мосту — неможливо дозволити одному ключу видавати токени без вилучення в реєстрі.

contract CarbonBridge {
    struct CreditMetadata {
        string registry;        // "Verra" | "GoldStandard"
        string serialNumber;    // унікальний ID у реєстрі
        uint256 vintage;        // рік
        string projectId;
        string methodology;
        string country;
        bool retired;           // використаний ли кредит
    }

    // tokenId => метаданні кредиту
    mapping(uint256 => CreditMetadata) public creditData;

    // верифіковані оператори мосту
    mapping(address => bool) public bridgeOperators;

    event CreditBridged(
        uint256 indexed tokenId,
        string serialNumber,
        address indexed beneficiary
    );

    function bridgeCredit(
        address beneficiary,
        CreditMetadata calldata metadata,
        bytes calldata registryProof  // підпис реєстру або IPFS хеш документу
    ) external onlyBridgeOperator {
        require(bytes(metadata.serialNumber).length > 0, "Empty serial");
        require(!_serialNumberUsed[metadata.serialNumber], "Already bridged");

        uint256 tokenId = _nextTokenId++;
        creditData[tokenId] = metadata;
        _serialNumberUsed[metadata.serialNumber] = true;

        _mint(beneficiary, tokenId);
        emit CreditBridged(tokenId, metadata.serialNumber, beneficiary);
    }
}

Fungible та Non-fungible токени

Це ключовий архітектурний вибір з серйозними компромісами.

ERC-721 (NFT) для кожного кредиту: кожен унікальний сертифікат — окремий NFT. Максимальна прозорість та верифіковуваність. Проблема: нульова ліквідність — неможливо торгувати NFT на DEX.

ERC-20 пул (модель Toucan): подібні кредити об'єднуються в пул, пул видає ERC-20 токени (1 токен = 1 тонна CO2 з пулу). Приклад: BCT (Base Carbon Tonne) — пул кредитів Verra vintage 2008+. Це забезпечує ліквідність та можливість торгівлі на Uniswap, але «усереднює» якість: кредити з різних проектів та методологій змішуються.

Гібридна схема: ERC-1155 з категоріями — кожна унікальна комбінація (vintage, методологія, країна) утворює окремий fungible токен ID. Баланс виражає кількість тонн з однаковими атрибутами.

// Підхід ERC-1155: tokenId = хеш атрибутів
function getTokenId(
    string memory registry,
    uint256 vintage,
    string memory methodology,
    string memory country
) public pure returns (uint256) {
    return uint256(keccak256(abi.encodePacked(registry, vintage, methodology, country)));
}

Механізм вилучення

Вилучення — це використання кредиту для компенсації викидів. Після вилучення кредит більше не можна використовувати. On-chain вилучення повинно:

1. Спалити (burn) токен
2. Записати вилучення on-chain з вказанням бенефіціара та причини
3. Опціонально — ініціювати вилучення в оригінальному реєстрі через міст

function retire(
    uint256 tokenId,
    address retiringEntity,     // хто використовує кредит
    string calldata reason      // "2023 scope 2 emissions offset"
) external {
    require(ownerOf(tokenId) == msg.sender, "Not owner");
    require(!creditData[tokenId].retired, "Already retired");

    creditData[tokenId].retired = true;
    _burn(tokenId);

    emit CreditRetired(
        tokenId,
        creditData[tokenId].serialNumber,
        retiringEntity,
        reason,
        block.timestamp
    );
}

On-chain подія вилучення — верифіковуваний доказ компенсації. Це може бути включено в звіти ESG та аудиторські висновки.

Ціноутворення та оракли

Ціни на кредити вуглецю значно варіюються: кредити Gold Standard з природними проектами торгуються по $15-60, базові Verra Avoidance — по $1-8. On-chain агреговані пули втрачають цю диференціацію.

Для протоколів, які приймають вуглецеві кредити як залог (інтеграції DeFi), потрібен ціновий оракул. Toucan використовував оракул Chainlink для BCT. Складніші схеми — власний TWAP на основі DEX торгів.

Проблема «сміттєвих кредитів»: при створенні пулу типу BCT немає заборони на включення низькокачісних кредитів. Ранні учасники вносять хороші кредити, пізніші — погані. Протокол накопичує «дно» ринку, ціна пулу прагне до мінімуму. Toucan зіткнувся з цим у 2022.

Рішення: selective pooling з перевіркою критеріїв. Пул приймає тільки кредити з певними атрибутами (методологія, vintage, країна) та верифіковані сертифікати додаткової користі. Це зменшує ліквідність, але зберігає якість.

Інтеграція з реєстрами

Verra та Gold Standard мають різні API та політики. Verra надає обмежений API доступ. Gold Standard має більш відкриту позицію щодо блокчейн інтеграцій.

Практичний підхід для MVP: ручна верифікація + multisig міст. Оператори вручну верифікують документи про вилучення, multisig підписує транзакцію мосту. Повільно, але надійно та не потребує API-угод з реєстрами.

Для масштабування: партнерство з реєстром або використання верифікованих оракулів (dMRV — digital Measurement, Reporting and Verification), які інтегруються з реєстрами безпосередньо.

Нормативні розташування

Ринки вуглецю регулюються по-різному в різних юрисдикціях. В EU ETS (Emission Trading System) токенізовані кредити можуть мати інший статус, ніж EUA (European Union Allowances). У США ринок добровільного вуглецю слабо регулюється, але CFTC заявив про намір регулювати вуглецеві кредити як товари.

Проект обов'язково потребує юридичної оцінки в цільових юрисдикціях перед запуском. Особливо важливо: класифікація токена (security vs commodity vs utility), вимоги KYC для великих покупців, compliance для корпоративних покупців.

Додаткові функції системи

Панель облік вуглецю — організація вносить токени та отримує автоматичний звіт про компенсацію вуглецю: загальний обсяг, розбивка за типами кредитів, верифіковані посилання на on-chain транзакції вилучення. Формат сумісний з GHG Protocol.

Дробові кредити — стандартний кредит = 1 тонна, але багато покупців хочуть дробові обсяги. Представлення ERC-20 автоматично вирішує це: 0,1 токена = 0,1 тонна.

Рівень виявлення проектів — ринок з метаданнями проектів на ланцюзі, атрибутами CO-benefit (біорізноманіття, розвиток громади), верифікованими звітами з фото через IPFS. Покупець бачить, що саме він купує.

Стек розробки

Тривалість розробки: 8-14 тижнів для повної системи. MVP з ручною верифікацією та базовим мостом — 5-7 тижнів. Пріоритетні завдання: безпека контракту мосту (аудит обов'язковий), коректність стандарту метаданих, юридичне супровід.