- Hacken
- Audits
- venom-foundation
- [SCA] VenomBridge | Bridge | Nov2023
Introduction
We express our gratitude to the Venom Foundation team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
The Venom Bridge facilitates seamless token transfers and cross-chain messaging between various blockchain networks, specifically targeting TVM (Venom) and EVM (Ethereum, BNB Chain, Polygon, Avax, and Fantom).
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Venom Foundation |
| Audited By | Hacken |
| Approved By | Luciano Ciattaglia |
| Website | https://venombridge.com/→ |
| Changelog | 23/10/2023 - Preliminary report |
| 21/11/2023 - Final report | |
| Platform | TON |
| Language | TON Solidity / Solidity |
| Tags | Bridge |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Venom Foundation
- Audited By
- Hacken
- Approved By
- Luciano Ciattaglia
- Website
- https://venombridge.com/→
- Changelog
- 23/10/2023 - Preliminary report
- 21/11/2023 - Final report
- Platform
- TON
- Language
- TON Solidity / Solidity
- Tags
- Bridge
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/venom-bridge/audit-contracts→ |
| Commit | b5559c5e72144c148b48e21831df1e539814b6ca |
Review Scope
- Commit
- b5559c5e72144c148b48e21831df1e539814b6ca
Audit Summary
9/10
\-
9/10
6/10
The system users should acknowledge all the risks summed up in the risks section of the report
System Overview
Introduction
The Venom Bridge is designed to facilitate seamless token transfers and cross-chain messaging between various blockchain networks, specifically targeting TVM (Venom) and EVM (Ethereum, BNB Chain, Polygon, Avax, and Fantom).
The Venom Bridge also offers comprehensive Staking and Decentralized governance systems.
It leverages a centralized bridge mechanism initially, transitioning to a more decentralized and trustless model with the introduction of Relays selected through Staking.
The DAO system enhances governance control, allowing users to propose and execute changes in a decentralized manner.
Overall, the Venom Bridge aims to provide a robust means of interoperability, asset transfer, and messaging between TVM and EVM chains.
It encompasses three primary on-chain and one off-chain functionalities: the Venom Bridge, Staking system, DAO, and Relays (off-chain part is out of audit scope).
1) Venom Bridge:
Bridge Type: The Venom Bridge operates in a "Lock and Mint" format. Users lock tokens in a smart contract on either the source chain (TVM or EVM), and wrapped versions of these locked tokens are then minted on the destination chain in the form of IOUs (I Owe You) tokens.
Intermediary Role: In the case of the EVM to EVM bridge, the Venom TVM bridge acts as an intermediary, facilitating token transfers between two EVM chains.
Centralized Nature: This bridge solution is centralized, relying on user trust in the bridge operators to operate as expected. Initially, the Venom Project manages the operation, and later, Relays are chosen through the Staking system.
Trust and Reputation: Users place significant reliance on the reputation of the Venom Bridge operators and must relinquish control of their crypto assets.
Chain Support: The Venom Bridge supports TVM and various EVM chains, enhancing interoperability across different blockchain ecosystems.
Relay Verification: Messages between chains are externally verified by Venom Bridge Relays, ensuring security and reliability.
Cross-Chain Messaging (AMB): The Venom Bridge integrates the Arbitrary Message Bridge (AMB) within the Bridge part. The AMB facilitates the transfer of messages, including oracle data, hashes, addresses, and other arbitrary data, between the TVM and EVM chains, enhancing the versatility of the Venom Bridge ecosystem.
Relay Selection: Initially, the Venom Project manages the first set of Relays. Later, a Staking system is introduced to select and qualify Relays, who must lock Venom Bridge tokens in escrow as a commitment/insurance against malicious actions.
Impact: The Venom Bridge plays a pivotal role in the Venom chain, serving as its primary and official bridge, expected to handle millions of dollars in assets.
2) Staking Functionality:
Staking Rewards: Normal users can stake their tokens within the Venom Bridge system and receive rewards on a pro-rata basis, incentivizing active participation and engagement.
Voting Power: Tokens staked within the Venom Bridge can also be utilized as voting power within the DAO system, empowering stakers to influence governance decisions.
Relay Eligibility: Users meeting specific criteria, including holding a sufficient token balance and confirming their signatures on both TVM and EVM chains, can participate in the election process to become a Relay for the Venom Bridge system.
3) DAO Functionality:
Governance Control: The DAO system provides governance control over administrative functionalities within the Venom Bridge and Staking systems. Users can propose and vote on changes and improvements. Execution of Proposals: DAO proposals may contain TVM and EVM transaction calls, which are executed on the respective chains upon successful approval of the proposal. This facilitates decentralized decision-making and the execution of actions within the Venom ecosystem.
Relays:
Cross-chain Message Delivery: Relays are responsible for monitoring and confirming events in EVM and TVM networks. For instance, when a user deposits DAI into a special smart contract (Vault) on the Ethereum side, each Relay sends a transaction to the Venom network, confirming the deposit event. Once a quorum is reached, DAI tokens are automatically minted on the Venom side.
Signed Payload Storing: The bridge also operates in the Venom to EVM direction, with Relays signing specific EVM-compatible payloads to avoid high network fees. Relays sign payloads and store their public keys on the TVM side. Anyone can send a payload and a list of signatures to the Vault, which will send tokens to the user's Ethereum address upon signature verification.
Execution Pipeline
The management pipeline for the Venom Bridge involves the following steps:
Staking: Users can stake their tokens in the Venom Bridge, gaining staking rewards and voting power.
Relay Election: Users meeting specific criteria can participate in relay elections and become relays.
DAO Governance: The DAO system allows stakeholders to propose and vote on changes and improvements.
Cross-Chain Proposals: Proposals created on the TVM side can indicate actions in any EVM connected network, allowing crosschain governance.
The execution pipeline for the Venom Bridge involves the following steps:
Token Locking: Users initiate token locking on the source chain (TVM or EVM).
Relay Action: Venom Bridge Relays sign, deliver, and verify messages between chains.
IOU Minting: Wrapped tokens (IOUs) are minted on the destination chain.
Staking Bridge Tokens
The project introduces a governance token. Token holders can stake the tokens in the bridge and receive rewards. The governance tokens come from liquidity management on the EVM side.
Relay Auction
Stakeholders holding over 100,000 governance tokens can become relays. They can start a relay node and apply for relay elections, which occur every week. Malicious behavior by a relay, such as confirming incorrect events, can lead to slashing by the DAO, with the stake and reward distributed among current stakeholders.
Liquidity Management on the EVM Side
Liquidity management allows locked EVM tokens to be transferred to yield farming protocols. Gains are sent to the TVM side and distributed among stakeholders and relays.
DAO
The DAO is managed by Bridge token stakeholders. DAO decisions cover bridge configuration, relay slashing, new tokens, new networks, and managing locked liquidity.
Stakeholders with a specific amount of governance tokens can create DAO proposals, which undergo review, voting, and timelock phases. Cross-chain proposals are also possible, enabling actions in various connected networks.
Project Structure
The repository comprises two smart contract folders:
1) Ethereum: EVM side implementation.
bridge: Venom Bridge (TVM) events import and validation
Bridge: Rounds and relays management, TVM side events verification
StakingRelayVerifier: Request relay TVM address verification
libraries: Well-known multipurpose libraries.
multivault: Diamond pattern-based vault for multiple tokens.
multivault: Core diamond pattern contracts (facets and storage plugins).
proxy: Well-known proxy contracts.
Diamond: Diamond entry point with plugins attached.
MultiVaultToken: ERC20 token implementation that multivault works with.
DAO: Venom Bridge DAO (TVM) proposals import and execution.
2) Everscale: TVM side implementation.
bridge: Core bridge contracts alien-token: TIP3 token implementation to represent ERC20 tokens on the TVM bridge side alien-token-merge: Centralized pool to swap tokens across different chains with a 1:1 rate event-configuration-contracts: Event configuration helper contracts event-contracts: Execute events on the TVM side to be signed with relays and transmitted to another chain factory: Makes configuration contracts deployment easier hidden-bridge: Bridge edge cases processors EventCloser: Part of the credit-transfer pipeline, receives event list and closes them all EventDeployer: Part of the credit-transfer pipeline, deploys multiple event contracts at once Mediator: Part of EVM-TVM-EVM token transfers, transmits further transfer if the mint amount equals the burn amount proxy: Multivault implementation based on alien-token contracts.
dao: DAO core contracts.
DaoRoot: Proposal deployer configuration.
Proposal: Proposal voting and executing logic.
staking: Stake to become a relay contracts.
Election: Round relays election.
RelayRound: Contract manages relays in the current round.
Staking: Contract manages the whole staking configuration.
UserData: Relay entry point.
Executive Summary
Documentation quality
The total Documentation quality score is 6 out of 10.
The litepaper provides general system requirements.
The code core is covered with comprehensive NatSpec comments.
The litepaper provides system architecture details.
User interaction flow description and diagrams are not provided. Technical description is lacking.
Code quality
The total Code quality score is 9 out of 10.
Style guide violations have been found.
Contradictory naming has been found.
Redundant code has been found.
Security score
Upon auditing, the code was found to contain 1 critical, 3 high, 27 medium, and 41 low severity issues. Out of these, 53 issues have been addressed and resolved, leading to a security score of 9 out of 10.
All identified issues are detailed in the “Findings” section of this report.
Summary
The comprehensive audit of the customer's smart contract yields an overall score of 7.9. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.
Risks
Highly Permissive Role Access: The bridge system depends on a few critical accounts, such as Governance, Management, and WithdrawGuardian, which have extensive permissions. Management and WithdrawGuardian can impact bridge interoperability, with Management adjusting fees up to 50% and WithdrawGuardian blocking withdrawals. Misconfigurations by the Governance account could lead to issues like transaction freezes, fund losses due to incorrect token settings, and disrupted interoperability from improper withdrawal limits.
Inefficient Loop Iteration Over rewardRounds: The processClaimReward function loops over the rewardRounds array, which may grow indefinitely, leading to potential gas inefficiencies. As the array length increases, transactions might fail or incur high fees. Introducing a mechanism to limit loop iterations by marking the last active round could enhance efficiency.
Centralization and Address Tampering Vulnerability: The setBridge function allows only the owner to update the bridge address, concentrating control and risking security if owner access is compromised. To prevent unexpected behaviors or fund loss, implementing multisignature approvals or a decentralized voting process could safeguard against misuse.
Centralization and Potential Fund Loss Due to roundSubmitter Key Exposure: The onlyOwner modifier centralizes control over the roundSubmitter address, which is pivotal to bridge operations. Compromised keys could allow fund manipulation, risking significant loss. Using a decentralized approach or multi-signature confirmations could reduce this risk, alongside secure key management practices.
Potential Misconfiguration of EVM Settings: Direct access to modify EVM settings without checks could disrupt system operations or allow unintended actions, such as unauthorized token minting. Introducing a timelock and multi-signature confirmations would enhance security for critical EVM settings.
Centralization and Potential Fund Loss Due to roundRelaysConfiguration Key Exposure: The onlyOwner modifier centralizes control over roundRelaysConfiguration, increasing vulnerability if the owner's keys are exposed. Given the configuration's importance in bridge functionality, misconfiguration could disrupt operations or cause fund loss.
Potential Misconfiguration of Solana Settings: Modifying Solana settings without checks may lead to unintended operational issues or vulnerabilities, potentially enabling token minting risks. Implementing a timelock and multisignature approvals could secure Solana setting changes.
Potential Loss of Valid Bridge Operations in updateRoundTTL() Function: Expiring roundTTL values could cause valid bridge operations to lapse if not executed in time, impacting user experience. The system's reliance on timely user actions may lead to missed operations if users are unaware or unable to respond within the timeframe.
Potential Misuse of Unverifiable callHash in addDelegate() Function: The function’s lack of verification on callHash may allow for malicious data encoding, with limited inspection capabilities making it difficult to audit or troubleshoot, posing a security risk.
Centralization Concerns and Potential Fund Losses with Manager Role: The manager role centralizes significant authority within the system, creating a single point of control. If compromised, unauthorized modifications to token pools could misdirect or lose funds.
Centralization and Potential Fund Loss Due to roundSubmitter Key Exposure: Sole control over the forceRoundRelays function by roundSubmitter centralizes power, creating risk if keys are compromised. This could lead to potential fund loss, as roundSubmitter has extensive control over bridge functionality.
Out-of-Scope Dependency Concern in TokenRootUpgradeable.tsol Import: Relying on the external TokenRootUpgradeable.tsol contract introduces risks from potential vulnerabilities, version changes, and maintainability issues, which could impact system security and functionality.
Potential User Funds Lock in the withdraw() Function: The onlyActive modifier restricts fund withdrawals, potentially locking user funds during emergencies, impacting user trust and causing financial implications.
Dynamic electionTime during Voting in the endElection() Function: Modifications to electionTime during ongoing voting can lead to unexpected election duration changes, making it difficult for stakeholders to strategize effectively.
Potential Withdrawal of Tokens by Relays during Inadequate Elections: Relays can withdraw tokens even when still needed for transaction signing, which could disrupt bridge operations by weakening the relay pool’s reliability.
Gas Insufficiency in TVM Call Chain Execution: Unpredictable gas costs in the TVM call chain may result in gas shortages, causing transaction failures or locking funds. Simulating transactions in advance could help anticipate gas requirements.
Transaction Replay Vulnerability in sendTransaction() Function: The function is vulnerable to replay attacks, risking depletion of contract funds due to the ability of validators to resend failing external messages, resulting in significant potential fund loss.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2023-1684 | Share Inflation and Front-Running in MultiVault Contracts | fixed | Critical | |
| F-2023-1687 | Potential Funds Lock on Close Event in TVM to EVM Bridge | mitigated | High | |
| F-2023-168 | Funds Loss Due To Initialization Front Run | fixed | High | |
| F-2023-1685 | Invalid Fee Beneficiary Handling for Zero Liquidity | fixed | High | |
| F-2023-1689 | Inconsistent Native Token Replacement Across EVM and TVM Chains | mitigated | Medium | |
| F-2023-168 | Centralization Risk Due to Owner's Access to User Funds in ProxyMultiVaultAlien Contract | fixed | Medium | |
| F-2023-171 | User Funds Mismanagement in propose() Function | accepted | Medium | |
| F-2023-1713 | Transaction Replay Possibility in close() Function | fixed | Medium | |
| F-2023-1712 | Potential Overpayment in Token Deposit Functionality | mitigated | Medium | |
| F-2023-1711 | Potential Funds Lock on Token Burn in TVM to EVM Bridge | mitigated | Medium |
Appendix 1. Severity Definitions
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/venom-bridge/audit-contracts→ |
| Commit | b5559c5e72144c148b48e21831df1e539814b6ca |
| Litepaper | Provided→ |
Scope Details
- Commit
- b5559c5e72144c148b48e21831df1e539814b6ca
- Litepaper
- Provided→