TNZO Governance

1. Abstract

TNZO is the economic unit powering the AI economy — the native utility and governance token of the Tenzro Protocol, the operating system for the agentic era where both humans and autonomous AI agents participate as first-class economic actors. 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, settlement operations, agent funding (fundAgent), and token swaps (swapToken)
• 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 genesis supply of 1,000,000,000 (one billion) tokens. Staking rewards introduce controlled inflation to incentivize network security, while EIP-1559 base fee burning provides deflationary pressure. 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

2.1 Token Functions

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

• Gas Fees: All on-chain transactions on Tenzro Ledger 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. Three-Tier Fee Structure

Tenzro Network implements a three-tier fee model: blockchain transaction costs, node operator payments, and a network commission layer with dynamic routing intelligence.

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:

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: Node Operator Payment

The majority of every service payment flows directly to the node operator providing the compute — GPU inference, TEE computation, or validation capacity. Node operators are the primary value creators in the network and are compensated accordingly. At 70–80%, Tenzro's operator share is at the high end of the market: comparable decentralized compute platforms (Akash, io.net, Aethir) typically pay operators 60–75%, while centralised platforms take a larger implicit margin through opaque pricing.

3.3 Dynamic Volume-Based Commission

Network commission rates adjust dynamically based on node volume to reward high-performing operators and lower barriers for new entrants. High-volume nodes on Tenzro pay a lower commission than the industry standard taken by most platforms, making sustained operation highly competitive:

Commission tiers are determined at the epoch boundary based on trailing 30-day volume and uptime metrics. Nodes transition tiers automatically as their performance qualifies them.

3.4 Routing Intelligence Margin

When the network auto-routes requests across providers, Tenzro captures a routing intelligence margin — the spread between the node's quoted price and the price presented to the user. This margin reflects the genuine value of optimal routing: latency optimisation, load balancing, failover, and price discovery across a decentralised provider set. This model is structurally distinct from how other decentralised compute networks operate: rather than charging a flat percentage, Tenzro earns more when it routes better — directly aligning protocol revenue with network quality. For comparison, managed inference APIs on centralised platforms (Replicate, Together AI, RunPod Serverless) add a 2–5× markup over raw compute for equivalent orchestration functionality. Tenzro's routing margin captures a fraction of that value while still delivering substantially lower end-user prices than hyperscalers.

The routing margin is not a fixed fee — it is determined by the spread the protocol can achieve through intelligent provider selection. As network liquidity deepens and price competition increases among providers, this margin compresses. It is the primary long-term revenue driver for the protocol.

3.5 Agent Layer Fee Stack

Specialized agents deployed on the network can introduce an additional fee layer on top of base model pricing. This creates a three-layer fee stack for agentic workloads:

Agent creators set their own premium above the model cost. Tenzro takes 5–10% of that agent fee, creating a platform revenue stream that scales with the diversity and quality of agents deployed on the network. The network provides 10 reference agent templates (including Multi-Chain Portfolio Manager, Intelligent Payment Router, Cross-Chain Liquidity Aggregator, Autonomous RWA Custodian, and Agentic Inference Marketplace) that demonstrate common monetization patterns for the agent fee layer.

Governance: All commission rates, tier thresholds, and routing margin parameters are governable. Changes require on-chain governance proposals with 20% quorum and 50% approval threshold.

3.6 Nanopayment Batching

For high-frequency AI inference billing where individual payments may be fractions of a cent per token, Tenzro implements a NanopaymentBatcher that accumulates micro-settlements off-chain and flushes them in batched on-chain transactions. This dramatically reduces gas costs for per-token billing scenarios.

Off-chain accumulation: Individual nanopayments are accumulated locally with signed state updates between the payer and payee. Each state update carries a monotonically increasing sequence number and the cumulative payment total, signed by the payer. The payee can submit the latest signed state to the chain at any time to claim accumulated payments.

Periodic batch flush: Rather than settling each micro-payment individually, the batcher flushes all accumulated payments in a single on-chain transaction. Flush triggers are configurable across three dimensions:

• Time-based: Flush every N seconds (e.g., every 60 seconds during active inference)
• Amount-based: Flush when the accumulated total exceeds a configured threshold (e.g., 10 TNZO)
• Count-based: Flush after N individual nanopayments have been accumulated (e.g., after 100 payments)

The gas cost savings are substantial. Batching amortizes the fixed transaction overhead across all payments in the batch:

The channel deposit acts as collateral, ensuring the payee can always claim accumulated payments even if the payer goes offline. If a dispute arises, the latest signed state update can be submitted on-chain for resolution through the micropayment channel dispute mechanism.

