TNZO Governance

Version: 0.1.0 — March 2026

Status: Technical Specification

Authors: Tenzro Network Team

1. Abstract

TNZO is the native utility and governance token of the Tenzro Protocol—decentralized infrastructure designed for the AI age, where both humans and autonomous AI agents participate as first-class network citizens. TNZO enables governance over the protocol, economic coordination between all participants, and alignment of incentives across validators, model providers, TEE providers, and users—whether human or machine. TNZO serves three critical functions within the network ecosystem:

Utility: Payment medium for transaction fees (gas), AI inference services, TEE computation, and settlement operations
Governance: Voting rights for protocol parameter changes, treasury allocations, and network upgrades
Security: Staking collateral for validators and service providers securing the network

TNZO implements 18-decimal precision with a maximum supply of 1,000,000,000 (one billion) tokens. The token is NOT a security token—it is a functional utility token required for network operation. This whitepaper details the complete economic model, fee structures, staking mechanisms, reward distribution, liquid staking protocol, treasury management, and governance system.

2. Token Overview

Property	Value
Token Symbol	TNZO
Decimal Precision	18 decimals
Maximum Supply	1,000,000,000 TNZO
Smallest Unit	10^-18 TNZO (1 wei)
Total Supply (wei)	10²⁷ smallest units
Token Type	Utility / Governance (NOT a security)

2.1 Token Functions

1. Utility Function: TNZO is required for all network operations:

Gas Fees: All on-chain transactions on Tenzro Ledger (L1) pay gas fees in TNZO
AI Inference Payments: Users pay model providers in TNZO for AI inference requests
TEE Service Payments: Users pay TEE providers in TNZO for confidential computation and key management
Settlement Fees: Micropayment channel settlements and escrow operations charge fees in TNZO
Bridge Fees: Cross-chain transfers via LayerZero, Chainlink CCIP, deBridge, or Canton pay fees in TNZO

2. Governance Function: TNZO holders participate in protocol governance:

Voting power proportional to staked balance (1 staked TNZO = 1 vote)
On-chain proposals for parameter changes, treasury spending, validator set updates, and protocol upgrades
Delegation support allows token holders to delegate voting power while retaining custody
Minimum 10,000 TNZO stake required to submit proposals

3. Security Function: TNZO serves as staking collateral:

Validators stake TNZO to participate in consensus (minimum 1,000 TNZO)
Service providers (model, TEE) stake TNZO to signal quality and commitment
Slashing mechanism punishes misbehavior by burning staked TNZO
Staking rewards incentivize long-term network security and service provision

3. Two-Tier Fee Structure

Tenzro Network implements a two-tier fee model separating blockchain transaction costs from service marketplace commissions:

3.1 Tier 1: Ledger Transaction Fees (Gas)

All on-chain transactions on Tenzro Ledger pay gas fees in TNZO. The network implements an EIP-1559 dynamic fee market with the following parameters:

Parameter	Value
Max Gas Limit (per block)	30,000,000 gas
Target Gas Usage	15,000,000 gas (50% of max)
Base Fee Adjustment	±12.5% per block
Min Base Fee	0.1 Gwei (10⁸ wei)
Max Base Fee	1,000 Gwei (10¹² wei)
Min Gas Price	1 Gwei (10⁹ wei)
Default Gas Limit (per tx)	10,000,000 gas

Fee Distribution: Following EIP-1559 mechanics, the base fee component is burned, creating deflationary pressure on TNZO supply. Priority tips (tips above base fee) flow to validators who produce blocks. This mirrors Ethereum's EIP-1559 burn mechanism.

3.2 Tier 2: Network Commission Fees

The Tenzro Network protocol charges a commission on service marketplace transactions to fund network development, treasury operations, and staker rewards. The commission is 0.5% (50 basis points) of gross payment value for:

AI inference payments to model providers
TEE computation payments to confidential computing providers

Distribution of Network Commission:

Recipient	Allocation	Purpose
Network Treasury	40% (20 bps)	Development, operations, grants, ecosystem growth
Token Burn	30% (15 bps)	Deflationary pressure, reduce circulating supply
Stakers	30% (15 bps)	Additional rewards for validators and service providers

Example: User pays 1,000 TNZO for AI inference.

Model Provider receives: 995 TNZO (99.5%)
Network Commission: 5 TNZO (0.5%)
- Treasury: 2 TNZO (40%)
- Burned: 1.5 TNZO (30%)
- Stakers: 1.5 TNZO (30%)

