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

Re: Connectors and market makers (left-over question from the workshop)

From: Jehan Tremback <jehan.tremback@gmail.com>
Date: Wed, 2 Mar 2016 13:20:42 -0800
Message-ID: <CABG_PfSzdp+_7T+AEZUOCUd1-xa1PVyx_VRNkW3Gpw2r=fHBVg@mail.gmail.com>
To: stéphane canon <stephane.canon@scarlet.be>
Cc: Evan Schwartz <evan@ripple.com>, Interledger Community Group <public-interledger@w3.org>
The connector must have money in accountB@ledger2 to pay out, aka
liquidity. I suppose that two ledgers holding the same token could have
their own connector which would transfer money directly between the ledgers
by some system other than ILP, but this is outside of the scope of ILP.


On Wed, Mar 2, 2016 at 1:15 PM, stéphane canon <stephane.canon@scarlet.be>

> If the payment does not require an exchange, is there a problem of
> liquidity ? the connector is receiving the money on his accountA@ledger1
> and paying from his accountB@ledger2.
> If the payment requires an exchange, I understand the market maker must
> provide some liquidity in the currency of the target currency.
> Stephane
> Le 2 mars 2016 à 16:54, Evan Schwartz <evan@ripple.com> a écrit :
> In order to facilitate payments between two ledgers, the connector needs
> an account on one ledger that it can receive money into and an account on
> another that it can pay out from.
> If the connector represents a currency exchange it could be set up such
> that it has two pooled accounts, one on each ledger, that represent the
> total balances of all of the market makers or traders trading on the
> exchange. When a payment goes through, the balance in the exchange's
> account on the first ledger will increase, its balance on the second ledger
> will decrease, and some number of orders on the exchange will be consumed
> and the market makers' balances with the exchange will be updated
> accordingly. The rates offered by this type of connector would likely
> represent the top of the order book.
> Alternatively, a connector could be operated by a single market maker,
> bank, or institution. In this case the quotes it gives would be determined
> purely by that institution and it would be the one providing the liquidity.
> Nevertheless, the operator of the connector would still need to hold an
> account on each ledger in order to receive money on one and pay out on the
> other.
> The role of the notary is actually quite different. The notary does not
> receive any money and is not in the flow of the transaction in that way.
> The notaries are just there in atomic mode to serve as witnesses to enforce
> a timeout dictating how long the recipient has to sign and submit the
> receipt. The reason for this is that if there are different timeouts on the
> transfers on each ledger, the full payment will not be completely atomic.
> However, connectors won't want their funds to be tied up indefinitely. So
> instead of having the timeout enforced on each ledger, atomic mode uses a
> notary or group of notaries that come to consensus about whether the
> receipt has been received in time. This way, each of the ledgers can
> actually process the transfers at distinct times, but you can be sure that
> they will all either execute the transfers or all of them will roll them
> back, because all of the ledgers will base that on the decision of the
> notaries.
> On Wed, Mar 2, 2016 at 11:36 AM, stéphane canon <stephane.canon@scarlet.be
> > wrote:
>> "Connectors provide liquidity to send payments between different ledgers."
>> Is a connector really providing liquidity? Up to know, I was seeing the
>> connector as a notary: receiving and releasing money. He would need
>> liquidity if there is a currency exchange and then he would be a market
>> maker.
>> > Le 1 mars 2016 à 19:42, Evan Schwartz <evan@ripple.com> a écrit :
>> >
>> > Connectors provide liquidity to send payments between different ledgers.
> --
> Evan Schwartz | Software Architect | Ripple
> [image: ripple.com] <http://ripple.com>
Received on Wednesday, 2 March 2016 21:29:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 21:29:18 UTC