Tenzro Ledger: The Settlement Layer for the AI Economy

Abstract

Tenzro Ledger is the L1 settlement layer of the Tenzro Network — the operating system for the AI economy. Where the Tenzro Network protocol layer provides intelligence, security, and agent infrastructure, the Ledger provides the verifiable foundation for agentic and AI commerce through 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 (BFT consensus), execution layer (multi-VM with parallel Block-STM), fee market (EIP-1559), account abstraction (ERC-4337), settlement protocols, storage, and networking.

1. BFT consensus Consensus

Tenzro Ledger uses BFT consensus, 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

The protocol 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. Tenzro implements ECVRF-EDWARDS25519-SHA512-TAI per RFC 9381 §5.4.1.1, reusing existing Ed25519 validator keys. The same primitive is exposed to application smart contracts via EVM precompile 0x1007and the NFT factory's mintRandom entry point (selector0x52517e21), enabling provably-fair NFT reveals, randomized trait assignment, and verifiable lotteries.

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

The EVM executor includes all 9 standard Ethereum precompiles (0x01-0x09), 7 BLS12-381 precompiles (EIP-2537, 0x0a-0x10) using the blst library, plus 9 Tenzro-specific precompiles for native access to ledger services.

Standard EVM Precompiles (0x01 – 0x09)

Tenzro-Specific Precompiles

2.7 EIP-1153 Transient Storage and Reentrancy Guard

Tenzro Ledger implements EIP-1153 transient storage, introducing the TSTORE and TLOAD opcodes for temporary key-value storage that is automatically cleared at the end of each transaction. This provides a gas-efficient mechanism for intra-transaction communication without persisting data to the state trie.

A TransientReentrancyGuard built on transient storage protects all Tenzro-specific precompiles from reentrancy attacks. This is critical for precompiles that interact with external state, particularly TNZO_BRIDGE, TOKEN_FACTORY, and CROSS_VM_BRIDGE, where a reentrant call could manipulate balances or allowances mid-execution.

• Guard cost: ~100 gas per check (TSTORE + TLOAD) versus ~5,000 gas for traditional SSTORE-based reentrancy guards
• Automatic cleanup: Transient storage is cleared after each transaction, so no residual lock state can persist
• Per-precompile isolation: Each precompile address uses a separate transient storage slot, preventing cross-precompile interference
• Coverage: All Tenzro-specific precompiles (0x0100 through 0x1005) are protected by TransientReentrancyGuard

2.8 Token Registry Security

The unified Token Registry (TokenRegistry) catalogs all tokens across EVM, SVM, and DAML virtual machines, providing a single source of truth for token metadata, balances, and cross-VM transfers.

• Deterministic TokenId: Computed as SHA-256 of creator address concatenated with a monotonic nonce, preventing collision and spoofing across VMs
• ERC-20 approval storage: Per-spender allowances tracked within the registry, enforced before any transfer
• Cross-VM validation: All cross-VM transfers are validated by the TokenRegistry before execution, ensuring the source and destination token representations refer to the same underlying asset
• Persistence: Token metadata and state persisted to RocksDB via the CF_TOKENS column family with DashMap-indexed in-memory lookup

2.9 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 v0.8 account abstraction, enabling smart contract wallets with programmable transaction validation, gas sponsorship, and modular security features. The v0.8 format splits the legacy initCode and paymasterAndData fields into separate typed fields with EIP-712 typed data hashing and a gas penalty threshold of 40,000.

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)

5.5 EIP-7702 Set Code Transaction

EIP-7702 extends account abstraction by allowing Externally Owned Accounts (EOAs) to temporarily delegate their execution to a smart contract implementation without deploying a new contract. This bridges the gap between EOAs and smart accounts.

A set code transaction includes an authorization list where each entry specifies:

EIP-7702 is fully compatible with the existing ERC-4337 infrastructure. An EOA can delegate to an existing SmartAccount implementation, gaining access to modules such as SocialRecovery, SessionKey, and SpendingLimit without migrating assets to a new address. This is particularly useful for validators who want to delegate their EOA to a multi-sig or spending-limited account during operation while retaining their established on-chain identity.

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 (~100-bit security post-exTNFS) 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.

11.5 Equivocation Detection and Slashing Pipeline