Governance: Commission rate and distribution percentages are governable parameters. Changes require on-chain governance proposals with 20% quorum and 50% approval threshold.

4. Staking Mechanism

Staking is the foundation of Tenzro Network's economic security. Validators and service providers stake TNZO to signal commitment and quality. Staking enables governance participation and earns rewards.

4.1 Staking Parameters

Parameter	Value
Minimum Stake	1,000 TNZO
Unbonding Period	7 days (168 hours)
Reward Distribution Frequency	Per epoch (governance-configurable)
Base Reward Rate	5% APY (500 basis points)

4.2 Provider Types and Multipliers

Different provider types receive different reward multipliers based on the value and difficulty of their contributions:

Provider Type	Multiplier	Responsibilities
Validator	1.0x	Block production, consensus participation, transaction validation
TEE Provider	1.2x	Hardware-attested confidential computing (Intel TDX, AMD SEV-SNP, AWS Nitro, NVIDIA H100/B200)
Model Provider	1.1x	AI model hosting, inference serving, model registry updates

TEE providers receive a higher multiplier (1.2x) because they must operate specialized hardware with hardware-backed attestation (Intel TDX, AMD SEV-SNP, AWS Nitro Enclaves, or NVIDIA Confidential Computing). Model providers receive a moderate multiplier (1.1x) due to GPU infrastructure requirements.

4.3 Staking Lifecycle

Staking follows a state machine with the following transitions:

Stake: User locks TNZO tokens via stake(amount, provider_type) transaction. Tokens move from wallet to staking pool.
Active: Staked tokens become active in the next epoch. Active stakes earn rewards and grant governance voting power.
Unbonding: User initiates withdrawal via request_unstake(amount). Tokens enter 7-day unbonding period. No rewards earned during unbonding.
Withdrawn: After unbonding period completes, user can execute withdraw() to return tokens to wallet.

Important: Tokens in unbonding state cannot participate in consensus, earn rewards, or vote in governance. The 7-day unbonding period provides security by preventing rapid exit during attacks or governance disputes.

4.4 Slashing Mechanism

Staked tokens are subject to slashing for misbehavior. Slashing reduces a provider's stake and burns the slashed tokens (reducing total supply). Slashing conditions include:

Equivocation (Double-signing): Validators signing multiple conflicting blocks at the same height. Automatically detected and enforced via the SlashingCallback trait, resulting in immediate 10% stake penalty.
Downtime: Validators missing more than 50% of blocks in an epoch
Invalid attestations: TEE providers submitting fake or malformed attestations
Bad inference results: Model providers serving corrupted or malicious outputs (requires ZK proof verification)

Slashing severity is parameterized by governance. Current implemented parameters:

Equivocation (Double-signing): 10% of stake slashed (automatically enforced via SlashingCallback)
Downtime (persistent): 0.1% of stake slashed per epoch of downtime
Invalid attestation: 1% of stake slashed per incident
Bad inference: 2% of stake slashed per verified incident

5. Reward Distribution

Staking rewards incentivize network security and service provision. Rewards come from two sources: (1) Base staking rewards from inflation/treasury, and (2) Commission fee revenue distributed to stakers (30% of 0.5% network commission).

5.1 Epoch-Based Distribution

Parameter	Value
Epoch Duration	Governance-configurable (~24 hours target)
Block Time	Sub-second (HotStuff-2 BFT target)
Epochs per Year	~365 epochs
Base Reward Rate	5% APY (500 basis points)

5.2 Reward Calculation Formula

Rewards are calculated per epoch for each staker using the following formula:

epoch_budget = total_staked * (reward_rate_bps / 10000) / 365

stake_proportion = staker_amount / total_staked

base_reward = epoch_budget * stake_proportion

uptime_adjusted = base_reward * uptime_percentage

final_reward = uptime_adjusted * provider_type_multiplier

Example Calculation:

Assumptions:

Total staked across network: 100,000,000 TNZO
Staker's stake: 10,000 TNZO
Provider type: TEE Provider (1.2x multiplier)
Uptime: 98% (produced 98% of expected blocks/attestations)
Reward rate: 5% APY (500 bps)

epoch_budget = 100,000,000 * (500 / 10000) / 365
= 100,000,000 * 0.05 / 365
= 13,698.63 TNZO per epoch

stake_proportion = 10,000 / 100,000,000 = 0.0001

base_reward = 13,698.63 * 0.0001 = 1.37 TNZO

uptime_adjusted = 1.37 * 0.98 = 1.34 TNZO

final_reward = 1.34 * 1.2 = 1.61 TNZO per epoch

