Project

Summary

MembershipERC1155::shareOf function calculates an account's share of total profits based on a hardcoded set of power multipliers (64, 32, 16, etc.). However, the underlying tier configuration, which determines the power assigned to each tier, is not enforced or validated. This lack of enforcement can lead to confusion and potential issues for DAO creators and users. Plus to that, the same function does not consider configs having less than 7 tiers.

Vulnerability Details

In creating a DAO, DAO creators specify the power of each tier. While there is not much information about tiers and powers, if we look at the test files written by the protocol, we can see that SPONSORED and other types of (PUBLIC, PRIVATE, denoted as GENERAL in tests) DAOs have different power structures.

In the test files (MembershipFactory.test.ts), sponsored tiers are written as such:

We know that sponsored DAOs must have 7 tiers at all times, but that does not apply to public and private DAOs. From the same test file, we see that a general DAO is created with 3 tiers, with diferent power structure than the above sponsored one:

Which clearly suggests that powers are specified arbitrarily by the DAO, as there is no check or enforcement in power structure in the protocol's codebase.

Going back to MembershiptERC1155::shareOf, we can see that the power is calculated as follows:

As these values are hardcoded in the share calculation, they are not validated or enforced. This function, considered with the tests written, suggests that the values correspond to the power structure of the tiers. However, they do not satisfy what is expecte from the tier configuration.

Consider the scenario where there are only 3 tiers, and for the sake of simplicity, let's even ignore their power configuration. Accoring to the above function, the tier with the lowest importance (which is the highest number in the protocol, i.e if there are 3 tiers, 0 is the most expensive and strongest tier while 2 -since indexes start from zero- is the cheapest and the one with the lowest power) is not multiplied with 1, as it should be, but with the power of 16, because the shareOf function does not take into consideration that there might be less than 7 tiers.

This results in confusing calculations and poor user experience.

Impact

The lack of enforcement in tier power configuration leads to several issues:

1. Incorrect Power Distribution:

- In a 3-tier DAO, tier 2 (lowest tier) gets multiplied by 16 instead of expected 1

- Example calculation:

```

Tier 2 holder with 1 token:

Expected: 1 * 3 (from test config) = 3 power

Actual: 1 * 16 (from shareOf) = 16 power

```

2. System Inconsistency:

- Contradicts documented tier benefits

- Undermines trust in the protocol's membership model

- Creates unpredictable power distribution across different DAO types

3. Business Logic Violation:

- Sponsored DAOs' 7-tier structure/power config becomes meaningless when power calculation is hardcoded

- General DAOs with fewer tiers have their power structure completely ignored

To sum up, since nothing is clear or defined regarding the tier configuration, the above issue ends up causing the following impact:

- Contradicts documented tier benefits, undermining trust in the protocol’s membership model.

- Enables DAO creators to define arbitrary tiers that may disrupt the platform’s reputation and consistency.

- Variability in tier configurations without enforced structure creates ambiguity, disrupting user and creator expectations.

The impact is medium because likelihood of this situation occuring is very high, while the impact can be denoted as medium/low. Even if it is denoted as low, according to codehawks docs, high likelihood and low impact is considered a medium severity.

Tools Used

Manual review

Recommendations

- Ensure that the power of each tier is defined and enforced.

- Update shareOf function to consider the power of each tier and having less than 7