Deeplink

In the `Token` contract, the `lockTransferAdmin` role can transfer tokens to a specified address and add a lock period. If the `isLockActive` is true, users must wait for the unlock period to end before they can transfer these tokens out. ```solidity function transfer(address to, uint256 amount) public virtual override returns (bool) { if (to == address(0) || amount == 0) { return super.transfer(to, amount); } if (isLockActive && walletLockTimestamp[msg.sender].length > 0) { require(canTransferAmount(msg.sender, amount), "Insufficient unlocked balance"); } return super.transfer(to, amount); } ``` However, users can authorize another address and use the `transferFrom()` function to transfer out the locked tokens.

These contracts do not protect the initializer. An attacker can front-run the `initialize` call and assume ownership of the logic contract. Once in control, the attacker can perform privileged operations, misleading users into believing that they are interacting with the legitimate owner of the upgradeable contract.

In the `MultiSigTimeLock` contract, the `Proposal` struct includes a variable `canExecuteAfterTimestamp` to record the time a proposal can be executed. Once this time is reached and the proposal has garnered enough approvals to meet the threshold, anyone can execute the proposal through the `executeProposal()` function. However, the contract does not set deadlines for different stages of the proposal, such as the voting period and execution period. This could lead to the following issues: 1. After the `canExecuteAfterTimestamp`, signers can still change their decisions, it may affect the execution schedule of proposals. 2. If a proposal with certain settings is not executed in time, a malicious user could execute the historical proposal after the new one, causing the new proposal to be overridden by the historical one. - A proposal sets Alice's minting quota to 10,000 ether and is approved but not executed in time. - A new proposal sets Alice's minting quota to 100 ether and is executed. - Alice can execute the historical proposal to revert the quota back to 10,000 ether. 3. The proposal only includes the `canExecuteAfterTimestamp`, which does not effectively reflect delayed execution. Signers could vote and execute right at the `canExecuteAfterTimestamp`.

Contract `Token` extends `ERC20PermitUpgradeable` contract, but the extended contract is not initialized by the current contract. Generally, the initializer function of a contract should always call all the initializer functions of the contracts that it extends. Also, it is recommended that `ERC20BurnableUpgradeable` be initiated as well since the dependency version may be varied.

The `MultiSigTimeLock` contract grants several critical privileges to its signers, which may also be assigned to the contract itself. These include: - `_authorizeUpgrade` - `addSigner` - `removeSigner` - `updateRequiredApproveCount` - `updateMinDelaySeconds` The concern is that if any single signer’s key is compromised, that individual could effectively destory the multi-signature and time-lock safeguards. For example, they might upgrade the contract or lower the approval threshold and delay parameters, effectively bypassing the intended security controls.

In the `MultiSigTimeLock` contract, within the `_createProposal` function, there are conflicting require statements between lines 115 and 118. These conflicting conditions may cause the function to revert unexpectedly when `block.timestamp` is equal to `_canVoteBeforeTimestamp`. ```solidity=115 require(block.timestamp <= _canVoteBeforeTimestamp, "Vote period passed"); ``` ```solidity=118 require(_canVoteBeforeTimestamp > block.timestamp, "Can vote before should be > current timestamp"); ```

In the `MultiSigTimeLock` contract, each stage of a proposal (voting, delay, and execution) is governed by the `minDelaySeconds` parameter. In the latest update, when a signer calls `approveProposal()` and the required approval threshold is met, the function updates `canExecuteAfterTimestamp`. We understand this is intended to allow earlier execution, for instance, in emergencies. However, we would like to confirm the following points with the team: 1. By updating `canExecuteAfterTimestamp` without adjusting the expiration, the execution period may extend beyond what was defined by the original `minDelaySeconds` intervals. 2. Accelerating the proposal could lead to out-of-order execution, and the current model **allows race condition** issues and the new design may increase the likelihood as well. 3. If the threshold is met and `canExecuteAfterTimestamp` is already updated, any subsequent approvals will continue to update `canExecuteAfterTimestamp`, potentially pushing execution time further out. This seems contradictory to the second point. We would appreciate clarification on whether these behaviors are intentional.

In the `MultiSigTimeLock` contract, the contract can set `requiredApproveCount` as the threshold for proposal approval during initialization, and signers can modify this threshold at any time. The verification range for `requiredApproveCount` is as follows: ```solidity require(newApprovedCount > 0, "Must have at least one"); require(newApprovedCount <= signers.length, "Too many required approve count"); ``` The lower limit of the range is inappropriate. According to the majority principle, the threshold should be greater than half of the number of signers. Additionally, when adding or removing signers, the threshold should also change with the number of signers.

The `requestSetMinter()` function returns the bytes of data for the `mint()` function, which may prevent the proposal from being executed. ```solidity function requestSetMinter(address minter, uint256 amount) external pure returns (bytes memory) { bytes memory data = abi.encodeWithSignature("mint(address,uint256)", minter, amount); return data; } ```

The `Token` contract inherits from the `OwnableUpgradeable` contract, but the contract does not have any functions exclusive to the `owner` role.