Annual return: 1.61 TNZO/epoch * 365 epochs = 587.65 TNZO/year (~5.88% effective APY due to 1.2x multiplier)

5.3 Reward Claiming

Rewards accumulate as pending balances in the staking contract. Stakers must explicitly claim rewards via claim_rewards() transaction. This design prevents reward dust and reduces on-chain storage costs.

Rewards accrue per epoch based on active stake
Pending rewards are tracked per staker address
Claims can be batched across multiple epochs
Claimed rewards are transferred to staker's wallet or auto-restaked (if configured)

Sequential Epoch Enforcement: Rewards for epoch N can only be claimed after epoch N+1 begins. This ensures reward calculations are finalized before distribution.

6. Liquid Staking (stTNZO)

Tenzro Network implements a native liquid staking protocol allowing users to stake TNZO and receive stTNZO (staked TNZO) tokens representing their staked position. stTNZO is a rebasing token that accrues value as staking rewards are earned.

6.1 Liquid Staking Parameters

Parameter	Value
Token Symbol	stTNZO
Decimals	18
Protocol Fee	10% (1000 basis points) of staking rewards
Unbonding Period	7 days (same as direct staking)
Delegation Strategy	Multi-validator (diversified)
Arithmetic Safety	Overflow-safe u128 (quotient/remainder split)

6.2 Exchange Rate Mechanism

stTNZO maintains a rebasing exchange rate that increases as staking rewards accrue. The exchange rate is calculated as:

exchange_rate = total_tnzo_staked / total_sttnzo_supply

As rewards are earned, total_tnzo_staked increases while total_sttnzo_supply remains constant (unless new deposits/withdrawals occur), causing the exchange rate to rise over time.

6.3 Deposit and Withdrawal

Deposit (Stake):

sttnzo_to_mint = tnzo_deposited / exchange_rate

protocol_fee = 0 (no fee on deposit)

Withdrawal (Unstake):

tnzo_to_return = sttnzo_burned * exchange_rate

protocol_fee = 0 (no fee on withdrawal)

unbonding_period = 7 days

The protocol fee (10%) is charged on staking rewards, not on deposits or withdrawals. This is implemented by reducing the reward accrual rate before calculating the new exchange rate.

6.4 Arithmetic Safety

Liquid staking calculations involve multiplying two 18-decimal values (amounts and exchange rates), which can overflow u128. The implementation uses quotient/remainder decomposition to prevent overflow:

// Instead of: (a * c) / b (overflows)

// Use: (a / b) * c + (a % b) * c / b

result = (amount / divisor) * multiplier + (amount % divisor) * multiplier / divisor

This ensures safe arithmetic for the maximum TNZO supply (10²⁷ smallest units) which fits within u128 (max ~3.4×10³⁸).

6.5 Multi-Validator Delegation

The liquid staking pool delegates staked TNZO across multiple validators to reduce centralization risk and improve resilience. Delegation weights are determined by:

Validator performance (uptime, block production history)
Validator commission rates
Diversification targets (no single validator receives more than 20% of pool stake)
Governance whitelist (validators meeting minimum quality criteria)

7. Network Treasury

The Network Treasury is a multi-asset vault that accumulates fees from network operations and funds protocol development, ecosystem grants, and operational expenses.

7.1 Treasury Revenue Sources

Network Commission (40%): 40% of the 0.5% commission on AI inference and TEE service payments flows to treasury
Governance Proposal Fees: 10,000 TNZO stake required to submit proposals (returned if proposal passes, burned if rejected)
Slashing Revenue: Slashed tokens from misbehaving validators/providers are burned (not sent to treasury)

Important: Gas fees (Tier 1 transaction fees) flow directly to validators, NOT to the treasury. Only the network commission (Tier 2 fees) contributes to the treasury.

7.2 Multi-Asset Support

The treasury supports multiple assets bridged from external chains or received as payments:

Asset	Type	Decimals
TNZO	Native Utility Token	18
USDC	Stablecoin (bridged)	6
USDT	Stablecoin (bridged)	6
ETH	Cryptocurrency (bridged)	18
SOL	Cryptocurrency (bridged)	9
BTC	Cryptocurrency (bridged)	8

7.3 Multi-Signature Withdrawals

Treasury withdrawals require multi-signature approval to prevent single points of failure or misuse. The multi-sig scheme is configurable via governance:

Parameter	Default Value
Required Signatures (M)	2
Total Signers (N)	3
Scheme	2-of-3 threshold
Signer Management	Governance-controlled

Withdrawal flow:

