The Dtec World security record

In the contract `PublicSaleLock`, users can call `claim()` function to claim the `DTEC` tokens they purchased earlier in the `DTECPublicSale` contract after a certain period. However, it is noted that in the `getClaimable()` function, the contract uses the code below to calculate the claimable amount of `DTEC`, and the value of `numerator` is always less than **10000**, which means 10% of `info.totalAmount` will be stuck in the current contract. ```solidity=70 uint256 numerator = getReleaseNumerator(periodsPassed); uint256 totalClaimableSoFar = info.totalAmount * numerator / 10000; if (totalClaimableSoFar > info.totalAmount) { totalClaimableSoFar = info.totalAmount; } return totalClaimableSoFar - info.totalClaimed; ```

The function `migrateOldUsers` is intended to facilitate the migration of tokens from an old contract to a new one. It requires that each user's bought amount in the new contract be zero before allowing migration. ```solidity function migrateOldUsers (address[] calldata users ) external onlyOwner nonReentrant { //... for (uint256 i = 0; i < users.length; i++) { require(addressToBoughtAmt[users[i]] == 0, "User should only migrate once, no duplicate amount"); //... require(oldSaleContract.amountSold() == totalMigratedTokenAmount , "All bought amounts should be migrated"); emit MigrationMade(users, block.timestamp, totalMigratedTokenAmount); } ``` This may bring a potential DoS attack and no token can be migrated from an old contract to a new contract.

In the `migrateOldUsers()` function, the contract calculates the value of `allocation` via `addressToBoughtAmt`. However, it is noted that `addressToBoughtAmt` is possibly inconsistent with `allocation` in the old contract due to the `claimAllocation()` function. If a user has called `claimAllocation()` in the old contract, the `allocation` of this user is zero. But the migration incorrectly updates `allocation` to the corresponding bought amount, which causes a user can claim more tokens than bought.

In the contract `DTECTokenSale`, the `_owner` can transfer `_amt` amount of `DTEC` tokens away. It is noted that this function misses a sanity check for `_amt`, as a result, the allocated tokens of users may be also transferred, causing calling to `claimAllocation()` failed.

The `PrivateSaleLock2` contract is designed with two primary methods, `releaseFunds()` and `claim()`, to facilitate users in claiming tokens. Specifically, the `releaseFunds()` method reads the quantity of tokens purchased by the user from the `DTECPrivateSale` contract and directly releases a certain amount of tokens to the user based on the `immediateReleaseRate` set in the `DTECPrivateSale` contract. The `claim()` method calculates the total amount of tokens released to the current user through the `PrivateSaleLock` contract, subtracts the amount already claimed by the user, and transfers the currently claimable tokens to the user. The underlying design intent here is that the total number of tokens released through `releaseFunds()`, combined with the total released through the `claim()` method, equals the number of tokens purchased by the user via the `DTECPrivateSale` contract. Additionally, since users can obtain their purchased tokens through both the original `DTECPrivateSale` contract and the `PrivateSaleLock` contract, and can also receive the same amount of tokens through the `PrivateSaleLock2` contract, they ultimately have the opportunity to receive double the amount of tokens.

The associated variables have been given fixed values through hard coding, which cannot be modified. Additionally, the token decimal appears to be hardcoded to 18.

The `lockStartTime` state variable in the `CommunityIncentives` and `TgeVestingBase` contracts signifies the commencement time for the release of the vested amount. It is designated as immutable, indicating that its value is assigned only once. For the vesting service to operate accurately, `lockStartTime` must not be initialized to zero. Consequently, evaluating whether `lockStartTime` equals zero is redundant. ```solidity if (info.totalClaimed == info.totalAmount || lockStartTime == 0 || block.timestamp < lockStartTime) { return 0; } ``` ```solidity if (info.totalClaimed == info.totalAmount || lockStartTime == 0 ) { return 0; } ```

The contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity DTECPrivateSale public constant privSale1 = DTECPrivateSale(0x6d158bb60FfF3a66F0290BF3F156B9d355163e50); PrivateSaleLock public constant privSale1Lock = PrivateSaleLock(0x47D5c7599991F121A817C289B8E62Dd2015D5Eb3); IERC20 public constant dtecToken = IERC20(0xd87aF7B418d64FF2cdE48d890285bA64fc6E115F); ``` ```solidity address public immutable dtecTokenAddress; ```

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

The provided codebase cannot be compiled. Additionally, suppose the contracts are within the same folder. There will be inconsistency in the imports of the `ITokenLock.sol` interface between the different files. Specifically, the discrepancy lies in the paths used to import this interface: - In the file `DTECTokenSale.sol`, it is imported as ```solidity import {ITokenLock} from "./interfaces/ITokenLock.sol"; ``` - In the file `PublicSaleLock.sol` and `LinearLock.sol`, it is imported as ```solidity import {ITokenLock} from "../interfaces/ITokenLock.sol"; ```