Tenzro Ledger
- Consensus
- HotStuff-2 BFT
- Block target
- 400 ms
- VMs
- Canton DAML + EVM + SVM
- Signatures
- Ed25519 + ML-DSA-65 + BLS12-381
- Chain ID
- 1337
- Gas market
- EIP-1559
Three VMs, picked for what they do best
A single chain that picks one VM forces every workload to fit that VM. Tenzro Ledger runs three and routes by transaction type. Each VM is picked for what it does best, and all three share the same state, the same gas token, and the same TDIP identity.
Canton DAML — institutional settlement. Canton is where the institutional financial system already settles tokenized cash, money-market funds, bonds, equities, treasuries, and OTC derivatives. The Canton bridge adapter speaks the Canton 3.5+ JSON Ledger API v2 directly. CIP-56 Canton Coin holdings round-trip with TNZO; CIP-26 user management binds each tenant to its own party with CanActAsrights enforced server-side; DAR upload, party allocation, command submission, and active-contract queries are all available through the same node API surface as EVM and SVM calls. Canton's privacy model means the transaction body is visible only to its signatories; Tenzro provides the public commitment.
EVM — liquidity and composability. The Ethereum Virtual Machine surface targets the broadest pool of liquidity, tooling, and existing contracts. Every standard precompile (ecRecover, SHA-256, RIPEMD-160, Identity, ModExp, EC_ADD, EC_MUL, EC_PAIRING, BLAKE2F) plus all seven BLS12-381 precompiles (EIP-2537) for native consensus-grade signature aggregation. Block-STM parallel execution with MVCC. EIP-1559 dynamic fee market. ERC-4337 v0.8 account abstraction, EIP-7702 delegation, and ERC-7579 modular validators are all implemented natively — smart accounts, session keys, social recovery, spending limits work without any setup contract.
SVM — throughput and latency. The Solana Virtual Machine surface targets workloads that need sub-second finality and high throughput — DEX routing, agent-to-agent micropayments, real-time settlement on a path. Solana BPF runtime, Solana programs run unmodified. SPL Token program maps onto the native unified token registry so a swap on SVM settles in the same balance space as a transfer on EVM. No bridging between the two.
The point is that an agent settling a DvP between a tokenized treasury (Canton) and a stablecoin payment (EVM) executes the whole thing as one workflow through one identity. The chain is the substrate; the workflow is the point.
HotStuff-2 consensus
Three-phase BFT (PREPARE → COMMIT → DECIDE), linear O(n) communication per round, deterministic finality. Block target is 400 ms. Finality follows within a small number of rounds under healthy network conditions.
Hybrid post-quantum signatures. Every safety-critical message — vote, quorum certificate, finality cert, equivocation evidence — carries three signatures simultaneously: Ed25519 for compatibility and speed; ML-DSA-65 (FIPS 204) for post-quantum soundness; BLS12-381 for O(1) aggregation in quorum certificates. A QC is a single 96-byte BLS aggregate plus a participation bitmap.
Reputation-weighted leader election.Leader selection is reputation-weighted rather than VRF-only. A validator's reputation is its historical block-production success times its TEE attestation multiplier (1.5× for hardware-attested validators) times a tip-following weight. The multiplier is multiplicative, so a chronically flaky TEE-attested validator is dwarfed by a non-TEE active one. Hardware-secured participation becomes economically rational without ever gating liveness on TEE possession.
Equivocation slashing.The detector watches every vote stream for double-signs in the same view. When detected, the slashing callback bridges the consensus crate to the staking manager and burns 10% of the offender's stake. Slashed stake is burned, not redistributed, so there is no positive feedback loop where surviving validators benefit from peers' slashing.
Two-tier validator model
Validator entry is open to anyone meeting the resource profile (hardware, bandwidth, uptime, optional TEE attestation). Bonded TNZO stake is optional and unlocks additional benefits.
Tier 1 — resource-only validators. Hardware profile check, stability profile (uptime, no equivocation history), optional TEE attestation, geographic and network diversity bonus. No stake required. Full participants in the BFT set: vote in PREPARE / COMMIT / DECIDE, propose blocks when elected, sign QCs with hybrid signatures. Earn priority fees plus a reputation-weighted base reward share. Capped at a base reward multiplier and excluded from leader election for high-trust block classes (e.g., blocks containing large-value institutional settlement or training round finalization).
Tier 2 — staked validators. Resource-only eligibility plus bonded TNZO. Full leader-election eligibility across every block class. Higher reward multiplier on top of the resource-only base. Governance vote weight. Eligibility for high-trust roles (training round witness committee, high-value bridge nodes, AP2 high-value mandate validation, institutional Canton route operation). Slashing exposure: 10% bond burn on equivocation.
The TEE attestation multiplier applies to both tiers. The model lowers the barrier to validator participation while preserving the economic security budget where it matters most.
Cross-VM token model
TNZO has a single canonical native balance. The wTNZO ERC-20 pointer on the EVM side and the wTNZO SPL adapter on the SVM side share the same underlying balance — no wrapped/unwrapped distinction, no bridge between them, no liquidity fragmentation. Canton CIP-56 holdings round-trip through the Canton bridge adapter.
From the application's point of view, a wallet has one TNZO balance regardless of which VM it last touched. Cross-VM transfer is a single typed-transaction call routed by the unified token registry. Permit2, EIP-7702, ERC-7683 cross-chain intents, and ERC-7802 native cross-chain mint/burn all participate in this unified balance model.
Tenzro-specific precompiles
Beyond every standard EVM precompile, the Ledger exposes protocol-aware precompiles to Solidity contracts:
TEE_VERIFY— real attestation across Intel TDX, AMD SEV-SNP, AWS Nitro, NVIDIA GPU CC, Intel Tiber.ZK_VERIFY— O(1) HashSet lookup against the on-chainZkCommitmentRegistry. Validators verify Plonky3 STARKs off-chain and write 32-byte SHA-256 commitments; the precompile is a constant-time lookup.VRF_VERIFY— ECVRF-EDWARDS25519-SHA512-TAI per RFC 9381.MODEL_INFERENCE,SETTLEMENT,STAKING,GOVERNANCE,TNZO_BRIDGE,TOKEN_FACTORY,NFT_FACTORY,CROSS_VM_BRIDGE.- ERC-7579 modular validators for smart-account custody — Social Recovery, Session Key, Spending Limit — installable per smart account and AND-combined at
validateUserOp. - ERC-8004 trustless agent identity, reputation, and validation registries.
Persistence and durability
RocksDB with column families per concern (blocks, state, accounts, transactions, identities, agents, models, providers, tokens, settlements, validator modules, agent memory, audit, API keys, MPC keyshares, training runs, training receipts, bridge nonces, equivocation evidence). Durable writes go through write_batch_sync with fdatasync. Block writes are atomic.
Snapshot bootstrap is cryptographically anchored — the joining node specifies a block hash it trusts via --state-sync-anchor; the snapshot must hash to that root or the bootstrap aborts. New validators do not silently adopt a hostile fork. Auto-repair handles WAL corruption on startup.
Every higher-layer registry — models, agents, identities, tokens, escrows, settlements, swarms, training runs, validator modules — writes through the same KvStore trait and hydrates on node restart.