District One

Introduction

DistrictOne (D1) is a gamified social platform built on Blast L2, merging money games with vibrant community mechanics. It introduces interactive modules like Linkup, Space Sprint, Daily Rally, and SpaceShare, enabling users to earn, network, and speculate in a competitive social arena. D1’s innovative approach turns growth mechanics into community-aligned games, lowering entry barriers for both users and creators.

Why Did They Need an Audit?

The SpaceShare module in D1 allows users to invest in and profit from the success of community-run "spaces," leveraging a reward-per-share distribution model similar to MasterChef. Mismanagement of reward accounting or fee logic could lead to reward theft, reward loss, or inaccurate supply tracking. DistrictOne engaged Three Sigma for a short-term security engagement to validate critical economic mechanisms before release.

Scope of the Engagement

• File Audited: SpaceShare.so
• Team: 2 auditors · 2 person-days
• Chain: Blast L2

Results and Findings

Key Critical Issue

Reward bypass via early return in _updateSharesReward()

• Description: The reward update function skipped updating user reward trackers if no new rewards were pending. This enabled a user to bypass reward accounting by increasing their balance during a 0-reward state, then claiming full rewards once fees were re-enabled. This led to exaggerated reward claims.
• Resolution: The rewardPerShare update now conditionally skips on zero new rewards, but _updateHolderReward() is always called to track user changes correctly.

Notable High-Severity Issues

withdrawRewards() fails to accumulate

• Description: A missing += in withdrawRewards() caused the loop to overwrite reward amounts rather than summing them, leading to partially lost user rewards.
• Resolution: Logic corrected to accumulate across space IDs.

Lost rewards due to reward timing in _sellShares()

• Description: The function updated user balances before calculating their rewards, causing reward accounting to miss the final accrued period before the sale.
• Resolution: Rewards are now calculated before share reductions.

Medium-Severity Issue

Signature check does not prevent address(0) signer

• Description: If the signer address is not explicitly set in the constructor, any invalid signature returning address(0) would pass checks, enabling unauthorized share purchases.
• Resolution: Updated to use OpenZeppelin’s ECDSA utilities, which validate against address(0).

Low-Severity Issues

Last user cannot fully exit space

• Description: Each space requires a minimum of one share to remain. Thus, the final user cannot fully exit via exitSpace(), which reverts when trying to burn the last share.
• Resolution: Acknowledged. Users can still manually reduce to one share and claim rewards.

Missing critical event emissions

• Description: Several state changes, such as reward updates and internal balance changes, did not emit events, limiting transparency and onchain monitoring.
• Resolution: Events were added to all critical state changes.

Solidity version may be incompatible with Blast

• Description: Contract used Solidity 0.8.21, which may not yet be supported by Blast L2 due to PUSH0 opcode inclusion.
• Resolution: Downgraded to 0.8.19 to ensure deployment compatibility.

In conclusion

Three Sigma performed a rapid yet deep security review of the SpaceShare module in DistrictOne. Despite the compact scope, the audit uncovered a critical reward accounting bug, two high-severity logical errors, and a signature bypass risk—all of which were addressed by the development team. The audit also identified several best-practice improvements, such as event emissions and Solidity version safety. Following the remediations, the SpaceShare contract demonstrates significantly improved resilience in user accounting, reward integrity, and onchain observability.