Litepaper

The regulated stablecoin settlement dilemma

Stablecoins and public blockchains can deliver near-instant settlement, interoperability, and programmable payments. For regulated institutions, the blocker is not settlement finality, it’s information leakage.On public chains, transaction graphs can expose:

Counterparty relationships (who pays whom)
Volumes and flow timing (treasury patterns, payroll cycles)
Customer and merchant networks (business intelligence)
Operational behavior (liquidity and routing strategies)

Even with pseudonymous addresses, institutional-scale activity becomes clusterable and attributable.

At the same time, regulated institutions cannot shift the compliance boundary to a third party. KYC/KYB, sanctions screening, transaction monitoring, and Travel Rule obligations must remain within the institution’s approved stack and governance.

The result is a deadlock: public settlement is attractive, but public visibility is unacceptable, and many privacy alternatives introduce trust assumptions or operational changes that regulated entities cannot accept.

What Tessera is

Tessera is a smart-contract settlement layer for stablecoin payments on public blockchains, designed for regulated institutions. Tessera’s key properties:

On-chain settlement: atomic settlement on a public chain.
Off-chain compliance: institutions keep compliance checks and approvals in existing systems.
Privacy-by-design: no public transaction visibility.
Zero counterparty risk: Tessera is non-custodial and inherits settlement guarantees of the public blockchain.
Institution-first integration: designed to plug into legacy compliance and risk workflows rather than replace them.
High TPS and low transaction cost: ensures Tessera can fit real payment and treasury use cases.

Design goals

Unlike other solutions, Tessera is optimized for institutional constraints faced by regulated actors:

Keep the control boundary intact: Institutions retain responsibility for onboarding, policy decisions, transaction monitoring, and regulatory reporting.
Minimize trust assumptions: Avoid architectures that require trusting any operator with custody, settlement integrity, or access control.
Privacy with auditability: Reduce public information leakage while preserving deterministic evidence that maps to internal approvals and case IDs.
Public-chain interoperability: Settle on public rails where the stablecoin ecosystem already exists (i.e. DeFi)
Operational simplicity: Support deployment models that align with standard governance, key management, and incident response practices.

What Tessera is not

Tessera is intentionally narrow: it provides non-custodial settlement coordination and privacy-preserving on-chain execution, while keeping compliance and policy inside regulated institutions. To avoid ambiguity, Tessera is not:

Not a compliance provider. Tessera does not perform KYC/KYB, sanctions screening, transaction monitoring, Travel Rule messaging, or regulatory reporting. These remain the responsibility of the institution and its approved vendors.
Not a custodian or wallet. Tessera does not custody user funds, hold balances on behalf of clients, or operate accounts. Key management and authorization remain with subpool owners and their designated signers.
Not a stablecoin issuer, distributor, or exchange. Tessera does not mint, redeem, market, or distribute stablecoins, and does not provide conversion, brokerage, or exchange services.
Not a private or permissioned blockchain. Tessera does not rely on a gated validator set, federation, or private network for privacy. Settlement occurs on public chains under the base chain’s consensus assumptions.
Not a retail anonymity tool. Tessera is not designed for consumer-grade anonymity or censorship resistance against a regulated institution’s lawful controls. It is built for institutional privacy and controlled disclosure.
Not a way to bypass issuer or legal controls. Tessera is designed to remain compatible with issuer-level token controls and lawful requirements (where applicable). It does not aim to circumvent freezes, seizures, or other compliance hooks implemented by issuers or required by law.
Not a guarantee against endpoint compromise. Tessera cannot protect against compromised institution systems, insider threats, malware on endpoints, or failures in the institution’s operational controls.
Not a substitute for security assurance. Open sourcing improves transparency but does not replace independent audits, formal review, and operational risk management required for production deployment.

Why we chose this architecture (and not gated chains, Validium, private chains, or private pools)

Tessera is built on a simple premise: institutions want the benefits of public blockchains (interoperability, composability, deep liquidity, DeFi access) without exposing sensitive payment intelligence, and without taking on new counterparty or governance risk.

