Midas - Instant Minter/Redeemer — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Midas - Instant Minter/Redeemer, 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 Midas - Instant Minter/Redeemer 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, 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 Midas - Instant Minter/Redeemer
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Midas - Instant Minter/Redeemer: Corruptible Upgradability Pattern
Midas's upgradeable DepositVault and RedemptionVault contracts inherit several base contracts (Pausable, Greenlistable, Blacklistable, WithSanctionsList) that contain storage variables but define no storage gaps, while only the top-level vault base contracts reserve gaps. During a future proxy upgrade, adding any new slot to a gap-less base contract would shift the storage layout and overwrite the derived vaults' existing state, corrupting accounting and permission data. The same class of issue was reported in an earlier Midas audit and partially fixed, but newly added contracts reintroduced the pattern. The protocol accepted the design, and a follow-up PR added gaps to the non-pure-function base contracts plus CustomAggregatorV3CompatibleFeed.
Midas - Instant Minter/Redeemer: RedemptionVaultWIthBUIDL does not redeem full balance if BUIDL balance is less than 250k post transaction.
Midas' RedemptionVaultWithBUIDL mismatches its spec: when a redemption leaves the contract's residual BUIDL balance below BUIDL's 250k minimum redemption threshold, the vault should redeem the entire remaining balance rather than only the shortfall. Because BUIDL shares cannot be sold back unless worth at least $250,000 absent an exception, the missing feature can permanently strand BUIDL tokens in the vault. The issue was filed under the contest's explicit spec-vs-code discrepancy allowance, acknowledged by the protocol, and fixed via a pull request to the midas-contracts repo. It self-declares medium severity with no audited payout recorded.
Midas - Instant Minter/Redeemer: Discrepancy between spec and code: Vault admin cannot update `tokensReceiver`.
The Midas instant minter/redeemer's ManageableVault initializes a public tokensReceiver field that fixes where subscription funds and mTokens are delivered, but provides no setter to change it after deployment. The protocol's own specification lists the investment recipient address among parameters the admin can "set and adjust," and every other parameter in that list has a setter except tokensReceiver. This means an admin dealing with custody or corporate-action changes cannot redirect incoming funds on-chain, contradicting the documented spec. The finding was upheld as Medium under the contest's rule that spec violations carry Medium severity regardless of impact, and the team added the missing setter in a follow-up PR.
Midas - Instant Minter/Redeemer: Standard redemption in `RedemptionVault` does not update token allowance.
Midas's RedemptionVault implements an allowance-based redeem cap in its TokenConfig, enforced for standard deposits and instant redemptions, but the standard (non-instant) redemption path in `_redeemRequest` never calls `_requireAndUpdateAllowance` on the token-out. As a result, a greenlisted user can submit standard redemption requests whose cumulative volume exceeds the admin-configured redeem allowance cap because the allowance is neither checked nor depleted. The finding was debated in an escalation over whether the cap applied to standard redemptions, and the judge ultimately agreed it breaks the documented spec and upheld it as Medium (with duplicates); the sponsor fixed it in PR RedDuck-Software/midas-contracts#69.
Midas - Instant Minter/Redeemer: `RedemptionVaultWIthBUIDL.sol#redeemInstant` will always DoS due to incorrect contract call.
In Midas's RedemptionVaultWithBUIDL, the initializer sets buidlLiquiditySource to the return value of buidlRedemption.liquidity(), which on Ethereum is the USDC token contract rather than the actual settlement liquidity source. Because USDC implements no token() function, the redeemInstant function always reverts at the line tokenOut = buidlLiquiditySource.token(), making instant redemption permanently unusable. The flaw stems from a misread of the external BUIDL contract API: the correct value comes from buidlSettlement.liquiditySource(). The finding was judged valid, downgraded to Medium via escalation, and grouped with four duplicates before being fixed.
Midas - Instant Minter/Redeemer: MBasisRedemptionVaultWithSwapper does not update mBasis daily limit or allowance when conducting mBasis->mTBill swap.
MBasisRedemptionVaultWithSwapper only decrements the mBasis instant daily limit and token allowance in the direct-redemption branch of redeemInstant. When the vault lacks sufficient tokenOut, it swaps the user's mBasis into mTBill and completes the redemption inside the mTBill redemption vault, so the mBasis cap is never updated. Users can therefore instant-redeem mBasis amounts exceeding the admin-configured daily cap, violating the protocol's redemption-limit spec. The finding was escalated as invalid, the escalation was rejected, and the lead judge upheld it as Medium with duplicates and the sponsor applied a fix.