In BFT consensus, equivocation means a validator signs two different messages for the same consensus position — typically a double PREPARE or double COMMIT vote at the same (height, view) for conflicting block hashes, or a leader proposing two different blocks at the same height. In an honest run of the protocol a validator only ever votes once per (height, view) tuple, so equivocation is direct evidence of a Byzantine fault: no legitimate software bug, network partition, or race condition can cause it.

Every vote that arrives at the VoteCollector passes through the EquivocationDetector, which indexes votes by (validator, height, view) and checks for a previous vote from the same validator at the same position with a different block hash. If one is found, the detector constructs an EquivocationEvidence structure containing both conflicting votes and their signatures. The evidence is self-verifying: any observer can independently check that both signatures come from the same validator public key and that they sign different block hashes, so no trusted third party is required to accept it.

The consensus crate does not know about staking — it operates at the BFT protocol layer, not the economic layer. To bridge the two, consensus exposes a SlashingCallbacktrait that the node wires to the staking manager at startup. When equivocation is detected, the detector invokes the callback, which computes the penalty (10% of the validator's total stake, 1000 basis points) and calls StakingManager::slash(). The evidence is persisted to the CF_SLASHING RocksDB column family for auditability.

VoteCollector::insert_vote(vote)
   │
   ▼
EquivocationDetector::check(validator, height, view, vote)
   │
   │  (prior vote from same validator at same height/view
   │   with a different block hash?)
   │
   ├── NO  → store vote, return Ok
   │
   └── YES → construct EquivocationEvidence
                 │
                 ▼
              SlashingCallback::slash(validator, evidence, 1000)
                 │
                 ▼
              StakingManager::slash(validator, 10% of stake)
                 │
                 ▼
              - Validator stake reduced
              - Evidence persisted to CF_SLASHING
              - Next epoch: removed from validator set
              - Evidence emitted as block metadata

Slashing is deterministic across all honest nodes: every node that receives both conflicting votes will independently detect the equivocation and produce the same evidence. The stake mutation is applied atomically as part of the block that includes the evidence. Slashed validators remain in the active set with reduced weight until the next epoch boundary, at which point the validator set is recomputed and any validator whose remaining stake falls below the minimum threshold is removed. A slashed validator is not permanently banned: after topping up stake above the minimum threshold, they can rejoin the active set at the next epoch.

11.6 Agent Protocol Integration (MCP & A2A)

Every Tenzro node bundles two protocol servers that expose ledger capabilities to AI agents and external clients: an MCP server on port 3001 that implements the Model Context Protocol (Streamable HTTP transport via the rmcp crate) with 31 tools (and growing) covering wallet operations, network queries, identity and delegation, payments, AI inference, cross-chain bridging, verification, staking, and tokens and contracts; and an A2A serveron port 3002 that implements Google's Agent-to-Agent specification with JSON-RPC 2.0 dispatching, Server-Sent Events (SSE) streaming, and a discoverable Agent Card at /.well-known/agent.json advertising six skills: wallet, identity, inference, settlement, verification, and staking.

Both servers are backed by the same underlying ledger state and share the same authentication layer: public read-only operations (balance lookups, block queries, agent card discovery) can be invoked anonymously, while any operation that mutates state or incurs a payment requires either an onboarding key or a JWT bearer token — both bound to a TDIP identity and subject to its delegation scope. Onboarding keys are issued automatically when a participant joins the network (via tenzro-cli join or the tenzro_participate RPC), are persisted in RocksDB so they survive node restarts, and are fully decentralized — any node can issue and validate them without a central authority. Autonomous agents receive onboarding keys through the same flow as human participants. The MCP server lets LLMs connect to Tenzro through Claude Desktop, Claude Code, or any MCP-compatible client; the A2A server lets autonomous agents discover, negotiate with, and pay each other directly over HTTP. Together they make every Tenzro node a first-class participant in agent-native workflows.

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 is the settlement layer for the AI economy — not a blockchain that also does AI, but purpose-built infrastructure where agents are first-class economic actors transacting, verifying, and settling autonomously. It combines:

• High-performance consensus: BFT consensus 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

Together with the Tenzro Network protocol layer and TNZO as the economic unit, the Ledger establishes the complete operating system for an AI economy where autonomous agents can access intelligence, security, and settlement services — all verifiable, all on-chain. The implementation is testnet-ready with all core subsystems operational and an extensible architecture designed to grow with the agentic era.