Last Man Standing

Root Cause

The developer opted for a manual boolean-based locking mechanism instead of using OpenZeppelin’s standardized and audited ReentrancyGuard, which is the industry norm.

Description

The contract implements its own reentrancy guard by using a _locked boolean flag, set manually in the claimThrone function:

While this may work in straightforward scenarios, manual reentrancy locks:

• Are more error-prone due to inconsistent state handling.

• Can be accidentally skipped or misused.

• Lack the confidence of an audited implementation.

Instead, OpenZeppelin’s ReentrancyGuard is a rigorously tested and gas-optimized library trusted across thousands of production-grade contracts.

Risk

• Impact: Low

• The custom _locked boolean does prevent reentrancy under normal usage. However, relying on hand-rolled logic increases maintenance burden and introduces potential for error.

• Likelihood: Low

• The current implementation appears safe, but deviates from best practices and lacks audit provenance.

Proof of Concept

While no reentrancy bug is present currently, a subtle mistake like missing the _locked = false on all revert paths would lead to denial-of-service. Similarly, nested external calls without checks could create future reentrancy vectors if logic expands.

Manual example:

Recommended Mitigation

Use OpenZeppelin’s built-in ReentrancyGuard modifier for robust and battle-tested protection:

Benefits:

• Standardized and audited.

• Less room for human error.

• Easier for auditors and reviewers to trust.

References

• OpenZeppelin ReentrancyGuard Docs

• SWC-107: Reentrancy