Penetration Test Report (Consensys): dandelion audit 2019 12

Dandelion Organizations Audit
1 Summary Date December 2019
2 Audit Scope
Auditors Alexander Wade
3 Key Observations/Recommendations
4 Security Specication
4.1 Actors
4.2 Trust Model
5 Issues
5.1 TimeLock spam prevention can be bypassed Critical ✓ Addressed
5.2 Passing duplicate tokens to Redemptions and TokenRequest may have
unintended consequences Medium ✓ Addressed
5.3 The Delay app allows scripts to be paused even after execution time has
elapsed Medium ✓ Addressed
5.4 Misleading intentional misconguration possible through misuse of
newToken and newBaseInstance Medium ✓ Addressed
5.5 Delay.execute can re-enter and re-execute the same script twice Minor
✓ Addressed
5.6 Delay.cancelExecution should revert on a non-existent script id Minor
✓ Addressed
5.7 ID validation check missing for installDandelionApps Minor ✓ Addressed
6 Tool-Based Analysis
6.1 Ethlint
6.2 Surya
Appendix 1 - Disclosure
1 Summary
ConsenSys Diligence conducted a security audit of 1Hive’s Dandelion org template and
supporting apps. Dandelion orgs are a DAO template that function similarly to MolochDAO,
and are comprised of a suite of modular Aragon apps that can be used in any DAO.
2 Audit Scope
This audit covered the following les:
File Name SHA-1 Hash
token-request-
56997c6cfa[PII_REDACTED]1aedcc4e032b29d400c6
app/contracts/lib/AddressArrayLib.sol
redemptions-
6b184d37d5cca932da3d962a2fdc938389778a76
app/contracts/lib/ArrayUtils.sol
dandelion-org/contracts/DandelionOrg.sol bdfeab2a56304ce4bbbbd1a43cff49a2103732e0
dandelion-voting-
3d131eb7a72d4a44e3ae387b7f12a255f38f5d6a
app/contracts/DandelionVoting.sol
delay-app/contracts/Delay.sol cbc8a9cdca4c7cb8a3afecb33d36d2ef2324c903
redemptions-
a26ba97e9c71367955a2b34c735ba3b1559cda26
app/contracts/Redemptions.sol
time-lock-app/contracts/TimeLock.sol b30260b66f876ea0462fc72ee108e085594b1123
token-
0e16f0bbe4870234b264f824d943e08d50c9bc59
oracle/contracts/TokenBalanceOracle.sol
token-request-
2fa54ed[PII_REDACTED]06416823d5539624a8418c8
app/contracts/TokenRequest.sol
token-request-
1226ee39e2eaca8320647bbaa0fcf2d577665ef6
app/contracts/lib/UintArrayLib.sol
The audit activities can be grouped into the following three broad categories:
1. Security: Identifying security related issues within the contract.
2. Architecture: Evaluating the system architecture through the lens of established
smart contract best practices.
3. Code quality: A full review of the contract source code. The primary areas of focus
include:
Correctness
Readability
Scalability
Code complexity
Quality of test coverage
3 Key Observations/Recommendations
A Dandelion organization functions similarly to MolochDAO:
The org has a native asset which represents “shares”. Holders of the asset are
conferred voting power within the org.
Shares are implemented via MiniMeToken , which tracks historical balances.
Shares are non-transferrable
Shares are minted when new members are accepted to the org
Shares are burned when redeemed for a proportion of the org’s assets
Members can vote to accept new members into the organization
Votes are executed in order of their creation, and between a vote’s passing and
execution is a grace period during which members of the org can exit their shares
(according to a few requirements)
Noteable differences:
Dandelion orgs are much more congurable
Dandelion proposals execute aragonOS EVMScripts, which are batches of
arbitrary calls to any destination. As such, Dandelion orgs can execute a much
wider range of actions through votes:
Modifying voting-specic parameters, like support required, minimum
quorum, number of blocks between votes, and vote execution delay period
Notably, vote duration ( durationBlocks ) cannot be changed
Managing permissions within the organization’s ACL
Managing registered applications within the organization
Modifying execution methods for executed proposals (via the
EVMScriptRegistry )
Modifying which assets are redeemable when burning shares
Modifying which assets are accepted by TokenRequest requests for entry
into the org
… and more.
MolochDAO is very minimalist. Dandelion’s complexity is much higher due to its
wider range of actions and congurations, as well as its highly modular design.
The wider range of actions allowed in Dandelion orgs allow the organization
to pass votes that radically change the structure and function of the
organization. It is possible to execute votes that do almost anything,
including dissolving the organization. Members of Dandelion orgs will need to
fully understand proposals, and carefully consider the entire range of actions
executed by a successful vote.
Dandelion orgs do not require an existing member to submit a proposal for a new
member to join. Instead, a new member can create a request to join (via
TokenRequest.createTokenRequest ).
Requests offer a deposit of tokens in exchange for the minting of new org
tokens
The requesting user can cancel their request at any point before its
nalization. Cancelled requests involve a refund of the deposited tokens.
Requests can be nalized through the passing of a vote in
DandelionVoting . On nalization, the requestor’s deposited tokens are
transferred to the org’s Vault, and the TokenManager mints shares for the
requestor.
Discouraging spam in MolochDAO is implemented by requiring a 10 ETH deposit
from the member sponsoring a request to join. In Dandelion, spam is discouraged
via the TimeLock app, which requires anyone creating a vote to lock up a
specied token for a congurable amount of time. The more votes created by a
single address before their timelocked tokens are released, the higher the spam
penalty is for each vote. The increase in spam penalty is calculated using the
congurable spamPenaltyFactor .
DandelionVoting introduces a congurable voting quorum and support
threshhold, while MolochDAO requires only a simple majority to pass a vote.
4 Security Specication
This section describes, from a security perspective, some of the expected behavior of the
system under audit. It is not a substitute for documentation. The purpose of this section is
to identify specic security properties that were investigated by the audit team.
4.1 Actors
The relevant actors are as follows:
Deployer: Responsible for instantiating the organization with its base settings via
DandelionOrg .
Organization Member: Holds non-transferrable org tokens, which represent a
redeemable portion of the org’s assets. Responsible for voting on new proposals to
carry out a wide range of actions within the org.
Requesting Member: Creates a request to be minted org tokens via TokenRequest .
Can cancel request before nalization. On nalization, deposit tokens are moved to the
org’s vault and the requesting member is minted an amount of org tokens.
4.2 Trust Model
In any smart contract system, it’s important to identify what trust is expected/required
between various actors. For this audit, we established the following trust model:
The parameters set up during instantiation ( newTokenAndBaseInstance and
installDandelionApps ) are important to the behavior of many critical systems in the
org:
_redemptionsRedeemableTokens describes the redeemable assets held by the
organization. The Deployer should ensure that this is a list of valid ERC20 tokens
(optionally including “ETH” by using address(0x00))
_tokenRequestAcceptedDepositTokens describes the tokens accepted for
deposit by requesting members. The Deployer should ensure that this is a list of
valid ERC20 tokens (optionally including “ETH” by using address(0x00))
The Deployer should be careful when including tokens in this list that are not
included in _redemptionsRedeemableTokens . If tokens are deposited that
are not directly redeemable, they must rst be added to Redemptions by
way of a vote.
Additionally, TokenRequest.acceptedDepositTokens and
Redemptions.redeemableTokens have different maximum allowed sizes.
The Deployer should note that a token must be redeemable in order for org
members to withdraw it.
_timelockToken is the a