Tenzro Ledger: L1 Settlement Layer

Abstract

Tenzro Ledger is the L1 settlement layer of the Tenzro Network — a purpose-built blockchain for the AI age providing four core pillars:

• Identity: Tenzro Decentralized Identity Protocol (TDIP) for unified human and machine identities with W3C DID compatibility
• Security: TEE-based key management (Intel TDX, AMD SEV-SNP, AWS Nitro, NVIDIA GPU) with hardware-attested consensus validation
• Verification: Dual ZK+TEE proof system for credentials, attestations, and inference results
• Settlement: Micropayment channels, escrow, and batch settlement for AI inference and TEE services

All transactions and settlements occur in TNZO, the native utility token used for gas fees, staking, and provider payments. The ledger supports three execution environments (EVM, SVM, DAML/Canton) through a unified multi-VM runtime, enabling autonomous agents to execute financial transactions on behalf of humans or autonomously.

This whitepaper describes the technical architecture of Tenzro Ledger, including consensus mechanism (HotStuff-2 BFT), execution layer (multi-VM with parallel Block-STM), fee market (EIP-1559), account abstraction (ERC-4337), settlement protocols, storage, and networking.

1. HotStuff-2 BFT Consensus

Tenzro Ledger uses HotStuff-2, a two-phase Byzantine Fault Tolerant (BFT) consensus protocol optimized for low-latency finality and linear communication complexity O(n). The protocol operates in sequential views with rotating leaders and provides optimistic responsiveness — it progresses at network speed during stable periods.

1.1 Protocol Parameters

1.2 Two-Phase Commit Protocol

HotStuff-2 reduces message complexity through a two-phase design:

1. PREPARE phase: Leader proposes block, validators vote to prepare. Requires 2f+1 votes for quorum.
2. COMMIT phase: Upon PREPARE quorum, validators vote to commit. Requires 2f+1 votes.
3. DECIDE: Upon COMMIT quorum, block is finalized and appended to chain.

The quorum threshold is defined as 2f+1 where f = floor((n-1)/3) for n validators, tolerating up to f Byzantine failures. All votes include cryptographic signatures verified before collection.

1.3 Leader Selection

Three leader rotation strategies are supported:

• Round Robin: Deterministic rotation through validator set, index = view % validator_count
• Stake Weighted: Probability proportional to staked TNZO, weighted random selection
• VRF (Verifiable Random Function): Cryptographically verifiable randomness based on previous block hash

1.4 TEE-Weighted Validation

Validators running within Trusted Execution Environments (Intel TDX, AMD SEV-SNP, AWS Nitro, NVIDIA GPU) receive 2x voting weight in leader selection and consensus quorum calculations. TEE attestations are verified before weight assignment. This incentivizes hardware-backed security and provides additional protection against validator key compromise.

1.5 Epoch Management

Epochs last 10,000 blocks (~67 minutes). At epoch boundaries:

• Validator set is updated from staking registry
• Slashed validators are removed
• New stakers are activated (after unbonding period)
• Rewards are distributed proportional to blocks signed
• Governance proposals executed

Epoch transitions are atomic and include a view change to ensure clean validator set rotation.

1.6 Finality and Fork Choice

Finality is tracked via FinalityTracker with sequential finalization guarantees. Once a block receives a COMMIT quorum, it is immediately finalized — no further confirmations required. The fork choice rule follows the longest finalized chain by block height.

2. Multi-VM Execution Layer

Tenzro Ledger supports heterogeneous smart contract execution through three independent virtual machines orchestrated by the MultiVmRuntime. Transaction routing is determined by the VmType field in the transaction header.

2.1 Supported VMs

2.2 EVM Executor

The EVM executor provides full Ethereum-compatible execution with the following features:

• Complete EVM opcode support (London/Paris hard fork)
• Keccak-256-based CREATE address derivation
• CREATE2 deterministic deployment
• Gas metering with overflow protection
• Event log extraction
• State access (balance, nonce, storage, code)
• Precompile registry (standard + Tenzro-specific)

2.3 SVM Executor

The SVM executor provides BPF program execution compatible with Solana:

• BPF bytecode interpretation and JIT compilation
• Solana-format account serialization
• Syscall support (logging, cryptographic operations, memory operations, invocations)
• Compute unit metering (max 1,400,000 CU per transaction)
• Program Derived Address (PDA) generation
• Cross-Program Invocation (CPI) support

2.4 DAML/Canton Executor

