Arrakis Valantis SOT — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Arrakis Valantis SOT, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 6
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 6 closed, publicly disclosed Arrakis Valantis SOT reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Oracle manipulation, Access control, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against Arrakis Valantis SOT
- Oracle manipulation findings disclosed against Arrakis Valantis SOT
- Access control findings disclosed against Arrakis Valantis SOT
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Arrakis Valantis SOT: ArrakisMetaVault::setModule Malicious executor can drain the vault by calling withdraw after initializePosition
In the Arrakis modular vault built on the Valantis HOT module, the executor who drives ArrakisStandardManager.setModule was trusted only for rebalance actions, but not for module switching. Because setModule lets the caller supply arbitrary payloads that are executed against the newly-swapped module, a malicious public executor could withdraw the vault's entire liquidity from the old module, deposit it into the new module via initializePosition, and then withdraw everything to an attacker-controlled address. The root cause was the missing reserve/correctness validation after module migration, which the sponsor fixed in PR #88 and the lead judge validated. Net economic impact is theft of all vault funds.
Arrakis Valantis SOT: ArrakisMetaVaultPrivate::fund No slippage control on private vault deposit can cause unlimited loss to owner
An attacker can front-run a deposit into an ArrakisMetaVaultPrivate vault, forcing the depositor's balanced liquidity to be committed around an unfavorable pool price with no slippage protection, since the private vault owner owns all shares so no minimum-share-minted bound can be defined. Because the HOT price-oracle check can be skipped in AMM-only mode, the deposit is accepted at the manipulated price and the depositor's one-sided liquidity is then back-run. A numeric example shows a 269 USDC profit to the attacker at the depositor's expense. The finding was escalated and upheld as High by the Sherlock judge with duplicates, and the protocol acknowledged the issue, recommending exposure of the HOT deviation parameters on the fund interface.
Arrakis Valantis SOT: A malicious executor can delete the fees belonging to the owner of `ArrakisStandardManager`
In the Arrakis/Valantis SOT integration, the executor role on ArrakisStandardManager is supposed to be restricted during a vault rebalance, but the ValantisHOTModule's swap() path hands the caller an arbitrary call target. Because the module itself holds the poolManager role on the associated SovereignPool, a malicious executor can point that arbitrary call at SovereignPool.claimPoolManagerFees, which credits the module's balance and thereby satisfies the swap's min-return/slippage check, after which the module re-deposits its entire balance into the pool. The net result is that all accrued manager fees are permanently re-deposited as pool liquidity and become unclaimable, and the poolManager is zeroed out, breaking other poolManager-only functions. The accepted fix blocks passing the associated SovereignPool as the router.
Arrakis Valantis SOT: USDT is not supported
Arrakis's modular USDT-enabled swap instruments rely on OpenZeppelin 4.9.5 allowance helpers that do not force-approve a token when a nonzero allowance already exists. Because USDT requires the allowance to be reset to zero before a new approval can succeed, any swap where the actual token amount consumed (determined by the swap payload) is smaller than the granted allowance leaves a stale nonzero allowance behind, permanently preventing the module from interacting with the SovereignPool or router again. This is reachable both through the public swap path on ArrakisPublicVaultRouter and through the untrusted-executor rebalance flow in ArrakisStandardManager, and it occurs even without malicious input because pools can consume less than the approved amount through rounding. The lead judge accepted the reporter's escalation and upheld the finding as a unique Medium, confirming the protocol's documented USDT support is violated.
Arrakis Valantis SOT: Through rebalance(), an executor can drain 100% of vault reserves by minting cheap shares
A malicious executor of ArrakisStandardManager can drain roughly 99% of a vault's reserves in a single rebalance transaction. Because the executor controls the payload and the router address passed to ValantisHOTModule.swap(), they can first withdraw all liquidity, then have an arbitrary contract mint vault shares at a near-zero price after inflating pool reserves with a rebase token, and finally burn those shares to collect virtually the entire TVL. The expected-min-return and TVL-slippage safeguards are bypassed cheaply, making the theft economically trivial. The finding was adjudicated as a solo high-severity issue after an escalation.
Arrakis Valantis SOT: Adding liquidity can be `DoS`ed due to calculation mismatches
The Arrakis modular liquidity suite lets users add liquidity through ArrakisPublicVaultRouter, which quotes required token amounts and then delegates to ArrakisMetaVaultPublic and the Valantis HOT module. A rounding-direction inconsistency means the router's quote rounds down while the module's deposit calculation rounds up, so the module can request one more unit of each token than the router pulled from the depositor, reverting legitimate add-liquidity transactions. The issue is reachable whenever pool reserves and vault supply hit values that trigger the mismatch (demonstrated at 1e18+1 each), and it permanently blocks affected deposits even against workaround attempts such as sending extra dust to the router. The judge upheld the finding at High severity after a contested escalation, and the fix was implemented and signed off in arrakis-modular PR #88.