HostNexFlow › Library › ZetaChain omnichain explained
ZetaChain — omnichain smart contracts, explained
ZetaChain's pitch is specific: one smart contract, deployed once on ZetaChain's EVM, that users on every connected chain can call and that can itself push assets back out to those chains — no per-chain deployments, no wrapped-token spaghetti. Whether that pitch survives contact with the details is what this page is for.
What "omnichain" means in this architecture
ZetaChain is a Cosmos-SDK L1 (CometBFT consensus) that carries an EVM execution environment — the zEVM — as its native layer. The differentiator is not the EVM itself but the direction of the wiring: contracts on zEVM are reachable from connected chains through gateway contracts, and can trigger transactions out to those chains. A lending contract deployed once on ZetaChain can accept collateral deposited on Ethereum and release a loan on BNB Chain, with the contract logic — rates, liquidation, accounting — living in exactly one place. That inversion (hub contract, spoke assets) is the actual product; "blockchain that connects blockchains" is the slogan version of it.
The moving parts
Gateway contracts. Each connected chain hosts a gateway contract that is the entry point: a user deposits an asset or calls depositAndCall, and the gateway emits the event the rest of the system watches.
ZRC-20. The foreign-asset standard: when ETH or USDC is deposited through a gateway, the corresponding ZRC-20 (e.g. ETH.ETH) is minted inside zEVM as the chain's canonical representation of that external asset, and burned on withdrawal. ZRC-20 is what lets a zEVM contract hold and move "real" ETH without the contract ever touching Ethereum directly — the custody is the validator set's problem, the accounting is the token's.
Observer-signer validators. ZetaChain validators do double duty: CometBFT consensus on ZetaChain itself, plus observing connected chains for gateway events and TSS-signing the outbound transactions a contract requests. The validator set is the bridge — that is the honest framing, and it's also the trust assumption to evaluate.
ZETA. The native token pays gas and cross-chain fees and is what validators bond. Contracts can also charge users in ZETA for the destination-chain gas of an outbound call, which is how a "one-contract" app prices its cross-chain writes.
A cross-chain call, end to end
Worth walking once, slowly, because the failure modes only make sense against the happy path:
1. A user on Ethereum calls the gateway's depositAndCall — tokens in, target contract + payload specified.
2. Observer-signer validators vote on the event; consensus on the observation mints the ZRC-20 representation and invokes onCrossChainCall on the zEVM contract.
3. The contract runs: updates its own state, and optionally requests an outbound call — say, sending USDC.ETH out to the user on Ethereum, or writing state to another chain's gateway.
4. The TSS signer set produces a real signature for the destination chain; the outbound transaction lands there like any other.
5. If the outbound call fails, the contract's onRevert path runs against a revert address the caller provided — the design acknowledges cross-chain calls can fail downstream and gives the contract a defined way to compensate.
End-to-end latency is "source-chain finality + vote + destination execution" — meaningfully slower than a same-chain call, and priced accordingly by gas on both ends.
The honest trust assumption: an omnichain contract inherits the security of the validator set's TSS custody over gateway deposits. That is a bridge-shaped trust assumption wearing a different shirt — the assets backing ZRC-20 representations sit in threshold-signer custody, so the honest question is always how decentralized and accountable that signer set is, not whether the UX feels seamless.
What it's actually good for — and where it isn't
The fit: applications whose core state must be shared across chains — omnichain lending, unified token registries, cross-chain orchestration where one contract must see deposits arriving from many networks and decide once. The anti-fit: anything latency-sensitive (the write path crosses two chains' finality), anything where per-chain native contracts would be simpler, and anything whose risk model can't accept the signer set as a custody dependency. Also worth saying plainly: omnichain UX reduces deployment sprawl but doesn't repeal liquidity fragmentation — a ZRC-20 balance on zEVM is still distinct from the native asset's liquidity on its home chain, and moving between them is a real, priced step.
Building on it
For developers the surface is ordinary Solidity — the difference is the lifecycle (contracts implement the cross-chain entry points, receive ZRC-20 instead of native tokens, and request outbound calls through the system contract) and the gas model (destination-chain execution is paid for from the call itself). Rehearse against the testnet the same way you'd rehearse any new execution environment — our Monad testnet piece covers why that discipline exists — and treat revert handling as a first-class code path, not an afterthought.
Where NexFlow stands on ZetaChain
We've filed a full operator profile with the ZetaChain validator delegation program — KYB document upload is the post-acceptance gate — and the honest status label is filed, which you can read live on /networks/zetachain/ alongside the rest of our on-chain footprint on /networks/. For the chains our RPC relay already covers — the same keyless lane shape as Monad and 80+ others — the index is /rpc/.
One contract, many chains
The whole architecture in a sentence: users deposit through gateway contracts on their home chains, your zEVM contract sees one call graph, and observer-signer validators settle the outbound side.
Frequently asked
What is a ZRC-20 token?
ZRC-20 is ZetaChain's omnichain fungible-token standard: a token inside the zEVM that represents an asset from a connected chain (ETH.ETH for Ethereum ETH, and so on). Depositing the real asset through a chain's gateway contract mints its ZRC-20 representation; burning it triggers a TSS-signed withdrawal back to the home chain. It lets a single zEVM contract hold and move foreign assets without deploying per-chain wrapper contracts — with the custody sitting in the validator signer set rather than a standalone bridge.
Is ZetaChain a bridge?
Not exactly — it's an L1 whose validator set performs bridging duties as part of consensus. Traditional bridges are external contracts moving messages between two chains; ZetaChain puts the EVM itself in the middle, so contracts live on ZetaChain and connected chains are its spokes. The custody assumption is bridge-shaped either way: the observer-signer validator set is the thing you're trusting to not sign fraudulently, same threat model as any validator-secured bridge.
What can I do on ZetaChain that I can't do on a normal L1?
Deploy one contract that all connected chains can reach: a user on Bitcoin can trigger your contract (via the gateway/deposit path) and your contract can send assets back out to them — state, logic and accounting stay in one place instead of N copies across N chains. You also get ZRC-20 representations of foreign assets usable inside ordinary Solidity. What you give up: same-chain latency, and simplicity for apps that never needed to touch more than one chain.
How do cross-chain transactions on ZetaChain work?
Deposit or call through the connected chain's gateway contract → observer validators reach consensus that it happened → the zEVM contract's onCrossChainCall runs with the minted ZRC-20 → the contract can request outbound writes, which the TSS signer set executes on the destination chain → failures route back through the contract's onRevert handler. Each hop waits on the source chain's finality, so the full round trip is seconds-to-minutes, not a single block.
Is ZetaChain proof-of-stake?
Yes — it's a Cosmos-SDK chain on CometBFT consensus, so validators bond ZETA and vote on blocks. The unusual part is the second role: the same validator set observes connected chains and produces threshold (TSS) signatures for outbound transactions, so a ZetaChain validator is simultaneously a consensus participant and a bridge signer. That's also why validator quality matters more here than on a single-chain network — the set is custodying external-chain assets, not just ordering its own blocks.
Does NexFlow run a ZetaChain validator?
Not yet — a full operator profile is filed with the validator delegation program, with the KYB document upload as the post-acceptance step. The honest status ('filed', not 'running') is live on /networks/zetachain/, and our operated infrastructure overall — validators, nodes, relay lanes — is on /networks/ and /validators/.