Please comment your vote if possible. Thanks. 
2 Likes
love the idea behind this poll. it actually kind of reminds me about the separation of duties portion of sox compliance in the US (but in a good way). given recent events like yemel’s security disclosure (source: Security disclosure - DAO Committee Incident), i think this is a smart approach to de-risking one of the most important aspects of the platform.
in addition to these changes, the bug bounty program is robust enough (and has a proven track record of paying out) that anyone who finds a vulnerability in one of DCL’s smart contracts would be braindead if they did anything other than disclose it responsibly and go through the bounty process. for example, why would an enterprising hacker steal a bunch of land parcels and absolutely crater the land prices when they can get paid $500,000 USD for honest work? it just doesn’t make sense to do anything else from a money-motivated hacker’s perspective.
2 Likes
I agree on some points, but I am not in favor of this proposal as a whole.
Add SAB a mandatory function of overseeing DAO transactions including DAO Committee actions by certain filters, for example if the transaction is more than a certain sum or transaction frequency.
The SAB are subject matter experts on the security of smart contracts. They are not paid, they are volunteers. They should not be bothered except in case of a really serious problem such as a bug in the smart contracts. Asking for “mennial” things, of which they are not experts, particularly out of unpaid subject matter experts that volunteer and could probably charge hundreds if not thousands of dollars per hour is, IMO, weird.
Increase transaction execution time delay. For example, from 24 hours to 48 hours.
This is a tradeoff security parameter. I’d like to point out that there’s no time limit if all 5 members vote. The scenarios for possible outcomes of votes are:
- 3 members vote yes: transaction can be executed in 24 hours since vote creation
- 3 members vote yes, one votes no: transaction is blocked (needs 100% agreement)
- 2 members vote yes: transaction is blocked (needs one more voter)
- 5 members vote yes: transaction is executed immediately
Imagine the LAND smart contract is hacked and someone can start to transfer LANDs. Wouldn’t you like to patch it as fast as possible? What if one of the SAB members is unreachable for 24 hours? This parameter, if increased, decreases the security of that scenario (the bug can’t be patched in the next 24 hours). At the same time, increasing from 24 hours to 48 hours increases the security against collusion from a subset of three SAB members.
Interview SAB members by the community once a year to ensure they are alive, in their right mind, have not lost the keys and are committed to continue performing their responsibilities. (Interviews can be held in Town Halls for example.)
I am of two minds about this. Doxxing details about how they live or what they think might reduce their security. On the other hand, I think it’s great to have a public discussion about who are the members of the SAB, voting members off, and voting new members on.
Thank you for creating this proposal!
2 Likes
as I understood it, the purpose of this poll was to see if there’s an appetite for this sort of change, and i interpreted lordlike’s suggestions as examples for a starting point on the discussion and later, a proposal. you bring up great points about the speed/security trade-offs, and I hope that makes it into any proposals that may result from this poll and the discussions around it.
I don’t think lordlike is proposing that the SAB members give up the kind of self-doxing details that could subject them to rubber hose cryptanalysis, for example. to me it read more like making sure that they’re still willing to volunteer for the SAB, that they still have the appropriate access (haven’t lost their keys, for example), and general health checking.
I agree with community oversight of the DAO SAB.
I don’t agree with the first paragraph of this proposal, that’s why I will vote against it.
This is a poll to start the process of increasing security of DAO critical smart contracts by upgrading SAB with mandatory function as a second layer of security on top of the DAO Committee to mitigate risks that include scammers, black hackers or human factor.
I think we’re mixing apples and oranges. SAB are experts in smart contract security, not necessarily experts against “scammers, black hackers, or human factors”.
2 Likes
Check out this blogpost, how they reacted in the past:
15:40 - Early informal notification received—security researcher was asked to notify security@decentraland.org
16:20 - Security report received at security@decentraland.org and handled by the on-call person at the Decentraland Foundation.
16:33 - SAB Team notified and asked to report immediately.
16:40 - Two SAB Team members verify the report and confirm the vulnerability.
16:50 - A SAB Team member starts building a new TheGraph subgraph implementation to detect and identify this condition on Ethereum Mainnet.
17:22 - A SAB Team member comes up with a fix.
17:28 - Four out of the SAB Team’s five members, plus one independent individual that was looped in, start verifying that the fix is sound.
17:30 - All of the SAB team is online and has reported, ready to do an emergency upgrade that needs 5/5 signers.
17:35 - Preliminary analysis of affected LAND stolen: 11 LAND plots taken by the security researcher. This LAND was returned to the Foundation by the security researcher.
17:55 - New implementation contract deployed.
18:00 - Bytecode contract verification made using private tooling, to avoid disclosing the fixed contract publicly.
18:10 - Second and third independent bytecode verifications were made with different private tools.
18:20 - Vote for the upgrade was submitted to the SAB Team.
18:30 - Voting finishes with 5/5 positive votes. The upgrade of the smart contract is finalized and the vulnerability is confirmed as fixed: Ethereum Transaction Hash (Txhash) Details | Etherscan
18:33 - Using the TheGraph subgraph and additional on-chain information, the SAB Team confirmed that the vulnerability was not exploited in the wild, and that only the 11 LANDplots reported by the security researcher were involved.
I feel that extending their responsabilities beyond quickly responding to smart contract vulnerabilities is like asking a SWAT team to also patrol the streets for speeding violations.
1 Like
While we may not agree on every point, I believe this proposal will increase the security of DAO critical smart contracts.
The DAO Committee is overseen by the SAB, which has the ability to pause and cancel any action initiated by the Committee.
When I first read about SAB, I thought that it is good for DAO to have a second layer of protection on top of the DAO Committee, which “oversees” it.
https://docs.decentraland.org/player/general/dao/overview/how-does-the-dao-work/
I was surprised when I found out that information on Decentraland website isn’t correct and decided to run a DAO poll to find out what community thinks on it.
Thanks all for your feedback!
I see that this proposal most likely wont pass but it is a good moment to look and think about SAB, as a group of individuals who control DCL DAOs core smart contracts and can add/remove DAO Committee members.
Do we know all this people ? Does DAO voted for them ? When last time we talked to SAB members, except HP ? 
Can they simultaneously be in DAO Committee and SAB ? Maybe they should be rewarded to devote more time for DAO smart contracts security ?
Say what you will about my comment but it bothers me that one of the first statements of this proposal is
mitigate risks that include scammers, black hackers or human factor.
I’d hope that would be altered to state black-hat hackers. still not great, whatever you want to call it.
1 Like
missed this… 
thx for comment
1 Like
The information is correct in the website. You wrote:
After a transaction is initiated a 24h execution delay starts. Within those 24h, any DAO Committee member (or SAB member) can pause or cancel that fund transfer.
I assume you refer to this paragraph, but I think it’s clear from the context that it’s DAO-Committee-originated transactions that have the 24 hr delay, not SAB-originated transactions:
1 Like
In any case, the 24 hour delay for DAO Committee transactions is no longer a strong requirement. Back when it was created, the DAO Committee had the ability to transfer out smart contracts and enact any transaction on behalf of the DAO. That’s no longer the case since 2022 (some of us sleep better), now the DAO Committee can only:
- Add/remove POIs, Catalysts or Banned Names
- Move ETH or ERC20 tokens in and out
1 Like
Thanks for the clarification, interesting info.
1 Like
Vote: NO
I find it a compelling argument what Esteban says about asking for more from the SAB members. They have a specific, limited function. They are working on a volunteer basis. I think the vulnerabilities in the smart contracts stemming from the access and control of the DAO Committee members ought to be addressed within the DAO Committee itself.
To this end, increasing the number of members is one positive solution. Collusion or hacking vulnerabilities would be mitigated by a higher threshold in reaching quorum or the minimum number of private keys for a multi-sig wallet. The committee positions are compensated. Rather than add on another stove pipe, further complicating procedures, I suggest tasking the committee to address security concerns with internal measures.
I have never made a request to change the docs so please correct me if I’m wrong, but anyone can submit this on github correct? This is something I’ve wanted to do in the past and have asked questions quite a few times about that DAO docs page you reference as there seems to be some conflicting information based on some of the updates you mention like:
“Back when it was created, the DAO Committee had the ability to transfer out smart contracts and enact any transaction on behalf of the DAO. That’s no longer the case…”
Would you perhaps be willing to make the suggested changes instead or work with me to complete this accurately? I think you probably have better understanding/visibility to what updated language is needed to describe how the system functions now, but I understand you may not have the time for this so I am happy to try and compile a draft update for the page for you to review even? Just not sure I feel confident enough to make this update completely on my own.
The current documentation is accurate:
DAO Committee #
The DAO Committee is a group of three trusted individuals who have been selected by the community to hold keys in a multi-sig wallet. This multi-sig is responsible for enacting any passed votes with a binding action, like funding a Grant, banning a name, adding or removing a POI, implementing a Governance proposal or adding a Catalyst node.
The DAO Committee is overseen by the SAB, which has the ability to pause and cancel any action initiated by the Committee.
Every on-chain transaction initiated by the DAO Committee has an automatic 24-hour delay before it is completed, allowing the SAB or the Committee to revoke the transaction.
Maybe there should be a DAO vote to make this part obsolete:
The DAO Committee is overseen by the SAB, which has the ability to pause and cancel any action initiated by the Committee.
This is factually correct right now. It’s no longer needed, it could be best if this power is taken off the SAB. But I’d try to increase the number of DAO Committee members before.
I hadn’t looked before my last comment, but I see now there have been some updates to the documents recently that do try to provide more clarity to the way the DAO functions in some of these regards. However the point you bring up is still one I think needs a little more detail.
The DAO Committee is overseen by the SAB, which has the ability to pause and cancel any action initiated by the Committee.
First, I’m curious why you think removing this power would be beneficial or why it is no longer a strong requirement? I’ve always thought this was a benefit that the SAB had the power to step in, specifically in the case of when moving ETH or ERC20 tokens is not in the best interest of the community despite a passed vote. I don’t think we need to talk about specific situations as its not my goal to get into that kind of debate here, but there have been two times I can think of where an action should have at least been highly considered. I see this as a real benefit, however there are also a few key problems I’ve found:
-
There is no clear process on how this power should be used to block ETH or ERC20 transactions or if those tx include grant payments.
-
There is no clear whistle blower process for the community to call on the SAB to review a questionable transaction.
-
There is no clear documentation on how these ETH or ERC20 tx move between the SAB controlled Aragon Agent wallet and the DAO Committee wallet which pays out the grant vesting contracts. Is money topped off monthly as needed or on a scheduled basis? Things like this would be nice to see transparently explained.
You also raise the point that the SAB are not a paid position like the DAO Committee and perhaps that is why you suggest this power should be removed. I may be inclined to agree with you, perhaps it should be given to the newly forming revocations committee as they are a paid community security board to be activated in the case of an emergency. While I know the DAO Committee wallet generally holds less funds than the Aragon Agent, I don’t think I agree that removing the protection would be a step in the right direction.
Increase DAO Security: SAB Upgrade
This proposal is now in status: FINISHED.
Voting Results:
- Yes 4% 240,239 VP (115 votes)
- No 95% 5,404,808 VP (51 votes)
- Invalid question/options 1% 170 VP (1 votes)
Increase DAO Security: SAB Upgrade
This proposal has been REJECTED by a DAO Committee Member (0xbef99f5f55cf7cdb3a70998c57061b7e1386a9b0)