MagicSea - the native DEX on the IotaEVM — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for MagicSea - the native DEX on the IotaEVM, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 15
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 15 closed, publicly disclosed MagicSea - the native DEX on the IotaEVM reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, 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 MagicSea - the native DEX on the IotaEVM
- Access control findings disclosed against MagicSea - the native DEX on the IotaEVM
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
MagicSea - the native DEX on the IotaEVM: Voting and bribe rewards can be hijacked during emergency unlock by already existing positions
MagicSea's staking contract permits existing NFT positions to call addToPosition() during an active emergency unlock, while renewLock(), extendLock(), and createPosition() are all blocked or rendered unusable in that window. An attacker who pre-opens many minimal 1 wei long-lock positions can top them up the moment an emergency unlock triggers, growing their amountWithMultiplier and thus their voting weight in Voter. Because no new assets can enter the voting circulation during the emergency and honest users cannot renew or extend, the attacker can monopolize pool votes and steer LUM emission and bribe rewards. The protocol team fixed it by applying the same emergency-unlock check used by _lockPosition() to addToPosition() as well.
MagicSea - the native DEX on the IotaEVM: Inconsistent check in `harvestPositionsTo()` function
MagicSea's MlumStaking contract implements harvestPositionsTo(), an external non-reentrant function meant to allow either an NFT position owner or an ERC721-approved operator to harvest staking rewards to a destination address. The function first gates the caller through _requireOnlyApprovedOrOwnerOf(), which permits approved addresses, but then imposes a contradictory require() demanding that msg.sender be both the token owner and the harvest destination. Because an approved operator is not the owner, every such call reverts with FORBIDDEN, making the documented approved-harvester path unusable. Sherlock adjudicated this as a Medium and the protocol fixed it by changing the logical connector from && to ||, in PR #23, which the Lead Senior Watson signed off on.
MagicSea - the native DEX on the IotaEVM: `MlumStaking::addToPosition` should assing the amount multiplier based on the new lock duration instead of initial lock duration.
MagicSea's MlumStaking staking contract computes a position's lock multiplier from the initial lock duration instead of the recalculated amount-weighted lock duration when a user calls addToPosition. Once a deposit's remaining lock time reaches zero, that term is dropped from the weighted average, so a user adding tokens at lock expiry keeps the full multiplier while effectively halving the lock commitment. A second, related flaw lets users alternate addToPosition and renewLockPosition to restore the higher initial multiplier even after the lock has been shortened. Both let stakers obtain voting-power and reward leverage that exceeds what their actual lock time warrants. The protocol fixed the renew/add mismatch in a subsequent PR, while the post-expiry behavior was accepted as a design choice.
MagicSea - the native DEX on the IotaEVM: Wrong call order for `setTopPoolIdsWithWeights`, resulting in wrong distribution of rewards
The MasterChefV2 staking contract on MagicSea allows MLUM stakers to vote on pools, with the admin periodically setting top-pool weights to govern LUM emission distribution for the following period. The documented operational sequence requires calling updateAll on old pools, then setTopPoolIdsWithWeights, then updateAll on new pools. When this exact sequence is not followed — or when a pool is passed to updateAll only after its new weight is set — the new weight is applied retroactively across the entire interval since that pool's last timestamp update. The researcher proves that a newly qualifying pool immediately accrues rewards for the full period since its creation, and the system over-distributes LUM beyond the configured emission rate. A coded PoC confirms that after setting weights, Alice accrues ~499999 reward units when updateAll runs after the weight change versus 0 when it runs before.
MagicSea - the native DEX on the IotaEVM: A voter lose bribe rewards if another voter voted before claim.
MagicSea's BribeRewarder tracks a single global _lastUpdateTimestamp that is not scoped to a specific bribe period. Because the unclaimed-reward calculation for a given periodId depends on this one timestamp, once any voter deposits for a later period the timestamp advances and the accrued-but-unclaimed rewards of prior-period voters can no longer be computed correctly. The PoC shows a third voter depositing for period 2 before alice and bob claim their period-1 rewards drops alice's claimable amount from 75e17 to 50e17 and bob's to 0, with the lost rewards stuck in the contract. Sherlock's lead judge upheld the finding at High severity and the protocol fixed it by making the timestamp period-dependent.
MagicSea - the native DEX on the IotaEVM: Adding genuine BribeRewarder contract instances to a pool in order to incentivize users can be DOSed
MagicSea's Voter.sol caps each pool at five BribeRewarder contracts per voting period but lets anyone register a rewarder without whitelisting the reward token or imposing a minimum reward amount. An attacker can mint a worthless ERC20, create five rewarder instances through RewarderFactory, and call fundAndBribe() across dozens of future two-week periods (e.g. 100 periods, roughly four years), exhausting the bribe slots so genuine, valuable bribes revert with "too much bribes". This makes the incentive system unusable for targeted pools or, by watching new pools, effectively for the whole exchange, depriving competitive projects of voter incentives and liquidity. The bug was acknowledged, fixed in PR #35, and signed off by the Lead Senior Watson.
All reports in this group
- MagicSea - the native DEX on the IotaEVM: New staking positions still gets the full reward amount as with old stakings, diluting rewards for old stakersLogic error$0
- MagicSea - the native DEX on the IotaEVM: Non-functional vote() if there is one bribe rewarder for this poolLogic error$0
- MagicSea - the native DEX on the IotaEVM: Rewards might get stuck when approved actor renews a positionAccess control$0
- MagicSea - the native DEX on the IotaEVM: Voting does not take into account end of staking lock periodLogic error$0
- MagicSea - the native DEX on the IotaEVM: Attacker can manipulate the `lockDuration` of other users positionsAccess control$0
- MagicSea - the native DEX on the IotaEVM: Voters will lose all bribe rewards forever if they do not claim their rewards after the last bribing periodLogic error$0
- MagicSea - the native DEX on the IotaEVM: Funds unutilized for rewards may get stranded in BribeRewarderLogic error$0
- MagicSea - the native DEX on the IotaEVM: Lack of support for fee on transfer, rebasing and tokens with balance modifications outside of transfers.Logic error$0
- MagicSea - the native DEX on the IotaEVM: Attacker can block all votes to a specific pool by triggering an overflow errorLogic error$0