The createContingentPool
and batchCreateContingentPool
functions of the DIVA protocol are vulnerable to front-running attacks due to a flaw in how the poolId
is generated. Attackers can exploit this vulnerability to force legitimate users into failing transactions by intentionally creating duplicate pools.
The poolId
is derived from the PoolParams passed to the createContingentPool
function, which includes parameters such as collateralToken, expiryTime, floor, inflection and other values that define a contingent pool. Within the AaveDIVAWrapper, the user-provided collateralToken is replaced with a wrapped version (wToken) but the underlying PoolParams are otherwise unchanged.
If two users provide identical parameters (including the same original collateralToken), the resulting PoolParams forwarded to DIVA will have the same values for all attributes, including the wrapped collateralToken (wToken). This leads to identical poolIds
for both users' requests.
Since the createContingentPool function is permissionless, attackers can detect pending transactions in the mempool, replicate the same parameters and submit their own transaction first causing a duplicate poolId collision.
Two or more users end up with the same poolId
due to identical PoolParams. This results in a rejected transactions for legitimate users
Manual Review
A unique factor such as the user's address (msg.sender
) or a random salt
value be added to the PoolParams
before hashing to create the poolId
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.