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

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

Токенизация углеродных квот — это перевод верифицированных carbon credits в блокчейн-токены с сохранением всей цепочки верификации, уникальности и механизма retirement. Рынок добровольных углеродных кредитов (VCM) исторически страдает от непрозрачности, двойного учёта и сложности доступа. Блокчейн решает эти проблемы, но добавляет свои технические вызовы.

Примеры реальных проектов: Toucan Protocol (TCO2 токены), KlimaDAO (KLIMA как reserve currency), Moss Earth (MCO2), C3 Protocol. Все они столкнулись с одной и той же фундаментальной проблемой: как сохранить верифицируемость off-chain сертификата при переводе on-chain.

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

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

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

Токенизация должна сохранить все эти атрибуты on-chain для верификации.

Bridging механизм

Ключевой вопрос: кто гарантирует, что on-chain токен соответствует реальному кредиту в реестре? Это принципиально нельзя сделать полностью децентрализованно — реестры (Verra, Gold Standard) — централизованные организации. Честная система требует:

1. Верифицированный bridge operator — организация с прямым API-доступом к реестру, которая может списывать кредиты из реестра и минтить токены. Это централизованный компонент с максимальным риском.

2. Proof of retirement — при переводе on-chain оператор берёт кредит из реестра (retirement на имя bridge контракта) и предоставляет верифицируемое доказательство retirement. Токен выпускается только после подтверждения.

3. Multisig + timelock на bridge оператора — нельзя допустить, чтобы один ключ мог минтить токены без retirement в реестре.

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;

    // верифицированные bridge операторы
    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 hash документа
    ) 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 vs Non-fungible токены

Это ключевой архитектурный выбор с серьёзными trade-off-ами.

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, methodology, country) образует отдельный fungible token 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)));
}

Retirement механизм

Retirement — использование кредита для offset выброса. После retirement кредит больше нельзя использовать. On-chain retirement должен:

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

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 retirement event — верифицируемое доказательство offset. Его можно включать в ESG-отчёты и аудиторские заключения.

Ценовое ценообразование и оракулы

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

Для протоколов, принимающих carbon credits в качестве залога (DeFi интеграции), нужен ценовой оракул. Toucan использовал Chainlink oracle для BCT. Более сложные схемы — собственный TWAP на основе DEX торгов.

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

Решение: selective pooling с whitelisting критериев. Пул принимает только кредиты с определёнными атрибутами (методология, vintage, страна) и verified additional benefit certificates. Это снижает ликвидность, но сохраняет качество.

Интеграция с реестрами

Verra и Gold Standard имеют разные API и политики. Verra предоставляет ограниченный API доступ. Gold Standard имеет более открытую позицию к блокчейн интеграциям.

Практический подход для MVP: manual verification + multisig bridge. Операторы вручную верифицируют документы о retirement, multisig подписывает bridge транзакцию. Медленно, но надёжно и не требует API-соглашений с реестрами.

Для scale: партнёрство с реестром или использование верифицированных оракулов (dMRV — digital Measurement, Reporting and Verification), которые интегрируются с реестрами напрямую.

Регуляторные соображения

Carbon markets регулируются по-разному в разных юрисдикциях. В EU ETS (Emission Trading System) токенизированные кредиты могут иметь другой статус, чем EUA (European Union Allowances). В США voluntary carbon market слабо регулируется, но CFTC заявлял о намерении регулировать carbon credits как commodities.

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

Дополнительные функции системы

Carbon accounting dashboard — организация вносит токены и получает автоматический отчёт о carbon offset: общий объём, разбивка по типам кредитов, верифицируемые ссылки на on-chain транзакции retirement. Формат совместим с GHG Protocol.

Fractional credits — стандартный кредит = 1 тонна, но многие покупатели хотят дробные объёмы. ERC-20 представление автоматически решает это: 0.1 токена = 0.1 тонна.

Project discovery layer — маркетплейс с on-chain метаданными проектов, CO-benefit атрибутами (biodiversity, community development), верифицированными фотоотчётами через IPFS. Покупатель видит, что именно он покупает.

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

Сроки разработки: 8-14 недель для полной системы. MVP с ручной верификацией и базовым bridge — 5-7 недель. Приоритетные задачи: безопасность bridge контракта (аудит обязателен), корректность metadata стандарта, юридическое сопровождение.