Authorized party submits withdrawal proposal (asset, amount, recipient)
Proposal requires M-of-N approvals from designated signers
Each signer reviews and cryptographically signs approval
Once M signatures collected, withdrawal executes automatically
Duplicate approvals from same signer are prevented

7.4 Backing Ratio

The treasury backing ratio provides transparency into the protocol's financial health:

backing_ratio = total_treasury_value_usd / (tnzo_circulating_supply * tnzo_price_usd)

A backing ratio above 1.0 indicates the treasury holds more value than the circulating token market cap, providing a reserve for development and operations. The backing ratio is published on-chain and updated per epoch.

8. Governance System

Tenzro Network implements on-chain governance allowing TNZO stakers to propose and vote on protocol changes. Governance is stake-weighted: 1 staked TNZO = 1 vote.

8.1 Proposal Types

Proposal Type	Description
ParameterChange	Modify protocol parameters (fees, reward rates, slashing thresholds, etc.)
TreasurySpend	Authorize treasury withdrawals for grants, development, operations
ValidatorChange	Add/remove validators from active set, modify validator weights
ProtocolUpgrade	Upgrade consensus rules, VM logic, or core protocol features
Custom	Signal votes or community decisions not directly executable on-chain

8.2 Governance Parameters

Parameter	Value
Minimum Proposal Stake	10,000 TNZO
Voting Period	7 days (168 hours)
Minimum Quorum	20% of total staked TNZO
Approval Threshold	50% of votes cast (simple majority)
Execution Delay	2 days (48 hours) after proposal passes
Vote Options	For, Against, Abstain

8.3 Proposal Lifecycle

Submission: Any address with 10,000 TNZO staked can submit a proposal. Stake is locked until voting concludes.
Voting Period: 7-day voting window. Token holders vote For/Against/Abstain with weight = staked balance at proposal submission.
Quorum Check: At least 20% of total staked TNZO must vote for proposal to be valid.
Approval Check: More than 50% of cast votes must be For (excluding Abstain).
Execution Delay: If passed, proposal enters 2-day timelock before execution.
Execution: Automated on-chain execution applies parameter changes, treasury transfers, or validator set updates.
Stake Return: Proposer's stake is returned if proposal passes; burned if proposal fails to reach quorum or majority.

Example: Proposal to reduce network commission from 0.5% to 0.4%

Proposer stakes 10,000 TNZO and submits ParameterChange proposal
Community votes over 7 days
Results: 25% of total stake participated (exceeds 20% quorum)
For: 60%, Against: 35%, Abstain: 5% (proposal passes with 60% > 50%)
After 2-day timelock, parameter updates at next epoch boundary
Proposer's 10,000 TNZO stake is returned

8.4 Delegation

Token holders can delegate their voting power to trusted addresses while retaining custody of their staked TNZO. Delegation is:

Per-address: Delegator assigns voting power to a single delegate address
Revocable: Delegation can be revoked at any time
Non-custodial: Delegate cannot access or transfer delegator's tokens
Recursive: Delegates cannot re-delegate voting power (prevents delegation chains)

8.5 Parameter Change Execution

Parameter changes take effect at epoch boundaries to ensure consistency. Execution flow:

Proposal passes and timelock expires
New parameter values are written to pending state
At next epoch transition, pending values become active
All nodes read new parameters for the new epoch

This prevents mid-epoch parameter changes that could cause consensus divergence.

9. Supply Distribution

TNZO has a fixed maximum supply of 1,000,000,000 tokens. The distribution strategy prioritizes community ownership and decentralization.

9.1 Allocation Overview

Community allocation is targeted at 35-40% of total supply. Specific allocation percentages and vesting schedules are determined through governance proposals as the network matures.

Key Principle: Majority of TNZO supply is allocated to community participants—validators, service providers, developers, and users—to ensure decentralized ownership and align incentives with network growth.

9.2 Deflationary Mechanisms

TNZO implements multiple deflationary pressures to reduce circulating supply over time:

EIP-1559 Base Fee Burning: The base fee component of every transaction is permanently burned, mirroring Ethereum's EIP-1559 mechanism
Commission Burning: 30% of network commission (0.5% * 30% = 0.15% of gross payments) is permanently burned
Slashing Burns: All slashed tokens from misbehaving validators/providers are burned
Failed Proposal Burns: Proposal stakes (10,000 TNZO) are burned if proposals fail quorum or majority vote

These mechanisms create significant deflationary pressure counterbalancing staking rewards, potentially reducing total supply below the 1 billion maximum over time. The base fee burn is the primary deflationary force, scaling with network activity.

