Skip to content

RLN-IP 0003

RLN-IP: 3
Title: RLN-IP Protocol Between Settlement Domains
Author: Anthony Culligan <anthony.culligan@setl.io>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/
Status: Active
Type: Process
Created: 2023-11-02
License: CC-BY-SA-4.0: [Creative Commons Attribution-ShareAlike]

Abstract

The Regulated Liability Network – A World of Interoperating Ledgers

The Evolution of a Network

Up until 1993, AOL offered a completely closed environment of bulletin boards and messaging between members. This competed with other similar offerings such as Prodigy and Compuserve. Each of these networks promoted a 'better' service to their users and sought to recruit ever increasing numbers of subscribers. These were extremely functional services with high levels of usability targeted at the public and requiring only basic computer operating knowledge.

In the meantime, a range of protocols were being proposed and implemented in the ARPANET project – a project led by the US military and computer research labs. The protocols included TCP, which provided reliable, connection-oriented communication between two computers by breaking data into packets, reassembling them at the destination, and ensuring data integrity between the sender and receiver, and IP which is the addressing and routing protocol that still underpins the internet today. The IP protocol introduced the IP Address. It is responsible for routing data packets between devices on a network.

In the early 80's a distributed address service was introduced to ARPNET, DNS. This replaced a centralised host.txt file which mapped computer names to IP Addresses – and was becoming ever more difficult to maintain. Also, during this time, ARPANET was being expanded to include universities, government departments and computer research facilities both in the US and abroad. The term 'Internet' started to be used to describe this expanded network.

With robust ways to transmit and receive data and a reliable distributed directory service for IP Addresses, higher level, more functional protocols began to emerge. SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol) and Gopher – a protocol to retrieve a text file from a remote computer. By 1989, the world wide web protocol, HTTP, was introduced.

Returning to AOL, in 1993, AOL's users demanded access to the internet and AOL provided this by acquiring Netcom and ANS Communications which provided gateways onto the internet. First, AOL offered particular services such as Gopher to allow their users to retrieve files from servers on the internet. Later AOL provided access to the world wide web and email through their own branded browser. By the end of the 90's AOL was effectively subsumed into the internet with its main business being to provide access to the internet as an ISP (Internet Service Provider).

The Regulated Liability Network

Like AOL and Compuserve, banks today offer their clients highly functional and user-friendly services. A customer of a bank or a custodian has balances recorded on that institution's ledger. Given that the majority of a person's wealth comprises these ledger entries, it is unsurprising that the operation of such ledgers is heavily regulated.

The process of spending or moving these balances, however, is fragmented and bespoke. Unlike the development of the internet, common basic protocols have not been put in place which allow more complex operations to be built on those protocols.

Ledgers

The purpose of this paper is to propose a set of rules that will allow technology entities to create software which is part of a Regulated Liability Network. It is envisaged that that software might include complete wholesale implementations of Regulated Liability Network Domains or components of the network, including compatible ledgers or wallets and user interfaces.

Basic Concept of the Regulated Liability Network

  1. Ownership of things, including money, is recorded on a ledger.
  2. There are many ledgers, each of which is a record of assets and liabilities.
  3. A change of ownership is achieved by updating one or more ledgers.
  4. A regulated ledger is one which is subject to lawful oversight and is controlled by an identifiable entity.

The Basics of an RLN Transaction

In the following description, ledgers communicate 'to the RLN' and the RLN 'sends messages to ledgers'. This is addressed in more detail further on but, in short, it is proposed that the RLN is made up of multiple settlement domains and that each of these domains provides a co-ordinating process which is the process that ledgers communicate with and the process that orchestrates the completion of a transaction. Domains can be run by individual participants or by groups of participants sharing the same domain-level processes.

Transactions on the RLN comprise the following steps.

  1. A participant ledger in the RLN makes a proposal for an atomic transaction. That transaction has one or more changes of ownership of an asset, each of which specifies the originating ledger and account, the beneficiary ledger and account, the asset to be transferred and the amount of the asset to be transferred.
  2. The RLN determines which ledgers, including intermediary ledgers, need to be updated for the transaction to settle.
  3. Each ledger and intermediary ledger receives a request to authorise the transaction and returns either a authorise or reject response to the RLN.
  4. When the RLN has received authority from all the participating ledgers, it issues a settlement finality message back to all participating ledgers. If any one of the participating ledgers rejects the transaction, a cancellation message is sent to all participating ledgers.
  5. Upon acceptance, the RLN adds the transaction hash to an ordered immutable chain which can be referenced by all participants for reconciliation and evidence of finality.
  6. Participating ledgers, upon receiving a finality message, update account balances reflect that settlement.

Technical Standards for the Regulated Liability Network

Core Principles

  1. A ledger is discoverable and reachable – like an internet URL.
  2. All ledgers belong to an RLN Domain. Domains are responsible for co-ordinating communications to and from their constituent ledgers.
  3. The RLN protocol is not prescriptive on the software implemented for an RLN domain or software used to maintain an individual ledger
  4. Each regulated ledger has an entity or party that is responsible for its upkeep and who has complete knowledge of that ledger.
  5. A transaction which spans more than one ledger should be atomic across those ledgers.
  6. Ledgers can contain information that is selectively shared. With whom elements of the ledger are shared is decided by the party who is responsible for that ledger.

These principles give rise to a proposed approach to defining a protocol for the Regulated Liability Network

Scope of RLN-IPs

The purpose of the following recommendations is not to prescribe how settlement is acheived within a domain. Each domain might implement a technology and protocol which is specific to that domain. The following recommendations are specifically addressing how different RLN settlement domains should communicate between each other.

Ledgers and Domains

For a ledger to discoverable it must be identifiable and be able to receive and respond to messages. This implies a naming convention, a public key infrastructure and message routing.

