
Fluton Confidential DeFi Security Review
Review of Fluton’s confidential DeFi and cross-chain infrastructure, including FHE token flows, bridge integrations, and a Diamond-based Aave V3 adapter.
Kann Audits / Security Review
Wild ProtocolReview of token launch, bonding-curve, liquidity-locking, state-management, and transfer-library contracts.
Executive summary
Review of token launch, bonding-curve, liquidity-locking, state-management, and transfer-library contracts.
This page reflects only the scope and review context disclosed in the published report. Fields the report does not provide are omitted rather than inferred; the PDF remains the source of record for issue detail and limitations.
Security is contextual. This report does not guarantee that the protocol is free from vulnerabilities. It applies to the review context documented in the report.
Scope & record
/src/Deployer.sol/src/LpLocker.sol/src/StateManager.sol/src/libraries/CurrencySend.sol/src/libraries/CurveMath.solFindings overview
The counts below are transcribed from the published report. Status and issue detail remain subject to that report’s exact terminology.
Published findings
Findings below are reproduced from the complete Kann Audits security review. View the full PDF for complete scope, methodology, assumptions, and audit context.
4.1.1
The function launchV4Pool() allows custom pool creation and token graduation (with manually set ticks and spacing). However, it does not call lpLocker.setTokenParams(), which is required to configure the LP locker for fee claiming. Without calling setTokenParams(), fees earned from the pool become unclaimable, rendering the fee distribution logic non-functional for tokens launched via launchV4Pool(). Incontrast, thegraduateToken()functiondoesinvokelpLocker.setTokenParams(), meaningfeeclaiming only works when using that path. This makes the launchV4Pool() function incomplete and effectively useless for real-world deployments where fees matter.
Fixed 4.2 Medium Risk
4.2.1
When launching a token with bonding curve parameters, there is no validation ensuring that stepsize * numSteps == curveSupply. If this is not aligned: If stepsize * numSteps > curveSupply, the bonding curve will appear to offer more tokens than were actually allocated, leading to potential inconsistencies (e.g., using LP pool tokens to fulfill purchases). If stepsize * numSteps < curveSupply, part of the curve supply will become unreachable via the bonding curve, and remain unused. While this behavior may be intentional to allow flexible bonding curve shapes, without an explicit check or warning, it can lead to unintended launch behavior due to misconfiguration.
4.2.2
When a user purchases a launch token using ETH (base token), the acceptAmount() function correctly calculates the amount used (amountInUsed) and refunds the excess ETH back to the user. However, despite the refund, the entire msg.value is still forwarded to the StateManager.buyToken() call, rather than just the used portion. This results in the StateManager contract receiving more ETH than it should, creating incorrect accounting and potential fund mismanagement.
4.2.3
When a user purchases tokens using an ERC20 base token, the function _getBuyQuote- AndFees()correctlycalculatestheactualamountused(amountInUsed)andtheassociatedfees. However, if the user sends more than amountInUsed, the excess tokens are not refunded. In contrast, when using ETH as the base token, any overpayment is explicitly refunded. This inconsistent behavior creates a silent loss of funds for users interacting via ERC20 tokens.
4.2.4
Uses ERC20(token).transfer(...) and checks whether it returns true to confirm success. However, some widely-used tokens like USDT do not return any value on transfer, which causes the boolean check to fail and revert even if the transfer was successful.
Fixed 4.3 Low Risk
4.3.1
Although the deployer can set allowForcedGraduation to false, graduateToken() and _launchV4Pool() do not validate this setting, allowing owner of deployer and creator to forcibly graduate a token even when it was explicitly disabled.
Fixed 4.4 Informational
4.4.1
In the PriceCurve bondingCurveParams, no check ensures that numSteps equals prices.length. A mismatch could result in unexpected pricing behavior or runtime errors.
Methodology
Kann Audits reports describe independent researcher review followed by collaborative analysis of findings and attack paths. The standard review foundation includes:
Audit team
Final assessment
All seven reported findings were marked fixed.
The assessment applies only to the review context and limitations documented in the published report. Missing details are not inferred, and later changes require separate analysis.
Start a conversation
Share the system, fixed scope, and target date. Build enough time into the plan for review, remediation, and verification.