I would like to see this being handled by a (layer 2) DAO. While there appears to be only $8400 of exposure there is no good reason to use a non-multi-signature mechanism if one does exist. After all getting people to change their votes on a proposal could take weeks to months depending on where the support is at the time of a misstep. Not only that, technical difficulty, as it's put here, would be mitigated from a system of peers where no one party has to perform actions.
You are viewing a single comment's thread from:
I agree, that would be a better solution in multiple ways at some point, but we can start with this, essentially as a pilot.
I have a DAO written and functioning handling the DLUX token at dlux.io. It provided atomic swaps for DLUX to Hive/HBD by locking open orders in Escrow Transactions between collateralized nodes. This paradigm is being extended to handle partial fills by setting up a multi-sig account between the peers holding the highest amounts of collateral. This DAO paradigm which forms a consensus off the Hive blockstream could also query account parameters that are altered by virtual ops(not on the blockstream, not easily ordered currently) and then autonomously perform these actions.
I would appreciate your support for these developments that not only extend the usefulness of Hive, but the trust required to maintain operations like this that you proposed. A DAO with a multi-sig wallet would even be capable of building a market for the non-transferable Account Creation Tokens held between it's operators or maintaining a pool of cross chain assets for swaps.
Proposal 148
Proposal 152
I expect this would be functioning sometime this month, this being a perfect use for testing, and tested and ready for others to use and build on by April for the community at large.
I will consider supporting your proposals and also supporting other uses cases, but I don't want to tie the HBD stabilization proposal directly to it at this time. I believe the degree of trust necessary here (unlike other cases) is minimal and tying it to a second level dependency prior to such dependency being firmly established and stable would be a negative.
Thanks! I agree this proposal is needed regardless of the tools that could make it trustless.