GPT-5.3

GPT-5.3 --- Security Report

Tool: GPT-5.3 Type: 3-round AI audit (Systematic → Economic → Triage) Contracts reviewed: evently.sol v5.4 · EventlyProfiles.sol v1.3 · EventlyMarketsV3.sol v3.2 (LMSR b=200 + CLOB bids/asks) Chain: MegaETH (Chain ID 4326) --- Solidity ^0.8.20 Date: March 2026 Status: Complete — v3.2 post-audit fixes verified

---

Summary

The evently system is generally well-structured and follows several good security practices (custom reentrancy guard, CEI ordering, pull-payments fallback, and fee accounting). No critical reentrancy or pot insolvency vulnerabilities were identified.

However 5 notable findings were discovered: - 1 High severity - 2 Medium severity - 1 Low severity - 1 Informational

The High severity issue relates to a dispute settlement imbalance in EventlyMarkets that can lead to protocol-level token loss. No production blockers exist for the core evently click game.

---

Findings

---

ID Severity Contract Title Status

---

F-01 High EventlyMarkets Dispute payout Fixed — V3 redesign: settleDispute handles all collateral paths can exceed available collateral

F-02 Medium EventlyMarkets Creator can By design resolve market dishonestly before dispute

F-03 Medium EventlyProfiles Username case Fixed — v1.2: _toLower() applied normalization inconsistency

F-04 Low evently Timer extension Acknowledged allows extreme round length

F-05 Informational evently Randomness By design manipulable by last clicker

---

Round 1 --- Systematic Review

Reentrancy

evently implements a manual reentrancy lock (_locked) protecting external entrypoints such as:

• dailyCheckIn

• withdrawCredits

• clickWithCredit

• useAllCredits

• claimWinnings

• clickDirect

• clickRich

• clickFree

Example:

pendingWithdrawals[msg.sender] = 0;
(bool sent, ) = msg.sender.call{value: amt}("");

State changes occur before external calls, preventing reentrancy exploits.

Verdict: Safe implementation

---

Access Control

Key protected functions:

• pause

• unpause

• transferOwnership

• setTreasury

• seedPot

Profiles contract uses onlyGame modifier, and Markets contract uses onlyAdmin.

Market resolution is controlled by the market creator:

require(msg.sender == m.creator, "Only creator");

This is a trust assumption rather than a vulnerability.

---

Integer Arithmetic

Solidity ^0.8 prevents overflow.

Examples reviewed:

CLICK_PRICE * POT_PERCENT / 100

(uint256 distributablePool * userBet) / winningPool

Dust may occur due to integer division but is negligible.

Verdict: Safe

---

Randomness

Entropy source:

keccak256(
 abi.encodePacked(
  block.timestamp,
  block.prevrandao,
  msg.sender,
  clickCount,
  _nonce
 )
)

This can be manipulated by validators or the last clicker but is an acknowledged design choice.

Classification: Design Tradeoff

---

Logic & State

Timer grows with every click:

timerEnd += TIME_PER_CLICK;

Rounds may become very long if users continue clicking. This appears intentional.

Username normalization issue

Profile creation:

usernameTaken[_username] = true;
usernameToAddress[lowerUsername] = msg.sender;

Case-sensitive duplicates possible (Alice vs alice), leading to inconsistent lookups.

---

Denial of Service

Loops are bounded by:

MAX_CLICKS_PER_TX = 200

Leaderboard loops iterate across all players but are view-only, therefore safe.

---

Front-running / MEV

Expected in:

• Last-click competition

• Prediction market betting

No exploitable contract logic issues found.

---

Round 2 --- Economic Analysis

Pot Solvency

Pot receives:

• 85% from direct clicks

• Credit click contributions

• Owner seed deposits

Bonus clicks do not increase pot, preventing insolvency.

Verdict: Pot remains solvent.

---

Credit System

Credits purchased:

creditBalance[msg.sender] += msg.value - fee;

Refundable via:

withdrawCredits()

No inflation vectors detected.

---

Referral Sybil Vectors

Mitigation exists:

REFERRAL_ACTIVATION_THRESHOLD = 0.01 ether

Attack still possible but economically inefficient.

---

Market Creator Advantage

Creator resolves markets but disputes require collateral (50 tokens), creating economic protection.

---

Treasury Risks

Treasury controlled by admin key.

Worst-case scenario: treasury drained but markets continue operating.

---

Round 3 --- Triage

F-01 --- Dispute payout imbalance (High)

Bug:

usdm.safeTransfer(m.disputer, DISPUTE_COLLATERAL + 25e18);

Contract only receives 50 tokens but sends 75, causing protocol loss.

Fix

function settleDispute(uint256 _marketId, bool _creatorWasRight) external onlyAdmin {
    Market storage m = markets[_marketId];
    require(m.status == MarketStatus.Disputed, "Not disputed");

    if (_creatorWasRight) {
        treasuryBalance += DISPUTE_COLLATERAL;
    } else {
        usdm.safeTransfer(m.disputer, DISPUTE_COLLATERAL);
        m.winningOption = m.disputeOption;
        m.creatorCollateralReturned = true;
        m.creatorFeePaid = true;
    }

    m.status = MarketStatus.Finalized;
    _emitFinalized(_marketId);
}

---

F-02 --- Dishonest creator resolution

Creator can resolve incorrectly before dispute.

Classification: Design Tradeoff

---

F-03 --- Username normalization bug

Recommended fix:

string memory lowerUsername = _toLower(_username);

require(!usernameTaken[lowerUsername], "Username taken");

usernameTaken[lowerUsername] = true;
usernameToAddress[lowerUsername] = msg.sender;

---

F-04 --- Timer extension

Potential mitigation:

timerEnd = min(timerEnd + TIME_PER_CLICK, block.timestamp + MAX_TIMER);

---

F-05 --- Randomness

Known design tradeoff.

---

Reentrancy Surface Summary

Function Guard CEI Verdict

---

withdrawCredits nonReentrant Yes Safe claimWinnings nonReentrant Yes Safe clickDirect nonReentrant Yes Safe clickRich nonReentrant Yes Safe useAllCredits nonReentrant Yes Safe dailyCheckIn nonReentrant Yes Safe claimReferralEarnings nonReentrant Yes Safe claimRefund None Yes Safe claimSlashedRefund None Yes Safe

---

Severity scale: Critical / High / Medium / Low / Informational Status options: In resolution | By design | Acknowledged | Frontend handles | False positive