Blockchain Carbon Credits Accounting System Development

Development of a Carbon Credits Accounting System on Blockchain

Carbon credits are a specific asset: one credit = one tonne of CO2 that was prevented or absorbed. The problem with existing registries (Verra, Gold Standard, American Carbon Registry) is information asymmetry and double counting. The same credit can be sold twice, "shelf-sitting" credits from 2010 projects are sold as fresh, and verification of real impact is left to the discretion of accredited auditors with conflicting interests.

Blockchain systems for carbon credits solve the technical problem of double counting through unique on-chain identifiers, but create new challenges: how to verify real CO2 absorption? How to ensure interoperability with existing registries? How not to create another "greenwashing" tool?

Standards for Carbon Credit Tokenization

Before writing smart contracts, you need to understand existing standards, otherwise the created tokens will not be recognized by the market.

Toucan Protocol standard — TCO2 (Tokenized Carbon Offset). Links existing credits from Verra VCS to ERC-20 tokens. Process: credit is "burned" in the Verra registry → TCO2 token is generated on-chain. This is a bridge between legacy registries and blockchain, but doesn't solve the quality problem of the credits themselves.

Moss Earth (MCO2) — similar approach, but only for Amazon projects.

Regen Network builds its own verification layer on Cosmos with data modules for environmental data — the most advanced system from a verification perspective.

W3C Verifiable Credentials + DID for project documents — emerging standard for digital certificates that progressive registries are beginning to use.

For a new system, we recommend: compatibility with Toucan standard for fungible credits + ERC-721 for project tokens (each project is unique) + custom verification layer.

Data Architecture and Verification

Carbon Credit Data Hierarchy

One carbon credit carries significantly more attributes than just the amount of CO2. For complete accounting:

struct CarbonProject {
    bytes32 projectId;          // unique ID
    string methodology;         // VM0007, AR-ACM0003, etc. — verification methodology
    string registry;            // Verra, Gold Standard, ACR
    string externalId;          // ID in original registry
    uint256 startDate;
    uint256 endDate;
    int256  latitude;           // project coordinates (in microdegrees)
    int256  longitude;
    ProjectType projectType;    // Forestry, Renewable, Methane, etc.
    address projectDeveloper;
    uint256 totalIssuable;      // maximum credit volume
    uint256 totalIssued;
    ProjectStatus status;
}

struct CarbonVintage {
    bytes32 vintageId;
    bytes32 projectId;
    uint256 year;               // year of absorption
    uint256 quantity;           // tonnes CO2
    string  verificationReport; // IPFS CID of verifier report
    address verifier;           // accredited verifier
    bytes32 serialNumber;       // number in original registry
    bool    retired;            // used (retired) — cannot be sold again
}

Retirement (credit usage) — critical operation. When a company offsets emissions, it "burns" the credit. On blockchain, this must be an irreversible operation with public record:

event CreditRetired(
    bytes32 indexed vintageId,
    address indexed beneficiary,   // who is offsetting
    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

Verification of real CO2 absorption is an oracle task. Existing approaches:

Satellite data oracles. NDVI (vegetation index) from satellite imagery (Sentinel-2, Landsat) allows assessment of forest project conditions. Services like Planet Labs or Verra's satellite-based monitoring provide data that can be put on-chain through Chainlink Functions or custom oracle.

// Chainlink Function to get NDVI data
const projectId = args[0];
const coordinates = args[1];  // "lat,lon,radius"

// Request to 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 sensors. For methane capture projects — gas flow sensors connected to blockchain through Chainlink Direct Request or custom oracle. Each measured tonne of CH4 (equivalent to 25 tonnes CO2) → credit generation to project account.

Trusted verifier system. Accredited verifiers (similar to notaries) sign verification reports. Multisig or threshold signature requires signatures from multiple independent verifiers. Less decentralized but complies with existing regulatory requirements.

Tokenization: fungible vs non-fungible

Controversial topic in the industry.

ERC-20 (fungible). All CO2 tonnes are interchangeable. Convenient for trading and DeFi (liquidity in pools). Problem: "bad" credits (old vintage, questionable methodologies) mix with "good" ones. Toucan solved this through carbon pools: BCT (Base Carbon Tonne) — pool with minimum requirements, NCT (Nature Carbon Tonne) — only nature projects after 2012.

ERC-1155 (semi-fungible). Credits of one vintage are interchangeable with each other but not with credits of another vintage. More accurate representation of real market but worse liquidity.

ERC-721 (non-fungible) for project tokens. Each project is an NFT with metadata, verification history, document links. Traded separately from credits, represents share in future credit stream.

Recommended architecture: ERC-721 for projects → ERC-1155 for vintages → ERC-20 pool for liquidity (similar to Toucan pools).

Interoperability with Legacy Registries

For a system claiming serious market presence, integration with Verra VCS or Gold Standard is mandatory. Technically this is a bridging process:

1. Project developer receives credits in Verra registry.
2. Passes KYC/AML verification in the system.
3. Initiates bridge: Verra through integration debits credits from account and generates revocation certificate.
4. Certificate is verified by oracle-node or trusted verifier.
5. Smart contract mints equivalent amount of on-chain tokens.

Problem: Verra doesn't yet provide API for automatic bridge. Process requires manual verification from Verra or use of accredited broker. Expected that by 2026 several major registries will release official APIs for blockchain integrations.

Trading and DeFi Integration

Automated Market Maker. Pool of carbon tokens on Uniswap V3 or custom AMM accounting for asset specifics: carbon credits are not depreciating assets but may have seasonality and correlation with climate regulation news.

Forward contracts. Sale of future credits — common practice in carbon market. Smart contract for forwards: buyer pays now, receives credits upon future vintage verification. Escrow with delivery conditions.

Reporting and audit trail. Critical for corporate buyers: complete ownership chain from generation to retirement, data export for ESG reporting, integration with corporate ERP systems (SAP, Oracle) via API.

Regulatory Compliance

Carbon credit accounting systems operate in regulated space. Key standards:

• UNFCCC Paris Agreement Article 6 — international rules for carbon credit trading between countries, including corresponding adjustments requirements (avoiding double counting between countries)
• ISO 14064 — standard for quantifying and reporting emissions
• CORSIA (aviation industry) — requires credits only from approved programs

KYC/AML is mandatory for market participants above certain thresholds — this is not optional. Implemented through whitelist mechanism with on-chain identity verification.

Development Timeline

Full MVP cycle (without bridge to legacy registries): 4–5 months. With full integration into existing carbon market infrastructure — 8–12 months, accounting for negotiation time with registries.