Each validator runs a Canton participant node connected via Ledger API v2:

• Ledger API: Command submission and state queries
• Admin API:Package management for DAML archives
• Lazy connection with graceful degradation
• Proper error handling when Canton is unreachable
• Supports DAML 3.x templates and workflows

2.5 Execution Constants

2.6 Precompile Registry

Tenzro-specific precompiles extend EVM functionality:

• TEE Precompile: Verify attestations, generate attested signatures
• ZK Precompile: Verify Groth16/PlonK/Halo2 proofs
• Model Precompile: On-chain inference verification
• Settlement Precompile: Escrow and micropayment channel operations

2.7 State Management

A unified state interface provides consistent access for all VMs:

• Account state: balance and nonce management
• Contract state: storage and code access
• Transaction isolation: state changes isolated until commit
• Atomic commit/rollback: all state changes or none

3. EIP-1559 Dynamic Fee Market

Tenzro Ledger implements EIP-1559 for predictable transaction fees and network congestion management. The fee market dynamically adjusts the base fee based on block gas utilization relative to the target.

3.1 Fee Market Parameters

3.2 Base Fee Calculation

The base fee for block n+1 is calculated based on block n's gas usage:

The base fee is clamped to [min_base_fee, max_base_fee] and burned, permanently removing TNZO from circulation.

3.3 Priority Fees

Users specify a max_priority_fee_per_gas to incentivize block producers. The priority fee is paid to the validator and is not burned. Total transaction fee:

3.4 Fee Suggestions

The FeeMarket provides priority fee suggestions based on desired confirmation urgency:

• Low: base_fee * 1.0 (next 5+ blocks)
• Medium: base_fee * 1.25 (next 2-4 blocks)
• High: base_fee * 1.5 (next block)
• Urgent: base_fee * 2.0 (immediate inclusion)

4. Block-STM Parallel Execution

Block-STM enables optimistic parallel transaction execution with automatic conflict detection and reexecution. This provides significant throughput improvements for independent transactions while maintaining correctness.

4.1 MVCC Multi-Version Data

The MultiVersionData structure maintains versioned state:

• Each write creates a new version indexed by transaction ID
• Reads fetch the latest version with ID < current transaction
• Read/write sets tracked per transaction for conflict detection
• Thread-safe concurrent access via RwLock

4.2 Execution Flow

1. Optimistic execution: Execute all transactions in parallel assuming no conflicts
2. Conflict detection: Compare read/write sets to identify dependencies
3. Reexecution: Conflicting transactions reexecuted sequentially with updated state
4. Fallback:If conflict rate > 50% or reexecutions > 16, fall back to sequential

4.3 Performance Metrics

The BlockStmExecutor tracks detailed execution metrics:

4.4 Configuration

5. Account Abstraction (ERC-4337)

Tenzro Ledger implements ERC-4337 account abstraction, enabling smart contract wallets with programmable transaction validation, gas sponsorship, and modular security features.

5.1 Core Components

EntryPoint Contract: Singleton contract that processes UserOperation bundles. Validates operations, handles gas payment, and executes calls. Max bundle size: 100 operations.

SmartAccount: Contract wallet with customizable validation logic. Supports modular extensions for different security models.

AccountFactory: Deploys smart accounts using CREATE2 for deterministic addresses. Address computed from factory address, salt, and initialization code hash.

Paymaster: Third-party contract that sponsors gas fees for user operations. Enables gasless transactions and subscription models.

5.2 Smart Account Modules

5.3 UserOperation Structure

5.4 Execution Flow

1. Validation: EntryPoint calls account's validateUserOp() with signature and gas limits
2. Gas payment: If paymaster specified, call paymaster's validatePaymasterUserOp(), else debit account
3. Execution: Call account's execute() with call_data
4. Gas refund: Refund unused gas to payer (account or paymaster)

6. Settlement Layer

The settlement layer provides flexible payment protocols for AI inference, TEE services, and provider payments. All settlements occur in TNZO with a 0.5% network commission on provider payments (flows to treasury).

6.1 Settlement Modes

Immediate Settlement: Direct one-shot payment from consumer to provider. No escrow. Executed in single transaction.

Escrow Settlement: Funds locked in escrow contract until release conditions met. Supports multiple release conditions:

• ProviderSignature: Provider signs completion
• ConsumerSignature: Consumer approves release
• BothSignatures: Mutual agreement (2-of-2 multisig)
• VerifierSignature: Third-party verifier attests
• Timeout: Automatic release after deadline
• Custom: Programmable condition via smart contract

