ERC-8040: ESG Tokenization Protocol

Environmental, Social, and Governance (ESG) asset tokenization with metadata, attestations, and lifecycle integrity.

Metadata

Status: DraftStandards Track: ERCCreated: 2025-09-06

Authors

Leandro Lemos (@agronetlabs) ([email protected])

Requires

EIP-20, EIP-721, EIP-1155

Links

GitHub page Discussion on Ethereum Magicians

Abstract

This ERC defines an overlay interface and metadata schema for representing Environmental, Social, and Governance (ESG) assets with existing token standards. Compliant contracts expose ESG metadata through a token-specific URI and an optional on-chain metadata view, record attestations as cryptographic digests, and emit events when assets are minted, audited, attested, or retired. The interface is intended to be implemented alongside ERC-20, ERC-721, or ERC-1155 so that ESG assets can keep their normal transfer semantics while adding machine-readable lifecycle state.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

This ERC is an overlay for tokenized ESG assets. Implementations maintain normal token ownership and transfer behavior through a base token standard, and add this ERC's functions for ESG metadata retrieval, audit recording, attestation recording, and retirement. Each token has a lifecycle status of issued, audited, or retired.

Metadata Structure

Tokens MUST expose a metadata JSON document with the following minimum fields. Implementations MUST make this document available from esgURI(uint256 tokenId). Implementations MAY also return the same values through getMetadata(uint256 tokenId) when storing the metadata on-chain.

The standard field identifies the metadata version. The category field describes the ESG asset class. The geo field identifies the geographic area for the asset. The carbon_value field represents the asset value for carbon assets. The digest, physical_id, attestation, and evidence fields bind the token to source records, external attestations, and supporting documentation. The status field records the lifecycle state.

Smart Contract Interface

Contracts implementing this standard MUST support the following interface:

JSON-RPC Example

Mapping & Compatibility

This ERC does not replace ERC-20, ERC-721, or ERC-1155. A compliant contract implements this ERC in addition to at least one base token standard.

ERC-20: Each unit represents a standardized fraction, such as 1e18 units representing one metric tonne of carbon dioxide equivalent (tCO2e).
ERC-721: Single credit with unique esgURI and immutable metadata.
ERC-1155: Homogeneous batch with common URI, metadata, and fungible amounts.

Rationale

Deterministic flows: Lifecycle follows strict state transitions (issued to audited to retired).
Immutable metadata: SHA3-512 digests bind metadata and evidence documents to the token record.
Machine-verifiable audit trails: Attestation digests and events allow off-chain systems to verify audit records deterministically.
Post-quantum readiness: SHA3-512 hash functions provide preimage resistance suitable for long-lived audit records.
Full hash storage: Using bytes instead of bytes32 allows complete SHA3-512 digest storage (64 bytes).

Security Considerations

Metadata immutability: All metadata fields MUST be cryptographically sealed after minting.
Validation independence: Implementations MUST NOT rely on unauthenticated off-chain statements. Attestations MUST be represented by verifiable digests and events.
Digest integrity: SHA3-512 (64 bytes) ensures audit-trail integrity. Implementations MUST use bytes type to store complete 512-bit digests.
Post-quantum cryptography: Hash functions and signature schemes MUST be quantum-resistant. SHA3-512 provides 512-bit security suitable for post-quantum scenarios.
Irreversible retirement: Once retired, tokens cannot be reactivated.
Physical seal validation: On-chain digest MUST match physical seal cryptographic hash.
Input validation: All off-chain documents MUST be hashed using SHA3-512 and publicly referenced on-chain.
Hash truncation prevention: Implementations MUST NOT truncate SHA3-512 digests. The bytes type MUST be used instead of bytes32 to prevent loss of cryptographic security.

Copyright