⚖ TenzaOne DAO Constitution

Version 0.1 — December 2025

Overview Governance Phases Proposals & Voting Tiers Token View Pooling Disclaimer

Purpose

This constitution defines the governance framework for the TenzaONE cooperative DAO and its investment pooling capability, and the governed technical specification for the tokenisation and blockchain architecture that underpins TenzaONE’s climate-finance platform.

Business Context

TenzaONE is a regenerative finance ecosystem connecting climate project developers, impact investors, and climate solution providers through AI-enabled project assessment, cooperative certification, and blockchain-backed transparency. The near-term objective is to finance future high-integrity project outputs (carbon credits and revenue streams), not to trade historical credits. Over the long-term, TenzaONE aims to operate a highly credible carbon market where eligible carbon assets can be traded under robust governance and compliance controls.

Constitutional Objectives

The TenzaONE DAO exists to govern a cooperative climate-finance ecosystem that:

  • finances and accelerates high-integrity climate mitigation and adaptation projects;
  • reduces certification and monitoring costs through cooperative structures;
  • increases market trust through transparent, verifiable, tamper-resistant data (AI + DePIN + blockchain);
  • aligns stakeholders (developers, investors, verifiers, and solution providers) through a shared treasury, credible incentives, and enforceable rules; and
  • progressively decentralises decision-making while maintaining institutional-grade compliance.

Governance Principles

PrincipleInterpretation
Integrity-first carbon financeNo governance action may knowingly create double counting, misrepresentation, or systematic over-crediting risk.
Regulatory pragmatismGovernance respects jurisdictional constraints; where required, DAO decisions route through regulated wrappers.
Transparency by defaultPolicies, votes, and treasury movements are public unless confidentiality is legally required.
Separation of powersRisk/compliance veto powers separated from treasury spending; technical upgrades separated from economic policy.
Progressive decentralisationCentralised safeguards may exist early but are sunset by governance milestones.
Skin in the gameVoting and proposal rights emphasise aligned incentives (staking, lockups, and reputation).
Pluralism and inclusionThe ecosystem supports projects and investors of varying sizes while maintaining consistent integrity standards.

Governance Phases

A
Phase A — Foundation (Current)

DAO constitution ratified. Credit-weighted quadratic voting active. Foundation retains veto for security. Proposal types: Temperature Check + Parameter Change.

B
Phase B — Co-Govern

Councils elected. Snapshot on-chain voting. Treasury Budget + Pool Launch proposals enabled. Foundation veto scope narrows to constitutional matters only.

C
Phase C — DAO-Led

ERC-3643 compliance for security tokens. Contract Upgrade + Constitutional Amendment proposals enabled. Foundation veto removed. Fully on-chain treasury management.

D
Phase D — Market

Fully autonomous on-chain carbon trading. Cross-chain bridges. Emergency Action governance for rapid response to market or security events.

Proposal Types & Voting Rules

TypeQuorumThresholdAvailable From
Temperature CheckNoneSimple majorityPhase A
Parameter Change10%55% YESPhase A
Treasury Budget15%60% YESPhase B
Pool Launch20% + membership60% YESPhase B
Contract Upgrade25%66.7% YESPhase C
Constitutional Amendment30%75% YESPhase C
Emergency ActionCouncil vote⅔ CouncilPhase D

Voting Mechanics

  • Discussion period: minimum 7 days for non-emergency proposals
  • On-chain vote window: minimum 5 days; extension allowed for high participation variance
  • Timelock: minimum 48 hours for parameter changes; minimum 7 days for upgrades
  • Execution: permissionless after timelock unless restricted by compliance wrappers
  • Post-mortem: mandatory for upgrades and any incident-related proposal

The DAO MAY introduce alternative mechanisms (quadratic voting, conviction voting) for specific domains such as grants, provided Sybil-resistance and compliance constraints are met.

Governance Lifecycle

Idea
Discussion
(Forum)
Draft
Proposal
Risk &
Compliance
On-chain
Vote
Timelock
Execution
Post-mortem
& Reporting

Standard Governance Lifecycle (default path; emergency path is separate)

Quadratic Voting Model

Vote weight = √(TNZE credits held). This ensures larger stakeholders have more influence but with diminishing returns, preventing any single actor from dominating governance.

3.2
10 credits
10
100 credits
22.4
500 credits
31.6
1,000 credits

Governance Tiers

Basic
0+ TNZE Credits
View proposals, participate in Temperature Checks
Participant
50+ TNZE Credits
Vote on Parameter Changes, submit proposals
Investor
250+ TNZE Credits
Vote on Treasury + Pool Launch, nominate council members
Enterprise
1,000+ TNZE Credits
All governance rights, eligible for Council election

Membership Classes

ClassEligibilityKey Rights
Community MemberOpen; wallet connection; Code of ConductDiscussion; hold $TNZU; temperature-check proposals
Verified ParticipantKYC/AML completed; jurisdictional eligibilityRegulated instruments, pooling, ERC-3643 transfers
Project DeveloperVerified + approved projectPerformance and integrity obligations
Verifier / AuditorVerified + accreditationIndependence and COI requirements
Solution ProviderVerified + vendor onboardingTreasury contracts for MRV, DePIN, AI services
DAO DelegateDelegation from $TNZU holdersDelegated voting; disclosure requirements
Council MemberElected/appointed; term-limitedGovernance body roles with accountability

