Bridges
Move TNZO between Tenzro Network and other chains over governed routes: lock and mint, committee-attested deliveries, fees in TNZO and portable finality certificates.
TNZO is native to Tenzro: the ledger here is the only place it is created, and its supply is fixed here. TNZO on another chain is a bridged representation, minted there only when the same amount is locked on Tenzro for that chain, and burned there when it comes back. The representation on an external chain can never exceed the TNZO locked on Tenzro for it, and anyone can check both sides.
Value moves over routes. A route names the transport (ccip, canton, ibc, deposit or contract), the external chain, the contract allowed to send to Tenzro, the committee that attests each delivery and how many members must sign, whether a light-client proof is also required, and how much may move per transfer and per epoch. Each external chain is served by one route. Routes live in chain state and are added, changed or removed only by an enacted governance proposal, so every node applies the same routes and the set of served chains can change over time.
Reading routes
# Every route with its caps, epoch usage, locked and outstanding supply
tenzro bridge routes --rpc https://rpc.tenzro.com
# One route by transport and external chain
tenzro bridge route --adapter ccip --chain ethereum --rpc https://rpc.tenzro.comThe JSON-RPC equivalents are tenzro_listBridgeRoutes, tenzro_getBridgeRoute (adapter, source_chain) and tenzro_getBridgeCircuit, which returns any pause or disable records for the routes to and from a chain. A route is open (carries traffic both ways), disabled (winds down: nothing new leaves, but TNZO already sent out can still come back) or paused (carries nothing).
Sending TNZO out
The holder signs a bridge transaction with its own hardware key. The node takes the TNZO from the holder's balance, locks it in the route's vault and stores the outbound message for the route's relayers.
tenzro bridge send --target-chain ethereum --recipient 0xRECIPIENT \
--amount 100000000000000000000 --rpc https://rpc.tenzro.com--amount is in the smallest unit (TNZO wei). A route may also carry listed stablecoins such as USDC; pass --asset USDC to send the representation back and have the route's vault release the token on the destination chain. Relayers read outbound records with tenzro_getBridgeOutbound.
From TypeScript:
import { TenzroClient } from "tenzro-sdk";
const client = new TenzroClient({ endpoint: "https://rpc.tenzro.com" });
const routes = await client.bridge().listRoutes();
const route = await client.bridge().getRoute("ccip", "ethereum");
// signer: the holder's hardware-backed signer
await client.bridge().send(signer, "ethereum", "0xRECIPIENT", 100n * 10n ** 18n);Receiving TNZO back
A relayer submits the route committee's signed delivery as an inbound transaction it signs and pays for itself; the node never relays from its own account. Execution releases TNZO to the recipient only if the committee signatures, the nonce, the expiry, the caps, the route mode and the amount outstanding on the other chain all check out. Each delivery is accepted once.
tenzro bridge deliver --adapter ccip --from-chain ethereum --delivery <DELIVERY_HEX> \
--rpc https://rpc.tenzro.comTransports
| Transport | Used for | How inbound deliveries are verified |
|---|---|---|
ccip | TNZO as a Chainlink CCIP cross-chain token, and carried stablecoins | The route committee's attestation, plus a light-client proof where the route requires one |
ibc | Cosmos chains | Light-client proofs of the counterparty chain's consensus (tenzro bridge ibc, tenzro bridge light-client) |
canton | Canton | The route committee's attestation of the ledger payload |
deposit | Deposit assets such as Bitcoin, credited on deposit and withdrawn over the route | The route committee; withdrawals are signed input by input (tenzro bridge withdrawal) |
contract | A governed contract on the external chain | The route committee's attestation |
Verification and replay protection
Every inbound delivery is checked against its route before any state changes. Verification is fail-closed: a delivery not signed by the route committee's threshold is rejected, a route that requires a light-client proof accepts nothing without one, and a paused route accepts nothing at all. Every delivery carries a nonce and an expiry, and each is accepted once, so a replayed delivery 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 covers source-chain gas, destination-chain gas and the transport's own fee. You do not need to hold the destination chain's gas token: the node quotes the destination-native fee in TNZO.
tenzro bridge-fee quote --adapter ccip --dest-chain eip155:1 --native-fee 1000000000000000 \
--rpc https://rpc.tenzro.comThe quote (JSON-RPC tenzro_quoteBridgeFeeInTnzo) converts the destination-native fee to TNZO at the USD rates validators committed on chain, and is refused while those rates are stale. Payment in stablecoins works the same way; see Stablecoin payments.
Supply across networks
TNZO supply is fixed at 1,000,000,000 on Tenzro. Every route records how much TNZO is locked for it and how much of its representation is outstanding on the other chain, and a delivery that would release more than is outstanding is refused, so a compromised relayer or committee on one route cannot create TNZO. tenzro bridge routes shows both figures for every route. Each route is also bounded by a cap per transfer and a limit per epoch, and a network-wide limit applies to every route; the tighter one wins.
Cross-chain intents
For transfers that should be filled by whoever can deliver fastest, Tenzro Network 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 as an attested delivery over a governed route. 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.com
tenzro erc7683 get --order-id <ORDER_ID> --rpc https://rpc.tenzro.comChain identifiers
Tenzro is registered in the chain-agnostic tenzro namespace. Tenzro testnet v1 starts from a fresh genesis, so read the chain id from the node (eth_chainId, or tenzro node status) rather than hard-coding it.
Access
| Class | Methods |
|---|---|
| Open | tenzro_listBridgeRoutes, tenzro_getBridgeRoute, tenzro_getBridgeCircuit, tenzro_getBridgeOutbound, tenzro_quoteBridgeFeeInTnzo |
| Signed by the sender | Bridge transactions submitted with tenzro_sendRawTransaction, as built by tenzro bridge send / tenzro bridge deliver |
See RPC access.
Related
- Chainlink CCIP, Canton
- Finality certificates
- Multi-VM runtime for how one balance appears in every runtime on Tenzro