Project

Summary: joinDAO function in Membershipfactory.sol is susceptible to a race condition vulnerability. This occurs because multiple users can simultaneously check the availability of a tier and proceed to join it based on outdated state information. This can lead to overbooking of the tier.

Scenario

Two users, Alice and Bob, attempt to join the same tier in a DAO at nearly the same time. The tier has a limited number of available spots.

Initial State

• Total spots available in the tier: 100

• Spots already taken: 99

• Remaining spots: 1

• Price per spot: 1000 tokens

Operations

1. Alice's Transaction:

   • Checks if the tier has available spots: true (1 spot available).

   • Transfers 1000 tokens from Alice to the DAO.

   • Increments the minted count of the tier by 1.

   • Mints the membership NFT to Alice.

2. Bob's Transaction (executed right after Alice's check but before Alice's transfer):

   • Checks if the tier has available spots: true (still 1 spot available, Alice's transaction hasn't yet updated the state).

   • Transfers 1000 tokens from Bob to the DAO.

   • Increments the minted count of the tier by 1.

   • Mints the membership NFT to Bob.

Final State After Race Condition

• Total spots available in the tier: 100

• Spots already taken: 101 (due to both Alice and Bob's transactions)

• Both Alice and Bob successfully joined the DAO, but Bob's transaction was based on outdated state information.

Potential Impact

• The tier gets overbooked, leading to inconsistencies.

Mitigation

To prevent this race condition, the contract should use proper synchronization techniques such as:

1. Optimistic Locking: Using a version number to track changes and validate the state before committing a transaction.