10. Supported Assets

The Tenzro Network supports multiple assets for payments, treasury holdings, and cross-chain interoperability:

Asset	Type	Decimals	Source
TNZO	Native Utility Token	18	Tenzro Ledger (native)
USDC	Stablecoin	6	Ethereum, Solana, Polygon (bridged)
USDT	Stablecoin	6	Ethereum, Tron, BSC (bridged)
ETH	Cryptocurrency	18	Ethereum (bridged via LayerZero/CCIP)
SOL	Cryptocurrency	9	Solana (bridged via Wormhole)
BTC	Cryptocurrency	8	Bitcoin (wrapped via deBridge)

Cross-chain assets are bridged to Tenzro Ledger via LayerZero V2 (omnichain), Chainlink CCIP (cross-chain messaging), deBridge (DLN intent-based), and Canton (enterprise DAML ledgers). Bridged assets maintain 1:1 backing with locked tokens on source chains.

11. Arithmetic Safety and Precision

Token economics calculations involve high-precision arithmetic with overflow risks. Tenzro Network implements the following safety measures:

11.1 Integer Representation

Type	Range	Usage
u128	0 to ~3.4 × 10³⁸	Token amounts (smallest units)
u64	0 to ~1.8 × 10¹⁹	Block heights, nonces, timestamps
u16	0 to 65,535	Basis points (0-10,000 bps)

Maximum TNZO supply in smallest units: 1,000,000,000 × 10¹⁸ = 10²⁷, which safely fits within u128 maximum.

11.2 Overflow Prevention

All arithmetic operations use checked variants:

checked_add() — addition with overflow detection
checked_sub() — subtraction with underflow detection
checked_mul() — multiplication with overflow detection
saturating_sub() — subtraction capped at zero (used for non-critical paths)

For high-precision calculations involving 18-decimal multiplication (e.g., token amount × exchange rate), quotient/remainder decomposition prevents overflow:

// Unsafe: (amount * multiplier) / divisor

// Safe decomposition:

let quotient = amount / divisor;

let remainder = amount % divisor;

let result_quotient = quotient.checked_mul(multiplier)?;

let result_remainder = remainder.checked_mul(multiplier)?.checked_div(divisor)?;

let result = result_quotient.checked_add(result_remainder)?;

11.3 Rounding and Precision Loss

Integer division causes rounding. The protocol uses floor rounding (round down) for all fee calculations to ensure users never overpay:

Fee = (amount * fee_bps) / 10,000 (rounds down)
Reward = (stake * rate) / total_stake (rounds down)
Exchange rate = total_tnzo / total_sttnzo (rounds down for deposits)

Dust accumulation from rounding is negligible (sub-wei amounts) and does not impact economic security.

12. Conclusion

TNZO is the governance and utility token powering a decentralized AI and confidential computing network designed for the AI age. The governance system ensures both humans and AI agents can participate in protocol evolution through stake-weighted voting, while the economic model balances multiple objectives:

Utility: Required for all network operations (gas, payments, settlements)
Security: Staking collateral with slashing for misbehavior
Governance: On-chain voting for protocol evolution
Sustainability: Fee revenue funds development and operations
Decentralization: Community-majority allocation and multi-sig controls

The two-tier fee structure separates blockchain transaction costs (gas to validators) from marketplace commissions (funding treasury and stakers). Liquid staking (stTNZO) provides capital efficiency without sacrificing decentralization. Multi-asset treasury support and cross-chain bridges enable interoperability with Ethereum, Solana, Bitcoin, and enterprise Canton ledgers.

All economic parameters—fee rates, reward rates, slashing thresholds, governance rules—are governable through on-chain proposals, ensuring the protocol can adapt to changing network conditions and community needs.

Important Disclaimer: TNZO is a utility token, NOT a security token or investment contract. Tokens are functional tools required for network participation. This whitepaper is a technical specification, not financial advice or investment promotion.

Current Status: Live testnet at rpc.tenzro.network with faucet at api.tenzro.network/api/faucet.

13. References

Tenzro Network Repository: github.com/tenzro/tenzro-network
EIP-1559: Ethereum Improvement Proposal for fee market change
ERC-4337: Account Abstraction via Entry Point Contract specification
HotStuff-2: BFT consensus protocol with linear communication complexity
LayerZero V2: Omnichain interoperability protocol
Chainlink CCIP: Cross-Chain Interoperability Protocol
Canton: Digital Asset Modeling Language (DAML) ledger integration

← Back to Whitepapers