We've been pulling apart the Tempo Zones architecture since the April announcement. This post covers the technical details: how the privacy model works, where the trust assumptions sit, and how we're integrating Zones into REM's settlement infrastructure for clients.
The architecture in plain terms
A Zone is a parallel, EVM-compatible chain anchored to Tempo mainnet through a Zone Contract, a smart contract on L1 that locks deposited funds and enforces withdrawal rules.
Here's how execution flows through the system:
When a user deposits, they call the Zone Contract on mainnet. The token, amount, and sender address are visible on L1, but the recipient address inside the Zone is encrypted. An observer watching mainnet sees "Address X deposited 50,000 USDC into Zone 7" but cannot determine who received it inside the Zone.
Once inside, transactions are fully private from the outside. Only the Zone operator, the entity running block production, can see balances, transaction history, and counterparty details. Standard EVM execution, standard wallets, no specialized tooling.
Withdrawals work in reverse. The user initiates from inside the Zone, and on mainnet the withdrawal appears as funds leaving the Zone, but the originating address inside the Zone is hidden via a cryptographic commitment. Observers can see someone withdrew from the Zone but not who.
Cross-Zone transfers aren't direct. You withdraw to mainnet, then deposit into another Zone. The amount and Zone IDs are visible on mainnet; the internal addresses on both sides are not.
One detail worth flagging: even reading a balance requires signing an auth-token with the keypair that controls the account. You can't query someone else's balance without their keys.
The operator trust model
This is the most debated part of the design, so it's worth being precise.
The operator can see all transactions, balances, and addresses within the Zone. They sequence transactions and build blocks. They can suspend a user's ability to transfer or withdraw for compliance enforcement. And they control which TIP-20 tokens are enabled in the Zone.
What they can't do: transfer a user's funds. Ownership stays with the user; funds are locked in the Zone Contract on mainnet and only the owner can withdraw. They also can't permanently censor withdrawals, since funds are ultimately secured by the L1 contract.
The criticism from the privacy community is fair. This is a trusted model. The operator is a single point of visibility. If your threat model requires privacy from the operator itself, Zones are the wrong tool. Look at ZK-based approaches like Aztec or Zcash.
But for institutional use cases, the threat model is different. Banks don't need privacy from their own compliance team. They need privacy from competitors, from the public, from anyone who shouldn't be watching settlement flows. The operator model maps onto existing financial relationships: your bank sees your transactions, your regulator can subpoena them, but the rest of the world can't.
Token and compliance portability
Two design choices that matter for institutional deployments.
Any TIP-20 token deployed on mainnet can be enabled in any Zone by its operator. The same token can exist across multiple Zones simultaneously. No wrapped tokens, no bridge risk, no fragmented liquidity.
Separately, issuer-defined transfer policies under TIP-403 (allowlists, blocklists, freeze capabilities) are mirrored across all Zones automatically. When a stablecoin issuer updates a blocklist on mainnet, every Zone enforces the change without operator intervention. This isn't optional; it's protocol-enforced.
The combination means you can run a private Zone with full compliance controls inherited from the token issuer, without building custom compliance logic at the Zone level.
What's missing (for now)
No in-Zone swaps. If you need to convert between stablecoins inside a Zone, you withdraw to mainnet, swap on Tempo's native DEX, and redeposit. Fast (sub-second finality) but adds round trips. No direct Zone-to-Zone transfers either, same pattern. For multi-institutional settlement workflows, each cross-Zone movement touches mainnet. The privacy properties hold (internal addresses stay hidden), but the extra hops add latency and gas costs.
There's also a single operator per Zone, no multi-party block production. If the operator goes down, the Zone's liveness depends entirely on them. Funds are safe (locked on L1), but transactions stall until the operator recovers. This is probably the constraint we think about most when designing multi-Zone architectures for clients.
How REM builds custom Zones for clients
We deploy and operate custom Tempo Zones as part of REM's settlement infrastructure. In practice, each client Zone gets configured to their specific compliance requirements: KYC allowlists mapped to their onboarded counterparties, transaction policies matching their jurisdictional obligations, and token enablement based on which stablecoins they settle in.
On the operator side, we either run the infrastructure or help clients run their own. For self-operators, we handle the initial deployment, monitoring setup, and failover configuration. For managed service clients, REM operates the Zone with SLAs on liveness and transaction throughput.
Custom Zones connect into our multilateral netting engine, so settlement obligations between counterparties across multiple Zones get netted down before final settlement. Fewer on-chain transactions, less capital locked in transit. For cross-border transfers, REM's compliance engine attaches FATF-compliant originator/beneficiary data even when the settlement happens inside a private Zone. The Zone protects settlement data from the public; REM ensures regulators and counterparties get the data they're required to see.
For clients operating across multiple corridors or entity structures, we design Zone topologies: which entities share a Zone, which get their own, how liquidity flows between them through mainnet, and how netting reduces settlement volume across the whole structure. This is where most of the design work happens, honestly. The Zone deployment itself is straightforward. Figuring out the right topology for a client's counterparty graph is the hard part.
How the layers fit together
Tempo mainnet gives you shared liquidity, token standards, and sub-second finality. Zones give you transaction privacy. REM gives you clearing, netting, and compliance orchestration between institutions. Each layer fills a gap the others don't cover. Mainnet without Zones means your transactions are public. Zones without a clearing layer means you have privacy but no settlement logic or compliance automation.
We built REM to be that clearing layer. The part that's still evolving is how we handle the Zone-to-Zone round-trip cost for high-frequency settlement corridors. Netting helps a lot (fewer gross movements), but the ideal would be direct inter-Zone settlement without touching mainnet. That's not in the protocol today, and it may never be, given the trust model implications. We're watching it.
See it in practice
We've published two full case studies showing what Zone deployments look like end to end:
Get started
If you're building stablecoin payment infrastructure and want to evaluate what a custom Zone deployment looks like, reach out at hi@rem.money or book a call. We'll walk through the architecture, scope the compliance requirements, and spec out the Zone configuration.
Source code for Zones is open-source at github.com/tempoxyz/zones. Protocol spec at docs.tempo.xyz/protocol/zones.