Incident,
On Jun-21-2023 Baby Doge token was attacked using flashloan from UniV3 protocol with gains worth of lost 442 BNB or $100K.
Source: De.Fi incident database.
- Audits before it
- 3.
- Audits since
- None on Trustblock.
As of 3 Nov 2026, Baby Doge has 3 audit reports by 2 security firms on Trustblock; the latest is by QuillAudits, dated 20 Jun 2023. Those reports list no open critical findings. It also holds 1 deployed contract on 1 chain and 1 incident (latest 20 Jun 2023).
Record last updated . It holds audits, findings and contracts up to Nov 2026, and incidents up to Oct 2026. Trustblock does not review code.
Newest first
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| BabyDoge - Deflationary Swap and Multitoken Burn P | Security firm: QuillAudits | Date: | Scope: Files named in the report | No open critical findings | Open · quillaudits.com |
| BabyDoge - BDBurner | Security firm: QuillAudits | Date: | Scope: Files named in the report | No open critical findings | Open · quillaudits.com |
| AI Baby Doge | Security firm: Cyberscope | Date: | Scope: 1 address on BNB Chain | No open critical findings | Open · cyberscope.io |
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 0 | 2 |
| Medium | 0 | 0 | 1 |
| Low | 13 | 0 | 7 |
buyTokensWithERC20() uses transferFrom to transfer tokens from msg.sender to contract and then sends it to adminFeeReceiver,feeReceiver as fee and uses remaining for swapping. In the case where the token that is getting transferFrom doesn't revert on failure( e.g when the user isn't having enough balance to transfer) the code will run without reverting the transaction, Now because the user hasn’t transferred any tokens to the MultiTokenBurnPortal while sending token fees to adminFeeReceiver,feeReceiver the contract send tokens from collected fees ( in the case if contract is getting used for collecting fees) and use collected fee for swapping tokens.
Open the reportERC20 token which doesn’t revert on transfer, transferFrom (or in other important operation) can make this code vulnerable. E.g. burnTokens() uses token's transferFrom function to transfer tokens to DEAD_WALLET to burn them. it can happen that a token that is getting transferred is a token that doesn't revert on failure (e.g while not having enough balance when transferring) instead, it returns a bool value. the returned value is not getting checked in the function and it proceeds on the next line to add the amount in burnedAmount[msg.sender][token] and in portals[token].totalBurned.So in this way a user would be able to increase the amount of burned tokens that contract stores without burning the tokens. and after that, while swapping tokens the user can get a discount for the amounts that weren’t actually burned.
Open the report_checkDiscounts() fails to validate from the 2nd index. It sets prevDiscount = _discounts[0] on L589 but never reassigns it to the next one while iterating through the loop. so while checking it every time, it checks the current index's discount data (i.e discount and burnAmount) with the prevDiscount's data which was set as the 0th index of _discounts. So for the 1st index, it compares index 0's discount data but for the next i.e for the 2nd index also, it compares the 0th index's data and not the 1st one which would be previous in this case.This happens because prevDiscount is not getting updated in the loop. Example: this is the discount array: [{ discount: 1000, burnAmount: 50e18 }, { discount: 2000, burnAmount: 150e18 }, { discount: 2000, burnAmount: 300e18 }]While validating this array the _checkDiscounts() function checks 1st index with 0th and the 2nd also with 0th index and not with 1st. so it fails to identify that 1st index's discount and 2nd index's discount amount are the same.
Open the reportBurnPortal struct is using uint128 for totalBought and for totalBurned, it is hard to directly predict that the amount of burn token and bought tokens won't reach the max limit of what uint128 can store (2**128-1), our recommendation would be to use uint256 for storing these values to avoid any problems in future while incrementing these values.
Open the reportReadme file states that "Swap path must be [ WBNB -> BabyDoge ] for buyTokensWithBNB". The code only checks that swap path should contain two elements and the first element would be weth but doesn't contain any check for checking if the second element ( token address) is BabyDoge or not.
Open the reportIn buyTokensWithBNB() and buyTokensWithERC20() there are external calls for sending fees to addresses, for transferring tokens to and from the msg.sender. It can happen that tokens having hooks can give control to the external address e.g msg.sender while transferring tokens, on the other hand side while sending native tokens to addresses e.g. as a fee. Once they receive a callback, they can then try to reenter for calling buyTokensWithBNB(), buyTokensWithERC20() functions.In some cases, msg.sender can make a reentrant call and can use the issue discussed in A.2 and can use collected fees. This issue gets fixed after using SafeERC20 wrapper, but we recommend using reentrancy guard for both buyTokensWithBNB(), buyTokensWithERC20() functions to avoid any other issues related to reentrancy because of having external calls.
Open the reportContracts are using floating pragma (pragma solidity ^0.8.0), Contracts should be deployed with the same compiler version and flags that they have been tested thoroughly. Using floating pragma does not ensure that the contracts will be deployed with the same version. It is possible that the most recent compiler version gets selected while deploying a contract which has higher chance of having bugs in it.
Open the reportContracts are using floating pragma (pragma solidity ^0.8.0), Contracts should be deployed with the same compiler version and flags that they have been tested thoroughly. Using floating pragma does not ensure that the contracts will be deployed with the same version. It is possible that the most recent compiler version gets selected while deploying a contract which has higher chances of having bugs in it.
Open the reportSome imported interfaces (IBabyDogeFactory and IBabyDogePair) are not getting used and can be removed.
Open the reportSome imported imports (SafeOwnable and IFactory) are not getting used and can be removed.
Open the reportAttached through a shared contract address. Our incident data ends in Oct 2026.
On Jun-21-2023 Baby Doge token was attacked using flashloan from UniV3 protocol with gains worth of lost 442 BNB or $100K.
Source: De.Fi incident database.
| Address | Chain | Source code |
|---|---|---|
| 0x9183…43790x9183818c7d34820950db6a836d51d52ebfe04379 | Chain: BNB Chain | 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="baby-doge"></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