Tensorplex Labs security record

The power of each validator in the defined validator set depends on the `powers` array. There is a sanity check that the sum of all elements in the `powers` array is at least two (because only then two thirds of the sum rounded up is greater than 2). This sanity check makes sure that there can be a supermajority of validators to submit a signature. However, there is no check that `powers` is distributed in a centralized way such that one validator can decide about any operation and/or that the vote of other validators does not matter. Examples of `powers` arrays where one validator decides over the vote include: `[2,0,0]` and `[5,1,1]`. In such configurations, it may be misleading to users as a set of several validators could practically still be a single sign vote.

The `checkValidatorSignatures()` function of `ConsensusBridge` validates that the signatures are generated from the known validators. Note that the encoded data which signatures are verified does not include chain or contract-specific details such as the current chain ID or contract address. It is best practice to follow the EIP-712 standard, which encodes a domain separator in the signed data to protect the signatures from cross-chain or cross-contract replay attacks. See [OpenZeppelin's EIP-712](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/cryptography/EIP712.sol) implementation for more details. Note that `state_gravityId` may be sufficient to prevent cross-chain or cross-contract replay attacks, but it depends on being correctly configured so that each contract's gravity ID is unique.

All privileged permissions should be documented for users. The privileged permissions of the protocol contract are documented below. The following are cases of `BridgeWrapper.DEFAULT_ADMIN_ROLE` privileges: - The admin can grant or revoke roles to other addresses <br> The following are cases of `BridgeWrapper.FEE_CONFIG_ROLE` privileges: - The role can assign fees through the following functions: `setBaseFee()`, `setServiceFee()`, `setMinimumAmount()`, `setMaximumAmount()` <br> The following are cases of `BridgeWrapper.APPROVE_TRANSFER_ROLE` - This role can invoke `receiveFromChain()` to mint the receiving address `wTokens` on the receiving chain. `ERC20BurnMint.MINTER_ROLE` and `ERC20BurnMint.BURNER_ROLE` , respectively, can mint or burn tokens.

In the provided specification, the `submitBatch()` function of `ConsensusBridge` should fulfill the following property: > **Transaction ID Uniqueness:** Checks if each transaction ID in the batch has been used before. This prevents duplicate transactions from being executed. However, in the implementation, the uniqueness of transaction IDs is not guaranteed or checked. As a result, if the `_transactionIds` array is malformed and contains duplicated or previously executed IDs, the `submitBatch()` function does not identify the error, which may lead to excessive tokens being minted on Ethereum. Also, the use case of `state_lastTransactionNonce` is unclear. Currently, it only keeps track of the number of executed transactions related to a specific `_tokenWrapperAddress`. Unlike the purpose of `state_lastBatchNonces`, it does not ensure that the transactions are executed in a particular order.