SDK access is available in both Rust and TypeScript:

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

4.2 Provider Types and Multipliers

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

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:

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

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) A share of the network commission revenue (the protocol's 5–10% cut of gross service payments) distributed to stakers.

5.1 Epoch-Based Distribution

5.2 Reward Calculation Formula

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

Example Calculation:

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

6.2 Exchange Rate Mechanism

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

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):

Withdrawal (Unstake):

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:

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 (5–10% of gross payment): The protocol's share of service payments (after node operator cut) flows to treasury, stakers, and burn
• Routing Intelligence Margin: Spread captured between node quoted price and user-facing price; the primary long-term revenue driver
• Agent Layer Commission: 5–10% of agent fee revenue from specialized agents deployed on the network
• 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. Node operator payments (70–80% of gross service payments) flow directly to operators. Only the network commission portion contributes to the treasury.

7.2 Multi-Asset Support

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

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:

Withdrawal flow:

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

7.4 Backing Ratio

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

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

8.2 Governance Parameters

8.3 Proposal Lifecycle

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

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:

1. Proposal passes and timelock expires
2. New parameter values are written to pending state
3. At next epoch transition, pending values become active
4. 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 genesis supply of 1,000,000,000 tokens. Staking rewards introduce controlled inflation to fund network security and service provision; the base fee burn mechanism (EIP-1559) provides deflationary pressure. 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.

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: A portion of the protocol's network commission (5–10% of gross service payments) is permanently burned — exact percentage governed on-chain
• 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:

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.

10.1 ERC-7802 Cross-Chain Token Supply

TNZO implements the ERC-7802 (SuperchainERC20) interface for standardized cross-chain token supply management. Unlike traditional lock-and-mint bridges that require liquidity pools on each chain, ERC-7802 provides a protocol-level interface enabling authorized cross-chain minting and burning without intermediary liquidity.

The interface exposes two core functions:

• crosschainMint(to, amount): Called on the destination chain when tokens bridge outward from Tenzro. Only authorized bridge adapters (LayerZero, CCIP, deBridge) can invoke this function.
• crosschainBurn(from, amount): Called when tokens return to Tenzro from an external chain, reducing the external supply and restoring native supply on the Tenzro Ledger.

TNZO supply is tracked per-chain with a unified total supply invariant enforced at the protocol level. The total circulating supply across all chains is tracked and enforced at the protocol level:

When tokens bridge from Tenzro to Ethereum, crosschainMint is called on the Ethereum TNZO contract, increasing the external supply while native supply decreases by the same amount. When tokens return from Ethereum to Tenzro, crosschainBurn reduces the external supply and restores the native balance. This ensures the total supply invariant is never violated.

SDK access is available in both Rust and TypeScript:

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

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:

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. TNZO as the Economic Unit of Agentic Commerce

Centralized agentic payment platforms operate on top of existing financial rails. Visa TAP settles through the card network at interchange rates of 1.5-3.5%. Stripe MPP settles through Stripe's payment processing at 2.9% + $0.30 per transaction. Coinbase x402 settles through stablecoin transfers on Ethereum or Base, incurring gas costs and CDP facilitator fees. These economics work for high-value transactions but break down for the high-frequency, sub-cent micropayments that characterize AI inference — a single GPT-4 token costs a fraction of a cent, making per-token settlement on card rails economically impossible.

TNZO is purpose-built for this economic reality. The network's base commission is 0.5% — an order of magnitude lower than card network interchange — and micropayment channels enable per-token billing with settlement costs amortized across thousands of individual token payments. An agent can open a payment channel, generate 10,000 inference tokens, and settle the final balance in a single on-chain transaction. The per-token cost of settlement approaches zero.

TNZO is not just a gas token. It is the settlement currency for the entire Tenzro economy: AI inference payments, TEE service fees, bridge transfers, marketplace task bounties, skill invocation fees, and governance participation. Agents can earn TNZO by serving models, providing TEE compute, completing marketplace tasks, or publishing skills and tools — creating a circular economy where the same token flows between consumers and providers of intelligence and security. This circular flow is not possible on centralized platforms, where the payment token (USD via Visa/Stripe) is external to the service economy and the platform captures value through fees rather than distributing it to participants.

13. Conclusion

TNZO is the economic unit powering the AI economy — the governance and utility token at the heart of Tenzro, the operating system for the agentic era. 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.

14. References

• Tenzro Network Repository: github.com/tenzro
• EIP-1559: Ethereum Improvement Proposal for fee market change
• ERC-4337: Account Abstraction via Entry Point Contract specification
• BFT consensus: 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