Most privacy approaches force institutions to choose between strong privacy, public-chain interoperability, and acceptable risk. Tessera is built to keep all three: it settles on public chains for liquidity and composability, keeps compliance and policy decisions inside the institution, and remains non-custodial to avoid introducing new counterparty dependencies.

For that reason, Tessera is not pursuing architectures where privacy depends on gated validator sets, off-chain committees, or private networks, because those models typically introduce additional trust assumptions, governance exposure, or ecosystem constraints that regulated institutions cannot easily accept.

Why not gated blockchains (Canton-style, federations)

Gated networks can deliver privacy by restricting who validates and who can see data, but they introduce structural risks institutions care about:

Breach blast radius: because transaction confidentiality depends on a limited validator set, a compromise of any validator (or a threshold of validators, depending on the design) can expose sensitive data. This creates a concentrated counterparty risk profile that many regulated institutions will find unacceptable.
Ecosystem constraint: reduced composability with public DeFi and the broader stablecoin ecosystem.
Portability risk: you are effectively choosing a network and its rules as a long-term dependency.

Why not Validium-style rollups

Validium architectures can improve scalability, but their privacy model typically relies on off-chain data held by a limited party or committee, which creates institutional-grade risk trade-offs:

Data availability and committee assumptions: Privacy often comes from the fact that a limited party (or small committee) holds the transaction data off-chain. This creates a dilemma: if data is lost or becomes unavailable, users can be unable to produce the proofs needed to update state, and funds can become effectively locked. To reduce this risk, the system must replicate or publish data, but that can undermine privacy. In short: keep data private and increase data-loss risk, or increase availability and weaken privacy.
Not full privacy for inter-institution flows: Even if amounts and details are hidden, at minimum the existence of a transfer between institutions can leak (e.g., that a transaction between Bank A and Bank B occurred), which is often the most sensitive information for regulated payment and treasury flows.

Why not private blockchains

Private chains and privacy-first networks can hide transaction details, but they create institutional trade-offs Tessera is designed to avoid:

Loss of native access to public DeFi and liquidity: Operating inside a private network typically means users and institutions cannot interact natively with public DeFi. Interoperability depends on bridging or bespoke connectivity, which adds operational complexity and cost, and can become a throughput bottleneck.ç
Interoperability is expensive: Bridges and cross-domain messaging introduce additional engineering, monitoring, and security overhead. They can also introduce separate trust assumptions and incident surface area, which increases procurement friction for regulated institutions.
Regulatory cleanliness is harder to guarantee: In a fully decentralized privacy network, you cannot reliably prevent “good” regulated funds from being mixed with “bad” funds at the network level, because participation and transaction flow are not controlled by regulated gatekeeping. This makes it harder for institutions to maintain a clean, institution-defined compliance boundary and can create “not regulated by design” perceptions, even when individual participants run strong compliance.
Institutions need privacy without leaving public rails. Even if a privacy-first network provides strong confidentiality, as a private L1 it has lower credibility (tested security) as a shared settlement rail for mainstream institutional flows. And even when the privacy system is decentralised (for example, a privacy L2 on Ethereum), institutional adoption still depends on how cleanly it integrates with existing compliance stacks and how directly it preserves interoperability with public rails without forcing institutions into a separate privacy domain or relying heavily on bridges.

Why not “private pools”

Privacy pool projects such as Privacy Pools and Railgun focus on transaction privacy by breaking on-chain linkability. However, they are not designed for regulated institutional settlement flows.

No regulated compliance boundary: these systems do not natively support institutional requirements such as KYC/KYB enforcement, sanctions controls, transaction monitoring workflows, Travel Rule messaging, or institution-controlled authorization tied to internal case IDs.
Not built for institutional governance and auditability: while they can provide privacy at the transaction level, they generally lack the governance, change-control, and audit-evidence mapping patterns that regulated institutions require for procurement, risk, and regulator-facing assurance.