Micropayment Channels: Off-chain per-token billing for high-frequency payments (e.g., streaming inference). On-chain channel open/close with cryptographic state updates.

6.2 Micropayment Channel Protocol

1. Open: Consumer deposits TNZO into channel contract, specifies provider and expiration
2. Off-chain updates: For each inference token, consumer signs new state: (channel_id, sequence_number, total_paid)
3. Close: Provider submits latest signed state on-chain, receives total_paid, remainder refunded to consumer
4. Challenge period: Consumer can dispute with newer state (higher sequence_number) within challenge window

6.3 Batch Settlement

The BatchProcessor enables atomic execution of multiple settlements in a single transaction. If any settlement fails, entire batch is rolled back. Useful for:

• Multi-provider inference requests
• Coordinated payment releases
• Bulk provider payouts
• Atomic escrow + channel operations

6.4 Fee Collection

The FeeCollector routes network fees:

7. Storage and State

Tenzro Ledger uses persistent key-value storage with a Merkle Patricia Trie for state commitment. This provides efficient range queries, atomic batch writes, and cryptographic state proofs.

7.1 Storage Organization

Storage is organized into dedicated column families for efficient access:

7.2 Merkle Patricia Trie

The state trie uses a modified Merkle Patricia Trie (same as Ethereum):

• Key-value mapping: Account address → account data
• Root hash: Cryptographic commitment to entire state, included in block header
• Merkle proofs: Prove account state without full state download
• Incremental updates: Only modified paths rehashed

7.3 Snapshots

Periodic snapshots enable fast sync for new nodes:

• Creation: Triggered every 1,000 blocks (configurable)
• Compression: State serialized and compressed with Zstandard
• Verification: Snapshot hash included in block header
• Retention: Keep last 100 snapshots (default)
• Restoration: Decompress and replay blocks since snapshot

7.4 Storage Configuration

7.5 Write Durability

Finalized blocks are written with fsync to ensure durability across power loss or crashes. Non-finalized blocks use async writes for performance. All batch operations are atomic — either all writes succeed or all are rolled back.

8. P2P Networking

Tenzro Ledger uses a modular peer-to-peer networking stack with multiple protocols for discovery, messaging, and content routing. The network layer supports multiple transports and security protocols.

8.1 Networking Stack

8.2 Gossipsub Topics

The network uses topic-based pub/sub for different message types:

8.3 Peer Management

The PeerManager tracks connection state and metrics:

• Connection tracking: Active connections, handshake state, protocol support
• Reputation scoring: Track peer behavior (valid messages, protocol violations)
• Rate limiting: Per-peer message rate limits to prevent spam
• Banned peers: Permanent/temporary bans for malicious behavior
• Metrics: Bytes sent/received, message counts, latency

8.4 Message Deduplication

Message deduplication prevents gossip amplification attacks:

• Tracks recently seen message IDs in cache (default: 10,000 entries)
• Message ID based on cryptographic hash of (topic, sender, content)
• Duplicates dropped before processing
• Cache TTL aligned with network propagation time

8.5 Bootstrap and Discovery

New nodes join the network through bootstrap peers specified via CLI:

After initial connection, the distributed hash table provides decentralized peer discovery. Peers periodically refresh their routing tables and discover new peers through structured queries.

9. Identity (TDIP)

The Tenzro Decentralized Identity Protocol (TDIP) provides unified identity for both humans and autonomous machines. All identities are anchored on-chain with W3C DID compatibility and support for verifiable credentials.

9.1 DID Format

9.2 KYC Tiers

Human identities have KYC tiers determining permissions and limits:

9.3 Delegation Scopes

When humans delegate control to machines, DelegationScope defines fine-grained permissions:

• max_transaction_value: Maximum TNZO per transaction
• max_daily_spend: Maximum TNZO per 24-hour period
• allowed_operations: Whitelist of transaction types
• allowed_contracts: Whitelist of contract addresses
• time_bound: Start and end timestamps for delegation
• allowed_payment_protocols: MPP, x402, Direct, Channel, Custom
• allowed_chains: Permitted chain IDs for cross-chain operations

9.4 Verifiable Credentials

TDIP supports W3C Verifiable Credentials for attestations:

• Issuer: DID of credential issuer (e.g., KYC provider)
• Subject: DID of credential holder
• Type: Credential schema (KycCredential, TeeAttestation, etc.)
• Claims: Key-value pairs of attested data
• Proof: Cryptographic signature binding issuer to claims
• Expiration: Credential validity period

