Re: holding of funds

To be clear, if a legacy ledger operator wants to ILP-enable their system
they *should* implement the 3rd option Adrian laid out.

The ledger would run a Ledger Adaptor (something we're talking about but
haven't actively started working on an implementation of) that would expose
a transfer API including the crypto condition based hold functionality.
Internally, that adaptor would manage a hold account on the underlying
ledger and would initiate and fulfill holds as transfers in and out of that
hold account.

This would not represent any additional risk to the participants who have
accounts with that ledger.

The other options should only be considered if the legacy ledger operator
does not want to or is unable to implement the hold functionality.

On Wed, Jul 27, 2016 at 10:35 AM, Adrian Hope-Bailie <adrian@hopebailie.com>
wrote:

> @Andrew: The core ILP protocol deals with movement of funds at a few
> levels of fucntionality below what you're describing. It is a protocol for
> moving money from A to B not for dealing with the legal or regulatory
> aspects of a transaction. Althoug, it is designed in such a way that these
> things can easily be layered on top.
>
> @Javier: To answer your question. The person making the payment on the
> legacy ledger is the person at risk. So they could make up for this risk in
> a number of ways, as you say.
>
> 1. They could have a legal relationship with the connector/receiver on the
> other side of the legacy ledger that protects them from non-delivery by
> that party
> 2. They could use a 3rd party escrow service
> 3. The legacy ledger could offer a psuedo-hold functionality by
> transferring the funds on hold into a suspense account and then from that
> account into the receiver's account when it receives the fulfillment.
>
> In the case of the pseudo-hold then the receiver also shares some of the
> risk as they need to trust the ledger to do the expected transfer when the
> fulfillment is delivered but that is no different to the current scenario
> where both parties need to trust the ledger to behave correctly.
>
> On 24 July 2016 at 23:25, Andrew Bransford Brown <andrewbb@gmail.com>
> wrote:
>
>> FYI, in my opinion, this is something for an in-person discussion.
>> Legal, business, and technical people discussing the terminology and rules,
>> while going through various scenarios.
>>
>> What is a 3-party legal contract?  That doesn't exist at the moment.
>> This is new "law".
>>
>> Andrew B. Brown
>> 10723 River Plantation Drive
>> Austin, Texas  78747
>> (512) 947-8282
>> http://linkedin.com/in/keihatsu
>>
>>
>> On Sun, Jul 24, 2016 at 4:11 PM, Andrew Bransford Brown <
>> andrewbb@gmail.com> wrote:
>>
>>> That is the reason we need a standard protocol.  Those examples are all
>>> internal functions of the application.
>>>
>>> A protocol defines the interface, but does not decide implementation.
>>> The Deliver event might be Bitcoin, dollars, or any good/service.  The
>>> protocol should verify that delivery was made and accepted, regardless of
>>> implementation.
>>>
>>> For example, I haven't decided how to handle 3rd party escrow services.
>>> Note the complexity of the legal contract:
>>>
>>> CommerceID     EventType         Description
>>> Javier         Terms-Escrow      ABC Escrow
>>> Andrew         Accept
>>> Computer       Notice            "This is a binding contract, dependent
>>> on ABC Escrow's acceptance."
>>>
>>> ABC Escrow     Accept
>>> Computer       Notice            "This is a 3-party legal contract."
>>>
>>> Javier         Deliver           Lasagna
>>> Andrew         Deliver           $25
>>>
>>> ABC Escrow     Deliver           Lasagna
>>> ABC Escrow     Deliver           $25
>>>
>>> Computer       Notice            "Contract complete."
>>>
>>>
>>> NOTE:  The "Deliver" destinations can be determined entirely via
>>> algorithm.
>>>
>>>
>>> Andrew B. Brown
>>> 10723 River Plantation Drive
>>> Austin, Texas  78747
>>> (512) 947-8282
>>> http://linkedin.com/in/keihatsu
>>>
>>>
>>> On Sun, Jul 24, 2016 at 3:22 PM, Javier Romero <elmurci@gmail.com>
>>> wrote:
>>>
>>>> Thanks for your responses Andrew!
>>>>
>>>> My question was more if rather than just failing the transaction other
>>>> alternatives had been explored when a legacy ledger doesn't have the
>>>> capability of *holding/authorise temporarily* funds and just admits
>>>> confirmed transactions...
>>>>
>>>> I guess a plugin sitting on top of the ledger could decide depending on
>>>> the situation:
>>>>
>>>> - If less than a certain value, accept the transaction even if it
>>>> leaves a negative balance
>>>> - Use a 3rd party escrow for high values
>>>> - Just fail the transaction if needed if conditions are not met.
>>>> - Write a debit movement on the way out and then a credit movement if
>>>> the payment fails on the way back.
>>>> - ...
>>>>
>>>>
>>>>
>>>> On 24 July 2016 at 15:30, Andrew Bransford Brown <andrewbb@gmail.com>
>>>> wrote:
>>>>
>>>>> The "Deliver" event would not occur, of course.  You could write an
>>>>> event to the "transaction stack":
>>>>> CommerceID     EventType         Description
>>>>> Andrew         Deliver-Failure   "Insufficient funds"
>>>>>
>>>>> The API could include a GetContractStatus(transactionID) that would
>>>>> return ""Undelivered", "Open", or "Partial delivery", or similar.  It would
>>>>> be up to the application to determine who ships/delivers first.
>>>>>
>>>>>
>>>>> Andrew B. Brown
>>>>> 10723 River Plantation Drive
>>>>> Austin, Texas  78747
>>>>> (512) 947-8282
>>>>> http://linkedin.com/in/keihatsu
>>>>>
>>>>>
>>>>> On Sun, Jul 24, 2016 at 5:51 AM, Javier Romero <elmurci@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Thanks Andrew,
>>>>>>
>>>>>> But you would still need some kind of funds holding?
>>>>>> What would happen if, in your example, Andrew doesn't have enough
>>>>>> balance of funds at the time the transaction is executed?
>>>>>>
>>>>>> On 24 July 2016 at 02:02, Andrew Bransford Brown <andrewbb@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Javier, good questions.
>>>>>>>
>>>>>>> I think the following can be useful for separating implementation
>>>>>>> from protocol.  This conforms to contract law.  Your questions pertain to
>>>>>>> the "Deliver" event:
>>>>>>>
>>>>>>> *CommerceID EventType Description*
>>>>>>> Andrew     Offer     $20
>>>>>>> Andrew     Terms     Lasagna
>>>>>>> Computer   Notice    "This is an open legal binding offer."
>>>>>>>
>>>>>>> Christine  Terms     $25
>>>>>>>
>>>>>>> Andrew     Accept
>>>>>>> Computer   Notice    "This is a binding legal contract."
>>>>>>>
>>>>>>> Christine  Deliver   Lasagna
>>>>>>> Andrew     Deliver   $20
>>>>>>> Computer   Notice    "Contract complete."
>>>>>>>
>>>>>>> The above forms what I call a "transaction stack" of events.  So, it
>>>>>>> functions as a data structure, a protocol, and potentially a Contract
>>>>>>> Scripting Language (CSL).  Each event would have a "snippet" to form a
>>>>>>> smart contract.  It will handle any transaction in any currency (or
>>>>>>> barter).  I think this can get ALL ledgers to talk the same language (easy
>>>>>>> to roll this into debits/credits).
>>>>>>>
>>>>>>> FYI, I have 20+ years of IT executive and design experience, a
>>>>>>> degree in Accounting, and a stock trading background.  Comments would be
>>>>>>> appreciated.
>>>>>>>
>>>>>>> Andrew B. Brown
>>>>>>> 10723 River Plantation Drive
>>>>>>> Austin, Texas  78747
>>>>>>> (512) 947-8282
>>>>>>> http://linkedin.com/in/keihatsu
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jul 23, 2016 at 9:51 AM, Romero, Javier (ISBANUK) <
>>>>>>> Javier.RomeroColomo@isbanuk.com> wrote:
>>>>>>>
>>>>>>>> When the legacy ledger does not have the capability of holding
>>>>>>>> funds, what would be the proposed solution?
>>>>>>>>
>>>>>>>>    - Assume the risk in the same way as an offline card
>>>>>>>>    transaction (depending on amount etc...)?
>>>>>>>>    - Get the balance at the moment of sending the instruction and
>>>>>>>>    then, on the way back where all the crypto conditions have been met apply
>>>>>>>>    the transfer if there are funds or fail it in case there aren't?
>>>>>>>>    - 3rd party escrow?
>>>>>>>>
>>>>>>>> I guess each case needs assessment but wanted to see if you guys
>>>>>>>> have a clear view in this.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> **********************DISCLAIMER*****************
>>>>>>>> This message is private and confidential and it is intended
>>>>>>>> exclusively for the addressee. If you receive this message by mistake, you
>>>>>>>> should not disseminate, distribute or copy this e-mail. Please inform the
>>>>>>>> sender and delete the message and attachments from your system. No
>>>>>>>> confidentiality nor any privilege regarding the information is waived or
>>>>>>>> lost by any mistransmission or malfunction.
>>>>>>>> Any views or opinions contained in this message are solely those of
>>>>>>>> the author, and do not necessarily represent those of ISBAN, unless
>>>>>>>> otherwise specifically stated and the sender is authorized to do so.
>>>>>>>> E-mail transmission cannot be guaranteed to be secure,
>>>>>>>> confidential, or
>>>>>>>> error-free, as information could be intercepted, corrupted, lost,
>>>>>>>> destroyed, arrive late or incomplete, or contain viruses. ISBAN does not
>>>>>>>> accept responsibility for any changes, errors or omissions in the contents
>>>>>>>> of this message after it has been sent.
>>>>>>>> This message is provided for informational purposes and should not
>>>>>>>> be construed as a solicitation or offer to buy or sell any securities or
>>>>>>>> related financial instruments.
>>>>>>>>
>>>>>>>> *********************AVISO LEGAL **********************
>>>>>>>> Este mensaje es privado y confidencial y solamente para la persona
>>>>>>>> a la que va dirigido. Si usted ha recibido este mensaje por error, no debe
>>>>>>>> revelar, copiar, distribuir o usarlo en ningun sentido. Le rogamos lo
>>>>>>>> comunique al remitente y borre dicho mensaje y cualquier documento adjunto
>>>>>>>> que pudiera contener. No hay renuncia a la confidencialidad ni a ningun
>>>>>>>> privilegio por causa de transmision erronea o mal funcionamiento.
>>>>>>>> Cualquier opinion expresada en este mensaje pertenece unicamente al
>>>>>>>> autor remitente, y no representa necesariamente la opinion de ISBAN, a no
>>>>>>>> ser que expresamente se diga y el remitente este autorizado para hacerlo.
>>>>>>>> Los correos electronicos no son seguros, no garantizan la
>>>>>>>> confidencialidad ni la
>>>>>>>> correcta recepcion de los mismos, dado que pueden ser interceptados,
>>>>>>>> manipulados, destruidos, llegar con demora o incompletos, o con
>>>>>>>> virus. ISBAN no se hace responsable de los cambios, alteraciones, errores u
>>>>>>>> omisiones que pudieran hacerse al mensaje una vez enviado.
>>>>>>>> Este mensaje solo tiene una finalidad de informacion, y no debe
>>>>>>>> interpretarse como una oferta de venta o de compra de valores ni de
>>>>>>>> instrumentos financieros relacionados.
>>>>>>>> Ref:[PDB#015]
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


-- 
Evan Schwartz | Software Architect | Ripple
[image: ripple.com] <http://ripple.com>