solutions/x402 placement

.vscode/settings.json

@@ -0,0 +1,2 @@
+{
+}

docs/finance-solutions/compliance/introduction.mdx

@@ -0,0 +1,114 @@
+---
+title: Introduction
+sidebar_label: Compliance
+---
+
+# Privacy-Preserving Compliance
+
+Compliance on Merces is a set of primitives that let regulated entities enforce KYC, AML, sanctions
+screening, and Travel Rule obligations **without exposing plaintext user data**, not to the
+application, not to a third-party screening engine, and not to TACEO. Compliance is built into the
+payment flow at the protocol layer, not bolted on as a separate surveillance system.
+
+:::tip Compliance is the wedge, not the tax
+Private payments cannot scale in regulated jurisdictions without compliance. The standard answer
+(run KYC and monitoring on plaintext, ship PII to third-party screening engines, and log everything)
+is fundamentally incompatible with privacy. Privacy-preserving compliance is what makes private
+rails shippable in regulated markets at all.
+:::
+
+## The core mechanism: selective disclosure via MPC
+
+By default, every Merces transaction is encrypted. The TACEO Network maintains the transaction
+graph in encrypted form; only the parties involved in a transfer see its full details. No
+plaintext sits anywhere in the system.
+
+When an authorized party (a regulator, compliance team, or other entity with reveal rights)
+submits a decryption request for a specific account, the MPC network nodes **jointly approve and
+perform the decryption**. The result is the transaction history for that account, returned in
+plaintext. Decryption requests are scoped: they expose the selected data and nothing else.
+
+This same pattern underlies every Merces compliance primitive. An application or policy authority
+queries the TACEO Network about a user, and the network returns a verifiable answer without
+disclosing the underlying data. Sanctions screens, allowlist checks, and AML audits all share
+this shape.
+
+ZK-only approaches give you selective disclosure but struggle with persistent identity state,
+auditability, and lawful disclosure paths. MPC adds the missing pieces: stateful attestations,
+multi-party authorization for reveals, and the ability to enforce policies that depend on data the
+user themselves doesn't hold.
+
+:::note Public testnet vs. production
+On the [public Plasma testnet reference app](https://merces.taceo.io/compliance), anyone can try the
+decryption flow. In production deployments, access is restricted to explicitly authorized
+entities by policy and contract configuration.
+:::
+
+## Compliance primitives
+
+| Primitive | What it does | Status |
+|---|---|---|
+| **Selective disclosure (decryption requests)** | Authorized parties submit decryption requests for a specific account. MPC nodes jointly approve and decrypt, returning that account's transaction history in plaintext. Same flow used for AML audits and lawful disclosure. | Live on Plasma testnet ([compliance dashboard](https://merces.taceo.io/compliance)) |
+| **Wallet registration and blocklist** | Wallets must be registered in the Merces contract before transacting. Optional KYC or policy checks can be enforced at registration. Registered wallets can later be restricted or added to a blocklist by the administrator, blocking transfers to or from those accounts. | Live on Plasma testnet |
+| **Programmable reveal rules** | Per-token or per-jurisdiction policies defining who can decrypt what, under which conditions | In active design |
+| **Proof-of-compliance bundles** | Composable attestations a user can present (e.g. "KYC'd by issuer X, not on list Y, under threshold Z") | In active design |
+| **MPKYC** | MPC-based KYC: licensed providers attest to a user once; downstream apps query the attestation without seeing the underlying PII | Design / proposal stage |
+| **Travel Rule selective disclosure** | VASP-to-VASP information exchange that satisfies FATF Travel Rule without putting counterparty data on a public ledger | Design / proposal stage |
+
+## TACEO doesn't replace KYC. It makes KYC privacy-preserving.
+
+The compliance decision still belongs to a licensed provider, a KYC vendor, a screening engine, a
+VASP's compliance team. What changes is **where the plaintext lives** and **who sees it**.
+
+In the standard model, every application that needs a compliance signal pulls the user's full
+identity profile, hands it to a third-party API, and stores the result in a database. Each new
+integration is another copy of the user's data and another surveillance vector.
+
+In the Merces model, the licensed provider attests to a property of the user **once**, into the
+TACEO Network. Downstream applications query the attestation and receive a verifiable yes/no, no
+data shared, no copies created, no per-integration breach surface.
+
+## The identity proof point
+
+The MPC architecture that powers Merces compliance is built on the same cryptographic foundation
+TACEO co-architected for [World](https://world.org/)'s iris-code system, deployed in production
+at global scale as a GDPR regulatory remediation for biometric data. The protocol underneath
+Merces compliance is the same kind of system, applied to financial flows.
+
+## Who it's for
+
+| Audience | How they use it |
+|---|---|
+| **Fintechs and stablecoin issuers integrating Merces** | Compliance is built into the payment flow they're already shipping |
+| **VASPs and regulated entities** | Satisfy AML, KYC, sanctions, and Travel Rule obligations on private rails without standing up surveillance infrastructure |
+| **Licensed KYC and screening providers** | Issue privacy-preserving attestations on top of existing diligence work, expanding their reach without expanding their data exposure |
+| **Compliance and policy teams** | Auditable, scoped lawful disclosure paths that don't require the application to hold plaintext |
+
+## Status
+
+Compliance primitives sit at mixed maturity:
+
+- **Selective disclosure** is live on Plasma testnet, exposed through the
+  [compliance dashboard at merces.taceo.io/compliance](https://merces.taceo.io/compliance). MPC
+  nodes jointly approve and perform the decryption when an authorized party submits a request.
+  AML audits run through this same flow.
+- **Wallet registration and blocklisting** are live on Plasma. Wallets must be registered in the
+  Merces contract before transacting; the administrator can restrict or blocklist registered
+  wallets. Optional KYC or policy checks can be wired in at the registration step.
+- **Programmable reveal rules and proof-of-compliance bundles** are in active design, shaped by
+  ongoing work with regulated partners.
+- **MPKYC and Travel Rule selective disclosure** are at design / proposal stage. The use cases
+  are defined; the implementations are being worked through.
+- **The cryptographic foundation TACEO co-architected** is in production at global scale via
+  World's iris-code deployment.
+
+The product framing, *privacy and compliance can coexist with no trade-off needed*, is the
+position we are taking publicly and shipping toward.
+
+## Going deeper
+
+| Goal | Start here |
+|---|---|
+| Try the compliance dashboard | [merces.taceo.io/compliance](https://merces.taceo.io/compliance) |
+| Understand the underlying transfer protocol | [How it works](/docs/finance-solutions/x402/how-it-works) |
+| Talk through a regulated deployment | [Email the team](mailto:hello@taceo.io) |

docs/finance-solutions/overview.mdx

@@ -0,0 +1,151 @@
+---
+title: Finance Solutions Overview
+description: Private onchain finance, powered by Merces
+---
+
+# Finance Solutions on the TACEO Network
+
+Public blockchains expose everything by default: balances, counterparties, amounts, transaction
+flows. That's a dealbreaker for real financial operations. TACEO's finance solutions let
+developers, institutions, and AI agents move value on the chains they already use without
+putting their business on a public ledger.
+
+Our finance offering is one privacy solution, **Merces**, with multiple features on top. Merces
+is TACEO's confidential token transfer protocol. It wraps existing ERC-20 tokens (such as USDC)
+into a private form. Balances are held as secret shares across the TACEO Network, state
+transitions are verified onchain via CoSNARKs, and no single party (including TACEO) sees what
+anyone holds or sends. Compliance primitives are built into the protocol, not bolted on top.
+
+:::tip What is Merces?
+Merces is an integrable privacy layer for the chain you already use. Two things set it apart:
+
+- **We come to you.** Merces deploys on the EVM chain you already use. No migration, no new asset.
+- **Solutions, not primitives.** A payment system you can plug into a stablecoin or fintech
+  product, not raw cryptographic building blocks you have to assemble.
+
+Canonical write-up: [core.taceo.io/articles/merces-onchain-finance](https://core.taceo.io/articles/merces-onchain-finance/).
+:::
+
+## What's available today
+
+Merces ships two privacy modes, selectable per transaction, plus compliance and integrations on top.
+
+| Capability | What it does | Status |
+|---|---|---|
+| **Confidential payments** | Hide amounts and balances. Sender and receiver visible. | Live on Arc and Base testnets. Reference Implementation: [merces-dashboard.taceo.io/arc](https://merces-dashboard.taceo.io/arc). |
+| **Fully private payments** | Hide amounts, balances, sender, and receiver. | Live on Plasma testnet. Reference App: [merces.taceo.io](https://merces.taceo.io). |
+| **Compliance dashboard** | Selective disclosure to authorized auditors. | Live on Plasma testnet alongside the private payments deployment. |
+| **Confidential x402** | HTTP-embedded confidential payments. | Live on Base testnet. |
+
+The confidential payments network has processed ~5M demo transactions across Arc and Base testnets, sustaining ~300 TPS with single-digit-cents gas per transfer on L2. Mainnet deployment is in progress.
+
+## Features
+
+<div style={{display: 'grid', gridTemplateColumns: 'repeat(auto-fit, minmax(300px, 1fr))', gap: '2rem', marginTop: '2rem'}}>
+
+<div className="service-card-success">
+
+### Private Payments
+
+Private ERC-20 transfers on the EVM chain you already use. Users get a private virtual account
+alongside their normal public wallet.
+
+**Best fit:**
+
+- Payroll, treasury, and B2B settlement that can't be public
+- Stablecoin issuers and fintechs offering confidential accounts
+- White-labeled privacy rails inside an existing product
+
+[Learn more →](/docs/finance-solutions/payments/introduction)
+
+</div>
+
+<div className="service-card-primary">
+
+### Confidential x402
+
+The HTTP 402 Payment Required protocol with hidden amounts. Drop-in privacy for x402 clients
+and servers, no application code changes.
+
+**Best fit:**
+
+- Paid APIs with dynamic or negotiated pricing
+- AI agents transacting across providers without leaking strategy
+- Per-customer deals you can't put on a public ledger
+
+[Learn more →](/docs/finance-solutions/x402/introduction)
+
+</div>
+
+<div className="service-card-warning">
+
+### Compliance
+
+Privacy-preserving KYC, AML, sanctions, and Travel Rule. Selective disclosure via MPC, not
+surveillance infrastructure.
+
+**Best fit:**
+
+- VASPs and regulated entities on private payment rails
+- Fintechs integrating Merces who need compliance in the flow
+- KYC providers issuing privacy-preserving attestations
+
+[Learn more →](/docs/finance-solutions/compliance/introduction)
+
+</div>
+
+</div>
+
+## Coming Soon
+
+<div style={{display: 'grid', gridTemplateColumns: 'repeat(auto-fit, minmax(300px, 1fr))', gap: '2rem', marginTop: '2rem'}}>
+
+<div className="service-card-muted">
+
+### Private Yield
+
+**In active development.**
+
+Compliant private yield on Ethereum. Earn on private balances without exposing positions,
+counterparties, or strategy. Designed for regulated deployment from day one.
+
+[Learn more →](/docs/finance-solutions/yield/introduction)
+
+</div>
+
+<div style={{
+  padding: '2rem',
+  border: '1px solid var(--ifm-color-emphasis-400)',
+  borderRadius: '12px',
+  backgroundColor: 'var(--ifm-color-emphasis-100)',
+  opacity: '0.8'
+}}>
+
+### Private DeFi
+
+**On the roadmap.**
+
+Confidential swaps, dark pools, and approvals. Brings the private-balance model to swap
+routers, intent flows, and DeFi composability, so traders and LPs aren't forced to broadcast
+strategy to the rest of the market.
+
+</div>
+
+</div>
+
+## Going deeper
+
+| Goal | Start here |
+|---|---|
+| Add private payments to your product | [Private Payments](/docs/finance-solutions/payments/introduction) |
+| Hide payment amounts on a paid API | [Confidential x402 Quickstart](/docs/finance-solutions/x402/quickstart) |
+| Understand the compliance story | [Compliance](/docs/finance-solutions/compliance/introduction) |
+| Read the protocol paper | [Escudero et al., IACR ePrint 2026/850](https://eprint.iacr.org/2026/850) |
+| Browse the source | [github.com/TaceoLabs](https://github.com/TaceoLabs) |
+
+---
+
+**Looking for a design partner slot?** We're working with a small group of stablecoin issuers,
+fintechs, and payment infrastructure teams shipping private rails to production.
+[Email the team](mailto:hello@taceo.io?subject=Merces%20design%20partner). General questions go
+in [Discord](https://taceo.io/discord).

docs/finance-solutions/payments/introduction.mdx

@@ -0,0 +1,123 @@
+---
+title: Introduction
+sidebar_label: Private Payments
+---
+
+# Private Payments
+
+Private Payments is the core capability of [Merces](https://core.taceo.io/articles/merces-onchain-finance/),
+TACEO's confidential token transfer protocol. It lets users send and receive ERC-20 tokens on a
+public EVM chain, with two privacy modes that callers select per transaction.
+
+The integration model is API/SDK: stablecoin issuers, fintechs, and payment infrastructure builders
+white-label Merces into their products. End users never see TACEO.
+
+:::tip Live infrastructure
+Merces is live across multiple testnets today.
+
+- **Confidential mode** on Arc and Base testnets. Reference Implementation: [merces-dashboard.taceo.io/arc](https://merces-dashboard.taceo.io/arc).
+- **Fully private mode and the compliance dashboard** on Plasma testnet. Referenece App: [merces.taceo.io](https://merces.taceo.io).
+
+The confidential network has processed ~5M demo transactions sustaining ~300 TPS, with single-digit-cents gas per transfer on L2.
+:::
+
+## The problem with public rails
+
+Public blockchains expose everything by default: balances, counterparties, amounts, transaction
+flows. For real financial operations this is a non-starter.
+
+- **Payroll** broadcasts every employee's salary to the world.
+- **Treasury** moves reveal cash position, runway, and operational tempo.
+- **B2B settlement** exposes customer relationships, deal sizes, and pricing structure.
+- **Consumer payments** turn every wallet into a public spending diary.
+
+Existing privacy approaches force a trade-off. Privacy-first L1s require migrating off the chain
+you've already chosen. Cryptographic toolkits hand you raw primitives and leave assembly to you.
+Neither is a path most issuers, fintechs, or institutions can take to production.
+
+## Two privacy modes
+
+Merces supports two modes for transfers, selectable per transaction:
+
+| Mode | What's hidden | What's visible | Use when |
+|---|---|---|---|
+| **Confidential** | Amounts, balances, transfer history | Sender and receiver wallet addresses | You want to hide pricing or amounts but settle to known counterparty wallets. The basis for [Confidential x402](/docs/finance-solutions/x402/introduction). |
+| **Fully private** | Amounts, balances, sender, and receiver | Nothing identifying about the transfer | You need full transaction-graph privacy: consumer payments, sensitive treasury moves, regulated user flows. |
+
+Both modes share the same Merces protocol, the same secret-shared balance model, and the same
+compliance primitives. Callers pick the mode for each transfer.
+
+## How Merces works
+
+Merces wraps existing ERC-20 tokens (such as USDC) into a private form that lives alongside the
+public token on the same chain. Users gain a **private virtual account** without leaving their
+existing wallet, RPC, or chain.
+
+Three properties make this work:
+
+1. **Balances are held as secret shares** across the TACEO Network's MPC operators. No single
+   party, including TACEO, ever sees a plaintext balance or amount.
+2. **State transitions are verified onchain via CoSNARKs.** Both the client's spending proof and
+   the MPC network's balance update proof are checked by the Merces contract before any commitment
+   moves.
+3. **The chain stays the chain.** Merces deploys as a contract on the EVM you already use. There's
+   no bridge, no new consensus, no migration.
+
+For a step-by-step walk through the cryptographic flow (commitments, secret shares, Groth16
+proofs, EIP-712 signing, and the MPC settlement loop), see
+[How it works](/docs/finance-solutions/x402/how-it-works), which uses the x402 payment as the worked example but
+documents the underlying Merces protocol.
+
+## What you get
+
+| Capability | Status |
+|---|---|
+| Confidential transfers (amounts hidden, addresses visible) | Live on Arc and Base testnets |
+| Fully private transfers (amounts and addresses hidden) | Live on Plasma testnet |
+| Per-transaction mode selection | Live on Plasma testnet |
+| Compliance dashboard with selective disclosure | Live on Plasma testnet (see [Compliance](/docs/finance-solutions/compliance/introduction)) |
+| `transferWithAuthorization` (basis for [Confidential x402](/docs/finance-solutions/x402/introduction)) | Live on Base testnet |
+| Allowlists at the contract layer | Live on testnet |
+| Private yield | In development (see [Private Yield](/docs/finance-solutions/yield/introduction)) |
+| Private DeFi (swaps, dark pools, approvals) | On the roadmap |
+| Mainnet deployment | Shipping toward production |
+
+## Privacy assumptions
+
+In **confidential mode**, Merces hides balances, transfer amounts, and the state of the virtual
+account. Sender and receiver wallet addresses remain visible onchain.
+
+In **fully private mode**, Merces additionally hides sender and receiver. A gateway service
+abstracts gas payment and submitter identity so the transaction graph itself stays opaque.
+
+In both modes, no single party (including TACEO) ever sees a plaintext balance or amount.
+Balances are held as MPC secret shares; reveals require explicit authorization through the
+compliance flow.
+
+For a full privacy analysis at the protocol level, see the x402
+[Protocol reference](/docs/finance-solutions/x402/protocol-reference#privacy--trust-model).
+
+## Who it's for
+
+| Audience | What Merces gives them |
+|---|---|
+| **Stablecoin issuers** | Privacy as a feature for issued tokens, without forking the asset |
+| **Fintechs and neobanks** | A confidential rail under existing user accounts |
+| **Payment infrastructure builders** | An SDK-integrable private ledger on the EVM they already target |
+| **Institutions and treasuries** | Confidential settlement on public rails for payroll, vendor payments, and intra-org transfers |
+| **AI agents and agent platforms** | Spending that doesn't broadcast strategy across paid endpoints |
+
+## Get started
+
+| Goal | Start here |
+|---|---|
+| Try confidential payments in a browser | [merces-dashboard.taceo.io/arc](https://merces-dashboard.taceo.io/arc) |
+| Try fully private payments and the compliance dashboard | [merces.taceo.io](https://merces.taceo.io) |
+| See it run end-to-end with a real (test) payment via x402 | [Confidential x402 Quickstart](/docs/finance-solutions/x402/quickstart) |
+| Understand the protocol architecture | [How it works](/docs/finance-solutions/x402/how-it-works) |
+| Look up addresses and endpoints | [Network & Contracts](/docs/finance-solutions/x402/network-and-contracts) |
+| Read the underlying paper | [Escudero et al., IACR ePrint 2026/850](https://eprint.iacr.org/2026/850) |
+| Browse source | [github.com/TaceoLabs](https://github.com/TaceoLabs) |
+
+For production access, integration support, or a deeper conversation about a specific use case,
+[email the team](mailto:hello@taceo.io).