Re: Non-currency asset transfers & Connector commissions

Hi David,


> Indeed, this has been on our minds also. I think there are few possible
>> scenarios, and I can imagine our community to come up with even better ones.
>> In general, one would like to see a payment receipt for the charges in
>> order to transfer the shares. Hence the traders would need to connect -
>> besides their shares ledger - to an ILP compatible payment ledger.
>>
>
> This is an interesting approach -- it seems like you're proposing that the
> coordination of, in my example, the "share" transfer and the
> "currency/commission" transfer be done outside of ILP?  Or am I mis-reading?
>
> I was trying to think about how a sort of "commissioning" system could be
> accomplished *inside* of ILP, maybe as an associated "side-car" transfer or
> something like that.  So, if I transfer 10 shares of XYZ, I could also
> specify an additional transfer in currency to *pay* a connector for the
> share transfer (?)
>
> Without something done *inside* of ILP, it's difficult for me to see why a
> connector would fulfill an ILP transaction that they can't profit from
> (i.e., a non-currency transfer), which tends to limit ILP to either systems
> that coordinate commission payments independently and outside of ILP, *or*,
> a global ILP system that only handles things like currencies that can be
> fungibly "commissioned" by deducting a certain fee from the transfer.
>
> I'm curious to hear any other thoughts from the community around this
> topic of connector "fees."
>
>

My proposal is to everything inside ILP, but to hook up a mix of ledgers,
see image
[image: Inline afbeelding 1]

The asset ledgers could be of the same type or of different types.
In parallel the fee would be placed in escrow between the originator A and
the connector Co.

This would mean, that in order for B to redeem the asset, He would need to
present a receipt to the Connector (Co).
Once B redeemed the asset, then Co can redeem the fee and the asset on
ledger 1.

All the receipts are encoded using the ILP fulfillment URI's (which is a
serialization of the ILP crypto-conditions
<https://interledger.org/five-bells-condition/spec.html>).
The execute condition of the escrow of asset ledger 1 would contain both
receipt B as well as receipt Co.


> The payment ledger would then create an ILP fulfillment URI to fulfill the
>> shares transfers that are in escrow. It's still a bit vague but it would be
>> truly cool if we can spin up a demo for this. (Actually I would be
>> interested in doing so on the ILP hackaton 6/july in London). I can imagine
>> many more use cases that would follow such a pattern
>>
>>
> Can you give more specifics here - I'm somewhat new to ILP, and not
> familiar with the notion of a "fulfillment URI."  Is this your term, or
> something from ILP?
>

See above


>
> But ILP allows to connect homogeneous ledgers of various asset types,
>> given there are suitable connectors/exchanges. The latter will be an
>> interesting topic for ILP.
>>
>
> Can you elaborate more on this idea?  Is this idea to chain the share
> transfer and a commission into a single ILP transaction somehow?
>
>
I guess there are multiple ways to mix asset ledgers with currency ledgers
- besides the parallel approach above. One can think of liquidation of the
asset in an intermediate ledger.
eg: <A> --- assets ledger --- <Co1> --- currency ledger --- <Co2> --- asset
ledger --- <B>


> Moreover, it would be interesting if there would be a formal registry of
>> asset types.
>>
>
> Agree, although it seems like this might already exist for certain types
> (e.g., for currencies ISO-4217 <https://en.wikipedia.org/wiki/ISO_4217>).
> I suppose there must be other existing standards for various asset classes,
> but it could be an interesting sub-project in the ILP work to consider
> standardizing something like "classes" of asset.  For example, "currency",
> "bond", "stock", "ticket", etc, and then potentially delegate to existing
> standards for specific types of each class (e.g., "currency" is defined by
> ISO-4217, etc).
>

Yes, In fact we are working on an Intelectual property spec (COALA IP
<https://www.w3.org/2016/04/blockchain-workshop/interest/mcconaghy.html>,
under construction) for formally defining media licenses, together with IPFS
<https://ipfs.io/>, IPLD <https://github.com/bigchaindb/py-ipld>, and the LCC
framework of the copyright hub <http://www.rdi-project.org/#!faq/c11lh>.


> Thanks for all of your input and answers -- it's a fascinating topic!
>
> 100% agreed, would be great to see the thoughts from the rest of our
bright community...


Cheers,


-- 


Dimitri De Jonghe, PhD
Developer

+49 157 5946 2122 | Twitter <https://twitter.com/DimitriDeJonghe> | LinkedIn
<https://www.linkedin.com/in/dimitridejonghe> | GitHub
<https://github.com/diminator> | S <https://facebook.com/>kype:
dimi.dejonghe
[image: Logo] <https://www.bigchaindb.com/>

BigchainDB GmbH
Wichertstr. 14a, 10439 Berlin | Managing Director: Bruce Pon | Registered
in Berlin HRB 160856B |info@bigchaindb.com | www.bigchaindb.com