Venombridge security record

Any staker above a certain staking threshold can add proposals, and there is no restriction on the `tonActions` and `ethActions` in the proposal, including the target address and the function call itself. If a malicious proposal is added and passes the voting process, the DAO contract can execute the actions defined in the proposal on the Everscale side and/or the Ethereum side.

The "confirm" and "reject" function has the following comment: ```txt @dev Can be called only by parent event configuration @dev Can be called only when event configuration is in Pending status ``` The implementation doesn't match the comment: 1. The function can be called by selected relays, instead of only the parent event configuration. 2. The "confirm" function can be called in the "Pending" status and "Confirmed" status, instead of only in the Pending status 3. The "reject" function can be called in any status.

The staking module is not compatible with non-standard ERC20 tokens, such as deflationary tokens or rebase tokens. Deflationary token is defined as a token with transfer fees, such that the amount received by the recipient is less than the amount sent by the sender. There are plenty of such tokens in other layer 1 protocols. The staking contract records the `amount` being transferred by the staker as its staking balance. If the token itself is deflationary, this would inaccurately reflect the amount of tokens received by the staking contract, causing loss of fund when the staker withdraws its staked tokens. ```solidity token_balance += _tokens_to_deposit; ```

In ProxyMultiVaultAlien_V3.sol, anyone can call `deployAlienToken()` to deploy new alien token.

The "deployConnector()" function is public and has no access control. Anyone can deploy a new connector to increase the connector count.

In ProxyMultiVaultAlien_V3.sol, anyone can call `deployMergeRouter()` to deploy new merge router.

The contracts are serving as the underlying entity to interact with third parties SushiSwap, Convex Finance's Booster Contract, and tokens(e.g. usdt). The scope of the audit treats 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc. Note that the liquidity pools may be prone to flash loan attacks, which may cause losses to the strategies and the vault.

The communication for the bridge between the Everscale blockchain and multiple EVM chains is via different "events". For example, when a user bridges a token from Eversacle to Ethereum, a "TokenTransferEvent" will be deployed, and "Relay" need to verify the event. The user needs to use the signature from the "Relay" to withdraw the token from the Ethereum vault. The "Relay" is crucial to the system; the scope of the audit treats the "Relay" entities as black boxes and assumes their functional correctness. However, in the real world, the dependencies can be compromised, and this may lead to lost or stolen assets.

The implementation of several interfaces are unknown. The scope of the audit treats unknown implementation / 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets.