The contract has unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to different compiler versions. This can lead to an ambiguity when debugging as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.

Unlocked Compiler Version

The linked statements do not affect the functionality of the codebase and appear to be either leftovers from test code or older functionality.

Redundant Code Components

The linked variables could be declared as `constant` since these state variables are never modified.

Set `constant` to Variables

Functions that affect the status of sensitive variables should be able to emit events as notifications to customers.
- `addStaticReward()`
- `addAirdropReward()`
- `setRewardsFactor()`
- `activate()`
- `excludeFromFees()`
- `allowTransferBeforeTradingIsEnabled()`
- `allowNftTrade()`
- `updateClaimWait()`
- `updateTreasureAllowance()`
- `setMarketingWallet()`
- `setTeamWallet()`
- `emergencyWithdraw()`

Missing Emit Events

`public` functions that are never called by the contract could be declared `external`. When the inputs are arrays, `external` functions are more efficient than `public` functions.

Function Visibility Optimization

The `require` can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.

Missing Error Messages

In the contract `Uland`, the role `owner` has authority over the following functions:
- renounce ownership through `renounceOwnership()`
- transfer ownership through `transferOwnership()`
- set `tradingEnabled` through `activate()`
- bulk airdrop through `bulkAirdrop()`
- select winner through `grandAirdrop()`
- set `uniswapV2Pair` through `updateUniswapV2Router()`
- set NFT contract allow through `setNFTContractAllow()`
- exclude account from fees through `excludeFromFees()`
- set automated marketMaker pair through `setAutomatedMarketMakerPair()`
- allow account transfer before trading through `allowTransferBeforeTradingIsEnabled()`
- set `LIQUIDATE_TOKENS_TRIGGER` through `updateLiquidationThreshold()`
- set `claimWait` through `updateClaimWait()`
- burn tokens through `burn()`
- set `treasureAllowanceCounter` and `treasureAmount` through `updateTreasureAllowance()`
- set `marketingWallet` through `setMarketingWallet()`
- set `teamWallet` through `setTeamWallet()`
- withdraw BNB through `emergencyWithdraw()`

Any compromise to the `owner` account may allow a hacker to take advantage of this authority.

The role `nftContracts` has authority over the following functions:
- add airdrop reward through `addAirdropReward()`
- add static reward through `addStaticReward()`
- set account's dividends balance through `setRewardsFactor()`
- allow Nft trade through `allowNftTrade()`

Any compromise to any `nftContracts` account may allow a hacker to take advantage of this authority.

Centralization Related Risks

The `renounceOwnership()` and `transferOwnership()` functions are to renounce and transfer the ownership, but the privilege of the original `_owner` is not revoked.

The same issue applies to `_uniswapV2Router`, `marketingWallet` and `teamWallet`. 

Privilege not Revoked

The contract is serving as the underlying entity to interact with third-party PancakeSwap protocols. The scope of the audit would treat those 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties may be compromised and lead to assets being lost or stolen.

Third Party Dependencies

