[DAO:6676d0a] Increase DAO Security: SAB Upgrade

by 0x247e0896706bb09245549e476257a0a1129db418 (LordLike)

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.

SAB controls and can update Decentraland DAO core smart contracts, can add or remove DAO Committee members. It is vital for Decentraland and DAO to maintain and improve SAB security.

1.WHAT ARE DECENTRALAND SMART CONTRACTS ?

The Decentraland DAO owns several of the most critical smart contracts of the Decentraland platform. They are listed below:

  • The LAND contract. This is the contract that manages the LAND tokens. The DAO is the owner of the LAND smart contract. This means that any changes or modifications to that contract must be carried out by the DAO and the SAB.

  • The Estate contract. Like the LAND contract, the DAO owns the Estate contract which can only be modified by the SAB, after approval has been given by the DAO through a community vote.

  • POIs. The list of Points of Interest is also owned by the DAO. This list is stored on a contract and can only be modified after passing a vote by the community that is then enacted on-chain by the DAO Committee.

  • Names. The contracts used to mint the NFTs for unique avatar names in Decentraland are owned and controlled by the DAO. Any changes to the names contract must be approved by the DAO.

  • Banned names. The list of names that have been banned from the Decentraland client is stored in a contract owned by the DAO. This list can only be modified after passing a vote by the community that is then enacted on-chain by the DAO Committee.

  • Catalyst nodes.The list of Catalyst nodes that serve content and establish the peer-to-peer connections needed to keep Decentralandā€™s virtual world running is also owned and controlled by the DAO. This list is stored on a contract and can only be modified after passing a vote by the community that is then enacted on-chain by the DAO Committee.

  • Wearables collections. The contracts used to manage wearables collections are owned and controlled by the DAO.

  • Marketplace contracts. These contracts are also where the marketplace fees are defined, and can only be changed with the DAOs approval.

  • Grants. The vesting contracts used to make recurring payments as part of the DAOā€™s Grant framework are also owned by the DAO. These contracts are created by the DAO Committee on behalf of the DAO, and are overseen by the SAB to prevent any risk of monetary loss due to vulnerabilities or mistakes made by the Committee.

2. HOW DAO WORKS ?

Decentralandā€™s DAO uses off-chain voting for the community and a multi-sig wallet controlled by a ā€œDAO Committee ā€˜ā€™ to enact those off-chain decisions on the Ethereum blockchain. The use of a multi-sig wallet is controlled by a DAO Committee which is composed of trusted persons which guarantee the DAO security and enact proposals. A second multi-sig owned by the SAB provides a second layer of security on top of the DAO Committee.

3. WHAT IS SAB ?

SAB is the Security Advisory Board responsible for the security of Decentraland DAO Aragon smart contracts including LAND and Estate contracts. The SAB controls updates on DAO Aragon smart contract and other smart contracts owned by Aragon. They respond to vulnerability and bug reports in any of Decentralandā€™s contracts.

The SAB includes 5 experts that have initially been selected by the Decentraland dev team.

Any time a modification is to be made to the LAND or Estate contracts, the update must be unanimously supported by the SABā€™s multi-sig. At least three signatories are required with no dissenting votes in order to make any changes to the LAND or Estate contracts. The SAB has the ability to pause, resume, or cancel any action taken by the DAO Committee.
Funds transfers from DAO Aragon smart contracts can be initialized by one DAO Committee member or done by 3 out of 5 SAB members (only in extreme cases related to security of smart contracts).

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.

4. WHAT IS 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.
Every on-chain transaction initiated by the DAO Committee has an automatic 24-hour delay before it is completed, allowing the SAB or the DAO Committee members to revoke the transaction during this period of time .

5. POSSIBLE RISKS:

In theory DAO Committee members can be hacked or colluded with each other for fraudulent activities and there will be no mandatory force that will stop them.

The Security Advisory Board does not oversee the operations and what is being done with the DAO or DAO Committee actions, they are purely for smart contracts security.

SAB can cancel funds movements from the DAO Aragon wallet, but they are not supposed to do it unless itā€™s clearly something that should not happen. (Rogue DAO Committee or hacked address trying to steal money).

Also, a 24 hour transaction execution delay is a pretty small amount of time and bad actors can choose date and time which will increase risk of transaction being unnoticed such as weekend, holiday or resonant event that will distract attention.

6. POSSIBLE SOLUTIONS:

  • 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.

  • Increase transaction execution time delay. For example, from 24 hours to 48 hours.

  • 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.)

The SAB membersā€™ possible compensation can be discussed in other proposal.

These are forward thoughts to start community discussion on security issues or concerns that should be solved or mitigated.

7. VOTING OPTIONS:

Yes: I support this proposal as a starting point to increase DAO smart contracts security.

Final actions on improving DAO smart contracts security and their implementation pathways will be described in DRAFT and GOV proposals after achieving community consensus in discussions.

No: Leave as it is.

  • Yes
  • No
  • Invalid question/options

Vote on this proposal on the Decentraland DAO

View this proposal on Snapshot

1 Like

Please comment your vote if possible. Thanks. :heart:

2 Likes

@RobL Please read this proposal before voting!

I support this - well done @web3nit

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.

https://forum.decentraland.org/t/dao-478b4f5-set-duration-period-for-dao-committee-members/17798/8?u=web3nit

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 ? :grin: 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ā€¦ :flushed:

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:

  1. 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.

  2. There is no clear whistle blower process for the community to call on the SAB to review a questionable transaction.

  3. 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)