For these reasons, Tessera does not rely on “privacy pool” architectures as the primary solution for regulated stablecoin settlement.

What Tessera is designed to deliver

Tessera is designed to deliver this specific combination in one system:

Zero counterparty risk: Tessera inherits security and finality from the underlying public blockchain and remains non-custodial, so institutions do not need to trust a separate operator, committee, or custodian to safeguard funds.
Banking-grade privacy: no public transaction visibility, while the regulated institution retains the full information and evidence it needs to meet regulatory and audit requirements.
Regulated compliance alignment by keeping KYC/KYB, sanctions, monitoring, and Travel Rule processes inside the institution
High TPS and low cost: Tessera delivers high throughput and low transaction costs on public blockchains by using succinct proofs and a rollup-style architecture.
Access to public DeFi and liquidity because settlement happens on public blockchains, not isolated private networks

This is the rationale behind the Tessera architecture: keep a trust model “inherited” from public blockchains, keep compliance where it already lives, and remove unnecessary intermediaries that create counterparty risk.

Transaction flow (high level)

Step 1: Initiation and pre-checks (off-chain). A user initiates a payment. The institution runs internal controls and checks, including KYC/KYB status, sanctions screening, transaction monitoring, and Travel Rule messaging as per its existing systems.

Step 2: Authorization. If controls pass, the institution issues a signed authorization or settlement instruction. This references an internal case/approval ID (or equivalent) to preserve a clean audit trail.

Step 3: On-chain settlement (atomic). Tessera’s smart contracts settle the stablecoin transfer on the public chain. No identifiable information about the transaction is visible on the public chain

Step 4: Evidence and audit mapping. Contract events provide deterministic references that map back to internal approvals and case records for audit, dispute handling, and regulator review.

Privacy model (explicit, institutional-grade)

Tessera’s privacy model is defined by three questions:

What is hidden (target)?

Tessera is designed to eliminate public visibility of:

Sender/receiver linkage (counterparty relationships)

Transaction amounts (flow intelligence)
Transaction graph linkability over time (pattern inference)

What remains visible (by necessity)?

On public chains, some elements are inherently visible:

Transaction inclusion and finality (a settlement happened), however, you cannot identify neither the institutions nor users involved

Contract execution correctness (state transitions)
Base-chain level metadata (e.g., block timing and inclusion)

Tessera aims to hide exposed metadata while preserving public-chain verifiability.

What can be revealed (to auditors / regulators)?

Institutions must be able to demonstrate compliance and explainability. Tessera is designed so the institution can produce:

A mapping from on-chain evidence (event references) to internal case/approval IDs

Signed authorizations corresponding to specific settlements
Internal logs showing the compliance checks performed and outcomes

The protocol supports selective disclosure controlled by the institution, without requiring public transparency of payment relationships.

Threat model

This section defines the security and privacy boundaries of Tessera. It clarifies who we defend against, what we assume, and what is explicitly out of scope, so institutions can evaluate the protocol’s risk posture and integrate it into their existing control frameworks. The goal is to make Tessera’s trust assumptions legible for compliance, security, and procurement teams, and to avoid ambiguous “privacy” claims.

Adversaries

Public observers: Attempt to infer counterparties, volumes, and business relationships from on-chain data.

Counterparties / competitors: Attempt to learn institutional flow patterns and customer networks.
Malicious or compromised endpoints: Attempt to submit unauthorized transactions or leak sensitive data through compromised institution systems.
Protocol-level attackers: Attempt to exploit smart contract vulnerabilities, authorization logic flaws, or upgrade paths.

Tessera mitigations (high level)

Obfuscate publicly observable settlement metadata to reduce inference risk

Require explicit, signed authorizations tied to internal approvals
Keep compliance decisions off-chain, under institutional control
Use deterministic evidence mapping to support audit and dispute resolution

Out of scope (explicit)

Compromise of institution internal systems, end-user devices, or insider fraud

