Trick or Treat

Summary

The Swan contract exhibits a timing vulnerability related to asset listing and relisting functionality. Specifically, the vulnerability arises when an asset is initially listed and subsequently relisted before the intended listing period expires. This issue occurs because the createdAt timestamp is updated to the current block.timestamp upon relisting, effectively ignoring the prior listing history and creating the potential for unexpected contract behavior.

Vulnerability Details

The core of the vulnerability lies in the improper handling of the createdAt timestamp during the relisting process. When an asset is relisted, the contract sets a new createdAt value to the current block.timestamp. This update overrides the original listing’s timing data, leading to the following issues:

1. Inconsistent Timing Information: The updated createdAt upon relisting disregards the initial listing time, potentially causing logic relying on the original timing (e.g., restrictions based on round duration or asset history) to fail.

2. Round Overlap Ignored: Since previous contract states before block.timestamp are ignored, the relisted asset may appear "new," disregarding the duration it was previously listed.

3. Event Overlap Risk: By updating the listing’s createdAt upon relisting, the contract may inadvertently enable relisting within an active round, which could bypass intended checks (such as limitations on listing frequency or time-based pricing adjustments).

Impact

This vulnerability impacts the integrity of time-based functionality and round-based mechanics within the Swan contract:

• User Confusion: Users or buyers relying on consistent timing information might interpret relisted assets incorrectly, potentially undermining their trust in the platform.

• Round Abuses: The ability to relist with a new timestamp could potentially bypass round-based restrictions, allowing an asset to be relisted multiple times within a single round, thus violating the intended contract flow.

• Event Emission Discrepancy: Events emitted upon relisting will reflect updated times without accurate historical context, which could impact audits and data analysis of the marketplace activity.

Tools Used

• Manual Code Review: To identify logical and structural flaws in the contract's time-tracking mechanisms.

• Static Analysis (e.g., Slither): Used for detecting any related code patterns and to verify the integrity of functions handling state updates and timestamp logic.

Recommendations

To mitigate this vulnerability, consider the following recommendations:

1. Separate Initial and Relisting Timestamps: Store the initial createdAt timestamp separately from any updates on relisting, allowing the contract to maintain a complete history of the asset’s timeline.

2. Add Relisting Restriction Logic: Enforce timing restrictions that prevent an asset from being relisted within the same round or a specified period after the initial listing.

3. Implement Conditional Logic Based on Rounds: Ensure that relisting checks for round completion before updating the createdAt timestamp. This logic should be based on round-specific parameters instead of a general timestamp to maintain compatibility across multiple rounds.

4. Enhanced Event Logging: Include both the original and updated timestamps in relisting events to ensure transparency and accurate tracking of listing history.