For the record, I have been voting for this motion all along. Others have not though, most likely due to the influence Phoenix would receive if this passed. With Phoenix no longer a factor in the motion, I think there is a better chance other shareholders will vote for it and we can move forward.
Motion updated, we need elect members of RSOT team one by one.
https://daology.org/proposals/7ec027e1c3d7596a414148c8b8761e8cff2a91a1
1f8d60f8c1ab0016aa2653fd9c7ef6de89d7b8bb
As per https://daology.org/proposals/62054f625111fb3ea92ebd6957fb2588b280ced8
Sabreiib applies to join the RSOT, will try best to contribute B&C project.
I like the updates! Voted and will apply for the RSOT team aswell. I hope @mhps is also willing to join the team!
Voting now. @Sabreiib, I think it would help with visibility if your RSOT application was posted in its own thread, rather than buried in this one. It might be possible that people donât realize you updated this motion, so your application should draw attention to the fact that we need more RSOT applicants.
Not yet working on it, I have voted for your proposal and motion to join with my remaining shares however.
It looks like a reasonable proposal to me.
It is important that B&C shareholders reach some consensus on who and how funds should be handled. Until that occurs, funds canât be spent on any new initiatives, such as paying for an exchange listing or purchasing NSR as I have proposed. I would like to finalize motions to move forward with those endeavors, but that isnât really practical until shareholders decide who should hold the funds.
No consensus has been reached on the formation of RSOT and who its members should be. Shareholders are rightly frightened of multisig groups given that these groups have been the primary cause of the loss of about 2 million USD in NuShares, BlockShares and NuBits in recent months. FLOT has been our most costly mistake, and B&C shareholders are demonstrating due caution to avoid a repeat of the severe failures of FLOT.
I have talked about a 2 of 3 group with @jooize and either @Sabreiib or @cryptog as the third signer. Neither @Sabreiib nor @cryptog are particularly eager to sign up for that. But we shouldnât delay any longer.
That is why I plan to create a motion soon that will mandate B&C development funds be transferred to my custody. My guess is consensus can be forged for this action with defined rules for accountability. Later, the funds can be transferred to a multisig group once a better plan to make those groups accountable to shareholders is in place.
I plan to present monthly reports of total funds remaining and spending reports by category, probably with compensation and expenses as the categories. I will charge a 3% handling fee for all funds disbursed. I wonât reveal addresses because our contractors want some privacy about what they are being paid. It is easy to be critical of this small bubble of privacy in our otherwise incredibly open solution, but critics need to understand that making exact compensation arrangements public is undesirable to many contractors and such a policy would make it more difficult to secure the professional help we need. @sigmike has clearly stated his preference for privacy in his exact compensation arrangements, for instance.
I realize some will not support transfer of B&C funds to me. I would encourage such people to make constructive counter proposals. Saying you donât like it doesnât count. Where shareholders have rejected multisig groups for now, this seems like the most sensible way forward.
No. I only said I was not sure it was in everyoneâs interest to make it public when one person asked for it.
I will hold the dev fund if RSOT motion passed. BTW, both @sigmike and @eleven have revealed their ID in linkdin. I wonder why we should protect nobodyâs privacy.
Or @phoenix will write codes for B&C and wants to keep privacy?
Not sure about that either or donât understand. Are you proposing to hold the funds outside a multisig?
Iâm confused why we canât get to a majority for multisig. Do shareholders really want all eggs in one basket?
Or do we only have one big shareholder with many faces like with Nu?
BTW Iâve added this motion to my datafeed for what it is worth.
I will hold the fund with other 5 RSOT members.
BTW, I prefer to lump sum contract . We pay the developers when they finish some software upgrade.
Good, agree with lump sum proposal. Still can be split in e.g. 50% upfront and 50% on successful delivery.
Similar to the NuDroid contract.
Anything appears to be better than handing over the dev funds to @Phoenix who doesnât seem trustworthy considering the shady renaming from @JordanLee to @Phoenix.
Even trusting @Sabreiib with the funds would create less uneasy feelings.
Moving the funds to RSOT multisig should clearly be the preferred way to go for shareholders.
Make sure to make the multisig 4 of 6 to require a majority of members to move the funds - just in case there are controversial decisions, consensus on RSOT level is required.
Btw. the dev funds are held in NBT, right?
Does NBT support multisig with 6 signers? I think I remember that FLOT had 5 signers. Was that due to organizational or technical reasons?
Voting.
After careful consideration, I think such a multisig wallet is reasonable.
We would not have the same problem of âaction slownessâ that FLOT underwent for liquidity operations.
If it is not efficient enough, we can always adopt @Phoenix s proposal.
Iâm baffled that this hasnât past, can any shareholders that oppose this motion clarify why they havenât voted or what they would like to see changed? After all that has happened it seems paramount to me that we get the developer fund under shareholder control as soon as possible.
I am opposed to the formation of RSOT. The main reason is that I donât believe the community has enough qualified signers right now. I would like to see a 3 of 6 group, but 2 of 4 might work. However, I canât name 4 signers I have enough confidence in who have also indicated a reasonable commitment to being a signer.
The failure of FLOT to move funds to keep liquidity operations running in June was a 2 million USD failure. With this kind of unaffordable waste and devastation in our very recent past, we need to be wary of a similar failure. I donât think we have addressed the problems that occurred with FLOT in a manner that gives confidence in a new multisig group.
I am satisfied with the selection of reputed signers, however. Because all the signing they will do is automated, the risk of poor judgement or insubordination to shareholders is low when compared to manual signing groups like FLOT and RSOT.
In the case of FLOT, we found that signers simply werenât informed enough about liquidity operations to function in their role. My guess is that signers that would be chosen for RSOT would be much less informed than me about issues that need to be understood to competently allocate and spend funds.
On a related topic, our problem with FLOT wasnât that they spent funds on items they shouldnât have. Rather, there was a consistent pattern of inaction when funds very much needed to be transferred. The problem of not moving funds when they should be appears much more likely than inappropriate transfer of funds. Accordingly, instead of 2 of 3, 3 of 5 or 5 of 8, I would like to see 2 of 4, 3 of 6 and 4 of 8. This also applies to reputed signer configurations.
One globally distributed group of 5 of 8 signers take 6-18 hours to sign if there is complete consensus, simply because people wake up and able to sign at different hours. For a globally distributed 3 of 5 signers itâs 4-18 hours.
FLOT was formed to have one week signing requirement, as told by the architect after repeated questioning from me. FLOT members promised 24 - 48 hr reaction time and they mostly kept it.
Reaction time is not signing time. If there is no easy consensus among the members the time to sign is unknown. You can shorten signing-time-with-consensus by adding more groups. Reducing the number of members but only keep one group as
will not solve the problem. There is little you can do to shorten signing time if there is no majority consensus.
So donât blame the FLOT and donât repeat @JordanLeeâs mistake.
I think FLOT performed beyond what was promised and to be expected. I know you see FLOT or specific actions FLOT took as being responsible for losing the peg but I strongly disagree with that notion. The peg was lost because our reserves were to small and couldnât handle the large selling pressure that we experienced in a matter of days. Why were the reserves to small? Because we spent 555 bitcoins on an inefficient buyback program initiated by Jordanlee. You try to scapegoat the small increase in buy offset that was only done when our reserves were already next to empty (roughly 20k USD left if I recall correctly) as the reason the peg failed while it most definitely wasnât.
Now I know we wonât agree on the exact reason and itâs been debated to many times already. Regardless of your interpretation of the perceived âfailingâ of FLOT I donât see how this is relevant to a multisig team that would hold developer funds. For as far as I can tell itâs mainly about holding the funds in the hands of multiple shareholders instead of a single entity that can vanish overnight (as we have experienced). No funds held by FLOT were ever intentionally misused, stolen or lost and multiple members of that team are still around so I have trouble understanding your claim that the community doesnât have enough âqualified signersâ at the moment.