10. Security (TEE + ZK)

Tenzro Ledger uses a dual security model combining Trusted Execution Environments (TEE) for hardware-backed confidentiality and Zero-Knowledge (ZK) proofs for cryptographic verification.

10.1 Supported TEE Providers

10.2 ZK Proof System

Groth16 SNARKs on BN254 curve (~128-bit security) with three pre-built circuits:

• InferenceVerificationCircuit: Prove correct execution of ML model inference without revealing inputs or model weights
• SettlementProofCircuit: Prove payment conditions met without revealing transaction details
• IdentityProofCircuit: Prove credential possession (e.g., KYC tier) without revealing full identity

10.3 GPU-Accelerated Proving

The GpuProvingEngine provides batch proof generation with multi-level compression:

10.4 Hybrid ZK-in-TEE

Combining ZK proofs with TEE attestations provides layered security:

• TEE layer: Hardware-enforced isolation and attestation of execution environment
• ZK layer: Cryptographic proof of computation correctness
• Combined proof: TEE attestation of ZK prover execution + ZK proof of circuit satisfaction
• Trust model: Requires breaking both hardware and cryptography

11. Token Economics

TNZO is the native utility token of Tenzro Ledger with 18-decimal precision. It serves three primary functions: gas fees, staking, and settlement.

11.1 Token Utility

11.2 Liquid Staking (stTNZO)

Users can stake TNZO in the liquid staking pool and receive stTNZO representing their staked position:

• Exchange rate: Rebasing rate (stTNZO value / TNZO value) increases with rewards
• Multi-validator delegation: Pool stakes across multiple validators for diversification
• Protocol fee: 10% (1000 bps) of staking rewards to treasury
• Unbonding period: 7 days to withdraw TNZO
• Transferability: stTNZO is transferable and composable in DeFi

11.3 Treasury and Governance

The NetworkTreasury collects protocol fees and distributes via governance:

• Revenue sources: Provider payment commissions (0.5%), liquid staking fees (10%)
• Multi-asset support: TNZO, USDC, USDT, ETH, SOL, BTC
• Multisig withdrawals: Requires threshold signatures for security
• Governance proposals: On-chain voting for treasury spending

11.4 Reward Distribution

Validators and providers earn rewards distributed at epoch boundaries:

• Block rewards: Fixed TNZO emission per block (decreasing schedule TBD)
• Priority fees: Paid directly to block producer
• Distribution: Proportional to blocks signed during epoch
• Slashing: Validators lose stake for equivocation (double-signing), downtime, or invalid attestations. Equivocation is automatically detected and results in a 10% stake penalty.

12. Implementation Status

12.1 Core Components

• MPC wallet system with threshold signing, encrypted keystore, and transaction validation
• Block-STM parallel execution with MVCC and conflict detection
• EIP-1559 dynamic fee market with base fee adjustment and burning
• ERC-4337 account abstraction with smart accounts and paymasters
• Gas metering with overflow protection

12.2 Development Phases

1. Core infrastructure (cryptography, consensus, networking)
2. Execution layer (multi-VM integration, state persistence)
3. Network and consensus (bootstrap, genesis, validator management)
4. Identity and payments (TDIP, MPP, x402, Tempo integration)
5. Agent and protocol integration (MCP, A2A protocols)
6. Testnet deployment
7. Economics and settlement (liquid staking, micropayment channels)
8. Bridge and interoperability
9. AI infrastructure
10. Client applications
11. Production hardening and security audits

13. Conclusion

Tenzro Ledger provides a purpose-built L1 settlement layer for the AI age, combining:

• High-performance consensus: HotStuff-2 BFT with 400ms block time, TEE-weighted validation
• Heterogeneous execution: EVM, SVM, and DAML/Canton with parallel Block-STM
• Modern fee market: EIP-1559 with burning, account abstraction (ERC-4337)
• Flexible settlement: Immediate, escrow, micropayment channels, batch
• Unified identity: TDIP for humans and machines with delegation scopes
• Dual security: TEE hardware attestation + ZK cryptographic proofs
• Token economics: TNZO utility for gas, staking, settlements, liquid staking

The design establishes a foundation for building decentralized infrastructure enabling autonomous AI agents to access intelligence and security services with verifiable settlement. The implementation follows a phased development approach, with core infrastructure, execution layer, and settlement protocols in active development.