Security Overview

Approach

evently's security process is structured in three phases:

Phase 1 — AI audits (7 engines) + automated tools    ← current
Phase 2 — Professional third-party audit              ← shortlist under evaluation
Phase 3 — Ongoing monitoring + bug bounty             ← post-launch

All findings, fixes, and the contracts reviewed at each stage are documented publicly in this documentation and in the GitHub repository.

---

AI Security Audits

All three evently contracts were audited by 7 AI engines with a 3-round methodology (Systematic review → Economic analysis → Triage). The contracts reviewed are: evently.sol v5.4, EventlyProfiles.sol v1.3, and EventlyMarketsV3.sol (LMSR, b=200).

AI Tool	Contracts	Findings	Critical	High	Medium	Low	Info
Claude Opus 4.6	v5.4 · v1.3 · V3 LMSR	6	0	0	1	4	1
GPT-4o	v5.4 · v1.3 · V3 LMSR	13	2	4	5	0	2
Gemini 1.5 Pro	v5.4 · v1.3 · V3 LMSR	9	1	2	2	2	2
Grok (xAI)	v5.4 · v1.3 · V3 LMSR	6	0	0	1	2	3
DeepSeek R1	v5.4 · v1.3 · V3 LMSR	7	0	1	2	2	2
Qwen3.5	v5.4 · v1.3 · V3 LMSR	4	0	0	0	1	3
Perplexity	v5.4 · v1.3 · V3 LMSR	—	—	—	—	—	—

All 7 AI engines reviewed EventlyMarketsV3 (LMSR). Key cross-tool findings documented in Consolidated AI Audit.

---

Automated Tool Scans

25 automated security tools are scheduled for the patched contracts, following the methodology recommended by z0r0z/majeur. Individual reports are linked in the Audit Reports section.

---

Third-Party Audits

Firm	Status
Cyfrin	Shortlisted
OtterSec	Shortlisted
Sherlock	Shortlisted
Spearbit	Shortlisted

Selection finalized post-raise based on availability, scope fit, and budget. Formal audit reports will be published here upon completion.

---

Security Properties

Reentrancy

All state-mutating functions use a custom _locked mutex (ReentrancyGuard pattern). CEI (Checks-Effects-Interactions) enforced. All AI audits confirmed: 0 reentrancy vulnerabilities found in active paths. Minor hardening recommended on resolveMarket, cancelMarket, slashMarket (see individual audit reports).

Pull Payment

Winners receive funds via direct transfer. If the transfer fails (e.g. contract wallet), funds are stored in pendingWithdrawals[winner] and claimed via claimWinnings().

Treasury Resilience

Treasury and referral fee transfers in _processClick use soft-fail accumulation (v5.4). If a transfer fails, fees are accumulated in accumulatedTreasuryFees and flushed later by the owner. The game never reverts due to a treasury issue.

Access Control

• onlyOwner — game admin functions

• onlyGame — profile write functions restricted to the authorized game contract

• onlyAdmin — markets admin functions

• onlyWhitelisted — market creation and betting (during early access)

• authorizedCallers — swap recording restricted to approved addresses (v1.3)

Emergency Controls

The game contract can be paused by the owner at any time via pause(). All clicks and check-ins are blocked while paused.

No Upgradeability

Contracts are immutable. No proxy pattern. Any upgrade requires a new deployment with migration.

---

Known Design Choices

Item	Decision	Rationale
On-chain randomness	block.prevrandao + keccak	Acceptable for low-stakes game mechanic. VRF on roadmap.
Unbounded allPlayers array	Acknowledged	Leaderboard reads O(n) — view-only, off-chain reads acceptable
recordSwap() access control	Restricted to authorizedCallers	Fixed in v1.3
Treasury withdrawFees()	Owner pulls accumulated fees	Protocol revenue — not user funds
ERC-1155 pre-resolution transfers	No restriction hook	Positions technically transferable. optionSupply tracks total minted, not per-wallet.
Single admin key in V3	Centralization risk	Mitigated by planned Gnosis Safe multisig post-raise.
LMSR subsidy locked on cancel	No sweep mechanism	Creator subsidy lost on cancellation. Admin sweep function on roadmap.
subsidyDeposited not in cancel refund	By design	Only poolBalance distributed pro-rata on cancel/slash.