Sort:  

Most recently I've been thinking that complex financial instruments are all better handled at the 2nd layer. In other words, bonds, markets, escrow, etc would all be implemented there. Any link to base layer tokens (if desired) would be done thru proxy tokens issued via some kind of multisig setup.

This 'second layer' would be jsons written to hive and managed largely by 3rd parties?

Is there a technical reason that precludes allowing hive to organically escrow a token created by locking hbd?

A gui would have to be created/incorporated into the existing front ends, but a base layer function that allows me to transfer the token/bond to another account through an escrow feature seems the most elegant way to me.
To have to introduce 3rd party risk would be a deal breaker outside the community being small enough that we can all know each other's reputation for trustworthiness.
Simply creating another H-E type arrangement doesn't solve the 3rd party risk issue, for me.
If there is a technical reason that is a bad idea please state that so I can better understand why we have waited this long for this feature.

1st layer functions don't know anything about 2nd layer stuff. So you can't escrow 2nd layer tokens.

But you can create a 2nd layer escrow function.

You can achieve all functions on the 2nd layer just like on the first layer: it's just a different group of people running different software.

Essentially with 2nd layer, you can run one or more separate "blockchain protocols" with their own rules that just piggy back of the p2p network and transaction ordering functionality of the 1st layer. So the "trustworthiness" of a specific 2nd layer protocol just depends on how that protocol is designed. There's no reason it can't be just as trustworthy as the 1st layer protocol.

So you can't escrow 2nd layer tokens

Creating this token at 1st layer would slow the chain?
Too much data to be tracked?

it's just a different group of people running different software.

It is possible that a malicious update could be successful?
At least for the amount of time it takes to revert the changes?
Keychain would be my example.
I couldn't defend against a malicious update absent the social aspect of hive tipping me off to delete the app.

So the "trustworthiness" of a specific 2nd layer protocol just depends on how that protocol is designed.

So with open source distributed nodes keeping everybody honest a 2nd layer is just as secure as hive?

How are you envisioning the functioning of 'bonds'?
A '2nd layer' gui that manages 'bond tokens' according to the contract at the time of escrow?
ie, I stake hbd for a set period of time and receive interest, to liquidate the position I send the token to a 2nd layer contract that executes according to its parameters?