EXECUTIVE SUMMARY
Golden Beans is a new cryptocurrency linked to the BNB All Star project. It has elastic properties that distribute some fees to all token holders by increasing its value. The total supply also changes algorithmically, by increasing or decreasing.
It's recommended that users review the whitepaper of the project and this report in its entirety to fully understand the application's fundamentals and risks.
We found one medium-severity issue related to frontrunning; the deployer team acknowledged it.
SCOPE
FUNDAMENTALS
This is an elastic token which means the total supply is modified algorithmically, in this case, by burning fees which reduces the total supply of the token, and distributing other fees into the price of each token. This token is acquired by purchasing BEANS through interaction with the smart contract. BEANS can then be burned (which decreases the total supply) and exchanged for BNB. The contract also features a referral system which allows users to increase their individual earnings by inviting others to purchase tokens.
Name: Golden Beans
Symbol: BEANS
Initial price: 0.00000011 BNB for 1 Golden Bean
Fees & burn:
Fees receivers (1% each, from purchases and withdraws):
Whitelist (early roasters): While the whitelist system is active, the maximum deposit per whitelisted address is 1 BNB.
Referral system:
Notable fact: This token does not use a standard liquidity pool. The price for each token is determined algorithmically and swapped from the smart contract directly.
FINDINGS
| INTERACTION | SEVERITY |
|---|---|
| [CPFM-1] sandwich | MEDIUM |
| [CPFI-1] dividend fee does not decrease supply | INFORMATIONAL |
CPFM-1: An attacker can frontrun a buyer purchasing by buying tokens before and selling their tokens immediately after, in order to turn a profit. Buyers can mitigate this frontrunning risk by using private transaction solutions. POC
CPFI-1: function brew(): The dividend fee that is removed from circulation in this function does not decrease the total supply of the token and only increase the value of tokens, which is inconsistent with other usage of this fee.
UNIT TESTS
| INTERACTION | RESULT |
|---|---|
| [CPUT-1] buying | OK |
| [CPUT-2] selling | OK |
| [CPUT-3] fees | OK |
| [CPUT-4] supply variation | OK |
| [CPUT-5] transfer | OK |
| [CPUT-6] whitelist | OK |
| [CPUT-7] elasticity | OK |
Unit testing was conducted to verify possible exploits, validate the logic, and ensure it aligns with the project's fundamentals. It was done so successfully.
PRIVILEGES
RECOMMENDATIONS
We recommend implementing a delay before the sale of a token in order to mitigate sandwich attacks and resolve issue CPFM-1, but also to remove a point of failure.