UBD Network

In the `UBDNLockerDistributor` contract, the `OWNER_ROLE` has authority over the following functions: - `setPaymentTokenStatus()`: Sets the status of a given payment token with a 48-hour timelock. - `setDistributionToken()`: Sets the distribution token only once. - `renounceOwnership()`: Renounces ownership of the contract, leaving it without an owner and thus disabling the functionality of `onlyOwner` restricted functions. - `transferOwnership()`: Transfers ownership of the contract to a new account. This function can only be called by the current owner. The `Guardian` has authority over the following function: - `emergencyPause()`: Emergency pause a payments method for one hour. Any compromise to the `OWNER_ROLE` could enable an attacker to take advantage of these functionalities, potentially leading to security risks. In particular, a malicious actor gaining control of the `OWNER_ROLE` could transfer ownership to an account under their control or even renounce ownership, rendering the contract ownerless and disabling certain functions. Therefore, the audit team strongly advises clients to mitigate this risk by applying decentralization and promoting transparency in future endeavors. *Important Note: Certain identification and KYC procedures were attempted to be applied to the project team in order to better understand the centralization situation and potential risks of the project. The project team refused to cooperate with the investigation efforts given the excuse of approaching the timeline for launch. Thus based on the negative signals we concluded that there is potential high risk to the project. We strongly advise end users to conduct further research and exercise due diligence before engaging with the project. It is crucial for end users to independently verify and assess all available information to make informed decisions.*

`INITIAL_SUPPLY` UBD Network (UBDN) tokens are sent to `_initialKeeper` when deploying the contract. This could be a centralization risk as the `_initialKeeper` can distribute tokens without obtaining the consensus of the community. ```solidity=15 constructor(address _initialKeeper, address _minter, uint256 _premintAmount) ERC20("UBD Network", "UBDN") { INITIAL_SUPPLY = _premintAmount; _mint(_initialKeeper, INITIAL_SUPPLY); minter = _minter; } ``` On-Chain Analysis (06/27/2023) - The address of the finalized `UBDN` token is [0xd624e5c89466a15812c1d45ce1533be1f16c1702](https://etherscan.io/address/0xd624e5c89466a15812c1d45ce1533be1f16c1702) - During the [creation](https://etherscan.io/tx/0x00387a9cf601c85c8ff02bde1f2f6e50a51bbdfd91d9440025a7c2e524c52668) of UBDN token contract, 5,000,000 UBDN tokens were sent to the multi-signature wallet [0xE206f8AC6067d8253C57D86ac96A789Cd90ed4D4](https://etherscan.io/address/0xe206f8ac6067d8253c57d86ac96a789cd90ed4d4). The audit team would like to remind users that two outdated `UBDN` tokens exist in the mainnet. - [0x3c388f96d5c698f980c49d31fc48ef88f90d0d8b](https://etherscan.io/token/0x3c388f96d5c698f980c49d31fc48ef88f90d0d8b#code) - [0xda7d1ca5019d4ca46fa9e70035a0764c7547cf2c](https://etherscan.io/token/0xda7d1ca5019d4ca46fa9e70035a0764c7547cf2c#code) The audit team would like to know the token distribution plan for the initial supply hold by `_initialKeeper`. *Important Note: Certain identification and KYC procedures were attempted to be applied to the project team in order to better understand the centralization situation and potential risks of the project. The project team refused to cooperate with the investigation efforts given the excuse of approaching the timeline for launch. Thus based on the negative signals we concluded that there is potential high risk to the project. We strongly advise end users to conduct further research and exercise due diligence before engaging with the project. It is crucial for end users to independently verify and assess all available information to make informed decisions.*

In the `UBDNLockerDistributor` contract, the contract owner is granted significant privileges, including the ability to withdraw all the deposited funds (stablecoins) from the contract by sending them to the `owner()` address. This represents a major centralization risk. ```solidity function buyTokensForExactStable(address _paymentToken, uint256 _inAmount) external returns(uint256) { require(address(distributionToken) != address(0), 'Distribution not Define'); require(paymentTokens[_paymentToken], 'This payment token not supported'); // 1. Receive payment IERC20Mint(_paymentToken).safeTransferFrom(msg.sender, owner(),_inAmount); ... } ``` In this case, users who deposit their stablecoins into the `UBDNLockerDistributor` contract in order to buy UBDN tokens may lose their assets if the owner account is compromised or the owner chooses to withdraw the deposited funds without properly operating the project. Furthermore, the lock period of 90 days is long. Users who purchase UBDN tokens cannot claim these tokens immediately; instead, they must wait for this lock period to expire. During this time, if the owner account is compromised or the project stops running, users may lose the values of the locked tokens. *Important Note: Certain identification and KYC procedures were attempted to be applied to the project team in order to better understand the centralization situation and potential risks of the project. The project team refused to cooperate with the investigation efforts given the excuse of approaching the timeline for launch. Thus based on the negative signals we concluded that there is potential high risk to the project. We strongly advise end users to conduct further research and exercise due diligence before engaging with the project. It is crucial for end users to independently verify and assess all available information to make informed decisions.*

The `UBDNLockerDistributor` contract contains precision loss issues in its `calcTokensForExactStable()` and `calcStableForExactTokens()` functions. The issue is rooted in the way Solidity handles integer division, rounding down to the nearest integer, which can cause minor discrepancies. Over repeated operations, these minor discrepancies can compound, leading to more significant discrepancies.