NetMind-Audit

In the contract `Ownable` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority. - transfer ownership of the contract to a new account - renounce ownership will leave the contract without an owner  In the contract `AccountManage` the role `_auth` has authority over the functions shown in the diagram below. Any compromise to the `_auth` account may allow the hacker to take advantage of this authority. - freeze user's tokens for the job - deduct assets from user's account  In the contract `AccountManage` the role `_executor` has authority over the functions shown in the diagram below. Any compromise to the `_executor` account may allow the hacker to take advantage of this authority. - init user’s information - update user‘s address  In the contract `AccountManage` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority. - set `signNum`, `authSta`  In the contract `CommunityFund` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority. - set `LockTime`, `votingPeriod` - add node information - delete node information  In the contract `Conf` the role `wards` has authority over the functions shown in the diagram below. Any compromise to the `wards` account may allow the hacker to take advantage of this authority. - grant/revoke `wards` role. - update state values of `Conf` contract. - update accountant addresses. In the contract `Crosschain` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority. - set `trader`, `exector`, `threshold`, `signNum`, `pause`, `chargeRate`, `tokenSta` - withdraw the fee - add node information - delete node information  In the contract `Crosschain` the role `exector` has authority over the functions shown in the diagram below. Any compromise to the `exector` account may allow the hacker to take advantage of this authority. - pause the contract  In the contract `Crosschain` the role `trader` has authority over the functions shown in the diagram below. Any compromise to the `trader` account may allow the hacker to take advantage of this authority. - transfer the token for the user  In the contract `Ledger` the role `accountant` has authority over the functions shown in the diagram below. Any compromise to the `accountant` account may allow the hacker to take advantage of this authority. - update ledger. In the contract `Pledge` the role `_nodeaddr` has authority over the functions shown in the diagram below. Any compromise to the `_nodeaddr` account may allow the hacker to take advantage of this authority. - stake NMT or ERC20 token assets.  In the contract `Pledge` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority. - set `guarder`, `tokenSta` - update node information - add node information - delete node information  In the contract `Pledge` the role `guarder` has authority over the functions shown in the diagram below. Any compromise to the `guarder` account may allow the hacker to take advantage of this

All contracts in the project inherits upgradeable contracts, indicating that it is part of an upgradeable system. Upgradeable contracts often pair with a proxy contract that is responsible for managing contract upgrades. The `privileged roles` of the proxy often have the authority to update the implementation contract. Any compromise of the privileged account could allow a hacker to exploit this authority, potentially altering the implementation contract pointed to by the proxy and thus executing malicious functionality within the implementation contract.

There is no storage gap preserved in the logic contract. The storage gap is essentially reserved space within a contract's storage layout. It's a placeholder for future variables that might be added in upgraded versions of the contract. The storage gap ensures that new variables added during upgrade do not overwrite existing storage variables, preserving the integrity of the contract's state. Any logic contract that acts as a base contract and which is inherited by other upgradeable contracts should have a reasonably sized storage gap preserved. In the audit scope, all contracts are upgradeable and derive from either the `Initializable`, `Ownable`, or `ERC20` super contract.

The `refund()` function is designed to be called to return contract assets to users. when the function is invoked with an `amt` parameter less than the `paymentId`'s token amount, the remaining tokens are irretrievably locked in the contract because the function is callable only once with a specific `paymentId`. ```solidity=166 require(R.amount >= amt, "invalid amt"); ```