yAudit reconstruction of the Cantina Mento V3 competition findings

yaudit-mento-v3-reconstructed-findings.md

Mento V3 — Reconstructed Cantina Findings

Independent yAudit reconstruction. This is not an official Cantina report and does not reproduce the original finding text. It is a rewritten answer key assembled from the Cantina competition results, the audited source, and public remediation history.

This document is intended for use by the yBorg program as a shadow-audit benchmark for calibrating and regression-testing security tools. Keep it separate from the audit target so agents do not see the answer key before completing the exercise.

• Shadow-audit package: yAudit/yborg-mento-v3-shadow-audit
• Cantina competition results: Mento V3 leaderboard
• Competition announcement: Cantina on X

Result summary

Severity	Count
High	0
Medium	7

Repository split:

• mento-core: 6 Medium findings
• bold: 1 Medium finding

Exact audited baselines

These are the pre-remediation commits against which the shadow audit should run:

Repository	Audited commit
mento-protocol/mento-core	78fc103fab67e798258621e04176e25561b6f093
mento-protocol/bold	d8735b6ecd5b3915918340cf278868703d845fb6

Do not replace these with the later integration commits. Those commits contain remediations and would remove vulnerabilities the benchmark is meant to detect.

Reconstructed findings

M-01 — LPs can sandwich rebalancing to avoid the rebalance cost

• Cantina finding: #706
• Repository: mento-core
• Original title: “LPs can sandwich rebalancing to avoid losing value due to rebalance incentives”
• Reconstruction: A liquidity provider can withdraw immediately before a predictable rebalance and return immediately afterward. Because the rebalance incentive is paid from pool value, the exiting LP avoids its proportional share of that cost and leaves passive LPs bearing more of it.
• Impact: Repeated timing around rebalances can unfairly shift value from passive LPs to active or MEV-capable participants.
• Remediation status: No dedicated public remediation PR was identified. Later public code retains the relevant incentive mechanism, which is consistent with acknowledgement or non-remediation, but the precise Cantina resolution is not publicly visible.

M-02 — The 1% combined-fee ceiling is incompatible with wider oracle thresholds

• Cantina finding: #642
• Repository: mento-core
• Original title: “Hardcoded limit for lpFee+protocolFee to 100 bps is not compatible with data feed with threshold > 1%”
• Reconstruction: The pool capped the combined LP and protocol fees at 100 basis points even though a supported price feed could permit a deviation threshold above 1%. That mismatch prevented governance from configuring fees that matched the risk envelope of such a feed.
• Impact: Some markets could not be configured as intended, weakening availability or the economic protection expected around oracle deviations.
• Fix: Raise the maximum combined FPMM fee to 2%.
• Remediation: PR #683, source commit 6515685771c527b21974e2bfd0aa4150701cddbe, merge commit d89d04028da7c3b93a81305193ea96c9103827ee.

M-03 — OracleAdapter accepts a stale median price

• Cantina finding: #593
• Repository: mento-core
• Original title: “OracleAdapter doesn't verify that the returned median price timestamp is not stale”
• Reconstruction: The adapter consumed the oracle median without confirming that its timestamp remained within the token report-expiry interval. A structurally valid but obsolete price could therefore be treated as current.
• Impact: Protocol operations could use an outdated exchange rate, exposing swaps or rebalancing to incorrect pricing.
• Fix: Return the median timestamp and reject reports older than the configured expiry period.
• Remediation: PR #681, commits d645e8c3675c6ff67fb1e41baa24a00dbdd296d2, d3fd8ace471cdb6a05b10c8feed5cc2690bba687, and 0987cbfec60ba92fe92aeb6e726d313ec00f6438; merge commit 1c1402ac6edc318666388805967d1ed21fc2cd7c.
• Attribution caveat: The remediation PR links Cantina finding #24, not #593. The code change is a strong semantic match and likely represents the same duplicate cluster, but the private adjudication record is unavailable.

M-04 — Trading-limit accounting incorrectly includes swap fees

• Cantina finding: #586
• Repository: mento-core
• Original title: “Trading limits incorrectly include fees”
• Reconstruction: Trading-limit netflow was updated using the gross input amount, including the portion retained as swap fees. Fees are not part of the asset flow the limit is intended to measure, so the accounting drifted from actual traded volume.
• Impact: Limits could be consumed prematurely or otherwise miscomputed, causing avoidable trade denial and incorrect risk enforcement.
• Fix: Remove the fee component before updating trading-limit accounting.
• Remediation: PR #672, source commit c765a5ccd571ab066ff5e94631b45722116592a1, merge commit 7e5283a42a9236943504bbb9f040a94d41376e81.

