Why Tessera Is Implemented as a Smart Contract Rather Than a as a Rollup

Regulated institutions, including banks, are increasingly open to stablecoin infrastructure because they recognise its benefits. However, adoption tends to favour approaches that reduce risk and operational friction while minimising architectural novelty. In institutional payments, the winning designs are the ones that fit existing trust boundaries. In practice, most banks and regulated payment firms are willing to integrate with a small number of public blockchains they already understand and trust. What they consistently resist is being asked to extend that trust boundary to an additional execution environment, with its own liveness, governance, and operational assumptions.

Payment infrastructure can be analysed as a dependency graph: every additional component that must function correctly becomes part of the system’s effective trust and availability boundary. A rollup typically adds such components, most notably a sequencing and posting workflow that users depend on for timely execution. In that model, the base chain is no longer the only element that must remain live and well governed. Tessera is therefore implemented as a smart contract on existing public chains, rather than as a rollup, in order to avoid introducing an additional operational dependency in the transaction path for the following reasons:

1) Avoiding sequencer dependency

A rollup introduces an additional execution workflow on top of the base chain, typically centred on a sequencer that orders transactions and posts commitments to the underlying chain. In theory, a rollup can remove concentrated dependencies if sequencing is credibly decentralised. In practice, decentralised sequencing remains difficult to achieve and is not yet the dominant operational model across rollups.

Tessera’s design avoids placing any new operator in the transaction path. Users interact with a smart contract that executes directly under the security and availability assumptions of the underlying chain. No separate party is required to order transactions or to operate critical infrastructure for the protocol to function.

2) Staying within existing institutional trust boundaries

Regulated institutions are structurally conservative in how they extend trust. Many banks are prepared to underwrite the risk of a specific L1 or established L2 because those environments are legible: they have observable security properties, mature governance, robust infrastructure, and established internal review paths.

A rollup typically adds a second layer of institutional diligence. Even where a rollup is well designed, adoption often requires additional scrutiny of:

• the sequencing and liveness model,

• governance and upgrade authority,

• operational resilience assumptions, and

• external dependency surfaces.
  

For banks, this additional review can be decisive: it slows deployment and materially increases internal coordination costs. We have repeatedly encountered institutions that are willing to integrate with a public chain, but are reluctant to rely on a third-party rollup stack.

By remaining a smart contract, Tessera can be treated as an additive layer on chains the institution is already comfortable with, rather than requiring the institution to expand its trust boundary to a new execution environment.

3) Reducing operational and security complexity for users

A rollup is not merely a codebase; it is a system that must be operated and secured: sequencing infrastructure, data availability assumptions, monitoring, incident response, and upgrade processes. Even if these responsibilities sit with a third party, institutions still inherit the associated operational risk because their payment flows depend on that system.

Tessera avoids this class of dependency. Users do not rely on a third party to operate a separate execution environment in order to transact; they rely on the chain they are already using and on their own established operational controls.

4) Cost considerations

There are contexts where a rollup design can be justified primarily on economic grounds, notably where direct settlement on Ethereum L1 is required at high volume and fee efficiency becomes a binding constraint. By contrast, on other chains and many L2 environments, fees and throughput are already compatible with payment flows, and the economic rationale for a rollup is weaker.

Accordingly, Tessera’s smart contract implementation is a pragmatic response to the current cost and adoption landscape across chains.

Conclusion

Tessera is not a rollup because this solutions would typically introduce additional trust assumptions (often via sequencing), expand institutional diligence requirements, and add operational complexity that does not materially improve the core objective: regulated, institution-grade confidentiality on public settlement rails. In environments where cost and throughput are already acceptable, a smart contract architecture is the more efficient and adoptable design.