Bridges

Tenzro Network 1 connects to the major networks, including Ethereum and its rollups, Solana, Cosmos chains, Polkadot and Canton, through established cross-chain protocols. A single bridge router sits in front of them. You ask for a route from one chain to another; the router compares the protocols that serve that lane, quotes each, and executes through the one you choose. Fees can be paid in TNZO.

How a transfer works

1. Quote. The router asks every protocol that serves the lane for a live fee and time estimate. Quotes carry a time-to-live and stale quotes are refused.
2. Choose. Pick the cheapest, the fastest, a balance of both, or pin a specific protocol.
3. Execute. The paying account signs the transfer. Value leaves Tenzro only from a finalised block.
4. Track. Follow the transfer by its id until it is delivered on the destination chain.

# Compare routes
tenzro bridge routes --from-chain tenzro --to-chain base --token USDC --rpc https://rpc.tenzro.xyz

# Quote a transfer (optionally pin a protocol with --protocol)
tenzro bridge quote --from-chain tenzro --to-chain ethereum --token TNZO --amount 100 \
  --rpc https://rpc.tenzro.xyz

# Execute
tenzro bridge execute --from-chain tenzro --to-chain ethereum --token TNZO --amount 100 \
  --sender 0xYOUR_ADDRESS --recipient 0xRECIPIENT --rpc https://rpc.tenzro.xyz

# Track
tenzro bridge status <TRANSFER_ID> --rpc https://rpc.tenzro.xyz

From TypeScript:

import { TenzroClient } from "tenzro-sdk";

const client = new TenzroClient({ endpoint: "https://rpc.tenzro.xyz" });
const bridge = client.bridge();

const routes = await bridge.getRoutes("tenzro", "base", "USDC");
const transfer = await bridge.bridgeTokens("tenzro", "base", "USDC", "250", "0xRECIPIENT");

Protocols

Each protocol keeps its own trust model; the router never mixes them within one transfer. Pages for the most-used routes go deeper.

tenzro bridge adapters (JSON-RPC tenzro_listBridgeAdapters) lists the protocols configured on the node you are using.

Verification and replay protection

Every inbound message is checked against its protocol's trust source before any state changes. Verification is fail-closed: a message that is not attested by the configured quorum is rejected, and a protocol with no trust source configured accepts nothing. Every message carries a nonce, and each protocol keeps a persistent record of nonces and message ids already seen, so a replayed message is rejected even after a node restart.

Portable finality certificates

Outbound messages leave Tenzro only from finalised blocks. Each finalised block has a finality certificate signed by the validators with ML-DSA-65 under Tenzro DAG Consensus, and the certificate can be compressed with a STARK proof. The certificate is portable: a relayer, a light client or a verifier contract on the destination chain can check that a Tenzro block is final without trusting whoever delivered it, and a certificate signed by a validator for two conflicting blocks is evidence for slashing. See Finality certificates.

Fees in TNZO

A cross-chain fee has four parts: source-chain gas, destination-chain gas, the protocol's own fee, and a Tenzro protocol fee that goes to the treasury. You do not need to hold the destination chain's gas token. The node quotes the destination-native fee in TNZO, debits TNZO from your account into a per-protocol sponsorship pool, and a registered relayer fronts the destination gas from that pool.

tenzro bridge-fee quote --adapter ccip --dest-chain eip155:1 --native-fee 1000000000000000 \
  --rpc https://rpc.tenzro.xyz

The quote returns the TNZO due, the rate used, its source (a price feed or a governance-set rate) and an expiry. tenzro bridge-fee price --symbols TNZO,ETH,USDC (JSON-RPC tenzro_getPrice) reads the prices behind it, and tenzro bridge-fee list-pools (tenzro_listBridgeSponsorshipPools) shows the pools. Sponsorship pools can also cover fees for eligible agent and end-user flows. Payment in stablecoins works the same way; see Stablecoin payments.

Supply across networks

TNZO supply is fixed at 1,000,000,000. When TNZO moves to another network, each protocol mints and burns its own representation there, and every mint and burn is recorded on Tenzro in one supply registry. The registry enforces, per asset, that total mints minus burns never exceed the canonical supply, that each protocol's sequence of changes only moves forward, and that no burn exceeds what is circulating. A compromised relayer on one route cannot create TNZO, because its next change is refused at the registry. Read it with tenzro global-supply circulating --asset-id <ASSET_ID> and tenzro global-supply policy --asset-id <ASSET_ID> (JSON-RPC tenzro_globalSupplyCirculating and tenzro_globalSupplyPolicy).

TNZO supports ERC-7802 crosschainMint and crosschainBurn, so protocols that follow the standard can move it natively. Only authorised bridge contracts may call these hooks. tenzro_erc7802GetCrossChainSupply returns the supply across every configured chain.

Cross-chain intents

For transfers that should be filled by whoever can deliver fastest, Network 1 supports ERC-7683 orders. A user or agent opens an order on the origin chain describing what it pays and what it wants delivered on the destination; a filler delivers; the order settles once a proof of the fill arrives through a supported route (LayerZero, Wormhole, deBridge or Hyperlane). Orders move through Open, AwaitingProof, then Settled, Refunded or ForceRefundEligible. Order ids are deterministic hashes of the order, so both chains can check a fill against the same id. Opening an order can be combined with a Permit2 signature, so one signature authorises both the order and the token pull.

tenzro erc7683 list --rpc https://rpc.tenzro.xyz
tenzro erc7683 get --order-id <ORDER_ID> --rpc https://rpc.tenzro.xyz

Chain identifiers

Tenzro is registered in the chain-agnostic tenzro namespace. Look identifiers up rather than hard-coding them, since Network 1 starts from a fresh genesis:

The CLI equivalents are tenzro caip caip2, tenzro caip caip10 --address <ADDRESS> and tenzro caip caip19. The browser provider @tenzro/inject uses these identifiers in CAIP-25 sessions.

Access

See RPC access.

Related

• LayerZero, Chainlink CCIP, Wormhole
• Finality certificates
• Multi-VM runtime for moving TNZO between runtimes on Tenzro itself