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:
Who initiates the transaction?
Who verifies the identity and eligibility of the participants?
Who locks the assets and funds?
When is compliance verification performed?
Who provides the exchange rate or price?
Under what conditions are assets and funds transferred?
To what extent is the transaction rolled back if it fails?
To which ledger is the final entry reflected?
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マネー にピックアップされました

