As of 25 Oct 2026, MBD Financials has 2 audit reports by 2 security firms on Trustblock; the latest is by CertiK, dated 2 May 2024. Those reports list no open critical findings. It also holds 2 deployed contracts on 1 chain.
Record last updated . It holds audits and findings, contracts and incidents up to Oct 2026. Trustblock does not review code.
Newest first
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| MBD Financials Token | Security firm: CertiK | Date: | Scope: 2 addresses on Ethereum | 3 critical findings, fixed | Open · skynet.certik.com |
| MBD Financials (Token) | Security firm: Paladin | Date: | Scope: 1 address on Ethereum | No open critical findings | Open · paladinsec.co |
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 3 |
| High | 2 | 2 | 19 |
| Medium | 1 | 0 | 12 |
| Low | 2 | 2 | 23 |
The function `addProposal` incorrectly uses a local variable `proposalIDcount` to track proposal IDs. Changes to `proposalIDcount` within the function do not persist between transactions because the local variable is not stored back into a state variable. This can lead to logical errors in the management of proposal IDs, as each call to `addProposal` will start with the same initial `proposalIDcount`, ignoring previous increments.
Open the reportThe `submitVote()` is missing an `else` branch after checking if `blocked[msg.sender] == 0` or if the current proposal has a deadline further in the future than the one that is blocking the sender. This oversight allows for the possibility of a voter being able to vote multiple times on the same proposal.
Open the reportIn the `MBD` contract's voting mechanism, there is a critical design flaw where a user can vote on a proposal and then transfer their tokens to another account to vote again. This process can be repeated indefinitely, allowing the token holder to amplify their voting power disproportionately.
Open the report```solidity=1361 uniswapV2Router.addLiquidityETH{value: ethAmount}( address(this), tokenAmount, 0, // slippage is unavoidable 0, // slippage is unavoidable owner(), block.timestamp ); ``` The function `addLiquidity()` calls function `uniswapV2Router.addLiquidityETH()` with the `to` address specified as `owner()` for acquiring the generated LP tokens from the `MBD-ETH` pool. As a result, over time the `_owner` address will accumulate a significant portion of LP tokens. If the `_owner` is an EOA (Externally Owned Account), mishandling of its private key can have devastating consequences to the project as a whole.
Open the reportThe `swapAndLiquify` function converts half of the `contractTokenBalance` MBD tokens to ETH. The other half of MBD tokens and part of the converted ETH are deposited into the MBD-ETH pool on pancakeswap as liquidity. For every `swapAndLiquify` function call, a small amount of ETH is leftover in the contract. This is because the price of MBD drops after swapping the first half of MBD tokens into ETHs, and the other half of MBD tokens require less than the converted ETH to be paired with it when adding liquidity. The contract doesn't appear to provide a way to withdraw those ETH, and they will be locked in the contract forever.
Open the reportThe `swapExactTokensForETHSupportingFeeOnTransferTokens` and `addLiquidityETH` functions in the `IUniswapV2Router02` interface are missing the `deadline` parameter. The official Uniswap V2 Router requires a deadline for these functions to prevent front-running and ensure the transaction is executed within a specific timeframe.
Open the reportThe `submitVote` function does not check whether the `votingDeadline` of a proposal is still in the future, which allows votes to be cast on proposals that should no longer be active. This could result in votes being submitted after the deadline has passed, affecting the proposal's outcome and potentially violating governance rules.
Open the reportAn attacker can use a flashloan as the initial funds for an exploit to enlarge the profit or manipulate the token price in decentralized exchanges. If swapping/adding liquidity happens without price and slippage control and can be triggered on-chain by anyone, then an attacker can exploit the contract. ```solidity=1347 uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens( tokenAmount, 0, // accept any amount of ETH path, address(this), block.timestamp ); ``` Function `MBD.swapTokensForEth` invokes `IUniswapV2Router02.swapExactTokensForETHSupportingFeeOnTransferTokens` without setting restrictions on slippage or minimum output amount, which may be triggered by anyone.
Open the reportThe `whenNotBlocked` modifier and `onlyEligibleVoter` modifier are used in the `submitProposal` and `submitVote` functions to restrict voting access to non-blocked addresses, and voter eligibility validation. However, the definitions of these modifiers are missing in the contract, leading to a compilation error and potential security risks.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe `submitVote()` does not check whether a proposal has already passed before allowing a vote to be cast. This lack of validation allows votes to be submitted for a proposal that has already met the required threshold of votes to pass, which can lead to unnecessary gas expenditure and potential confusion about the final tally of votes.
Open the reportGenerally, deflationary tokens are incompatible with DEX and special rules need to be coded for DEX addresses eg. excluding them from reward. Otherwise, a hacker can exploit the protocol using the reflection mechanism. The balance of accounts that include rewards is calculated by `rAmount/rate`, where the rate is determined base on the total supply. If the `deliver()` function is executed with significant input, it can significantly decrease `rTotal`, thereby allowing for manipulation of the rate.
Open the reportVariable `_rOwned[account]` is not updated in the function `includeInReward()`, which will make the accounts included siphon off the tokens out of the balances of all token holders. The Rate was higher at the moment of the `excludeFromReward(account)` call, so the `_rOwned[account] / _tOwned[account]` ratio is bigger than expected for accounts included in the reward.
Open the reportThis issue pertains to a situation in which a contract utilizes a variable, `ProposalID`, before setting its value, leading to potential errors and unexpected behavior in the contract's execution.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe `whenNotBlocked` modifier is intended to prevent blocked accounts from voting. However, it incorrectly checks the `governance` array instead of the `blocked` array, which is supposed to track blocked accounts. This discrepancy can lead to unintended behavior, allowing blocked accounts to vote or preventing governance accounts from voting.
Open the reportThe `submitVote` function emits the `VotesSubmitted` event twice, once within an if-statement and once at the end of the function, without any conditional differences that justify two separate emissions. This redundancy could lead to confusion and unnecessary gas costs when the event is emitted.
Open the reportThe current implementation of the `_getTValues` and `_getRValues` functions leads to unnecessary recalculation of `tmarketing`. The `tmarketing` value is calculated twice: once in `_getTValues` and again in `_getRValues`. This redundancy increases gas costs and can be optimized.
Open the reportThe functions `_takeLiquidity` and `_takeMarketing` do not validate whether the `tLiquidity` and `_takeMarketingAmount` values are greater than zero before performing operations with these values. This could lead to unnecessary function calls and state changes, potentially wasting gas.
Open the reportAddresses are not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities. For example, transferring tokens to a zero address can result in a permanent loss of those tokens. ```solidity=1239 MarketingAddress = _marketingAddress; ``` - `_marketingAddress` is not zero-checked before being used.
Open the reportThe function `swapTokensForEth()` and `addLiquidity()` function don't check if the `tokenAmount` variable is above zero before executing. This could cause gas costs for each function call.
Open the reportPerforming division by zero would raise an error and revert the transaction. ```solidity=1047 return rAmount / currentRate; ``` The expression `rAmount / currentRate` may divide by zero. Its divisor has has estimated interval [0, 115792089237316195423570985008687907853269984665640564039457584007913129639935]. --- ```solidity=1179 return rSupply / tSupply; ``` The expression `rSupply / tSupply` may divide by zero. Its divisor has has estimated interval [ninf, pinf]. --- ```solidity=1193 if (rSupply < _rTotal / _tTotal) return (_rTotal, _tTotal); ``` The expression `_rTotal / _tTotal` may divide by zero. Its divisor has has estimated interval [0, 40000000000000000000000000000].
Open the reportA sandwich attack might happen when an attacker observes a transaction swapping tokens or adding liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (before the transaction being attacked) a transaction to purchase one of the assets and make profits by back running (after the transaction being attacked) a transaction to sell the asset. The following functions are called without setting restrictions on slippage or minimum output amount, so transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large: - `uniswapV2Router.swapExactTokensForETHSupportingFeeOnTransferTokens()` - `uniswapV2Router.addLiquidity()` Moreover,
Open the reportThe condition `!_isExcluded[sender] && !_isExcluded[recipient]` can be included in `else` .
Open the reportState variables that never change should be declared as `constant` to save gas. ```solidity=779 uint256 public _feeDenominator = 10000; ``` - `_feeDenominator` should be declared `constant`. --- ```solidity=780 uint256 public _MaxtotalFee = 2000; ``` - `_MaxtotalFee` should be declared `constant`. --- ```solidity=803 uint256 private numTokensSellToAddToLiquidity = 500000 * 10 ** 18; ``` - `numTokensSellToAddToLiquidity` should be declared `constant`. --- ```solidity=819 uint256 public _locktime = 60; ``` - `_locktime` should be declared `constant`.
Open the reportThe for loop contains repeated storage read access in the condition check. Given that the ending condition does not change in the for loop, the repeated storage read is unnecessary, and its associated high gas cost can be eliminated. ```solidity=1185 for (uint256 i = 0; i < _excluded.length; i++) { ``` Loop condition `i < _excluded.length` accesses the `length` field of a storage array.
Open the reportOne or more logic contracts do not protect their initializers. An attacker can call the initializer and assume ownership of the logic contract, whereby she can perform privileged operations that trick unsuspecting users into believing that she is the owner of the upgradeable contract. ```solidity=217 contract MBD is Initializable, IERC20Upgradeable, AccessControlUpgradeable { ``` - `MBD` is an upgradeable contract that does not protect its initializer. ```solidity=313 function initialize() public initializer { ``` - `initialize` is an unprotected initializer function.
Open the reportThe smart contract does not check or store the return value of an external call in a local or state variable, which may introduce vulnerabilities due to the unhandled outcome. ```solidity=1361 uniswapV2Router.addLiquidityETH{value: ethAmount}( address(this), tokenAmount, 0, // slippage is unavoidable 0, // slippage is unavoidable owner(), block.timestamp ); ```
Open the reportThe smart contract contains one or more values that are not used, which can lead to unnecessary complexity and reduced maintainability. ```solidity=1523 proposalIDcount = proposalIDcount + 1; ``` - The variable `proposalIDcount` is never used after this assignment.
Open the reportThe linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage. ```solidity=776 uint256 private _tTotal; ``` ```solidity=784 uint256 private _decimals; ```
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the report| Address | Chain | Source code |
|---|---|---|
| 0xa088…182e0xa08898cabe14680cdfea55398143bc120889182e | Chain: Ethereum | Source code: Verified source |
| 0x4ff3…6f460x4ff319847664b03a956d8f4f076a35ec2d4a6f46 | Chain: Ethereum | Source code: Verified source |
Is this your project? Show this record on your own website. The label states what the record holds, links to this page and updates by itself. It is free and needs no sign-in.
Automatic: the three strongest facts of this project’s own record (its last audit and two more), highlighted. They update with the record. Picking a fact turns Automatic off.
<head><script src="https://widget.trustblock.run/project-widget.min.js" defer></script></head><body><divdata-tb-project-widgetdata-tb-project-slug="mbd-financials"></div></body>
Paste the code where the label should appear. It uses no API credit and updates by itself.
Something wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us