> For the complete documentation index, see [llms.txt](https://docs.evently.market/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.evently.market/audit-reports-ai/gemini.md).

# Gemini 3.1 Pro

**Tool:** Gemini 1.5 Pro (Google DeepMind) **Type:** 3-round AI audit (Systematic → Economic → Triage) **Contracts reviewed:** EventlyProfiles.sol · EventlyMarkets.sol (LMSR b=200 + CLOB bids/asks) **Chain:** MegaETH (Chain ID 4326) — Solidity ^0.8.20 **Date:** March 2026 **Status:** Complete

***

## Summary

| Severity      | Count |
| ------------- | ----- |
| Critical      | 1     |
| High          | 2     |
| Medium        | 2     |
| Low           | 2     |
| Informational | 2     |
| **Total**     | **9** |

***

## Round 1 — Systematic Scan

### Reentrancy, Access Control, Token Handling, and Math

The contract uses `nonReentrant` on core functions (`buyShares`, `sellToAMM`, `createSellOrder`, `disputeMarket`, `settleDispute`, `claimCreatorFees`, `redeemWinnings`, `claimCancelRefund`). However, `cancelMarket` and `closeBetting` lack this modifier. While these specific functions don't perform external calls before state changes, it is a best practice for consistency. (**L-01**)

`onlyAdmin` and `onlyWhitelisted` modifiers are correctly applied to sensitive functions. Solidity 0.8.20 provides native overflow protection. `SafeERC20` is used for all USDm transfers. The cost function `_lmsrCost` correctly implements `C(q) = b × ln(Σ exp(q[i]/b))`. PRBMath SD59x18 is used for fixed-point `exp` and `ln` operations.

***

## Round 2 — Economic Attack Analysis

### Solvency, Fees, and Order Book

The contract relies on `subsidyDeposited + poolBalance ≥ total winning shares`. The subsidy is calculated as `b × ln(n)`, which covers the worst-case transition from uniform to concentrated probability.

Fees are collected during `buyShares` and `sellToAMM`. A notable design characteristic: fees are taken from the `remaining` amount in `buyShares` *before* the AMM quote, effectively reducing the net USDm passed to the LMSR cost function. (**H-02**)

The `MAX_ORDERS_PER_BOOK` cap (A-03 fix) is correctly implemented and prevents order book flooding.

***

## Round 3 — Adversarial Triage

### C-01 — Potential Insolvency via P2P Redemptions \[RESOLVED / FALSE POSITIVE]

In `redeemWinnings`, if `payout > poolBalance`, the contract draws from `subsidyDeposited`. However, `poolBalance` only tracks net USDm from AMM trades. When a buyer fills a P2P sell order in Phase 1 of `buyShares`, the USDm is sent directly to the seller — but the buyer receives ERC-1155 shares that are indistinguishable from AMM-minted shares and are equally redeemable against the contract's pool.

If significant volume goes through P2P orders, the physical USDm backing those shares has already left the contract. The `poolBalance` does not account for this gap, and the subsidy alone may not cover the shortfall.

**Recommended Fix:** Implement a redemption reserve that retains a portion of P2P sales in `poolBalance`, or require that total USDm in the contract always equals the maximum possible payout:

```solidity
// Suggestion: explicit solvency check on buy
require(
    usdm.balanceOf(address(this)) >= totalMintedShares + treasuryBalance + resolverPoolBalance,
    "Solvency check failed"
);
```

### H-01 — P2P vs AMM Price Arbitrage / Griefing

`buyShares` fills P2P sell orders before routing to the AMM. If a P2P order is priced significantly above the current AMM implied probability (e.g., 0.99 USDm when AMM price is 0.50 USDm), a buyer calling `buyShares` is forced to fill the expensive P2P order first. While `_minShares` slippage protection helps, the execution is economically sub-optimal.

**Recommended Fix:** Compare the cheapest P2P order price against the current LMSR `getPrice` before filling, and skip P2P orders priced above AMM:

```solidity
if (o.pricePerShare > getPrice(_marketId, _opt)) { idx++; continue; }
```

### M-01 — `closeBetting` lacks access control

Any user can call `closeBetting` once the betting deadline has passed. While the function requires the deadline to be expired, allowing any address to trigger state transitions can lead to unexpected bot behavior.

**Recommended Fix:** Restrict `closeBetting` to admin, creator, or a permissioned keeper address.

### M-02 — Fee rounding dust always favors resolver

The `resolverCut = totalFee - creatorCut - treasuryCut` calculation means rounding dust is always absorbed by the resolver pool. Over many trades, this creates a systematic minor imbalance in fee distribution.

**Recommended Fix:** Document this as an explicit design choice, or implement round-robin dust assignment across the three recipients.

***

## Findings Table

| ID   | Severity | Contract       | Title                                                     | Status                                                                                                                            |
| ---- | -------- | -------------- | --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| C-01 | Critical | EventlyMarkets | Potential insolvency via P2P redemptions                  | **False positive — BUY orders escrow USDm upfront; CLOB fills deduct from escrowed budget, not new USDm; poolBalance unaffected** |
| H-01 | High     | EventlyMarkets | P2P vs AMM price arbitrage / griefing                     | Acknowledged — buyer sets \_minFill slippage guard; skipping expensive asks would break price-time priority                       |
| H-02 | High     | EventlyMarkets | Subsidy / pool imbalance in `claimCancelRefund`           | **False positive — poolBalance reduced by gross; fees credited separately; invariant holds**                                      |
| M-01 | Medium   | EventlyMarkets | `closeBetting` lacks access control                       | Acknowledged — permissionless by design; requires deadline elapsed                                                                |
| M-02 | Medium   | EventlyMarkets | Fee rounding dust always favors resolver                  | Acknowledged — intentional; resolver cut absorbs 1-wei rounding dust                                                              |
| L-01 | Low      | EventlyMarkets | Missing `nonReentrant` on `cancelMarket` / `closeBetting` | Acknowledged                                                                                                                      |
| L-02 | Low      | EventlyMarkets | Question length limit bypassable via admin                | Acknowledged                                                                                                                      |
| I-01 | Info     | EventlyMarkets | LMSR binary search tolerance near MIN\_TRADE              | Acknowledged                                                                                                                      |
| I-02 | Info     | EventlyMarkets | No event emitted by `closeBetting`                        | **Acknowledged**                                                                                                                  |

***

## Production Blockers

**C-01 (Critical):** Potential P2P insolvency — review the `poolBalance` accounting against P2P-settled shares before high-volume deployment. The mathematical LMSR solvency guarantee applies to AMM-minted shares only; P2P fills may create an uncovered gap.

***

## Severity Scale

| Severity      | Definition                                                            |
| ------------- | --------------------------------------------------------------------- |
| Critical      | Direct fund loss or permanent bricking — immediate production blocker |
| High          | Fund loss possible under specific conditions                          |
| Medium        | DoS, griefing, or logic error with economic impact                    |
| Low           | Edge case, minor logic issue, or gas concern                          |
| Informational | Code quality, missing feature, or best practice                       |

Status options: Fixed · In resolution · Acknowledged · Open · By design


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.evently.market/audit-reports-ai/gemini.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.