Summary

This audit addresses a vulnerability in the Swan contract's relist function. The function manages asset relisting based on buyer agents and enforces a maximum asset count (maxAssetCount). However, an issue with race conditions in the relist function may allow multiple calls to exceed this asset limit.

Vulnerability Details

The relist function logic:

The current sequence checks the asset count first, then updates the asset status. This logic may allow multiple relist calls to pass the asset count check before updating the asset’s status, creating a potential race condition. If multiple transactions execute the relist function concurrently, each transaction may pass the check independently, resulting in the asset count exceeding the intended limit.

Suppose maxAssetCount is 10, and an agent currently has 9 assets. Two concurrent relist calls are made: First Call: Passes the count check at 9 assets. Second Call: Before the first call completes, the count remains 9, allowing it to pass as well. This condition causes the asset count to reach 11, violating maxAssetCount.

Impact

By allowing asset count to exceed maxAssetCount, the contract’s intended limit on assets per round can be bypassed, affecting protocol integrity and creating inconsistent states.

Tools Used

Manual

Recommendations

Implement a mechanism to atomically handle the asset count check and status update, ensuring that only one relist call can pass through this logic at a time. This could involve locking the function until the current transaction is complete or using mutex-like behavior.