Recommendation 1 - Identifying Ledgers and Domains

Each ledger participating in a Regulated Liability Network must have a unique identifier in the form [domain: ledger]. Each domain is responsible for routing messages within the domain and for providing a single logical point of communication for ingoing and outgoing messages.

Recommendation 2 - A domain must present an interface

Messages into and out of a domain must comply with the RLN protocol. Each domain must publish an interface and method via which messages can be retrieved from that domain and via which messages can be forwarded to ledgers within that domain.

Recommendation 3 - Routing tables

Each domain will keep a routing table of those domains with which it can communicate. Where a domain does not have a direct connection to another domain it will record the number of 'hops' through other domains that it would need to take to access that domain. Routing tables will be propagated through the network of domains.

Communication Method Between Domains

For a domain to communicate with another domain, there would need to be agreement between those two domains as to how each of them receives and sends messages. For example, domain1 might host a Kafka environment and domain1 would consume messages from that environment and produce messages onto that environment. Alternatively, each domain might host their own Kafka environment and they adopt a convention that each manages their own outgoing queue.

Recommendation 4 - Method of Communicating Not Prescribed

The transport protocol between domains will not be prescribed by the RLN protocol. When two domains establish an ability to pass messages between each other, that connection will be recorded in both of their routing tables and propagated to other domains

Determining a Settlement Path

In order for a transaction to settle, one or more ledgers need to be updated. For example, if the sender and the beneficiary are on the same ledger – e.g., they are customers of the same bank, then a transaction can be settled by updating that single ledger.

If, however, the beneficiary is on a different ledger – say the customer of a different bank – then each of those ledgers need to be updated. For the bank of the beneficiary to grant a new liability in favour of the beneficiary, however, it must receive an asset from the sender's bank. This could be a bilateral relationship between the banks where the beneficiary bank receives a credit on the sender's ledger, or more commonly, the sender's bank would transfer value at an independent third party where both banks have accounts – such as a central bank.

In many cases, the sender's and the beneficiary's banks may not have a common entity where they both have accounts – for example they may be overseas banks that do not have an account at the central bank. In this case, they would each use an agent, a bank that does have access to the central bank and can hence make the necessary transfer.

A settlement path is the collection of ledgers that need to be updated for a transaction to be complete and for the beneficiary to have access to the received funds or asset.

Recommendation 5 - The Settlement Path Is Determined at the Time of Transaction

The settlement path should be determined at the time of the transaction. This is done by polling the initiating and beneficiary ledgers and asking them to declare their preferences for external settlement. If there is no common entity, such as a central bank, their agent banks are queried for their settlement preferences. This process is repeated until a common party is discovered in the settlement chain emanating from the sender and that emanating from the beneficiary.

Co-ordinating a Transaction and Declaring Finality

For a transaction to be atomic across ledgers there needs to be co-ordinating activity between ledgers which includes a single determinative event which either finalises the transaction or cancels it.

Recommendation 6 - Each RLN Transaction has a Process for Declaring Finality or Cancellation

Each RLN transaction has a single nominated process which will declare a transaction to be final or cancelled. This process will exist within a nominated domain – which is termed the 'Settlement Context'.

Recommendation 7 - Any Domain May Act as the Settlement Context for Cross Domain Transactions

Each Domain should be capable of acting as the co-ordinating entity for a transaction as the nominated domain or will nominate another Domain to do so. This process will determine the settlement path, will orchestrate the approval process for the transaction and will declare the transaction as final or cancelled.

Message Types

For a variety of technologies to co-exist there needs to be a commonly understood set of messages which are passed between domains.

Recommendation 8 - The Set of Standard Messages Defined in Protobuf

Messages which are passed between different components and domains will be defined in Protobuf.

Recommendation 9 - The Set of Standard Messages

The set of messages which comprise the RLN protocol will include;

  • An initiating proposal – is sent from the initiating ledger to a settlement context [or domain?], proposing one or more transfers. Each transfer includes an asset identifier, an amount, an originating ledger, an originating account, a beneficiary ledger and a beneficiary account.
  • A settlement query. This message is sent recursively from the Settlement Context to the beneficiary and originating ledgers to determine the settlement path between the initiating ledger and the beneficiary ledger.
  • A settlement query response. This message is the response that a participant sends to the RLN detailing one or more ledgers that it can use to settle the transaction asset. These responses are used by the Settlement Context in determining the settlement path.
  • A request for authorisation. This message is sent to each of the ledgers on the settlement path and seeks signed authorisation/rejection for finalisation of the transaction.
  • An authorisation. This message is sent to the Settlement Context to indicate acceptance or rejection of the transaction.
  • Settlement Finality. The Settlement Context will determine when and whether a transaction is either final or cancelled and will send a finality message to all of the participants of a transaction .

Message Authentication

All messages sent between domains on the RLN will be signed and will include a certificate. It is likely that trust will be distributed and that a number of separate PKI regimes will exist. Each domain will determine its own trust parameters in respect of these PKI groups.

Recommendation 10 - Message Authentication

All messages will contain a signature and a certificate.

Assets/Instruments

RLN transactions are in respect of one or more assets. The core function of the RLN is to orchestrate changes of ownership of those assets and it is therefore necessary for participants in a to have a common understanding of assets and a common way to reference those assets.

Recommendation 11 - Instrument/Asset Identifiers not Prescribed

Each transaction should specify the instrument/asset being transferred by reference to a market standard identifier. Whilst it is necessary for participants in a transaction to have a common understanding of the instrument they are transacting; no particular standard will be prescribed by the RLN.

Accounts

An account is a record of a balance which is owned by a person or legal entity.

Recommendation 12 - Account Identifiers not Prescribed

No particular standard for account identification will be prescribed by the RLN