REVIEWED BY: Elmyre

Preface:

This is a complete review of the WrappedMinu smart contract project based on the available code in https://scan.pulsechain.com/address/0x30D235fdC54b806e684e653989364eA1Ae9C8289/contracts#address-tabs.

Even though the code is simple, I would advise anyone that is reading this document to also look at other reviews and analysis of the contract! Some issues or security concerns might not be covered here due to my lack of knowledge and understanding, so getting a second opinion is a good thing to keep in mind! This review is based on the deployed version of the code.

Code Review:

The WrappedMinu smart contract inherits from two OpenZeppelin contracts:

• ERC20.sol (@openzeppelin/contracts/token/ERC20/ERC20.sol – v4.7.0).
• Ownable.sol (@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol – v4.7.0).

These are widely used for creating ERC-20 tokens and audited, reducing their likelihood of having critical bugs or vulnerabilities. They provide basic token functionality and enable ownership control.

This contract combines the functionality of wrapping and unwrapping tokens, along with a customizable burn fee, allowing users and the owner to manage token transactions. The OnlyOwner modifier ensures that only the owner has control over certain functions like setting the burn percentage and managing fee exclusions/inclusions.

The Constructor, on deployment, initializes the contract with the name “Wrapped Minu” and symbol “WMINU“. It also receives a token address as parameter (supposedly the one for the Minu token) and stores it in the public variable minu.

• State Variables and Mappings:
  • minu: Variable where the Minu’s tokens address is stored.
  • burnPercent: public variable with a default value of 1000 (1%) and corresponds to the burning percentage of the tokens to be burned on each token transfer. This value can be changed by the contract’s owner up to a value of 50000 (50%).
  • _isExcludedFromFee: Mapping used to exclude some addresses from a burn fee. When an address is excluded from the fee, it won’t be subject to a burn when transferring tokens. This mapping can be updated by the contract’s owner.
• OnlyOwner Functions:
  • excludeFromFee: Allows the contract’s owner to exclude a received address from the burning fee on WMINU’s tokens transfer.
  • includeInFee: Allows the contract’s owner to set a received address as being subjected to a burning fee on WMINU’s tokens transfer.
  • setBurnPercent: Allows the contract’s owner to set the burn percentage for the burn fee. It restricts the burn percentage to be no more than 50%.
• External Functions:
  • wrap: Responsible for wrapping Minu tokens based on a given amount. It verifies if amount is bigger than zero and if the user has enough Minu tokens for the transaction to procced. If all conditions are valid, it will transfer the Minu tokens from the user to this contract (based on the received amount) and mint the same amount of WMINU tokens to the user.
  • unwrap: Responsible for unwrapping Minu tokens based on a given amount. It verifies if amount is bigger than zero and if the contract has enough Minu tokens for the transaction to procced. If all conditions are valid, it will burn the WMinu tokens the user has (based on the received amount) and transfer him the same amount of MINU
• Public Functions:
  • transfer: Override of the ERC-20 transfer It allows users to transfer Wrapped Minu tokens to another address but adds extra conditions in order to verify if a percentage of the tokens to be transferred should be burned or not. It takes the amount of WMinu tokens as a parameter and ensures that the value is bigger than zero and that the user has a sufficient balance of tokens. It verifies if the user (msg.sender) is excluded from the burning fee or not (using the _isExcludedFromFeeI maping), and if it is not, a percentage of the tokens to be sent is burned, based on the “burnPercentage” variable value.
• Internal Functions:
  • _calculateTax: Pure function responsible for calculating the amount of tokens to be burned on each WMinu token transfer, based on the “amount” and “taxPercentage” variables received. It’s used by the transfer

Minor Bug: In the _calculateTax function, if “amount x burnPercentage” is less than 100000, the burn fee will always be zero due to the value of the division rounding down!

Conclusion & Security Concerns:

The contract has some owner-only functions that allows it to manage and configure the fee structure and decide which addresses are subject to the burn fee.

Also, as written, it has a mechanism where users are subjected to a burn fee on every transfer. This means that a portion of the WMINU tokens is burned on each transfer and removed from circulation. As a result, over time, the total supply of WMINU tokens will decrease due to the burn fee, and this decrease in supply is equivalent to Minu tokens being held by the contract.

Users who pay the burn fee effectively lose a portion of their WMINU tokens, and this amount cannot be unwrapped to retrieve the initial Minu tokens balance. The contract will accumulate Minu tokens over time because of the burn fees and are effectively owned by the contract.

This aspect of the contract design benefits the contract itself, including the owner if they control it, at the expense of users who are subject to the burn fee.

The contract’s owner can also mint has many WMINU tokens as it wants, via the _mint function, potentially being able to significantly influence the market value of both WMINU and MINU tokens.

Only the mentioned above minor bug was found, and no security risks were uncovered. However, since the contract depends heavily on the MINU token, any vulnerabilities or flaws in its contract could affect this one.

Important Note: The contract’s ownership was revoked in the transaction 0xc93d99082a7d2f09d7dd7ba8673c7a7c94faeeaf780b1ce81e388fdfbf5e49a5, which can also be verified in https://scan.pulsechain.com/address/0x30D235fdC54b806e684e653989364eA1Ae9C8289/logs#address-tabs.

This effectively means that the burning fees cannot be changed anymore and that the Minu tokens accumulated by the contract are effectively lost.