SYSTEM NOTICE

Auto translation by AI. Be sure, accuracy, nuances and authorial intent may not be fully reflected.
見出し画像

Starting the "Global On-Chain Projects" Series

Where should we look for overseas projects?

10 Perspectives for Comparing On-Chain Finance

Project Agorá, Project Guardian, Project Ensemble, Pontes, Appia, GBTD—.

When researching on-chain finance, project names from all over the world appear one after another.

While the number of participating central banks and financial institutions, the blockchains used, and the number of verified transactions attract attention, that alone does not explain the significance of the projects.

Even if they are all called "tokenized finance pilots," in reality, they are a mix of:

  • projects to improve international remittances

  • projects to settle securities and funds simultaneously

  • projects to tokenize bank deposits

  • projects to connect market DLT with existing central bank settlement systems

  • projects to design the entire future financial market

all mixed together.

In this series, "Anatomy of Global On-Chain Finance Projects," we will decipher the financial structures within these projects, rather than just looking at news headlines.

In Part 0, we will organize the 10 analytical perspectives that will be used in all future Project Files.

On-chain finance moving from pilot to implementation

On-chain finance projects are moving from the stage of discussing concepts to the stage of verifying specific architectures and actual transactions.

Project Agorá demonstrated through a prototype that it is possible to combine tokenized commercial bank deposits and central bank reserves to process multi-currency wholesale cross-border settlements atomically—that is, in a way where "either everything settles or nothing settles." The next stage is scheduled to be the verification of real-value transactions with limited currencies and participants.

In Europe, Pontes connects market DLT infrastructure with TARGET Services, providing a short-term mechanism to settle DLT transactions with central bank money. Meanwhile, Appia is a project with a vision to create a blueprint for Europe's long-term tokenized financial market by 2028, including the choice between a single common infrastructure or multiple interconnected infrastructures.

It is important to note here that the completion of a prototype, testing with real value, limited commercial provision, and full-scale market infrastructure are all different stages.

The phrase "successfully piloted" alone does not clarify the extent of what has been verified.

You cannot understand it just by the project name

There are at least three common misinterpretations regarding on-chain finance projects.

The first is focusing too much on the technology when reading about them.

While which blockchain was used is important, it is even more necessary to look at:

  • what was transferred as an asset

  • what was used for payment

  • who performed the final settlement

.

The second is confusing tokenized assets with settlement assets.

For example, even if securities are tokenized, if the payment is made via existing bank transfers, the securities side and the funds side move separately. Tokenizing securities alone does not complete DvP, or Delivery versus Payment.

The third is confusing what has been proven in a pilot with what can be commercialized.

Even if a transaction can be technically executed, it will not become market infrastructure unless the following are determined:

  • legal finality

  • participation eligibility

  • liquidity

  • responsibility in the event of failure

  • revenue model

  • coexistence with existing systems

.

Perspective 1 | What are they trying to solve?

The first thing to look at is not the technology, but the business challenges.

The problems targeted by projects differ, for example, as follows:

  • Cross-border payments are time-consuming and costly

  • Securities and funds operate on separate systems

  • Inability to track the location and availability of collateral in real-time

  • Multiple financial institutions reconciling the same data individually

  • Absence of central bank money on market DLT infrastructure

  • Lack of common bank money to settle tokenized assets

If you read without clarifying these points, every project will look like an "initiative to streamline finance with blockchain."

In this series, at the beginning of each Project File, we will confirm the current business workflow and identify where the problems lie.

Perspective 2 | Who is participating and what roles are they playing?

Simply listing the names of participating companies is insufficient.

What needs to be confirmed is the function of each participant.

  • Central Bank: Provision of central bank money, regulation/supervision, and currency-specific operations

  • Commercial Banks: Issuance of deposits, customer management, payment instructions, and liquidity provision

  • Securities/Asset Management Firms: Issuance, trading, and management of assets

  • FMI: Financial Market Infrastructure responsible for clearing, settlement, and securities custody

  • Technology Providers: Ledgers, smart contracts, connectivity infrastructure, and key management

  • Oracle Providers: Transmitting external data on-chain

  • Platform Operators: Participant accreditation, specification changes, and incident response