Governance Power Model

  • Voting Power (VP) — token-weighted, derived from $TNZU holdings and/or delegated holdings
  • Membership Power (MP) — binary/tiered eligibility from Gate Tokens and KYC status (e.g., eligible to vote on regulated pool proposals)
  • Reputation Signals (RS) — non-binding scoring from historical contributions, verification accuracy, and COI disclosures

Sensitive domains (regulated instruments, KYC-restricted pools) require BOTH VP and MP eligibility.

Token Standards

ERC-20 (TNZU) — Utility token on Polygon for platform fees, governance participation, and incentives. Not a financial or profit-sharing instrument.
ERC-1155 (Ed 0–5) — Per-project multi-edition tokens: Ed 0 Master, Ed 1.x Certification, Ed 2.x Performance, Ed 3.x Gate, Ed 4.x Carbon Futures, Ed 5.x Revenue Share.
ERC-3643 — Regulated security token standard for Phase C. Identity-verified transfers via compliance layer.
TNZE (Governance) — Non-tradeable governance credits. Used for quadratic voting weight and tier access.
Evidence Storage — Off-chain evidence (assessments, verification reports, MRV data) is cryptographically hashed and anchored on-chain via Merkle roots. Future: decentralised storage via IPFS for immutable, content-addressed document retention.

Tokens, Identity & Governance Power

TenzaONE’s token architecture deliberately separates (a) operational utility and governance from (b) investment instruments and regulated securities. This supports global participation while allowing jurisdiction-specific compliance.

  • $TNZU is the central operational/utility token for platform payments and cooperative governance.
  • Pre-licensing investment positions are represented as Convertible Impact Notes (CINs) issued under contractual agreements and mirrored on-chain as ERC-1155 receipts.
  • Post-licensing, CINs transition to permissioned ERC-3643 tokens with embedded identity and transfer restrictions.

Non-transferable access/gate tokens (ERC-1155 Ed 3.x) and verified identity attestations restrict sensitive actions to eligible participants — supporting decentralisation without sacrificing compliance.

Pooling Objective

DAO pooling aggregates community capital (and later, carbon assets) into governed pools that finance project capex and certification, pre-purchase future carbon credits, acquire revenue-share or fixed-income claims, build carbon asset treasuries for liquidity and price discovery, and fund ecosystem public goods.

Pooling reduces transaction costs, diversifies risk, and provides a clear governance surface for capital allocation decisions.

Pool Types

Pool TypeMandate
Project Finance — FixedFixed-rate financing for projects with predictable cash flows
Project Finance — Royalty/RBFCapital for revenue share up to repayment cap
Carbon Credit FuturesPre-purchase future credits at discount; high-integrity issuance focus
Hybrid PoolFixed income + revenue share + credit futures
DAO Treasury ReserveLow-risk assets (stablecoins, short-duration) for reserves
Insurance / BufferBuffer against reversals, shortfalls, and disputes
Protocol-Owned LiquidityLiquidity for $TNZU and eligible assets under strict risk controls

Eligibility & Lifecycle

Access: Capital contribution restricted to Verified Participants (KYC/AML) with jurisdictional eligibility. Pool share tokens may be ERC-3643 permissioned tokens post-licensing.

Lifecycle: Mandate Proposal → Risk & Compliance Review → DAO Approval Vote → Subscription Window → Deployment → Monitoring & MRV → Distributions → Wind-Down.

Key defaults: €25K minimum subscription, ≤20% single-project concentration, 12-month minimum lockup, 0–2% management fee, 1–5% buffer allocation, monthly KPIs + quarterly audit.

Draft Status

This Constitution is Version 0.1 (Draft) dated December 2025. It is an internal working document — not legally binding — subject to governance and legal counsel review. It will be formally ratified when the DAO becomes fully operational (Phase B).

The full specification covers 11 sections including governance constitution, DAO pooling framework, token model & economics, technical architecture, smart contract specifications, data/MRV/integrity architecture, compliance & identity controls, security & emergency procedures, operating model, and progressive decentralisation roadmap to 2028. The complete draft document is available on request under NDA.

Scope

In scope: DAO governance constitution and amendment rules; role definitions, rights, obligations, and enforcement; DAO pooling design; token taxonomy and lifecycle ($TNZU, PDAs, CINs, ERC-3643); reference technical architecture; security and emergency procedures.

Out of scope (this version): Final legal entity structuring documents; offering memoranda and jurisdiction-specific licensing; full exchange matching engine and market microstructure for 2028; detailed methodology-by-methodology quantification procedures.

Normative Language

Technical sections use MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY as defined in RFC-style specifications. MUST indicates an absolute requirement. SHOULD indicates a recommendation that may be deviated from with documented rationale. MAY indicates an optional feature.

Legal & Financial Disclaimer

This document is not legal advice, tax advice, or an offer to sell or solicit any security, token, or financial instrument. It is a technical and governance design artifact intended to be reviewed and adapted with qualified counsel and relevant regulators. All investment pooling and secondary trading capabilities described herein are contingent upon applicable licensing, KYC/AML controls, and jurisdictional permissions.

© Tenza Climate Solutions 2025, 2026. Not for Public Distribution without authorisation.

TenzaOne

Live infrastructure for the carbon project lifecycle.

Site Tour
Choose Your Tour
✕ Exit Tour
Loading tour...
Privacy Overview
TenzaONE

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.

Strictly Necessary Cookies

Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.