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.