A base-chain halt or censorship beyond the chain’s normal trust assumptions
Regulatory obligations themselves (Tessera supports compliance; it does not replace it)

Open Source

Tessera will be open source, with code published as soon as it is production-ready for external review. The objective is to:

Reduce vendor lock-in risk for institutions

Enable independent security review and assurance
Allow subpool owners to validate the protocol assumptions directly
Support long-term survivability beyond any single company

Open sourcing does not remove the need for audits, but it materially improves transparency and institutional comfort. For a glance at our code please email admin@tesseralabs.xyz

Governance model (co-designed with pool owners)

Tessera’s governance model is intentionally being developed in collaboration with Tessera pool owners. The objective is to converge on a governance approach that regulated institutions can adopt in practice, with clear accountability, predictable change control, and reduced reliance on any single vendor.

Avoiding single-vendor control over critical protocol changes and parameters
Change-management norms compatible with regulated institutions, including documented approvals, release processes, and auditability of changes
Upgrade policies and operational procedures, including incident response, rollback/pausing principles (where applicable), and communication expectations
Participation and membership rules (where applicable), including criteria and decision processes for admitting or removing pools, and how policy decisions are recorded

During the sandbox phase, pool owners will provide input on institutional requirements (risk, legal, security, procurement) and help shape the practical governance model. As this work progresses, Tessera will publish an explicit governance specification covering roles, decision rights, upgrade controls, and the minimum operational assurances required for production deployment, which will be shared with subpool owners.

Roadmap

Until May 2026: Build “tech for sandbox”

Core settlement flows implemented end-to-end, including the authorization pattern and evidence events needed for audit mapping

Integration scaffolding so counterparties can plug Tessera into existing compliance, monitoring, and payment workflows with minimal disruption
Privacy model for the sandbox deployment mode, implemented in a way that is testable, measurable, and clearly documented (what is hidden vs what remains visible)
Operational tooling and documentation suitable for institutional testing: deployment guides, environment setup, key management assumptions, logging/evidence mapping, and basic runbooks

Deliverable: a production-like sandbox environment with clear integration instructions and a defined scope of supported flows.

From June to November 2026 (6 months): Sandbox phase

Run a controlled sandbox with a limited cohort to test settlement workflows, operational processes, and policy integration under realistic conditions

Iterate in parallel on protocol capabilities to expand supported flows and harden assumptions based on sandbox feedback
Independent security audits and structured remediation cycles, with fixes prioritized and re-tested in the sandbox
Operational maturation: refine monitoring, incident response procedures, and integration playbooks based on observed usage and institutional requirements

Deliverable: validated integration patterns, improved operational readiness, and an assurance track (audit + remediation) that supports a transition from sandbox to broader deployment.

Legal & regulatory positioning

Tessera is designed to remain compatible as stablecoin regulation matures in both the EU and the US.

EU (MiCA + Travel Rule): MiCA applies in phases, with the stablecoin titles (ART/EMT) applicable from 30 June 2024 and the broader regime applicable from 30 December 2024. The EBA’s Travel Rule Guidelines under Regulation (EU) 2023/1113 apply from 30 December 2024.
US (GENIUS): The GENIUS Act was signed into law on 18 July 2025, establishing a federal framework for payment stablecoins and issuer obligations.

Tessera’s approach: Tessera keeps the compliance and legal control boundary off-chain, inside the regulated institution, while providing non-custodial on-chain settlement coordination and an evidence trail that maps to internal case or approval IDs. Institutions retain KYC/KYB, sanctions screening, transaction monitoring, and Travel Rule messaging in their existing approved systems. Tessera is designed to remain compatible with issuer-level requirements and token controls (where applicable), without becoming the compliance decision-maker.

Tessera does not custody funds and does not onboard end users. Institutions remain responsible for ensuring that their deployment, governance, and use of Tessera meet applicable regulatory requirements. In practice: the institution decides, authorizes, monitors, and reports; Tessera settles and provides verifiable on-chain evidence that can be linked back to internal records when required.