15 contract architecture
Overview
This document provides detailed technical architecture for the smart contract system, focusing on the ERC-1155 semi-fungible implementation and integration with Project Records and PoAI.
Contract Set (Recommended)
A) ProjectRegistry (Project "NFT" Record)
Standard: ERC-721 or ERC-1155 (supply = 1 per project)
Purpose: Immutable project identity anchor
Stores:
Project metadata hash
PoAI proof hashes
Issuance cap
Project status
B) CarbonCredit1155 (Semi-Fungible Units)
Standard: ERC-1155 (Multi-Token Standard)
Purpose: Credit units that are fungible within project, non-fungible across projects
Stores:
Balances per user per tokenId
Caps per tokenId
Issued/retired totals per tokenId
Transfer policies per tokenId
C) Governance/Access (Roles)
Implementation: OpenZeppelin AccessControl or similar
Purpose: Role-based access control
Roles:
ISSUER_ROLE: Can mint creditsGOVERNANCE_ROLE: Can configure projects and execute governancePAUSER_ROLE: Can pause contracts (emergency)
Token ID Strategy
Mapping:
Advantages:
Easiest to trace
Direct 1:1 mapping
Simple implementation
Use Case: One project record = one issuance batch
Mapping:
Advantages:
Supports multiple batches per project
Batch-specific tracking
Use Case: Multiple issuance batches per project
Recommendation: Use Option 1 for v1, upgrade to Option 2 if needed.
Units & Decimals Implementation
Fixed-Point Units
Definition:
Conversion:
UI Display:
CarbonCredit1155 Contract Design
Storage Structure
Core Functions
setProjectConfig
Validations:
PoAI must be approved
Cap must be > 0
Caller must have GOVERNANCE_ROLE
mintCredits
Validations:
Project must be active
Issuance must not exceed cap
Caller must have ISSUER_ROLE
retire
Validations:
User must have sufficient balance
Burns credits permanently
_beforeTokenTransfer (Transfer Policy Enforcement)
PoAI Integration (Gating)
ProjectRegistry Integration
CarbonCredit1155 Gating
Result: No PoAI → no activation → no mint.
Complete On-Chain Flow
Metadata Structure
uri(tokenId) Returns JSON
Security Considerations
Reentrancy Protection
Use
nonReentrantmodifierChecks-effects-interactions pattern
Gas Optimization
Storage Optimization
Pack structs efficiently
Use events for historical data
Store only essential data on-chain
Function Optimization
Batch operations where possible
Minimize external calls
Use view functions for reads
Last updated