The trade-offs between different designs of tokenized systems

As interest in tokenization grows, so too does the focus on the design of tokenized systems. Different approaches—such as centralized or decentralized systems—could achieve similar outcomes. But the choice of design involves consequential trade-offs that shape how the entire ecosystem evolves.

Financial system participants have become increasingly interested in tokenized assets and the ability to program and trade them openly among a range of individuals and organizations.

These two features of tokenized systems—programmability and openness—are usually associated with decentralized platforms like the Ethereum blockchain. But centralized platforms can also support these features.

So what factors should be considered when choosing the design for a tokenized system?

Our analysis shows that no particular design is universally optimal. The choice of one system design over another often involves trade-offs between performance and transparency. The choice of design should thus be guided primarily by business and regulatory requirements.

The insights from our work can help improve understanding of these trade-offs, which is critical as the tokenization ecosystem continues to develop and grow.

Programmability and public access can be achieved on both centralized and decentralized systems

As discussed in a previous Sparks at Bank article, tokenization involves representing an asset and its ownership together on a digital ledger. This allows smart contracts to execute pre-determined transactions after certain predefined requirements are met—known as programmability—and it allows for varying levels of participation, or openness.

The openness of a tokenized system is based on two properties: who can validate transactions and who can participate in the system.

Validation implies controlling the ledger and guaranteeing that operations are executed as designed and that the system state—such as source code, data and transaction history—is always correct. Based on this, validation can either be centralized or decentralized.

• In a centralized system, a single known entity validates every transaction recorded on the ledger.
• In a decentralized system, multiple entities—sometimes tens of thousands—validate transactions. This kind of system can be either:
  • permissionless, meaning the validators are anonymous
  • permissioned, meaning the validators’ identities are known

Choosing a centralized or decentralized system comes down to how many validators are needed for users to trust that the system will operate properly. This concept is called the trust model.

Regarding participation, a tokenized system can support public access, where anyone can participate in transactions and do so anonymously if they wish. A system can also support the opposite—private access—where access is restricted based on some identifying attributes, such as legal identities, digital keys or the results of identity checks.

Figure 1 shows how these characteristics relate to each other within a specific system design.

Despite the many ways to design a system, one thing remains true: programmability can be functionally achieved on any type of tokenized system. Likewise, having a system with public access does not depend on who validates transactions and can be realized on centralized or decentralized systems.

The key difference between system types is that a decentralized system is costlier and more complex than a centralized system. But that doesn’t mean decentralized is worse or better than centralized. Rather, this difference highlights some of the trade-offs between system designs.

Choosing a tokenized system involves balancing performance and transparency

Any tokenized system has several key attributes, two of which are:

• performance—the achievable throughput (in transactions per second) and the ability to scale it by adding resources
• transparency—how much of the system state is visible and to whom

Each trust model—or type of validation system—involves a trade-off between these two attributes. Figure 2 shows the trade-offs for centralized; decentralized, permissionless; and decentralized, permissioned systems. The relative rankings are illustrative—a higher score means:

• more transactions can be processed per second (performance)
• more entities can access system records (transparency)

Figure 2: Choosing a tokenized system involves a trade-off between performance and transparency

Tokenized system design attributes, by type of validation system

Source: Bank of Canada

Based on our analysis, the bottom line is that:

• centralized systems offer the best performance but the least transparency
• decentralized, permissionless systems offer the most transparency but the lowest performance
• decentralized, permissioned systems offer levels of performance and transparency that are between those offered by centralized and decentralized, permissionless systems

The choice of a tokenized system should be guided primarily by business and regulatory requirements

No system design—decentralized or centralized, permissioned or permissionless—is likely to be universally optimal. Rather, the best design options come down to the business needs of the use case.

Let’s look at different systems.

• Centralized systems would typically fit the needs of regulated assets. Having a single known entity like a government regulator, for example, in charge of such systems could help provide integrity and accountability, supporting trust in the system. As well, the low transparency of these systems could help maintain the confidentiality of the parties involved in transactions—a desirable feature of systems that manage regulated assets.
• Decentralized, permissionless systems could fit a business need for transparency, particularly if that involves having publicly verifiable records, such as proof of digital identity or confirmation of an executed transaction. However, there is a trade-off that involves placing trust and governance with a group of anonymous validators, which could prevent the use of permissionless systems for regulated assets.
• Decentralized, permissioned systems, like centralized systems, satisfy the need of having a known entity being responsible for the trading platform. These systems also allow for multiple entities to share control, like permissionless systems. A permissioned system might fit well in scenarios where a trusted intermediary is missing, such as in systems supporting cross-border payments or where sharing control is desirable for business reasons.

Why the choice of architecture matters for policy-makers

If the use of tokenized assets grows rapidly, the platforms behind these assets could become systemically important. And should this growth occur within a decentralized, permissionless system—where regulatory oversight is more difficult—it could eventually complicate efforts to ensure financial stability.

Our work can help authorities understand the trade-offs between system designs as they analyze the effects tokenization may have on banking and payment systems. The insights from our work are also helpful if authorities consider launching sovereign programmable platforms as part of a larger goal of infrastructure sovereignty.

Find out more