High Findings

Frontrunning Matched Funds for Unfair Gains

Severity: High

Ecosystem: Aptos

Protocol: Emojicoin

Auditor: OtterSec

Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772

Report Date: Feb 2025

Description:

There is potential for frontrunning when matching funds are allocated. This issue arises due to the way matched amounts are distributed. The emojicoin arena module features a mechanism where users may lock in a portion of their contribution to receive matched funds from the vault. An attacker may create a large number of pools with small amounts, increasing the likelihood that one of their pools is chosen during the crank scheduling. Before the crank selects a melee, the attacker may buy a large amount of their own token, driving up its price, inflating its value relative to other tokens in the pool. Consequently, if their pool is selected, they may then buy into the pool and swap out their tokens to capture the matched funds.

Wallet creation is vulnerable to front-running attacks

Severity: High

Ecosystem: Aptos

Protocol: Momentum Safe

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/MSafe%20-%20Zellic%20Audit%20Report.pdf

Report Date: Sep 2022

Description:

A malicious user can monitor the mempool for pending ini_wallet_creations transactions and block them by submitting transactions with a higher gas price that calls aptos_account::create_account(msafe_address). This is because msafe_address is directly readable from the mempool.

Potential front-running in orderbook create

Severity: High

Ecosystem: Aptos

Protocol: Laminar Markets

Auditor: Zellic

Report: https://github.com/Zellic/publications/blob/master/Laminar%20-%20Zellic%20Audit%20Report.pdf

Report Date: Oct 2022

Description:

address and seed are trivial. Attacker can front-run book::create_orderbook by creating account at right address, causing a revert.