What is particularly important is not who operates the ledger, but who bears the financial responsibility.

The entity issuing the token, the entity managing the underlying assets, the entity performing identity verification, and the entity performing final settlement are not necessarily the same.

Perspective 3 | What is being tokenized?

The explanation that "an asset has been tokenized" is not enough to understand what is being targeted.

What a token represents varies as follows:

  • Deposit claims against a bank

  • Reserve deposits at a central bank

  • Government or corporate bonds

  • Beneficial interest in a fund

  • Stocks

  • Assets used as collateral

  • Accounts receivable

  • Ownership of goods or movable property

  • Usage rights or profit-sharing rights

  • Instructions to move assets on an existing ledger, rather than the assets themselves

Tokenization does not necessarily mean creating new financial products.

Project Agorá also clarifies that tokenization does not change the legal nature of commercial bank deposits or central bank reserves.

What you should look at is not the appearance of the token, but

who holds what kind of legal rights against whom

.

Perspective 4 | What is used as a settlement asset?

Financial transactions involve the asset being traded and the money used to pay for it.

In on-chain finance, the following are used as settlement assets:

  • Central bank money

  • Commercial bank deposits

  • Tokenized deposits

  • Stablecoins

  • Deposit accounts opened between banks

  • Existing bank transfers

  • Temporary settlement tokens within a platform

These differences directly impact credit risk, liquidity, legal finality, and 24/7 operational capability.

When you read an article stating that "securities have been moved on-chain," you must always check:

what was ultimately used to pay for those securities

is necessary to confirm.

If the settlement asset is not clearly specified, the project may only be verifying the asset side.

Perspective 5 | How is the ledger structured?

There is not just one architecture for on-chain finance.

The main configurations include the following:

  • A common infrastructure model where all participants use the same ledger

  • A method that interconnects ledgers for each bank, jurisdiction, and market

  • A method of connecting market DLT with existing payment systems via a gateway

  • A hybrid method where assets are managed on DLT and funds are managed in existing accounts

  • A method of placing both assets and funds on the same programmable infrastructure

One must also be careful with the term "shared ledger."

There are designs that place all data on a single ledger, as well as designs that hierarchically combine a common transaction processing layer with ledgers managed by individual countries and banks.

Project Agorá adopted a tiered architecture that allows each central bank to maintain autonomy over its own currency and domestic operations while using an interoperable shared infrastructure.

Perspective 6 | How does a single transaction flow?

An architecture diagram alone does not explain how a transaction is executed.

We break down a single transaction in the following order:

  1. Who initiates the transaction?

  2. Who verifies the identity and eligibility of the participants?

  3. Who locks the assets and funds?

  4. When is compliance verification performed?

  5. Who provides the exchange rate or price?

  6. Under what conditions are assets and funds transferred?

  7. To what extent is the transaction rolled back if it fails?

  8. To which ledger is the final entry reflected?

  9. How is it integrated with existing core banking and accounting systems?

When an explanation says it was "automated by smart contracts," we also verify which specific processes were automated.

The meaning of the implementation differs significantly depending on whether it only covers the confirmation of transaction terms, the transfer of assets, the settlement of funds, or includes recording in the books.

Perspective 7 | Where does programmability lie?

Programmability is the ability to execute processes based on pre-defined conditions.

For example,

  • paying funds only when securities are transferred

  • executing FX only when funds for both currencies are secured

  • proceeding to settlement only when sanctions and AML checks are completed

  • requesting additional collateral when the collateral value falls below a certain level

  • paying the seller when the arrival of goods is confirmed

  • executing interest payments and principal repayment on the maturity date

are some examples of such processes.

However, programmability is not a feature exclusive to DLT. Conditional branching and automated processing can also be implemented in traditional systems. The significance of DLT and tokenization increases in scenarios where multiple organizations share the same state and execute everything from asset to money transfers in an integrated manner.

Therefore, in this series, we will examine

whether smart contracts were used

not,

which processes that were previously separate have been consolidated into a single transaction

we will confirm.

Perspective 8 | How are legal systems and finality designed?

Technically confirming a transaction is not the same as the final legal settlement of a payment.

