# REM — Full content
> REM is the financial control plane for tokenised finance. It makes tokenised-finance applications work with the systems their customers already use.
Site: https://rem.money
Last updated: 2026-09-23
This file is intended for LLM and AI agent ingestion. It mirrors the content available at https://rem.money.
---
## What REM does
REM turns authorised ledger activity into canonical financial state and events, coordinates durable workflows, and reconciles outcomes across chains, custody, books and records, and enterprise systems.
Product loop: observe authorised activity → establish canonical history and state → normalise financial meaning → enforce policy and approvals → execute durable workflows → reconcile every system → retain evidence and exceptions.
Modules: REM Edge (connectors deployed in REM cloud, customer VPC or cloud, on-premises, or embedded), REM Model (canonical financial objects and lifecycle events), REM Sync (APIs, webhooks, Kafka-compatible streams, databases, warehouses), REM Flow (durable workflows and approvals), REM Reconcile (cross-system comparison with explainable breaks).
Sources: public and private EVM networks, Tempo and Tempo Zones, custody and provider feeds, bank and internal ledgers.
Boundary: REM does not hold customer funds, keys, or custody, issue tokens, operate networks, or perform regulated execution. The customer, bank, custodian, or licensed provider remains the execution endpoint.
---
## Solutions
### Stablecoins (https://rem.money/products/stablecoins)
Stablecoin operations infrastructure. Deposit operations tracked through Observed → Pending → Confirmed → Finalised → Creditable → Credited → Reconciled, with reorgs, duplicates, missing memos, and finality policy handled. Settlement workflows across entities, wallets, providers, and bank accounts. Three-way reconciliation between chain, provider, and internal ledger.
### Tokenisation (https://rem.money/products/tokenisation)
Tokenised-asset lifecycle infrastructure. Allocation, coupons, transfers, calls, maturity, and redemption turned into canonical lifecycle events and synchronised to registers, accounting, and reporting systems, then reconciled against the custodian and internal books. Fixed income is the leading domain.
### Private ledgers (https://rem.money/products/zones)
Private-ledger integration for private EVM chains, Zk EVM networks, and Tempo Zones. REM Edge deploys inside the customer's permitted boundary and ingests only the authorised participant view, with provenance and visibility scope on every record.
---
## Case studies
### Intercompany reconciliation for a holding company (https://rem.money/case-studies/holding-company-reconciliation)
Reference architecture for multi-entity stablecoin settlement: continuous reconciliation across subsidiaries, wallets, providers, bank accounts, and internal ledgers on a private Tempo Zone, with entity-level privacy, parent-wide visibility, and scoped auditor access.
### Tokenised corporate bond: lifecycle to books and records (https://rem.money/case-studies/tokenized-corporate-bond)
Reference architecture for a fixed-coupon note on a private Tempo Zone. REM turns primary allocation, coupons, secondary transfers, and redemption into canonical lifecycle events and keeps the register and the issuer's books and records reconciled. Custody, signing, and issuance stay with the client and its licensed providers.
---
## Blog posts
### Inside Arc Privacy Sector
URL: https://rem.money/blog/inside-arc-privacy-sector
Published: 2026-06-19
Author: Abhi
Category: Industry
Circle's Arc privacy whitepaper proposes confidentiality with a governed access model — one chain, synchronous public and private execution, and EIP-712 authorized queries. Our notes on what it gets right, what's still open, and where it lands for institutional programmes.
On June 10, Arc published its privacy whitepaper, formally titled *Arc Privacy Sector*. It's a proposed design, not shipped code.
We've been building on Arc since testnet, alongside Tempo, Ethereum, Canton, Avalanche, and Base. Privacy is the question every serious institutional programme we run hits, usually within the first two meetings. So when Circle ships a whitepaper this material on a chain we already build on, it earns a careful read.
These are our notes.
## The problem the paper starts from
Most blockchains expose transaction data and contract state by default. That's the property that lets a stranger trust a ledger without trusting the operator. It's also the property that breaks the moment a workflow looks like real finance.
The paper's framing is direct. A payroll contract can't broadcast compensation, identities, and schedules to the market. A lending protocol can't ask borrowers to publish collateral and liquidation risk in real time. An issuer needs to enforce transfer rules and vesting without making its cap table globally readable. Intraday repo is more sensitive still: collateral, counterparties, and funding needs can reveal a firm's liquidity position before a trade settles.
This matches what we see on the buyer side. The rails work. Settlement is fast, fees are low, the compliance hooks exist. Then a treasury or risk lead asks whether competitors can see payroll, vendor flows, or position changes on a block explorer, and the programme stalls until there's a credible answer.
The unlock the paper argues for isn't privacy. It's confidentiality with an access model. Regulated finance can't use a black box any more than it can use a glass box. Compliance teams, auditors, and sometimes regulators need defined visibility. The public may not. Privacy with governed visibility, not anonymity.
## Why earlier privacy designs didn't take
The whitepaper's central claim, one line in the intro: "The primary obstacle is no longer pure cryptography."
That's a sharper statement than it sounds. The industry has had privacy primitives for years. The reason none of them became the default for onchain finance is that they each change too much about how you build.
Zero-knowledge proofs fit narrow flows better than arbitrary composable contracts. Build a confidential transfer with them, fine. Build a programmable lending protocol with full composability and identity-gated visibility, much harder. FHE runs orders of magnitude too slow for general transaction processing. MPC makes you reason about state in secret shares instead of ordinary contracts. Enclave-based systems get closest to ordinary execution but typically live as standalone chains, which turns private state into somewhere you bridge into and out of.
Each path solves cryptography. None of them solved adoption.
We've evaluated most of these for clients at this point. The verdict tracks the paper's argument: the gating factor on every programme has been how much the team has to bend their existing stack to fit the privacy primitive. Arc's bet is that the right move is to keep the developer environment ordinary. Keep the EVM. Keep Solidity close to untouched. Keep public and private execution under one consensus process. Let builders pick where confidentiality belongs in their application instead of rebuilding the whole app around a separate privacy universe.
That's the right framing.
## The proposed design: one chain, two execution environments
Public activity runs on Arc in the clear, on the normal EVM. Private activity runs in a private EVM inside hardware enclaves. You sign with a normal EVM key, encrypt the payload to the network's public key, and submit through an Arc precompile.
The public chain sees a precompile call and opaque ciphertext. The enclave decrypts, executes, and commits an encrypted private state root into the same Arc block. Both halves finalize together, in the same consensus round.
One chain, two execution environments. Public and private transactions are decrypted, executed, and committed inside a single Arc block — the same consensus round — so a private contract and a public one can coordinate without a separate chain or a delayed bridge.
The paper calls this synchronous execution and treats it as the core distinction from every prior privacy design. Most existing privacy systems are standalone chains or asynchronous L2s, which means a private contract has to bridge back to the public world and wait. Here, a private contract and a public one coordinate inside a single block. No separate chain, no delayed bridge.
That synchronous property is what actually changes the design space. A confidential lending position can read a public oracle and clear against a public DEX in the same transaction. A private payroll batch can settle against a public stablecoin balance atomically. Privacy stops being a side room.
## Crossing the boundary
Value moves through a controlled shield/unshield bridge. To go private, you shield: the token on the Arc side is locked or burned and a private mirror is minted on the private side. To go public, you unshield: the private mirror burns and the public side releases. Supply stays in parity, so a wrapped private balance can't mint tokens that don't exist on Arc.
The supply-parity invariant being enforced at the protocol level (rather than via off-chain attestation) is the kind of design choice that makes regulator conversations shorter. Inflows and outflows are observable on the public side even when the private state isn't. From the integration work we do, this matters a lot: it means our reserve attestation and travel-rule pipelines don't have to treat the private side as a separate balance sheet.
## The query model
This is the section of the paper that should matter most to anyone building for institutions. There are three ways to read private state.
An unauthenticated plaintext query, for things that are safe to read in the clear. An unauthenticated encrypted query that protects the request on the wire while the caller stays anonymous. And an authorized query, where the caller proves identity through an EIP-712 signature and the contract decides what to return based on who's asking.
The authorized query is the real institutional primitive. It isn't anonymity. It's access control over private state, expressed inside contract logic. A compliance team gets the view it needs, an auditor gets the access scoped to an audit, a counterparty sees the slice relevant to its trade, everyone else gets nothing.
This is exactly the shape every regulated client we work with describes when we ask what they actually need. Not privacy from regulators. Privacy from the market, with scoped visibility for compliance, auditors, and counterparties. Most privacy systems put privacy in the protocol and then bolt disclosure on as a sidecar. Here, governed visibility is a first-class read primitive in the contract. The disclosure logic lives with the asset.
For the programmes we run, that's the difference between "we built a privacy chain and added a disclosure tool" and "the privacy primitive itself supports identity-gated reads." The second one is what you can actually run a programme on.
The query model and the trust model. Governed visibility is a first-class read primitive — identity-gated reads decided in contract logic — and the decryption key is never held by any single party: split across validators and reconstructed only inside an attested enclave at Arc's BFT safety threshold.
## The trust model
Most enclave-based privacy systems run into the same question from a serious risk team. Who holds the keys.
Arc's answer: nobody, in the singular sense. The master secret is split across validators and only reconstructed inside an attested enclave, at a threshold tied to Arc's BFT safety bound. A colluding minority can't decrypt private state. Wire encryption is hybrid post-quantum, classical paired with post-quantum primitives, to blunt harvest-now-decrypt-later attacks.
This is a reasonable model on paper. The questions that decide whether it holds up in production are familiar enclave-system questions: how attestation chains rotate, how enclave compromises are handled, what happens on validator exits, how key shares are re-shared when the validator set changes. None of these are unsolved problems, but they're the ones where details matter, and they're where any institution's risk team will spend time. Ours included.
The post-quantum hybrid choice is worth calling out separately. It's the right call for a chain selling to regulated counterparties with multi-decade audit horizons. Confidential financial data encrypted today will still be sensitive in twenty years. Building post-quantum into the wire format from the start is cheaper than retrofitting it later, and it gets us past one of the questions that's been coming up in every serious institutional review we've done this year.
## What the benchmark actually says
The paper publishes a three-node enclave benchmark. Public throughput holds near 2,800 TPS, private transfers land around 1,070. The two paths run side by side without one starving the other.
This isn't a load test. It's an architectural signal. The point isn't the headline number, it's that the public chain doesn't slow down when private execution is active. Privacy isn't free here, but it doesn't collapse public throughput either.
For the institutional workloads we build for (payroll, settlement, repo) what matters isn't peak TPS, it's consistent latency under contention, especially on the authorized-query path where compliance reads will queue up. That's a number that only shows up under real traffic. We'll be among the first to test it.
## What it unlocks
The paper reaches for four workloads where this architecture is the unlock, not just an improvement. These map almost one-to-one onto the programmes our clients are quietly trying to ship.
**Payroll.** Compensation logic runs onchain, but amounts, recipients, and schedules stay sealed. Audit access is preserved. The reason this hasn't moved onchain at scale isn't payment rails. It's that no finance team will publish salaries to a public ledger. We've built payroll workflows for clients with employee allowlists, batch scheduling, and FATF travel-rule data attached per payment; Arc Privacy Sector gives the same property to teams that want a single public chain underneath.
**Lending.** Borrower collateral and liquidation risk stay hidden through the position's lifecycle, not just at origination. Every public-chain credit desk is currently a target map for anyone running strategies against it. Synchronous execution matters here because lending touches oracle reads, liquidations, and DEX paths that need to stay composable across the privacy boundary.
**Asset issuance.** Transfer rules, vesting, holder activity managed without publishing the cap table. Issuers enforce policy without making it globally readable. This is the workflow that moves tokenised credit and equity from interesting pilots to production scale, and it's most of what we build on the RWA side today.
**Intraday repo.** The sharpest example in the paper, and probably the workflow most likely to drive serious adoption. Collateral, counterparties, and funding needs reveal a firm's liquidity position before a trade settles. Programmable repo with confidential terms and identity-gated visibility is the kind of primitive that brings real treasury flows onchain. Public-chain repo isn't a near-term product. Confidential repo with governed disclosure could be.
The common thread across all four is that the workflows aren't gated on settlement speed or fees. They're gated on whether the rail can keep sensitive state confidential while still letting compliance see what it needs to see. That's the gap Arc Privacy Sector is built to close, and the gap we spend most of our time on.
## What's still open
It's a proposed design. The honest reading is that the architecture is well-argued and the primitives line up with what regulated programmes need, but the production questions are still ahead.
**Enclave attestation and operational hardening.** Enclaves have a history of side-channel issues. The whole design rests on attestation being trustworthy in practice, not just in the threat model.
**Throughput under realistic contention**, especially on the authorized-query path. The bench number is clean. Production traffic doesn't look like the bench.
**Compliance composability.** How identity-gated reads interact with travel-rule data, issuer policies, and existing KYT pipelines decides how cleanly this slots into existing institutional compliance stacks. Our own compliance stack is built to be portable across chains, so this is one of the first things we'll be testing on Arc.
**Mainnet timing.** Institutional buyers don't commit programmes on roadmap decks. The whitepaper is a strong design document. The shape of the rollout decides whether it actually gets used.
## Where this sits in the stack
Arc Privacy Sector is a more thoughtful design than most onchain privacy work to date. The synchronous public/private execution model is a real architectural contribution. The EIP-712 authorized query is the right primitive for institutional disclosure. The threshold-key trust model is defensible. The post-quantum hybrid choice is correct.
It's also still a paper. The interesting work starts when this lands on mainnet and real workloads hit it.
For the institutions we work with, this is the most credible institutional-privacy design currently in play on a public chain. We don't think any single chain wins the institutional privacy story outright. The serious programmes we build will use a combination of rails picked per workflow, with a common compliance and clearing layer on top. Arc Privacy Sector, if it lands as written, moves Arc into the small group of public chains we'd actually recommend for regulated, privacy-sensitive flows. That changes the shortlist.
If you're building a stablecoin or tokenisation programme and trying to figure out where Arc fits, what to ship on it, and how it slots into the rest of your stack, drop us a line at [hi@rem.money](mailto:hi@rem.money) or [book a call](https://calendar.app.google/1oJJb3QyFQ61Pras7). We've already mapped most of the trade-offs.
## Sources
Tim Baker, ["Built for the Money That Was Never Going to Move in Public"](https://community.arc.io/public/blogs/arcs-privacy-roadmap-built-for-the-money-that-was-never-going-to-move-in-public-2026-06-10), Arc, June 10, 2026.
---
### Exploring Zones — Part III
URL: https://rem.money/blog/exploring-zones-part-3
Published: 2026-05-26
Author: Abhi
Category: Engineering
A deep dive into the Tempo Zones architecture: how the privacy model works, where the trust assumptions sit, and how REM is integrating Zones into client settlement infrastructure.
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.
Alice sends money to Bob privately through a Zone. Funds bridge onto Tempo, deposit through the ZonePortal, transfer inside the Zone, then withdraw and off-ramp on the other side. Internal addresses stay hidden the whole way.
## 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:
- [Tokenised corporate bond on a private Zone](https://rem.money/case-studies/tokenized-corporate-bond)
- [Intercompany reconciliation for a holding company](https://rem.money/case-studies/holding-company-reconciliation)
## 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](mailto:hi@rem.money) or [book a call](https://calendar.app.google/1oJJb3QyFQ61Pras7). 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](https://github.com/tempoxyz/zones). Protocol spec at [docs.tempo.xyz/protocol/zones](https://docs.tempo.xyz/protocol/zones).
---
### Exploring Zones — Part II
URL: https://rem.money/blog/exploring-zones-part-2
Published: 2026-05-20
Author: Abhi
Category: Engineering
Your stablecoin payments are public. Settlement volumes, payroll, treasury moves, all readable by anyone with a block explorer. How Tempo Zones close that gap, and the custom Zones REM is building for banks, PSPs, and fintechs.
Every enterprise that has looked seriously at stablecoin settlement has hit the same wall. Tempo gives you sub-second finality, sub-cent fees, and protocol-level compliance controls. All good. Then someone in the room asks: "Can our competitors see how much we're settling with each merchant?"
On any public blockchain, the answer is yes. Settlement volumes, payroll amounts, treasury movements between entities, counterparty relationships. All of it sits on a public ledger that anyone with an internet connection can read.
This is why most institutional stablecoin projects stall. Not because the rails don't work. Because the rails are transparent.
Tempo Zones fix this. REM builds custom Zones for institutions that need private stablecoin settlement deployed to their specific requirements.
## What Zones give you
A Zone is a private execution environment: an EVM-compatible chain running parallel to Tempo's mainnet where all transactions are invisible to outsiders. Funds enter and leave through a smart contract on mainnet. Inside, only the Zone operator (usually you, or a party you trust) can see activity.
The operator sees everything inside the Zone, so audit trails, regulatory reporting, and transaction monitoring work the way your compliance team expects. Nobody outside the Zone can see transaction details, counterparties, or volumes. Same idea as part 1: privacy from the market, visibility for compliance.
Unlike private permissioned ledgers that isolate your assets, Zones stay connected to Tempo mainnet. Users can withdraw, swap on Tempo's native DEX, and redeposit without exposing internal addresses. No fragmented pools. No custom integrations to reach the broader market.
Issuer-defined policies under TIP-403 (allowlists, blocklists, freeze capabilities) propagate automatically across every Zone. When a stablecoin issuer updates a blocklist, every Zone enforces the change immediately. Protocol-enforced, not manual.
## Real institutions are already building on Zones
Howard Hughes Holdings (NYSE: HHH) is building onchain financial verification on Tempo. As a public company, their construction budgets, lease terms, and development economics are commercially sensitive. They're recording general ledger transactions on Tempo for real-time reconciliation and audit, shifting from month-end batch processing to continuous verification. Zones keep the financial data private while giving auditors full access.
Coastal Financial Corporation (Nasdaq: CCB) is building cross-border stablecoin settlement corridors. They're a regulated sponsor bank powering fintech products through their CCBX division. Their approach: keep existing KYC/AML screening in place, replace only the settlement layer. Stablecoins on Tempo instead of correspondent banking chains. Zones keep settlement volumes visible only to counterparties and regulators.
Both followed the same principle: don't rebuild the compliance stack. Replace the settlement rail underneath it.
## Five use cases we're building around
### Cross-border settlement corridors
The one we think about most. A bank in one country needs to settle with a bank or PSP in another. Today that means correspondent banking: multiple intermediaries, multi-day settlement, pre-funded accounts, fees at every hop.
With a custom Zone, both institutions transact inside a shared private environment. The sending bank converts to stablecoins, transfers to the receiver inside the Zone, and the receiver redeems to local fiat. Minutes instead of days, and settlement volumes stay between the two parties.
On our side, we configure these Zones with KYC allowlists matching the onboarded counterparties and jurisdiction-specific transaction policies, then plug them into our multilateral netting engine. Obligations get netted before final transfer. Less capital in transit, fewer transactions on the wire.
### Merchant settlement
PSPs settling with hundreds of merchants leak commercially sensitive data on public chains. Per-merchant volumes, average ticket sizes, seasonal patterns. A restaurant chain doesn't want competitors seeing daily revenue. A SaaS company doesn't want investors tracking settlement before quarterly reports.
We build Zones where each merchant sees their own settlement data, the PSP sees everything as operator, and the public sees nothing. Automated settlement scheduling, structured memo fields for ERP reconciliation, and netting across the full merchant book.
### Treasury operations
Corporations moving money between entities (intercompany transfers, liquidity rebalancing, subsidiary funding) reveal capital allocation strategy on public chains. For complex entity structures we build multi-Zone architectures: separate Zones for separate business units where needed, with liquidity flowing between them through mainnet. Intercompany settlements reduce to net positions rather than gross transfers.
### Payroll
Employee compensation is some of the most sensitive data a company handles. On a public chain, every payment amount is visible. We build payroll Zones with employee allowlists, scheduled batch payments, and multi-currency support for cross-border contractors. REM's compliance engine attaches FATF-compliant travel rule data to each payment for the relevant jurisdiction.
### Agentic payments
This one is early but it matters. AI agents making autonomous payments generate high-frequency patterns that reveal which services a company uses, how often, and at what cost. Inside a Zone, those patterns stay private. A lot of infrastructure for agent wallet with spend limits, service allowlists, and automated settlement between the agent's Zone and service providers is being built, all connected to x402 payment protocols and agentic payments SDK.
## How REM delivers custom Zones
We handle the full lifecycle. We scope your compliance requirements, counterparty structure, and operational workflow, then design a Zone (or multi-Zone) architecture that matches. We configure and launch it with your specific allowlists, transaction policies, token enablement, and operator setup.
Custom Zones plug into REM's clearing layer for multilateral netting, IVMS 101 compliance, and cross-border settlement orchestration. You can run the Zone yourself or have REM operate it under SLAs for liveness and throughput. Either model, we handle monitoring, failover, and ongoing configuration.
## What's next
Zones are on testnet now, with phased production deployments planned through Q2-Q3 2026. The protocol software is fully open-source. Conduit is supporting Zone launches, with more infrastructure providers expected.
If you're evaluating stablecoin infrastructure for payments, settlement, or treasury, and transaction privacy is a requirement, reach out at [hi@rem.money](mailto:hi@rem.money) or [book a call](https://calendar.app.google/1oJJb3QyFQ61Pras7) about what a custom Zone looks like for your use case.
---
### Exploring Zones — Part I
URL: https://rem.money/blog/exploring-zones-part-1
Published: 2026-05-13
Author: Abhi
Category: Engineering
Tempo Zones are the most boring breakthrough in stablecoin infrastructure. That's a compliment. An honest scorecard of every privacy approach we evaluated for our institutional clients, and why Zones won.
Crypto loves solving privacy with more cryptography. Zero-knowledge proofs. Fully homomorphic encryption. Multi-party computation. Impressive on a whiteboard, mostly unusable if you actually need to ship a payment product this quarter.
We build stablecoin settlement infrastructure for banks, PSPs, and fintechs. Our clients have one simple requirement: their transaction data cannot be public. So we sat down and evaluated everything on the market. Here's the honest scorecard.
## Pseudonymity is not privacy
Ethereum, Solana, every public L1 hands you a pseudonymous address instead of a name. That used to feel like enough. It isn't. Chainalysis, TRM Labs, and Elliptic have built entire businesses around linking wallets to identities. Once someone maps your treasury address, they can see every dollar you've moved and every counterparty you've settled with, going back to your first transaction. Retroactively. Permanently.
For an institution running payroll or settling with merchants, that's not a theoretical risk. It's a guarantee that your financial data becomes public eventually. Dead on arrival for regulated institutions.
## ZK privacy chains solve the wrong problem
The math is sound. The engineering isn't ready. ZK privacy systems need specialised wallets, force users to manage encrypted state, and create compliance gaps regulators won't tolerate. When a regulator asks for records, "the user holds the decryption key and we can't access it" is not an acceptable answer from a bank.
Some ZK architectures are working on selective disclosure through viewing keys and compliance proofs. The work is promising. It's also two to three years from being enterprise-deployable, and that's being generous.
## Private permissioned ledgers are islands
The Hyperledger and R3 Corda era tried this. Spin up your own private blockchain. Full privacy, full control. Also full isolation. Your assets are trapped. Want to swap USDC for EURC? Build your own liquidity pool. Want to settle with a counterparty on a different private chain? Custom integration every time. You end up with a network that does one thing for one set of counterparties and can't do anything else.
That's the approach that taught the industry a lesson the hard way: privacy without interoperability isn't worth much.
## Zones are the boring answer that works
Again, that's a compliment.
Zones took a different path. Instead of exotic cryptography or network isolation, the team built something that looks like the financial system institutions already trust, but runs on stablecoin rails.
A Zone is a private chain running parallel to Tempo's public mainnet. Transactions inside are invisible to the outside world. Tokens stay liquid through mainnet's shared pools. Compliance controls (allowlists, blocklists, freeze) propagate automatically from the token issuer across every Zone. Standard wallets work. No specialised tooling. Sub-second finality.
The Zone operator, usually the institution itself, can see everything inside. That's the part that makes cryptography purists uncomfortable. It's also the part that makes CFOs relax. They don't need privacy from their own compliance team. They need privacy from competitors and from anyone else who shouldn't be watching their cash flows.
The part that actually matters, though: liquidity isn't trapped. Any user inside a Zone can withdraw to mainnet, swap on Tempo's native DEX, and deposit into another Zone. No per-Zone pools, no wrapped tokens, no bridges. Private permissioned ledgers never solved this. They gave you privacy by cutting you off from everything else. Zones don't.
## The honest limitations
There are no in-Zone swaps; you round-trip through mainnet. No direct Zone-to-Zone transfers either, same pattern. One operator per Zone, so if the operator goes down, transactions stall (funds stay safe on L1). And the operator sees everything inside. This is a trusted model, not a trustless one.
Those are real constraints. For institutions whose threat model is "the public can't see our settlement data" rather than "nobody can see our settlement data, not even our own infrastructure," they're the right tradeoffs. For the cypherpunk ideal of zero trust, they're not. We're fine with that.
## What REM does with all of this
We build custom Zones for clients.
Your counterparties, your jurisdictions, your compliance framework, your operational workflow. We deploy a Zone configured for exactly that. Then we wire it into multilateral netting to compress settlement volume, IVMS 101 travel rule data for cross-border payments, and settlement orchestration between institutions.
You can run the Zone yourself or have REM operate it. Either way, you get private stablecoin settlement with institutional-grade compliance, without building the infrastructure from scratch.
Zones handle privacy. REM handles everything between you and your counterparties.
Reach out at [hi@rem.money](mailto:hi@rem.money) or [book a call](https://calendar.app.google/1oJJb3QyFQ61Pras7).
---
### Future of payments: a primer
URL: https://rem.money/blog/future-of-payments
Published: 2026-04-25
Author: Abhi
Category: Industry
Stablecoins finally behave like a real settlement asset, and AI agents are the new class of payer using them. What changes about identity, settlement, and velocity when both shifts land at once.
For most of the modern era, a payment system has had to answer three questions. Who is paying. Who is being paid. How do we know the money is good. The plumbing that grew up around those questions (cards, correspondent banking, ACH, SWIFT) assumed a particular shape of payer: usually a person or a long-lived business, with a billing address, a credit history, and the patience to wait two days for a wire to clear.
Two things are breaking that shape at once. Stablecoins finally have the volume and the regulatory cover to behave as a settlement asset, not a speculation. At the same time, AI agents are showing up as a new class of payer: short-lived, programmatic, indifferent to the relationship machinery the rails were built around. Either shift would force a rewrite on its own. Together they change what a payment rail is even for.
## Stablecoins as a settlement asset
Source: Visa Onchain Analytics (Visa × Allium adjusted methodology). 2024 figure is full calendar year; 2025 reflects the trailing twelve months. 2023 derived from reported ~2× YoY growth into 2024.
The stablecoin pitch used to be about access. Move dollars on the weekend. Route around correspondent friction. Get an FX rate that didn't bake in three intermediaries. The pitch in 2026 is settlement. Global settlement volume roughly doubled year over year. MAS and HKMA both have frameworks that license stablecoin issuers as payment institutions. Tempo, Solana, and Base are running institutional flow, not retail speculation.
Settlement venues now carrying institutional flow.
## The technology caught up
A decade ago Bitcoin cleared seven transactions per second and Ethereum cleared fifteen. A wire transfer was faster than a stablecoin transfer in any meaningful payment context. A few things changed since then:
- **Throughput.** Modern payment-grade chains run into the thousands of transactions per second sustained, with peaks an order of magnitude higher. Tempo is built for institutional flow. L2s like Base inherit Ethereum's trust assumptions while clearing at L2 economics.
- **Finality.** Confirmation windows that ran ten minutes on Bitcoin or a minute on Ethereum dropped to sub-second on the chains payment institutions are actually using.
- **Cost.** Per-transfer fees fell by three orders of magnitude. The marginal cost of a stablecoin transfer is now well below the marginal cost of an ACH debit or a card authorisation.
The throughput envelope for stablecoin settlement now sits above the throughput needs of most card networks. Capacity is no longer the bottleneck.
## The regulators caught up
The 2010s were a decade of prohibition. The 2020s are a decade of licensing. The frameworks now in force:
- **MiCA (EU).** Regulated stablecoin regime fully in force across the European Union since 2024. E-money tokens and asset-referenced tokens both have a license path.
- **GENIUS Act (US).** Federal framework for payment stablecoin issuers, signed in 2025. Issuers operate with bank-like oversight and 1:1 reserve requirements.
- **MAS and HKMA.** Singapore and Hong Kong license stablecoin issuers as payment institutions. The two jurisdictions where most APAC institutional flow originates are now both regulated rails.
What follows from licensing is that the controls a payment institution actually needs (issuer attestations, regulated reserves, KYT, travel rule) live inside the rail rather than being bolted on by a vendor afterwards. Once a settlement asset clears in seconds, costs a fraction of a cent, and satisfies the controls a compliance officer can actually sign off on, the question of which rail the agentic stack runs on stops being interesting.
## Agents are a new class of payer
A card network was designed for someone with a name, a billing address, and a thirty-day cycle. An agent has none of that. It's spun up to do a task, calls a few services, and disappears thirty seconds later. There's no credit history behind it, just a budget. The merchant isn't a relationship; it's a quote on a resource page.
This is in production already. Protocols like x402 and MPP turn HTTP 402 into a working handshake: the agent calls a resource, the server returns a quote, the agent settles, the resource clears. The unit of value is the call, not the account. The whole exchange might last 400 milliseconds.
The agentic payment primitives in production: x402, MPP, and MCP.
The grain breaks the existing rails. A credit card charge for $0.001 is uneconomic before the network fee. A bank wire is uneconomic by three orders of magnitude. Agentic commerce only closes on rails where the marginal cost of a transfer is below the marginal value of the call being paid for. That's never been true of fiat infrastructure. The stablecoin rail just described is the first one where it can be.
## Velocity changes the unit economics
T+2 used to be a settlement window. It was also a working capital problem, a reconciliation problem, and a financing line on the balance sheet. Compressing settlement from days to seconds does more than make a transaction feel fast. It removes whole categories of cost from the business sitting on top of the rail.
A payment institution that settles internally on a stablecoin rail doesn't need to pre-fund counterparty accounts to handle weekend traffic. A merchant clearing at T+0 has no reason to keep a factoring relationship just to bridge cash flow. The treasury team can stop modelling settlement timing as a variable independent of volume.
For agents the effect is sharper. An agent with a dollar of budget making a hundred calls can't afford to wait on any one of them. Without T+0 the workload simply doesn't exist.
## What this forces businesses to rebuild
A few architectural decisions stop being optional once an agent shows up at the door:
- **Identity at the transaction, not the account.** A payer that exists for thirty seconds will not fit a row in a customer table. Identity becomes a property of the transaction (wallet, issuer, admission contract), and the KYC stack has to learn to resolve at that layer.
- **Pricing on the resource.** A 402 response with a quote replaces the API-key handshake. Without it the agent has no way to know what to pay. With it, the resource itself is the price list.
- **Compliance inside the rail.** Bolted-on KYT vendors lag by hours and break under agentic call volume. The decision has to resolve before settlement, not after.
- **A treasury that thinks in stablecoins.** Reserves, hedging, reconciliation: all of it changes shape when the settlement asset is a stablecoin. The finance team has to learn the new instrument the way it learned cards in the 2000s.
The fintechs we work with hit all four of these in their first quarter on the rail. Usually in that order.
## What 2026 to 2028 looks like
The next two years won't be about whether stablecoins are a real payment rail. That question is closed. They'll be about which institutions move first, and whether the rails those institutions pick are compliance-native or assembled out of generic onchain SDKs with a vendor stack glued on top.
The first movers tend to find the same things in roughly the same order. Engineering cost is dominated by compliance, not by chain integration. The country-by-country corridor playbook of the last decade doesn't survive contact with rails that are licensed at the rail layer. The reconciliation team that used to need a quarter to close the books needs a week, and most of them are needed somewhere else.
The shift won't feel dramatic from inside any single company. A treasury starts settling a corridor in stablecoins. The pricing on a previously API-key-gated endpoint quietly switches to per-call. A compliance officer signs off on a control that resolves before the chain even accepts the payment. None of those moments looks revolutionary on its own. The cumulative effect is.
---
