When we launched Merces in November, we called it a confidential stablecoin payments demo. We had a paper coming, a dashboard running on Base testnet, and a small bet: that businesses would not move serious value onto public blockchains until the privacy story was solved.
Six months on, the bet looks right, and the thing we built has turned into something larger than we expected.
This is a note on what changed, what we learned, and where we are going next.
What Merces Actually Became
We started thinking about Merces as a product. A confidential payments app, a demo, a thing customers would integrate to hide transfer amounts.
Within weeks of the November launch, the feedback was unambiguous: hiding amounts was interesting, but not enough. For any institution operating onchain, the transaction graph itself is sensitive infrastructure. Knowing who transacted with whom, even without amounts, exposes business relationships, payroll structures, supplier dependencies, and competitive position. We shipped Merces II in March in response, adding fully private mode (sender, receiver, and amount hidden) alongside the original confidential mode. That was the moment Merces stopped being one capability and started being a platform.
Today, what we have is the backbone of our entire finance solution.
The published protocol (IACR ePrint 2026/850; technical walkthrough) describes a fairly general construction: balances are stored as commitments onchain, secret-shared across an MPC network, with state transitions verified by collaborative SNARKs. The paper formalizes it for confidential token transfers, but the same construction extends naturally to anything you can do with private state. Transfers were the first surface. They were not the only one.
This realization has shaped how we talk about Merces now. We do not have a payments product and a separate yield product and a separate x402 product. We have one solution, TACEO Merces, with capabilities that sit on top of the same protocol. The cryptography underneath is shared. What changes between capabilities is the function being computed on the private state, not the privacy guarantees, not the integrity guarantees, and not the integration model.
The distinction matters more than it sounds. It means a customer who integrates Merces for private payments gets x402, and soon yield, without re-integrating, and without changing their trust assumptions. The MPC network, the operator-blind property, and the onchain integrity guarantees carry across every capability. The published paper formalizes the core construction; each new capability is a new circuit that we build inside the same architectural framework. That gives us a single product story to tell, which is something we did not have when we started.
Where Things Stand Today
A snapshot of the offerings menu as it looks at six months:
| Capability | What it does | Status |
|---|---|---|
| Private Payments | Confidential and fully private transfers of any ERC-20. Deposit, transfer privately, withdraw. | Live on Base, Arc, Plasma testnets |
| Confidential x402 | Drop-in privacy for the x402 HTTP payment standard. Hides amounts on per-request agent payments. | Live on Base Sepolia |
| Authorized audit disclosure | An authorized auditor can decrypt a defined set of transactions, or activity linked to a specific wallet, without exposing anything else. | Live on Plasma testnet |
| Private Earn | Yield on private balances. Productive private accounts. | Shipping shortly |
| KYC and policy enforcement | Sanctions, KYC, and other policy attestations verified onchain before a Merces transfer can execute. Built with partners. | In development |
| Network dashboard | Live operator and network metrics, public. | In development |
| Private DeFi (swaps, vaults, dark pools) | Access lending and trading venues from a private account. | On the roadmap |
| Confidential settlement for stablecoin issuers | The flow the whole thing started with. | On the roadmap |
The numbers from the live deployments:
- 300+ TPS sustained, including proof generation
- Several million transactions processed end-to-end on Arc and Base testnets
- Sub-cent cost per transaction on L2
- Full UC security proof in the paper. Integrity holds unconditionally, even if the entire MPC network is compromised. The worst an adversary can do is halt the system, not steal from it.
What We Learned
A few things we knew going in, a few we did not.
A toolkit doesn’t solve the problem. We started the year talking to a lot of teams about cryptographic primitives. We assumed buyers would want the building blocks and assemble what they needed. They do not. Teams building payment products have payments roadmaps, not protocol roadmaps. The interesting question for them is not “can I compose this from MPC and ZK?” It is more along the lines of “what is the API, and how long until I can ship?” The win is shipping a complete solution that integrates by API, where their end user never sees TACEO at all. That is a different product than a developer toolkit, and it is the one we have leaned into.
I will admit we had to be told this more than once. Merces I in November was, in hindsight, closer to a primitive than a product. Merces II added the surface area that customers were actually asking for. The shift from “interesting demo” to “thing you could integrate” took about three months and a lot of patient feedback from people who knew exactly what they wanted and were willing to tell us.
Compliance is not the enemy of privacy. It is the customer. The early instinct in crypto privacy was adversarial: privacy against the regulator, against the bank. Almost none of the institutions we have talked to in six months want that. They want privacy for their institution: protect customer data from competitors, protect pricing from the public, protect strategy from onchain analytics, but stay verifiable to the auditor and the regulator.
What six months has clarified is that “compliance” here is not one capability but two, and a complete institutional surface needs both. The first is post-transaction disclosure: an authorized auditor decrypts a defined set of transactions, or activity linked to a specific wallet, without seeing anything else. That is shipped. The second is pre-transaction policy enforcement: sanctions, KYC, or other attestations verified onchain before a transfer can execute. That work is in flight with partners. Most other privacy systems ship one of these and not the other. Both belong in the same surface, and the disclosure path was part of our protocol design from the start, not bolted on as a separate trust assumption.
The trust model matters more than the technology. Most “private” payment systems on public chains today are not actually private from the system itself. A typical architecture has a single orchestrator (a permissioned rollup operator, a custodial server, an FHE service) that holds the keys, decrypts the data, or simply sees the plaintext as it processes transactions. The privacy is real for outside observers, but the operator sees everything, and customers are asked to trust that the operator does not leak, does not get breached, does not get subpoenaed, and does not eventually end up adjacent to a competitor. Hardware enclave approaches push the trust to a different place but do not remove it. Merces is operator-blind by construction: no single party ever sees plaintext, not the contract owner, not any one MPC operator, not us. Data is secret-shared across independent operators; computation runs on the shares. Integrity is unconditional (no party, not even the full MPC network in collusion, can forge a state transition or move funds without a valid user signature); privacy holds under a non-collusion threshold among the operators. That is a stronger and more honest statement than most privacy systems can make, and it is the part institutional buyers spend the longest time on.
The platform is real. This was the surprise. The same cryptographic stack underneath Merces also sits underneath the privacy layer for World ID, about 18 million people across 160 countries. We had always pitched this as a platform play internally. Six months of shipping across finance and identity has made it concrete in a way it was not before. Different verticals, same primitives. That is the architecture we will keep building on.
A Pattern From the Conversations
One observation worth sharing, because we keep encountering it.
A consistent pattern among institutions experimenting with onchain finance today: they avoid the privacy problem by isolating it. One wallet per customer. One contract per asset. Off-chain settlement for anything sensitive. These workarounds buy partial confidentiality, and they work until the moment two of those institutions need to transact with each other, at which point the privacy boundary collapses and the entire workflow ends up back on a public ledger.
Most teams know this. They are working around it because they do not see a better option. The better option is the thing we are building: a shared private account layer that does not collapse the moment counterparties interact. That is the conversation we keep having, and it is the one that has shaped the six months of work behind this post.
Where We Are Going
The next few months are mostly about turning the things in the “in development” row into things in the “live” row.
Private Earn is the closest. The construction is straightforward once you have the protocol: extend the private account so balances can sit in a yield-generating position without the position itself becoming visible to onchain analytics. It’s coming soon.
Pre-transaction policy enforcement is the other near-term one. We are working with partners on per-transaction attestations: a sanctions check, a KYC status, a jurisdictional rule, verified onchain before a Merces transfer can execute. This completes the compliance surface alongside the audit disclosure path that is already running.
Beyond that, the roadmap is private DeFi (swaps, vaults, dark pools) and the original use case that started this whole project: confidential settlement for stablecoin issuers, payroll, treasury, B2B. The protocol generalizes to all of it. The work now is engineering, rather than invention.
The Larger Thesis
Six months in, this is what we believe.
Every financial institution moving onto blockchain rails is going to need a private account layer, the same way they already need custody, compliance, and settlement infrastructure. Most of them will not build it themselves. They will integrate it.
That layer is what we are building. Merces is the protocol underneath. TACEO Merces is the solution on top. The TACEO Network runs it, alongside the identity workloads that prove the architecture generalizes.
Six months ago this was a demo. Today it is a paper, a protocol, a solution, several live capabilities, and a set of active design partnership conversations across payments, treasury, and stablecoin infrastructure. The interesting work is still ahead.
If you are building a payment product, a stablecoin platform, a treasury workflow, or anything that needs private state on public rails, we want to talk to you.
- Try the demo: merces.taceo.io
- Read the paper: IACR ePrint 2026/850
- Get in touch.