A 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.quote()`
- `uniswapV2Router.swapExactETHForTokens()`
- `uniswapV2Router.addLiquidityETH()`

Potential Sandwich Attacks

The `addLiquidity` function calls the `uniswapV2Router.addLiquidityETH` function with the `to` address specified as `owner()` for swapping out BNB from the `ULAND-BNB` pool. As a result, over time the `owner()` address will accumulate a significant portion of BNB. If the `owner()` is an EOA (Externally Owned Account), mishandling of its private key can have devastating consequences to the project as a whole.

Centralization Related Risks  In `addLiquidity`

`TOTAL_SUPPLY` tokens were sent to the `owner()`, `teamWallet`, `airdropWallet`, `liquiditySwapWallet`, `marketingWallet` and `deadWallet` when deploying the contract. This could be a centralization risk as the deployer can distribute tokens without obtaining the consensus of the community.

Initial Token Distribution

There are many hardcode addresses in this codebase.

Hardcode Address

1. The pair may not be set before `updateUniswapV2Router` is called, which will cause the pair obtained to be the zero address.
2. The new pair is not added to `automatedMarketMakerPairs`, nor is the old pair removed from it which leaves some inconsistency.


Discussion For The Function `updateUniswapV2Router`

The given input is missing the check for the non-zero address.

Lack of Input Validation

`tx.origin` check will be no longer valid after EIP-3074 is added in the coming months. EIP3074 introduces two EVM instructions AUTH and AUTHCALL. The first sets a context variable authorized based on an ECDSA signature. The second sends a call as authorized. This essential delegates control of the EOA to the smart contract. This means there will be a way for smart contracts to send transactions in the context of an Externally Owned Account, thus bypassing this check.

Also `tx.origin` is widely discouraged as there are possible phishing attempts.

Dangerous Usage of `tx.origin`

It is now well understood that the difficulty or timestamp is not a source of randomness. They can be manipulated if the attacker is also a miner. For EVM compatible blockchains such as Binance smart chain and Polygon, the `block.difficulty` can be the same value across multiple blocks, making the situation even worse. 

Risk For Weak Randomness

The return values of function  `addLiquidityETH` is not properly handled.

```solidity=1720
(uint256 amountToken, uint256 amountETH, uint256 liquidity) = uniswapV2Router
    .addLiquidityETH{ value: ethAmount }(
    address(this),
    tokenAmount,
    0, // slippage is unavoidable
    0, // slippage is unavoidable
    owner(),
    block.timestamp.add(300)
);
```

Return Value Not Handled

Literals with many digits are difficult to read and review.

Too Many Digits

All variable types within Solidity are initialized to their default `empty` value, which is usually their zeroed out representation. Particularly:

- `uint` / `int`: All `uint` and `int` variable types are initialized at `0`
- `address`: All `address` types are initialized to `address(0)`
- `byte`: All `byte` types are initialized to their `byte(0)` representation
- `bool`: All `bool` types are initialized to `false`
- `ContractType`: All contract types (i.e. for a given `contract ERC20 {}` its contract type is `ERC20`) are initialized to their zeroed out address (i.e. for a given `contract ERC20 {}` its default value is `ERC20(address(0))`)
- `struct`: All `struct` types are initialized with all their members zeroed out according to this table

Redundant Variable Initialization

`excludeFromFees()` and `excludeFromDividends()` alter critical parameters for users but there are no reverse methods to correct potential mishandling.

Lack of Reverse Methods

When static reward is added through `addStaticReward()`, no tokens are transferred to the reward wallet. This creates inconsistency between the available tokens in the reward wallet and the total dividends claims. As a result, users may not be able to receive their reward through `claim()` unless more tokens are transferred to the reward wallet separately.

No Transfer to The Reward Wallet

There is currently not restriction on `_allowanceCounter` and `_amount`, the owner might set a total treasure allowance that exceed current airdrop wallet balance. As a result, users may not be able to claim all the treasures through `treasureClaim()` unless more tokens are deposited to the airdrop wallet separately.

Restriction on Treasure Allowance

Treasures can be claimed by anyone as long as there is enough allowance. Opportunists may observe the treasure allowance and execute the `treasureClaim` function through bots to front-run all other players and maximize their gains.

Potential Front-running Risk of `treasureClaim()`

`quote` is determined on line 1124 by the token versus bnb ratio on the uniswap pair which is the same pair used for adding liquidity. It is possible to manipulate the price on that pair using a large amount of token or bnb and take advantage of it through the adding-liquidity feature during transfer.

Arbitrage through Flash-loan Pair Price Manipulation

The calculation of `totalWidthdrawn` should tally `staticRewardPayouts` but now uses `staticRewardBalances` instead.

Incorrect Calculation of `totalWidthdrawn`

The name of variable `totalWidthdrawn` has a spelling mistake, where it should be `totalWithdrawn`.

Spelling Mistake

`pair` has not been excluded from dividends and may account for a portion of distributed dividend rewards. Though the `pair` cannot actually claim the reward, this portion will be effectively insulated from the users for an unspecified purpose.

ULAND

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

28

0

27

0

1