M10’s hierarchical ledger allows both the segregation of tokenized liabilities as well as interdependent liabilities. The latter is important in some CBDC models.
There is no limit to the possible levels in the hierarchical ledger and it can be configured to meet the needs of central banks and commercial banks. However, for most use cases today, two levels are sufficient. The top-level (we call it M0) represents tokenized central bank reserves, or CBDC. The second level (M1) represents tokenized commercial bank money. If you’re a banker, this should sound familiar because it’s how the monetary system works today. And therein lies part of the M10 benefit - maintain today’s monetary system, but upgrade the underlying infrastructure.
The hierarchical ledger is immutable and operated by a proprietary, permissioned blockchain. Because of its permissioned nature and because it was purposely designed and built for bank credit and debits, the throughput of the M10 ledger is high - over one million transactions per second with sub second latency. See the performance report.
While the M10 system is an account-based system, offline payments are possible. Payments can be performed between offline devices and eventually reconciled with the online system upon synchronization.
In the M10 ecosystem, each participant is represented by a private/public key pair*. This key pair is used to generate and verify digital signatures used for authentication and authorization in the ecosystem. Each entity (individual, business) holds their private key securely in an HSM, TEE, or similar. The M10 system stores the entity’s public key. The system also stores aliases for each entity, such as name, email, phone number so the entity can be identified using a friendly name in the ecosystem. This is called Personally Identifiable Information, or PII for short.
Public keys are (of course) publically accessible, whereas PII is stored securely by encrypting the data on disk.
M10 is SaaS-based. However, many jurisdictions have data residency regulations that require data to be stored within their jurisdictional borders. Furthermore, financial market infrastructure is considered systemically important in most countries. Therefore, the M10 SaaS model allows an instance of the M10 cloud to be operated locally. M10 does not operate the infrastructure. Instead, M10 uses trusted local operators to run the infrastructure in each country/region. The operators are carefully selected by M10 based on their experience operating financial market infrastructure. Local M10 clouds don’t share data.
The instance in the United States is operated by the US Operator and conversely, the EU instance is operated by the EU Operator in, for example, Germany.
The M10 system can process over one million payments per second at latency less than one second. This level of performance can be delivered with a small number of instances, making M10 a payment system with a minimal carbon footprint.
M10 was designed to allow central banks and commercial banks to be quickly integrated in one of two ways:
The bank consumes the M10 APIs
M10 consumes the bank’s APIs
No part of the M10 cloud runs at the bank.
For API details, see M10 Docs.
When M10 consumes a bank’s APIs, we need access to the following functions:
Link with existing legacy account
Transfer funds between internal accounts
Retrieve balance of legacy accounts