Ah ok. How was BURN wallet created?
I agree with this 100%. There definitely should be other criteria. Airdrop and Kyc do not directly address our questions. Only team is privy to this information so using it as reasoning is circular logic of sort.
Maybe to clarify further:
It is possible to create fully customized wallet addresses (like the burn or voting addresses), with the exception of their last 6 characters. This can be done by both team members or community members. But these wallets can not be used actively. Any funds send to them are lost forever.
So when I said that custom wallets can not be created other than via pure luck (lots of trying), I was referring to wallet addresses that can actively be used and to which the private key is known. Hope that clears it up 
Hey Martin! Thanks for sharing your thoughts. I am sure Nikola will share his too, but in the meantime I will make a few points:
- First of all I want to emphasize strongly that the selection of the wallet addresses was NOT based in any way on the level of trust we have for these people. In fact, the entire point of the trustless group (as is also part of its name) is that it is considered trustLESS. So the logic behind this is that we assume to know absolutely nothing about these wallets (or their owners).
- Instead what matters is that they have a vested interest in the ecosystem that far exceeds any financial gain they could get from trying to cheat the system. So the goal is to take advantage of the self-interest of the individuals as opposed to trying to make judgments about who may or may not be an ethical person.
→ This point is very important, because there is a very key philosophical/strategical distinction here relative to a system where we try to identify ethical/moral people, which is something very subjective and difficult to do. Usually this kind of assessment can even fail within family members - let alone via the avatar of someone we don’t really know other than through Telegram. So personally I would prefer to stay in the realm of trustless mechanisms (which I consider safer) as opposed to pivoting towards a system that would require me to vote whether I trust someone or not (which I would honestly not really know how to accurately determine without even ever meeting the person). - My understanding is that this proposed list is meant to act as a starting point, which combines the three different groups and forces them to work with each other. Thus adding another layer of security on top of the existing ones. Adding/removing individuals is always possible.
Just wanted to share these thoughts. I am not opposing any of the ideas that were put forward. But it’s important to clarify the existing proposal and make sure everyone understands the idea behind it, before moving on to potential alternatives. I am sure Nikola will also add his perspective
3 Likes
One of the wallets on the short list is my wallet. I would gladly take the role of being one of the Treasury Admins.
3 Likes
Can you please confirm a few points?
- Would a YEA vote for this proposal also be approving the proposed members as well? 4 of the fixed and whichever 4/8 trustless members you listed?
- You mention the 5/8 consensus is “tentative”. Who decides the quorum number? Would it ever change? What process (procedural and technical) would be suggested to change it?
- If you removed a member by vote, would you then put forth a proposal to the community to decide the replacement?
- Is the core hydra team able to add/remove members and change the quorum requirement without a consensus vote?
Thanks
Oops. Now we’ve just lost the LESS part of trustLess, because we trust you
Well, somehow I feel more comfortable with the list of suggested wallets after this.
I only wish that other owners from the list would acknowledge their wallets, even though there’s no way to confirm that they actually own that wallet.
1 Like
The only way to show that I own that wallet is that I get a number between 0 and 1 hydra and that I need to send that amount to another wallet.
1 Like
Just to clarify, Trusted members are the ones who are elected based on a certain set of criteria that are fundamentally needed to establish a high degree of trust.
I absolutely agree and support the community to be more open to electing high-reputation trusted treasury admins.
However, it is essential to understand that it is impossible to establish trust with someone who is anonymous or pseudo-anonymous. I think it is the basic principle not only in the context of governance but in general in any transaction in life.
If any of the proposed individuals are willing to go through revealing who they are to the community and vetting their identity, expertise, and background, this can easily be included in an on-chain vote, similar to the current proposed Trusted Admins.
I would personally be supportive of such expansion (assuming the proposed admins have a strong track record with min 2 years of contribution to the Hydra ecosystem and are approved by the rest of the community in the vote).
- That’s the goal, yes. To begin with this setup and then re-evaluate continuously if it can be improved.
- In the context of the Gnosis multi-sig, the consensus is known as “policy”. The policy setting will be finalized once we know which of the trustless members will enroll. The goal is to ensure no potential stalling of decisions due to lack of engagement, and also enable robust security.
There are some default behaviors embedded in Gnosis when adding/removing new admins.
- When proposing to add new admin/ remove new admin, the exact same rules are present in terms of policy.
- When adding a new admin to the multisig, the policy does not change by default.
- Policy change has to go through the same voting consensus.
- I think this is something the community has to decide collectively. Keep in mind the end goal is the multi-sig to act as an admin of key infrastructure projects. This may involve dozens of operations on a weekly basis. Being present for each one of them will be a big responsibility. We need to ensure a safe, secure, and at the same time reliable, setup of admins so that operations can be efficient.
What matters more is starting in this direction and as always leaving room for improvement.
- No. All members are equal and only the policy/consensus matters. A founder’s vote is just as important as anyone else. As emphasized in the proposal, all three groups will need to work closely together to make each proposal approved or rejected.
By having a 5/8 requirement, and the proposed
- 2 founders admins
- 2 key ops admins
- 4 trustless community admins
multiple different setups can be formed to have the same outcome for each vote.
For instance, the 5 votes could be 4 trustless admins + 1 founder
or
4 trustless admins + 1 key ops (e.g. Florian or Myra as DAO secretary).
or
2 founders and 3 trustless admins.
I find this a particularly important step in the enhancement of the security.
Also since the 4 community members are likely to be pseudo-anonymous, it is important to have at least one trusted member in the consensus.
I have a high level of trust in all other trusted members and am confident that each one will make a great supervision of whatever activity is happening.
Ensuring this policy will be in place will be easy, once we know how many of the trustless admins have enrolled.
For instance, if there are 3 Trustless Admins and 4 Trusted, it can be 5/7, or if there are 8 Trustless Admins and 4 Trusted, it can be 9/12 to ensure at least one Trusted is necessary for consensus. And vice versa if the numbers of enrolled are on the low side, we can ensure one Trustless admin is required as a form of supervision form the broader community to the Trusted admins.
Something to also keep in mind is the DAO Secretary is elected by the broad community via an on-chain vote. So in a certain way, Myra is also representing the broader community.
If 4 trustless admins enroll and we go for 5/8 policy, the fact that the DAO Secretary together with 100% of the trustless admins will be capable of execution is pivotal in my opinion as it will come as a testament to how the security can outgrow the seed phase where it heavily relied on its founders for securing the treasury.
Lastly, I want to again remind everyone that the Treasury Admins have no authority over the decisions of the treasury. They just execute whatever the community decides via mandatory on-chain voting. So this is mostly a discussion about technically improving the security of executions.
Treasury Admins have no “voice” when it comes to executing the transaction. They simply follow the governance decisions. They are a technical extension of the DAO.
And if any Treasury Admin shows even the slightest nuance of conflicting with the governance decision (e.g. artificially delaying, or arguing against a proposal that has been decided by the collective DAO that represents 100% of the community), then this will be taken as a sign of corruption. In such cases, the harshest responses should be enforced by the remaining admins, ensuring consensus is immediately enabled for kicking out the rogue admin and adjusting the policy.
In terms of risks, I would classify them as such:
- Technology Risks: these arises out of the smart contracts and protocol. To mitigate this we try to adopt the best practices in the industry of forking and re-using technology that is already vetted and battle-tested
- Risk of private key hacking: This is mitigated by having more than 3 admins, as hacking simultaneously multiple independent accounts at the same time is almost impossible
- Risk of private key loss: this is mitigated by having a consensus policy which ensures that is not too tight. For instance, a 5/5 policy is very secure against hacking, but is weak against key loss, as only a single lost key would lead the multisig to a permanent stall.
- Risk of theft due to Coup d’état: This is a hypothetical case, where a small number of individuals overtake the operation. This can be mitigated by ensuring the consensus policy is not too loose. For instance, a 3/8 policy would enable this attack vector as it would take 3 admins to conspire and drain the funds. When there’s a strong set of criteria for selecting the admins and a strong policy that far exceeds 50% as a consensus, this risk is largely mitigated.
- Risk of a stall due to Coup d’état This is a case, where a small set of admins decide to not cooperate leading to a deadlock. This is an edge case where funds are not at risk of being dumped, but since the consensus requirement can not be met in a vote. E.g. in a 9/12 policy if 4 admins conspire and decide to deliberately work against the DAO’s will, then the remaining 8 won’t be able to reach the policy. The result will be a stall with no execution happening in any direction. This can be mitigated by additionally coordinated penalty measures where for instance, the community and the DAO can coordinate a defensive hard fork as a protocol measure, which would invalidate the 4 corrupt admins and in addition have their balances wiped out of the new forked chain. This can create a strong risk for attempting such an attack and since it is trivial to spot, should be disadvantageous.
and lastly, although not a security risk, it is still worth mentioning
- Risk of loss due to lack of engagement: some rare events require fast response. E.g. security patching, migrating liquidity, re-deploying LM incentives, or other operations that need timely execution of treasury shifts. In such an edge case, if the treasury admins are not available or not taking the responsibility seriously, it could take days or weeks for executions to take place. These delays could damage the system and should be perceived as a form of attack arising out of negligence. To be mitigated, improving communication among Treasury Admins is key and also enabling a maximum window period for an admin to engage back when asked to. It can be e.g. up to 12 hours beyond which the admin can be deemed “lazy” and kicked out.
The 5/8 policy and a 12-hour window seem like an optimal approach as a start which can be optimized later if needed.
3 Likes
Thank you for the detailed response.
Very good approach. I will support it. May be the community group could be expanded a little in order to be sure that you will have faster responses when needed. I am available to contribute too.
2 Likes