M-05 — StabilityPool proxy leaves accumulator P at zero

• Cantina finding: #448
• Repository: bold
• Original title: “StabilityPool proxy leaves accumulator P zero and bricks deposits”
• Reconstruction: The upgradeable deployment did not reproduce the implementation contract's state initialization for the P accumulator. Proxy storage therefore retained the zero default instead of the nonzero value assumed by deposit and reward calculations.
• Impact: Core StabilityPool arithmetic cannot operate as designed, preventing deposits or otherwise bricking the pool.
• Fix: Initialize P in the proxy initializer.
• Remediation: PR #35, source commit bbb0e5f48491460e890da3adf4614b88616b97b7, merge commit 3f3860f609653f9a0895c1d8c04163def152553e.

M-06 — A dust donation can deny rebalancing

• Cantina finding: #224
• Repository: mento-core
• Original title: “Rebalancing DoS via Dust Donation”
• Reconstruction: Rebalancing derived an amount from the difference between the live token balance and the stored reserve before synchronizing them. An attacker could donate a tiny amount directly to the pool, perturb the difference, and make the rebalance validation fail.
• Impact: Any account could cheaply and repeatedly deny rebalancing, impairing the mechanism that restores the pool to its intended price relationship.
• Fix: Synchronize reserves at the beginning of the rebalance flow.
• Remediation: PR #674, commits 0d0dd30965827b8a2d5d1d1f28dda546cdfea5de and d1ab8d7514ed3f39928fda2fefa139334c664d91; merge commit e8dbd2280048cc1887d9aca773692d98264a4741.

M-07 — Problems in the initial MINIMUM_LIQUIDITY handling

• Cantina finding: #213
• Repository: mento-core
• Original title: “Issues With MINIMUM_LIQUIDITY Handling”
• Reconstruction: The first-liquidity path subtracts permanently locked minimum liquidity and then applies an additional minimum-liquidity condition to the provider's resulting mint. This produces an unexpectedly restrictive bootstrap threshold and can reject otherwise reasonable initial deposits.
• Impact: Initial or small liquidity provisioning can revert unexpectedly, impairing pool deployment and availability.
• Remediation status: No dedicated public remediation PR was identified. Later public code retains the relevant pattern, which is consistent with acknowledgement or non-remediation, but the precise Cantina resolution is not publicly visible.
• Confidence note: This reconstruction is based on the accepted title and the audited implementation because the full adjudicated text is behind Cantina authentication.

Remediation commit map

Finding	Repository	Dedicated fix/merge commit	Consolidated integration commit
#706	mento-core	No public fix identified	—
#642	mento-core	6515685 / d89d040	4048a6c
#593	mento-core	d645e8c, d3fd8ac, 0987cbf / 1c1402a	4048a6c
#586	mento-core	c765a5c / 7e5283a	4048a6c
#448	bold	bbb0e5f / 3f3860f	073a25f
#224	mento-core	0d0dd30, d1ab8d7 / e8dbd22	4048a6c
#213	mento-core	No public fix identified	—

The four identified mento-core remediations were developed as separate PRs on feat/mento-v3, then landed together in develop through PR #631 at commit 4048a6c392790527d7ab3133af6f3336efc0cc97.

The BOLD remediation was developed separately and later landed in main through PR #17 at commit 073a25f049f423b3336e3785d5f1e13235ced07b.

Therefore, the fixes are not all contained in one commit across both repositories. They are consolidated into one integration commit per repository, and two accepted findings do not have an identified public remediation.

Method and limitations

• The seven accepted IDs and titles form the answer-key inventory: 0 High, 7 Medium.
• Finding descriptions above are original paraphrases reconstructed from the audited code and public remediation diffs. They are not copied Cantina report text.
• Cantina's individual finding routes currently require authentication, and no separate official public PDF was located.
• Remediation commits corroborate a finding but are not themselves authoritative adjudication records. A fix PR can refer to a duplicate submission, a different severity, or another review.
• Finding #593 has the strongest caveat: its matching remediation PR links finding #24, so the relationship is treated as a semantic/duplicate-cluster match rather than an exact ID link.
• For #706 and #213, no dedicated public remediation was located; their acknowledgement/non-remediation status is inferred and should not be represented as an official Cantina disposition.