Edge Matrix Computing security record

```sol=68 function burnERC721(address tokenAddress, uint256 tokenID) internal { ERC721MinterBurnerPauser erc721 = ERC721MinterBurnerPauser(tokenAddress); erc721.burn(tokenID); } ``` `ERC721Safe.burnERC721(tokenAddress, tokenID)` is called by `ERC721Handler.deposit()` if `_burnList[tokenAddress]`. It successfully burns NFT if `ERC721Handler` was approved by the token owner to transfer that NFT. However, after the user calls `ERC721.approve(ERC721Handler, tokenID)` the malicious actor can call `Bridge.deposit()` for that tokenID. As a result, the NFT will be burnt in favor of the malicious actor. So, all the bridged burnable NFT can be stolen.

According to the design, anyone holding a signature issued by the manager can bind to a node and become the beneficiary of that node. Beneficiaries can deposit into the node and create vesting schedules for anyone. However, the current signature verification design cannot determine uniqueness and may have the following potential risks: 1. Signed messages are not properly verified with the current chain ID, thus allowing attackers to perform replay attacks across chains. Hardcoded or cached chain ID values are also vulnerable since a hard fork may occur and change the chain ID in the future. 2. The `_nodeId` is not used as a parameter, and there is no check to verify whether the node is already bound to a beneficiary. Although hackers cannot get more tokens out because stakers can only withdraw their own quota. However, this issue can be exploited to disrupt the normal stake/withdraw operations of the protocol. ```solidity modifier verifyAddressSigner(string memory nonce, bytes memory signature) { require(!verifiedState[nonce], "signature validation failed"); bytes32 messageHash = keccak256(abi.encodePacked(msg.sender, nonce)); require( manager == messageHash.toEthSignedMessageHash().recover(signature), "signature validation failed" ); verifiedState[nonce] = true; _; } ```

```solidity=21 function fundERC721(address tokenAddress, address owner, uint tokenID) public { IERC721 erc721 = IERC721(tokenAddress); erc721.transferFrom(owner, address(this), tokenID); } ``` `ERC721Safe.fundERC721()` and `ERC20Safe.fundERC20()` allow any person to transfer someone's tokens to the Handler address, if the user has approved the Handler contract. Since normal Bridge work requires the user to approve the Handler contract before tokens are deposited, this can be used by the malicious actor to block the Bridge functioning.

EMCFI token has `totalSupply` of 100 million tokens. ```sol=9 function quorumVotes() public pure returns (uint) { return 400000e18; } // 400,000 = 4% of Finance /// @notice The number of votes required in order for a voter to become a proposer function proposalThreshold() public pure returns (uint) { return 100000e18; } // 100,000 = 1% of Finance ``` 400_000e18 tokens is only 0.4% of the `totalSupply`, that is too little for quorum. The comment is also misleading.

The copy size of calldata used in assembly of the function `ERC20Handler.deposit()` to copy the data of `recipientAddress` is mistakenly using the 0xE. Since the `recipientAddress` is placed at the end of calldata, so the correct copy size should be the `calldatasize - 0xE4`. `GenericHandler.deposit()` uses 0xC4 as a base metadata. However, the correct value is 0xA4 since the function has 4 arguments and the fifth is a dynamic data. `GenericHandler.executeProposal()` uses 0x64 as a base metadata. However, the correct value is 0x44 since the function has 1 argument and the second is a dynamic data. Wrong data parsing can lead to unexpected behavior including funds loss. The code comments are outdated and misleading.

```sol=1334 function getFinanceAddress() public view returns (address) { // return 0xc00e94Cb662C3520282E6f5717214004A7f26888; } ``` `FinancetrollerG7.getFinanceAddress()` doesn't return a value.

`Bridge.fallback()` permits deposits of native tokens. However: 1. Using `fallback()` instead of a function with a declared signature is not recommended. 2. The method approves the `erc20HandlerAddress` to transfer tokens, but subsequently uses `_resourceIDToHandlerAddress[resourceID]` as the handler. The `erc20HandlerAddress` is never validated and can be arbitrary. 3. The `fallback()` function can be invoked `whenPaused`, unlike `deposit()`. 4. Since `fallback()` uses `address(this)` as the sender/depositor, the Bridge's address is recorded in `_depositRecords` of the Handler instead of the `msg.sender`. 5. The logic within `fallback()` differs for testnet chain IDs as compared to `deposit()`. These issues can lead to unexpected behavior and potential security vulnerabilities.

The [EIP-721 standard](https://github.com/ethereum/EIPs/blob/78e2c297611f5e92b6a5112819ab71f74041ff25/EIPS/eip-721.md?plain=1#L103-L113) says the following about `transferFrom()`: ```solidity /// @notice Transfer ownership of an NFT -- THE CALLER IS RESPONSIBLE /// TO CONFIRM THAT `_to` IS CAPABLE OF RECEIVING NFTS OR ELSE /// THEY MAY BE PERMANENTLY LOST /// @dev Throws unless `msg.sender` is the current owner, an authorized /// operator, or the approved address for this NFT. Throws if `_from` is /// not the current owner. Throws if `_to` is the zero address. Throws if /// `_tokenId` is not a valid NFT. /// @param _from The current owner of the NFT /// @param _to The new owner /// @param _tokenId The NFT to transfer function transferFrom(address _from, address _to, uint256 _tokenId) external payable; ``` The function `lockERC721` transfers an ERC721 token to the input address via `transferFrom()`. This method does not check that the `recipient` is a contract, it is designed to support ERC721 tokens. If the `recipient` is a smart contract not designed to handle ERC721 tokens, they can become locked in the contract forever.

The constant like `blocksPerYear` inside the contract is often used for calculation on a per-block basis. But since different chain has different block interval, this constant should be different across chains and a careful check is required on this. `blocksPerYear = 2102400` means one block per 15 seconds. Expected value for Ethereum chain. The EMC chain produces a block every 2 seconds. ```sol=21 function votingPeriod() virtual public pure returns (uint) { return 17280; } // ~3 days in blocks (assuming 15s blocks) ``` Voting period and the comment are incorrect.

According to the design, the node's beneficiary could create the vesting schedule through the `releaser` contract. The start time of the schedule is 15 minutes after the schedule is created. ```solidity releaser.createVestingSchedule( _beneficiary, block.timestamp + 15 * 60, 1, DurationUnits.Days30, _amount); ``` However, according to the design of contract `ReleaseVesingV1`, when `minStartDays` is greater than 0, the schedule will not be created successfully. ```solidity function createVestingSchedule( address _beneficiary, uint256 _start, uint256 _duration, DurationUnits _durationUnits, uint256 _amountTotal ) external { ... require( _start >= block.timestamp + minStartDays * 1 days, string.concat("VestingContract: invalid start time") ); ... } ```