Points to verify include:

  • the legal nature of the rights represented by the tokens

  • Which is the official record: the ledger entry or the existing book?

  • The legal point of settlement completion

  • Handling of transactions if a participant goes bankrupt

  • Reversal of erroneous remittances and fraudulent transactions

  • Segregation of customer assets

  • AML/CFT and sanctions compliance

  • Personal information and sharing of transaction data

  • Governing law for cross-border transactions

These are some of the issues.

Even if a proof-of-concept succeeds in technical processing, these issues may remain unresolved.

Conversely, some projects aim to minimize institutional uncertainty by maintaining the legal nature of existing bank deposits or central bank money and structuring them as an extension of existing systems.

Perspective 9 | How far has the proof-of-concept progressed?

In this series, we categorize project progress as follows:

Stage 1: Concept and Research

The stage where issues, participants, and architectural candidates are being considered.

Stage 2: Technical Verification

Confirming smart contracts, ledger connectivity, transaction processing, etc., in a limited environment.

Stage 3: Simulated Transactions

Confirming end-to-end processing in an environment that mimics actual participants and business data. No actual value is transferred.

Stage 4: Real-Value Pilot

Using limited participants, assets, amounts, and currencies, we transfer actual legal and economic value.

Stage 5: Limited Commercialization

We provide services as an ongoing offering for specific target customers and use cases.

Stage 6: Market Infrastructure

Numerous participants connect and utilize the system under standardized rules and operational frameworks.

Project Agorá has completed its prototype and intends to move to the next stage of using real value. Pontes plans to begin practical delivery of DLT transactions settled in central bank money in the third quarter of 2026.

Instead of using the single word "proven," we will specify which stage it is in.

Perspective 10 | What has been proven and what remains

Finally, we categorize project outcomes into three parts.

What has been proven

Functions and performance confirmed through actual verification.

What has been suggested

Possibilities for future realization indicated by the results of the prototype.

What remains unconfirmed

Matters not confirmed in the demonstration, such as commercialization, legal systems, operations, liquidity, costs, and the expansion of participants.

For example, even if atomic settlement can be executed technically,

  • will overall market liquidity improve?

  • will it be cheaper than current methods?

  • can it be operated stably even during failures?

  • will a large number of financial institutions participate?

  • Whether the user companies pay for it

may not have been proven yet.

It is necessary to neither underestimate nor overestimate the results of a project.

Project Card

At the beginning of each Project File, the following project card will be included.

Project Name
Official name and abbreviation

Organizer
Central bank, government agency, industry association, private company, etc.

Target Region/Currency
Jurisdiction, target currency, scope of cross-border

Participants
Central banks, banks, securities firms, asset managers, technology companies, etc.

Problem to Solve
Current operational issues

Target Assets
Deposits, central bank money, securities, collateral, funds, etc.

Settlement Assets
Money used for transaction payments

Ledger Architecture
Common infrastructure, multiple ledgers, gateways, integration with existing systems

Proof Stage
Concept, technical verification, simulated trading, real value, commercialization

Last Updated
Date the Project File was last updated

By looking at this card, you can compare different projects using the same criteria.


When reading about on-chain finance projects, what matters is not the project name, the number of participating companies, or the blockchain adopted.

What you should look at is,

whose problem they are trying to solve, which assets and money they are using, and which ledger and system they are using to solve it

It is.

Furthermore, it is necessary to read by distinguishing between what a project has demonstrated and what it has not yet demonstrated.

In this series, we will dissect global projects from the same 10 perspectives to explore the common design principles behind individual cases.

In the next installment, Project File 01, we will cover Project Guardian.

Rather than just viewing it as a 'cross-border payment project using tokenized deposits,'

  • why were central bank reserves and commercial bank deposits combined?

  • how do common platforms and jurisdiction-specific ledgers coexist?

  • how is multi-currency atomic settlement achieved?

  • what has been proven, and what remains to be verified for real-world value?

We will decipher these points through transaction flows and architecture.


This article is a general analysis based on publicly available information and does not constitute a recommendation for any specific service or legal advice. Since definitions of figures vary by company and are subject to updates, please verify primary sources when using this information.


いいなと思ったら応援しよう!

この記事は noteマネー にピックアップされました

noteマネーのバナー