W3C home > Mailing lists > Public > public-interledger@w3.org > February 2016

Re: RTGS - Warnings on realtime settlement using distributed ledgers

From: Evan Schwartz <evan@ripple.com>
Date: Fri, 5 Feb 2016 10:43:54 -0800
Message-ID: <CAONA2jXJy5-iKC2FDAfs66No=-PZ23xiQ8cRuZKp5-S4deopCQ@mail.gmail.com>
To: Michael Smolenski <michael@midasium.com>
Cc: "public-interledger@w3.org" <public-interledger@w3.org>, George Samman <gsamman@midasium.com>, George Samman <george.samman@gmail.com>
Very interesting post, thanks for sharing!

One note about ILP in this context: ILP is perfectly capable of working on
a deferred net settlement basis.

Connectors facilitate payments between different ledgers meaning they must
be able to accept payments on one ledger and pay out on another. However,
from the protocol's perspective we don't care why the connector is able to
provide this function as long as they are indeed able to.

A connector could be providing RTGS or it could be a jointly operated
entity facilitating payments back and forth up to some limit defined by the
banks operating it. The parties operating the netting connector could
determine for themselves how often they want to settle the outstanding
balances tracked by that system.

On Thu, Feb 4, 2016 at 8:41 AM, Michael Smolenski <michael@midasium.com>
wrote:

> Sharing the following with Interledger community.
>
> Personally, I’m all in favour of real time settlement of inter-bank
> payments as opposed to the current over-night netting out process, but
> George’s article below gives some healthy warnings on the subject:
>
> https://twitter.com/sammantic/status/695240026779709440
>
> I believe that engineers can apply queuing theory models to the concept of
> a distributed settlement system to reassure decision makers that it can be
> a well regulated and a stable system...
>
> Cheers,
>
> Michael Smolenski
>
> web: midasium.com
> email: michael@midasium.com
> mb: +34 666 122 800
>
>


-- 
Evan Schwartz | Software Architect | Ripple
[image: ripple.com] <http://ripple.com>
Received on Friday, 5 February 2016 18:44:43 UTC

This archive was generated by hypermail 2.3.1 : Friday, 5 February 2016 18:44:43 UTC