This comprehensive threat analysis report provides an in-depth review of potential security vulnerabilities within the LightLink Token Transfer Bridge Architecture. Through rigorous application of both the STRIDE and ABC threat modeling frameworks, the report identifies key system weaknesses and offers strategic mitigation recommendations.
We have performed the threat analysis on the architecture of LightLink bridge and built a model according to the aspects that are weak in architecture and should be changed. We did the analysis according to the STRIDE Model, ABC Threat Modeling and came to the conclusion that the protocol has too few improvements which are described below.
The LightLink Bridge system architecture is based on a Proof-of-Authority mechanism with an external validator set that stakes its individual reputation in order to earn incentives for the trades on the LightLink bridge. This ensures a robust and interconnected framework enabling seamless asset transfers between Ethereum's Layer 1 and Layer 2. The bridge architecture consists of several key components, each playing a crucial role in the overall operation of the bridge. The bridge architecture consists of three main components, the front-end dApp, validator nodes and a single keeper node.
Note: While the provided documentation for the LightLink architecture is commendable and provides an essential overview, it could benefit from further detailed elaboration. A comprehensive breakdown of each component's functionality, interactions, and the specific roles they play in the broader architecture could enhance the depth and clarity of the document. Additionally, providing more detailed technical insights, workflows, and possible edge cases could facilitate a more robust understanding of the system. This will not only aid in improved transparency but also contribute to more effective and inclusive future audits, threat modeling, and security assessments.
A user interacts with the front-end dApp to initiate a cross-chain transfer. The user connects their wallet, selects Ethereum and Lightlink as the source and destination chains respectively, enters the amount they want to transfer, and initiates the transfer. Internally, the dApp uses the ethers.js library to interact with the BridgeRegistry.sol smart contract on Ethereum to deposit the specified amount.
When the user initiates a deposit, the Ethereum node stores an event labeled "Deposited". This event signifies that a user has deposited tokens into the smart contract and they're ready to be bridged.
Validators constantly monitor Ethereum nodes for the "Deposited" event. When the event is detected, the validators confirm the finality of the transaction. They check that the event data is finalized and not likely to be reverted due to chain reorganization. After approximately 12 blocks (~6 minutes), the validators consider the transaction to be final. The validators then send a proof, including their signature, to the Keeper node.
The Keeper node receives proofs from various validators and checks for consensus (currently set at 70% agreement). Once consensus is reached, the Keeper node initiates a transaction on the Lightlink network to mint tokens equivalent to the deposited amount.
The Lightlink node, upon receiving the transaction from the Keeper node, mints an equal amount of tokens and credits them to the user's account on the Lightlink network.
The user's tokens are now available in their Lightlink account, indicating the successful completion of the cross-chain transfer from Ethereum to Lightlink.
The withdrawal process begins when a user initiates a withdrawal request to retrieve any type of token on the Lightlink network. The Lightlink node then registers a "Withdrawn" event.
Following this, the validator nodes start scanning the event data from their assigned full nodes, which may vary for each validator. It's noteworthy that this data validation process occurs in real-time, as the Lightlink network doesn't have chain-reorganization issues.
Once the event data is finalized, the validators send a proof that includes their signature to the Keeper server. The users receive this proof and its signature and then send a transaction to the Ethereum node to claim their assets. Please note that a transaction fee (in terms of gas) applies during this process.
While Modeling the threats analysis on the architecture of LightLink bridge, the following classes of business and data assets were identified. Furthermore, the stakeholders were also identified as threat actors or victims of threats.
Threat Description:
The LightLink bridge employs two validator nodes with disproportionate powers of 50 and 20 respectively. This implies that one validator node has significantly more influence over the consensus mechanism than the other.
The threat here is of a potential collusion between the two validators, or the validator with higher power getting compromised. Given their disproportionate power, the validators could manipulate the consensus mechanism or block transfers maliciously. It could lead to potential security breaches, manipulation of asset transfers, or even rendering the entire bridge useless.
Attack Scenario:
An attacker who gains control over the validator with power 50 could potentially manipulate the proof of deposits and withdrawals, effectively gaining control over the cross-chain transfer of assets. This could result in false transactions being validated or valid transactions being blocked.
The attack could be even more potent if both validators collude or are compromised. In such a case, they can bypass the 70% consensus threshold mechanism, leading to a complete breach of the bridge's security and functionality.
Mitigation:
Threat Description:
The implementation of multisig contracts in LightLink bridge currently involves only one member, creating a centralization risk. In the context of the Ronin bridge attack, this centralized multisig scheme can become a single point of failure and pose serious security threats.
In the blockchain context, multisignature (multisig) refers to requiring more than one key to authorize a transaction. It is a technique that adds an additional layer of security for blockchain transactions. The multisig members in the LightLink bridge can be either validators or separate entities depending upon the architecture design. They play a vital role in authorizing critical operations on the bridge such as asset transfers, thus, it's crucial to ensure their decentralization to avoid any single point of failure.
In the Ronin case, they claimed to have nine validators, but in reality, a single entity controlled five, effectively having control over more than 50% of the decision-making power. This issue underscores the importance of decentralization in multisig implementation, as the centralization of power can lead to catastrophic consequences if that entity is compromised.
Attack Scenario:
In the current architecture of the LightLink bridge, a malicious actor gaining control over the single member in the multisig setup could potentially manipulate asset transfers across the bridge. They could approve false transactions, block legitimate ones, or even freeze the contract entirely. This scenario mirrors the Ronin bridge attack, where a single entity's control over the majority of validators led to a massive security breach.
Mitigation:
Threat Description:
Bridges such as the LightLink bridge are fundamental to cross-chain asset transfer, enabling transfer of a myriad of tokens including stablecoins and their wrapped counterparts. While this functionality enhances interoperability, it also introduces unique security risks. One notable threat lies in the potential unauthorized minting of wrapped stablecoins like Wrapped USDT (wUSDT), if the bridge or its components become compromised.
It's important to understand that while stablecoins like USDT are issued by a centralized entity (e.g., Tether Limited) and can be frozen or blacklisted by the issuer to halt illicit transactions, this protection doesn't inherently apply to wrapped versions of these stablecoins. The overall security of a wrapped stablecoin depends heavily on the trustworthiness and security measures of its issuer, as well as the security of the bridge.
Attack Scenario:
In a potential attack, an adversary who gains control over the LightLink bridge or its validators could create fraudulent proofs of locked USDT tokens on the Ethereum network. Leveraging this, they could then illicitly mint an equivalent amount of wUSDT on the LightLink network. If the wrapped token's issuer is less secure or slower to respond than the original issuer, the attacker could then exchange these illegitimately minted wUSDT for other assets before the fraudulent activity is detected and halted.
Mitigation:
Threat Description:
Tokens with elastic supply, like Ampleforth (AMPL), operate on a unique model where the token's supply automatically adjusts or "rebases" to market conditions. This means the quantity of these tokens held by an address can fluctuate daily, without any transactions occurring.
In the context of the LightLink bridge, this could create potential security challenges. Since the quantity of tokens isn't fixed, an attacker could potentially exploit these fluctuations to manipulate transactions across the bridge.
Attack Scenario:
Let's consider an attacker who holds an elastic supply token on the Ethereum side of the bridge. They initiate a transfer to LightLink during a positive rebase period when their token quantity is increasing. The bridge smart contract locks the initial amount of tokens, but in the subsequent rebase, the attacker's token quantity increases.
Since the bridge's smart contract may not be designed to handle such fluctuations, the attacker might be able to claim more tokens than were originally locked, leading to an imbalance in the bridged tokens.
Mitigation:
Threat Description:
Like BadgerDAO, LightLink bridge could be vulnerable to threats associated with the compromise of centralized interfaces used in its tech stack. The exploitation of Cloudflare, a web infrastructure platform, in the BadgerDAO incident highlights the potential risks that centralized services pose to blockchain applications. Attackers manipulated the vulnerability in Cloudflare to alter JavaScript files on the website, redirecting transactions to their own accounts.
Attack Scenario:
An attacker could exploit a vulnerability in the centralized services used by the LightLink bridge, such as Cloudflare (if used). With this foothold, they could alter the code on the website to manipulate transaction data. This could result in unauthorized asset transfers across the bridge, potentially leading to massive financial losses akin to the $120 million stolen in the BadgerDAO hack.
Mitigation:
The following is a detailed analysis of threats and vulnerabilities that Blockchain Bridges, including Lightlink, may face, primarily based on the comprehensive Defi Threat Modeling repository created by a security researcher from BlockApex. This repository dissects the functional aspects of various web3 components and reveals potential security vulnerabilities and threats related to these functionalities.
In the specific context of LightLink architecture, replay attacks could pose a more insidious threat. In a scenario where the database storing transaction proofs is not adequately protected or rate-limited, there is a potential risk of Denial of Service (DoS) attacks or even a system crash. This situation could arise if repeated replay attacks lead to an overflow of the database disk due to the storage of excessive, potentially redundant proofs. The user experience could be severely hampered, ranging from slowed operations to complete denial of service. To mitigate this threat, it is recommended to implement rate-limiting measures, perform regular maintenance and monitoring of the database, and ensure efficient handling of transaction proofs. This way, the database can cope with the transaction load without compromising operational efficiency or system security.
In another scenario known as "source chain poisoning", a fake blockchain could be created by an attacker that mirrors a legitimate Chain ID. If the system isn't verifying the authenticity of the chains, it could mistakenly interact with this fake chain, leading to token loss or invalid states.
Mitigation includes implementing dynamic Chain ID checks that confirm the validity of each transaction and maintaining a whitelist of allowed Chain IDs to prevent interaction with unauthorized or fake chains.
STRIDE was first devised by Microsoft to test traditional software applications but it is also used for blockchain protocol to identify potential major issues in the protocol. The classification below shows the threat models that were identified on the stakeholders according to STRIDE.
| Spoofing | Tampering | Repudiation | Information Disclosure | Denial of Service | Elevation of Privilege | |
| Users | Users could use stolen credentials to impersonate other users and initiate unauthorized transactions | Users could exploit system vulnerabilities to exploit system data | Users could deny conducting a transaction, in the absence of proper audit trails | Users could inadvertently or deliberately leak sensitive information, such as private keys. | A malicious user could attempt to flood the system with requests, causing a denial of service for others. | Users could exploit vulnerabilities to gain unauthorized privileges. |
| Software Ecosystem Contributors | Any individual or entity within this broad group of contributors could potentially be impersonated by malicious actors. With the right stolen credentials, an attacker could introduce malicious code or exploit existing vulnerabilities. This risk extends beyond just in-house developers and can include open-source contributors, third-party developers, DevOps professionals, and even tooling services used in the development process. | Contributors to the software ecosystem, due to their intimate knowledge of and access to the system, can potentially alter the system's components. This can lead to the introduction of malicious functionalities, changes that can compromise existing security controls, or even the creation of new, exploitable vulnerabilities. | Without a comprehensive and secure logging system, any contributor might deny responsibility for the introduction of vulnerabilities or malicious code. This is a risk since the group of contributors is large and diverse, making tracking and attribution of changes more challenging. | Given their access to the system, contributors could inadvertently or intentionally leak sensitive information. This can include system design details, source code, keys, or any other proprietary or confidential information. | Any contributor with a malicious intent or an external attacker with compromised credentials can manipulate the system components to create conditions that can lead to a system-wide failure. This can manifest in different ways, including excessive resource consumption, critical component failure, or blocking access to resources. | Since contributors inherently have certain privileges to be able to perform their roles, these privileges could potentially be misused. This can also include situations where an attacker is able to escalate privileges due to compromised credentials or vulnerabilities in the system, giving them an unusual amount of control over the system. |
| Validator Node Operators | A rogue operator or an attacker with stolen credentials could impersonate a legitimate validator to validate fraudulent transactions | Operators could alter transaction data before validation. | - | Operators could leak sensitive transaction data. | Malicious operators could refuse to validate legitimate transactions. | A compromised validator node could potentially manipulate the consensus mechanism. |
| Keeper Node Operator | A rogue operator could impersonate the Keeper Node to initiate unauthorized token minting. | The operator could manipulate transaction data before minting. | - | The operator could leak sensitive transaction data. | A malicious operator could refuse to mint tokens for legitimate transactions. | An attacker with access to the Keeper Node could gain unauthorized privileges. |
| Ethereum and LightLink Network Operators | A rogue operator or attacker with stolen credentials could impersonate legitimate network operators to perform unauthorized operations. | These operators could alter network configurations or transaction data. | - | - | Misconfigured or compromised network nodes could disrupt the service. | Unauthorized access to network configurations could result in privilege escalation. |
| Infrastructure Providers | Attackers could impersonate legitimate infrastructure providers to perform unauthorized actions. | Infrastructure providers could alter the operating environments or configurations. | Providers could deny having performed certain actions in the absence of proper logging. | Providers could leak sensitive information. | Providers could unintentionally disrupt the service due to outages or intentionally in case of malicious actors. | Unauthorized access to infrastructure settings could lead to privilege escalation. |
| Community | Bad actors within the community could impersonate protocol administrators, community leaders, or even other community members on social platforms, potentially leading to misinformation or harmful actions being taken. | Misinformation spread by community members could lead to other members making adjustments to their local protocol configurations, effectively tampering with how the protocol operates on their end. | A community member might spread false information or instructions and later deny doing so, particularly in unofficial side channels where communication isn't as regulated or transparent. | Information that should be kept private could be leaked within the community, either intentionally or accidentally. This could be protocol-sensitive information, private keys, or even personal data of community members. | A coordinated attack by a group within the community, or even the spread of false information leading to incorrect protocol usage, could effectively result in a Denial of Service. This might disrupt the protocol's operation or make it unavailable to some or all community members. | In this context, Elevation of Privilege would more likely occur through social manipulation than through technical vulnerabilities. A community member might claim to have more authority or knowledge than they actually do, leading to other members giving their false claims or harmful instructions more credence. |
The following matrix defines the mitigations for threats identified through the STRIDE classification, assigning each threat an impact and likelihood, and providing suggestions to counter these threats. Countermeasures should be implemented against each threat to ensure the protocol is free from security loopholes.
| Threat Vector | Impact | Likelihood | Mitigation | CounterMeasures |
| Unauthorized Access (Spoofing) | High | Medium | Implement strong authentication mechanisms | Encourage the use of multi-factor authentication |
| Exploitation of System Vulnerabilities (Tampering) | High | Medium | Regularly update and patch system vulnerabilities | Monitor and regulate user activity for any anomalies |
| Denial of Transaction (Repudiation) | Medium | Low | Maintain a comprehensive and secure logging system | Use non-repudiation measures such as cryptographic signatures |
| Leakage of Sensitive Information (Information Disclosure) | High | Medium | User education and awareness programs | Provide guidelines on safe practices and the secure handling of sensitive information |
| System Flooding (Denial of Service) | Medium | Low | Employ rate limiting techniques | Monitor user traffic to prevent system flooding |
| Unauthorized Privileges (Elevation of Privilege) | High | Medium | Regularly update and patch system vulnerabilities | Limit user privileges to essential tasks only |
| Threat Vector | Impact | Likelihood | Mitigation | CounterMeasures |
| Impersonation (Spoofing) | High | High | Implement secure credential management | Use multi-factor authentication and regular credential rotation |
| Alteration of System Components (Tampering) | High | High | Foster secure coding practices and rigorous code review processes | Implement automated vulnerability scanning and manual code reviews |
| Denial of Responsibility (Repudiation) | Medium | Medium | Foster secure coding practices and rigorous code review processes | Implement automated vulnerability scanning and manual code reviews |
| Denial of Responsibility (Repudiation) | High | Medium | Maintain a comprehensive and secure logging system | Track changes and maintain developer accountability |
| Leakage of Sensitive System Details (Information Disclosure) | High | Medium | Restrict access to sensitive system details | Conduct regular security audits and access reviews |
| System-wide Failure (Denial of Service) | High | Low | Regular system monitoring and maintenance | Develop a robust disaster recovery and incident response plan |
| Misuse of Privileges (Elevation of Privilege) | High | High | Implement strict role-based access control | Regularly audit privilege assignments and usage |
| Threat Vector | Impact | Likelihood | Mitigation | CounterMeasures |
| Fraudulent Transactions (Spoofing) | High | Medium | Implement secure authentication mechanisms | Regularly verify and authenticate validator nodes |
| Alteration of Transaction Data (Tampering) | High | Medium | Implement transaction validation protocols | Conduct regular audits of transaction records |
| Leakage of Sensitive Transaction Data (Information Disclosure) | High | Medium | Implement strict data access controls | Regularly review and update data protection measures |
| Denial of Transaction Validation (Denial of Service) | High | Low | Establish failover mechanisms for transaction validation | Regularly monitor validator node performance and responsiveness |
| Manipulation of Consensus Mechanism (Elevation of Privilege) | High | High | Implement secure consensus protocols | Regularly verify and validate consensus protocol operations |
| Threat Vector | Impact | Likelihood | Mitigation | CounterMeasures |
| Unauthorized Token Minting (Spoofing) | High | Medium | Implement secure authentication mechanisms | Regularly verify and authenticate keeper nodes |
| Manipulation of Transaction Data (Tampering) | High | Medium | Implement transaction validation protocols | Conduct regular audits of transaction records |
| Leakage of Sensitive Transaction Data (Information Disclosure) | High | Medium | Implement strict data access controls | Regularly review and update data protection measures |
| Denial of Token Minting (Denial of Service) | High | Low | Establish failover mechanisms for token minting | Regularly monitor keeper node performance and responsiveness |
| Unauthorized Privileges (Elevation of Privilege) | High | High | implement secure access control mechanisms | Regularly verify and validate keeper node permissions |
| Threat Vector | Impact | Likelihood | Mitigation | CounterMeasures |
| Unauthorized Operations (Spoofing) | High | High | Implement secure authentication mechanisms | Regularly verify and authenticate network operators |
| Alteration of Network Configurations (Tampering) | High | High | Implement change control processes for network configurations | Conduct regular audits of network configurations |
| Disruption of Service (Denial of Service) | High | Medium | Regular system monitoring and maintenance | Develop a robust disaster recovery and incident response plan |
| Unauthorized Access (Elevation of Privilege) | High | High | Implement strict role-based access control | Regularly audit privilege assignments and usage |
| Threat Vector | Impact | Likelihood | Mitigation | CounterMeasures |
| Unauthorized Actions (Spoofing) | High | High | Implement secure authentication mechanisms | Regularly verify and authenticate infrastructure providers |
| Alteration of Operating Environments (Tampering) | High | High | Implement change control processes for infrastructure configurations | Conduct regular audits of infrastructure configurations |
| Denial of Actions (Repudiation) | Medium | Medium | Maintain a comprehensive and secure logging system | track changes and maintain accountability |
| Leakage of Sensitive Information (Information Disclosure) | High | Medium | Implement strict data access controls | Regularly review and update data protection measures |
| Disruption of Service (Denial of Service) | High | Medium | Regular system monitoring and maintenance | Develop a robust disaster recovery and incident response plan |
| Unauthorized Access (Elevation of Privilege) | High | High | Implement strict role-based access control | Regularly audit privilege assignments and usage |
| Threat Vector | Impact | Likelihood | Mitigation | CounterMeasures |
| Impersonation (Spoofing) | High | Medium | Implement community verification mechanisms | Encourage verification of community leaders and regular members |
| Spread of Misinformation (Tampering) | Medium | Medium | Establish community guidelines and rules | Regularly monitor community channels for misinformation |
| Denial of Spreading False Information (Repudiation) | Low | Low | Maintain logs of community interactions | Use verifiable sources for information and news |
| Leakage of Sensitive Information (Information Disclosure) | High | Medium | Community education and awareness programs | Provide guidelines on secure practices for the handling of sensitive information |
| Disruption of Protocol Operation (Denial of Service) | Medium | Low | Monitor and regulate community activities | Implement mechanisms to filter and control information flow in the community |
| False Claims of Authority (Elevation of Privilege) | Medium | Low | Establish clear community roles and responsibilities | Regularly verify the credibility and authority of community members |
ABC is a systematic threat modeling framework that's primarily geared towards cryptocurrency-based systems. However, its tools and methodologies are also useful for any distributed system. ABC assists designers in focusing on the following key areas:
The ABC framework also integrates seamlessly with other crucial steps of system design such as risk management and threat mitigation, providing a comprehensive and robust approach to ensuring system security.
From the provided details, the system model characterization for LightLink Bridge architecture might look as follows:
Given the nature of the system and the assets identified, here are potential threat categories:
| Data Assets | Security Threat Category |
| DApp Server | Unauthorized Access: An unauthorized entity may gain access to the DApp Server, resulting in potential manipulation of data, application logic, or server settings. This could potentially lead to compromise of the entire system.Denial of Service (DoS): An attacker may attempt to overload the DApp server with requests, resulting in denial of service to legitimate users.Data Tampering: The data stored or transferred by the DApp server might be altered or tampered with, affecting the integrity of the system.Information Disclosure: Confidential or sensitive information stored or processed by the DApp server might be disclosed to unauthorized entities.Elevation of Privileges: An attacker may exploit vulnerabilities to elevate privileges, gaining more control over the DApp server and its functionalities.Using Component with known vulnerabilities (Server using vulnerable libraries and components can lead to the loss of access to the server)Social Engineering (Server credentials are maliciously utilized) |
| User Assets | Unauthorized access to assets: This occurs when an unauthorized user gains access to another user's assets.Asset loss during transfer: This occurs when assets get lost during the transfer process due to a bug or an attack. |
| Nodes | Node impersonation: This occurs when an attacker successfully pretends to be a legitimate node in the network.Node compromise: This occurs when an attacker gains control over a node, potentially manipulating its behavior or accessing sensitive information. |
| L1 and L2 smart contracts | Contract exploitation: This occurs when an attacker discovers and exploits a vulnerability in a smart contract to perform unauthorized actions. |
| Network | Network attacks (DoS/DDoS): These attacks aim to overwhelm the network or a specific node, making it unavailable for legitimate users.Man-in-the-middle attack: This occurs when an attacker intercepts and potentially alters the communication between two parties without their knowledge. |
Attack Scenario:If an unauthorized entity gains access to the DApp server, it could potentially manipulate user data, change application logic, or alter server settings. Such intrusion could compromise the entire system, disrupting user transactions and potentially stealing sensitive data. This could result in severe reputation damage and financial losses.
Attack Scenario: A DoS attack is a scenario where an attacker attempts to make the DApp server unavailable by overwhelming it with a flood of internet traffic. The attacker could potentially send an exceedingly high number of requests, exhausting server resources, and making the DApp server unresponsive to legitimate user requests. This could cause inconvenience and frustration to users and potentially make them lose trust in the system.
Attack Scenario: If the DApp server is compromised, an attacker could potentially alter or tamper with the data stored or transferred by the server. This can affect the integrity of the system, leading to incorrect or misleading data being shown to users. It could also lead to improper transaction execution, affecting the accuracy of asset transfers or causing unexpected loss of funds.
Attack Scenario: In a situation where the DApp server's defenses are breached, confidential or sensitive information, including user details, private keys, or transaction details, could be leaked. This unauthorized disclosure could lead to loss of privacy, identity theft, or misappropriation of funds.
Attack Scenario: This is a scenario where an attacker manages to exploit vulnerabilities in the DApp server to gain higher-level privileges. This could allow them more control over the server and its functionalities, enabling them to manipulate data, alter application logic, or even disrupt the operation of the server.
Attack Scenario: Servers are made up of different components and packages. The components can be vulnerable, given a dependent library fails due to a new bug. So If the server’s code containing a vulnerable version of the library doesn't update on time or is
patched, the result is a weakness for the protocol. Attackers can view the versions of the dependencies containing the vulnerable code and confirm the exploit as easily as by checking it on websites such as exploit-db.
Due to the large complexity of modern applications, it is easy to lose sight of all the dependencies and software being used, commonly termed as a SBoM. It is important to know that automated scanners or manual testing might reveal outdated software with issues. Exploiting known issues can have disastrous impacts, they are often the first thing the attackers look at and abuse to gain a foothold, elevate their privileges, impersonate other users and whatnot. If the attacker gets hold of the server all the users can lose their funds and NFTs.
Attack Scenario: Nowadays it’s common to host the server on cloud infrastructure such as AWS so in that case if the attacker gets the admin console credentials of the server through social engineering then it can have full control over the server and can execute malicious activity which will create a financial loss for the users of ember protocol.
Attack Scenario: An attacker may use phishing techniques to trick users into revealing their private keys. Once the attacker has access to a user's private keys, they can access the user's assets and transfer them to an address under their control.
Attack Scenario: During the asset transfer process, a number of issues could lead to asset loss. If there's a bug or vulnerability within the L1 or L2 smart contracts, an attacker could exploit it to redirect asset transfers to their own address. Additionally, if the user interacts with a malicious dApp, it could initiate unauthorized transfers. A network disruption (due to DDoS or other reasons) during a transfer could also potentially lead to asset loss. Furthermore, if a transaction is not properly validated or if a malicious validator node is involved, assets could be incorrectly sent or not sent at all.
Attack Scenario: A malicious actor could try to impersonate a legitimate node (like an ETH node, LightLink node, Keeper, or Validator) within the system. If successful, this would give the attacker the ability to manipulate the data that the node is supposed to handle, possibly leading to incorrect validation of transactions or even unauthorized transactions. For instance, if an attacker impersonates a Keeper node, they could provide false confirmations for transactions, leading to assets being sent to wrong addresses or the approval of illegitimate transactions.
Attack Scenario: An attacker may exploit a vulnerability in a node's software or hardware to gain control over it. With control over a node, the attacker can manipulate transaction data, insert false transactions, or prevent certain transactions from being processed.
Attack Scenario: A malicious actor discovers a bug or vulnerability in the L1 or L2 smart contracts. This bug could be exploited to perform unauthorized actions. For instance, an attacker could manipulate the contract to redirect asset transfers to their own address, effectively stealing user assets during the transfer process.
Attack Scenario: Attackers could flood the network with illegitimate requests, effectively slowing down or even halting the network's ability to process legitimate requests. This could result in users being unable to transfer their assets. Alternatively, a DoS/DDoS attack could target a specific node (like a Keeper or Validator node), which could disrupt the functioning of the whole system.
Attack Scenario: In a Man-in-the-Middle (MitM) attack, a malicious actor could position themselves between two communicating parties (e.g., between the dApp and a node or between two nodes). By doing so, they could intercept and potentially alter the data being exchanged. In the context of the LightLink Bridge architecture, this could enable an attacker to alter transaction details, redirect asset transfers, or gather sensitive information.
Service Theft Threat Collusion Matrix
In the LightLink bridge architecture, the following are the primary stakeholders:
A Collusion Matrix could be structured as follows, considering the "Service Theft" threat:
| U | D | V | K | E | I | C | |
| U | Y | Y | Y | Y | Y | Y | |
| D | Y | Y | Y | Y | Y | Y | |
| V | Y | Y | Y | Y | Y | Y | |
| K | Y | Y | Y | Y | Y | Y | |
| E | Y | Y | Y | Y | Y | Y | |
| I | Y | Y | Y | Y | Y | Y |
Here, 'Y' indicates the potential for collusion between the stakeholders to perform a "Service Theft" attack. Let's further describe the possible collusion scenarios:
This Threat Modeling Report is prepared by BlockApex for the express purpose of informing and advising the development team of LightLink Bridge on potential threats, vulnerabilities, and security measures relevant to their blockchain application.
While every effort has been made to ensure the accuracy and completeness of the information contained in The Report, it is provided on an "as is" basis. The information included in The Report is based on the best available information as of the date of its publication. Future changes in technology, legal and regulatory frameworks, or the security landscape may necessitate updates to The Report.
The proposed threat scenarios and mitigation strategies in The Report do not constitute an exhaustive list of all possible risks or solutions. The inclusion or omission of any particular threat or solution should not be taken as an endorsement or dismissal. Other unanticipated or unidentified threats may exist.
The mitigation strategies outlined in The Report do not guarantee complete security or immunity from breaches, hacks, or other security events. The effectiveness of these strategies is contingent upon their correct and consistent implementation and may vary depending on individual circumstances.
Neither BlockApex nor any of its officers, employees, agents, or contractors will be held liable for any losses, damages, costs, or expenses, whether direct or indirect, including consequential loss or damage, arising from or in connection with any use or reliance on the information contained in The Report.
BlockApex (Auditor) was contracted by LightLink (Client) for the purpose of conducting a Smart Contract Audit/ Code Review. This document presents the findings of our analysis, which started on 12th June ‘2023.
| Name |
| LightLink Bridge |
| Audited by |
| Moazzam Arif | Muhammad Jarir Uddin |
| Platform |
| Ethereum and EVM Compatible Chains | Solidity |
| Type of review |
| Manual Code Review | Automated Tools Analysis |
| Methods |
| Architecture Review | Functional Testing | Computer-Aided Verification | Manual Review |
| Git repository/ Commit Hash |
| Private Repo | b8eab88ce573a7b6150c36afd62590fe21f171d0 |
| White paper/ Documentation |
| Whitepaper for LightLink Network |
| Document log |
| Initial Audit Completed: June 22nd ‘2023 Final Audit Completed: July 3rd ‘2023 |
The shared git-repository was checked for common code violations and vulnerability-specific probing to detect major issues/vulnerabilities. Some specific checks are as follows:
| Code review | Code review Functional review | |
| Reentrancy | Unchecked external call | Business Logics Review |
| Ownership Takeover | ERC20 API violation | Functionality Checks |
| Timestamp Dependence | Unchecked math | Access Control & Authorization |
| Gas Limit and Loops | Unsafe type inference | Escrow manipulation |
| DoS with (Unexpected) Throw | Implicit visibility level | Token Supply manipulation |
| DoS with Block Gas Limit | Deployment Consistency | Asset’s integrity |
| Transaction-Ordering Dependence | Repository Consistency | User Balances manipulation |
| Style guide violation | Data Consistency | Kill-Switch Mechanism |
| Costly Loop | Operation Trails & Event Generation |
LightLink Bridge is a core component of the LightLink network, a high-performance, secure, and scalable solution built on Ethereum. The bridge serves as a conduit for assets between Ethereum's Layer 1 (L1) and Layer 2 (L2), enabling fast and low-cost transactions. It is designed to unlock the power of Layer 2 scaling solutions, thereby enhancing the efficiency and scalability of the Ethereum network.
The LightLink Bridge supports a wide range of token standards, including ERC20, ERC721, ERC1155, and native tokens, making it highly versatile and adaptable for various applications. It is built to onboard new users, offering both Enterprise mode and standard transacting. This flexibility, combined with the optionality to pay fees in either ETH or its native token, LL, makes LightLink Bridge a powerful tool for asset management on the Ethereum network.
With its highly composable nature, LightLink Bridge is suitable for a wide range of applications, including enterprise ecosystems, gaming and metaverse projects, ticketing, and identity management. It represents a significant advancement in Layer 2 scaling solutions, contributing to the ongoing development and evolution of the Ethereum ecosystem.
The LightLink Bridge system architecture is based on a Proof-of-Authority mechanism with an external validator set that stakes its individual reputation in order to earn incentives for the trades on the LightLink bridge. This ensures a robust and interconnected framework enabling seamless asset transfers between Ethereum's Layer 1 and Layer 2. The bridge architecture consists of several key components, each playing a crucial role in the overall operation of the bridge.
These components include Bridge Registries, Predicates Proxies, Token Proxies, and some helper libraries.
Bridge Registries are the core of the LightLink Bridge, maintaining the mapping information for each token. The registries are divided into L1 and L2 Bridge Registries, each responsible for operations on their respective Ethereum layers.
These registries ensure the accurate representation and tracking of assets across layers.
Token Predicates Proxies handle the deposit and withdrawal operations for different token standards. They include L1 and L2 Predicate contracts for ERC20, ERC721, ERC1155, and native tokens.
These proxies ensure the secure and accurate transfer of assets between layers.
Token Proxies are responsible for creating and operating L2 tokens. They include templates for ERC20, ERC721, ERC1155, and native tokens. These templates are used to create new L2 tokens that represent the L1 assets. The Token Proxies interact with the Bridge Registries and the Predicate Proxies to ensure the accurate representation of L1 assets on L2.
The Prerequisite include Multisig contracts on both L1 and L2. These contracts provide the necessary security measures for the management of assets and the execution of transactions. The Multisig contracts require multiple signatures for certain operations, adding an extra layer of security. They are crucial for the operation of the Bridge Registries and the Predicate Proxies.
Libraries in the ecosystem provide additional functionalities that enhance the operation of the LightLink Bridge. They include Create2, MemberSet, and ValidatorSet libraries.
These libraries provide essential tools for the efficient operation of the LightLink Bridge.
The codebase was audited using a filtered audit technique. A band of two (2) auditors scanned the codebase in an iterative process for a time spanning ten (10) days.
Starting with the recon phase, a basic understanding was developed, and the auditors worked on developing presumptions for the developed codebase and the relevant documentation/whitepaper. Furthermore, the audit moved on with the manual code reviews to find logical flaws in the codebase complemented with code optimizations, software, and security design patterns, code styles, best practices, and identifying false positives detected by automated analysis tools.
LightLink, being a POA bridge, relies on a set of trust assumptions considering its external validators. The smart contracts' technical interpretation of this trust is reflected in the validity of off-chain signed messages, watched events, and signatures.
The focus of this audit revolved around a targeted niche of attack vectors which further expanded to a spectrum of vulnerabilities that present themselves in the scope of smart contracts and hence arise in the following cases;
Listed below is a set of security assumptions that are ensured to only work with the respective security controls if the smart contracts are implemented correctly.
Our team performed a technique called Filtered Audit, where two individuals separately audited the LightLink Bridge.
After a thorough and rigorous manual testing process involving line-by-line code review for bugs, an automated tool-based review was carried out using Slither for static analysis and Foundry for fuzzing invariants.
All the flags raised were manually reviewed and re-tested to identify the false positives
| # of issues | Severity Of the Risk |
| 0 | Critical Risk Issues(s) |
| 1 | High Risk Issues(s) |
| 1 | Medium Risk Issues(s) |
| 4 | Low Risk Issues(s) |
| 4 | Informatory Risk Issues(s) |
| # | Findings | Risk | Status |
| 1 | Centralization Risk Due to Majority Power Saturation | High | Fixed |
| 2 | Violation of Checks-Effects-Interactions Pattern | Medium | Fixed |
| 3 | Missing Pause Functionality | Low | Fixed |
| 4 | Absence of Recovery Functionality | Low | Fixed |
| 5 | Missing Input Validations in Multisigable Contract | Low | Fixed |
| 6 | Length Check for Input Array Arguments | Low | Fixed |
| 7 | Lack of Events in Crucial Functions | Info | Fixed |
| 8 | Use Calldata for Function Arguments | Gas-Opt | Fixed |
| 9 | Use Custom Error Messages for Revert Statements | Gas-Opt | Resolved |
| 10 | Substandard Order of Layout Incurs Higher Gas Costs | Gas-Opt | Fixed |
Path:
contracts/bridge/core/L1/L1BridgeRegistry.sol contracts/bridge/core/L2/L2BridgeRegistry.sol
Status: Fixed
Function Name:
__L1BridgeRegistry_init
__L2BridgeRegistry_init
Description:
The __L1BridgeRegistry_init and __L2BridgeRegistry_init functions in the respective contracts initialize two validators with different powers. One of the validators is assigned a majority power (50 out of 70), which poses a centralization risk. This validator has the ability to influence the rest of the validators and control the overall protocol direction.
Code Affected:
The entire protocol is potentially vulnerable due to this centralization risk.
function __L1BridgeRegistry_init() internal {
validators.add(0x574f879160252895a4b15fF9316bf9e9ADc46423, 50); // Majority power
validators.add(0x2681682d1197131D339a169dF10940470D602806, 20);
consensusPowerThreshold = 70;
}
Note: The same function is initialized in the L2BridgeRegistry contract as well.
Impact:
The validator with an influential powerThreshold can control the protocol's decisions, leading to a centralized system. This is contrary to the decentralized nature of blockchain systems and could lead to misuse or manipulation of the protocol.
Recommendation:
It is recommended to distribute the power among multiple validators to reduce the centralization risk. This can be achieved by breaking down the validator power saturation into multiple validators right from the beginning. The updated code could look like this:
| function __L1BridgeRegistry_init() internal { validators.add(0x574f879160252895a4b15fF9316bf9e9ADc46423, 35); // Reduced power validators.add(0x2681682d1197131D339a169dF10940470D602806, 35); // Increased power consensusPowerThreshold = 70; } |
Another option to prevent the consensusPowerThreshold from being saturated is to increase the number of validators in the registry contract.
2. Violation of Checks-Effects-Interactions Pattern
Path:
contracts/bridge/core/L1/predicates/**
contracts/bridge/core/L2/predicates/**
Status: Fixed
Description:
The mapToken function in the Predicate contracts violates the Checks-Effects-Interactions pattern, potentially opening a door to reentrancy attacks. The function first interacts with the childToken contract by calling its initialize function. Only after this interaction is done, it updates its own state (l1ToL2Gateway[l1Token]=childToken) and emits an event (TokenMapped).
This coding pattern is against the best practices where during reentrancy the check for mapping require(l1ToL2Gateway[l1Token] == _l2Token, "Token not mapped"); can be bypassed easily.
Code-Affected:
| // call initialize using call (bool success, bytes memory data) = childToken.call( abi.encodeWithSignature( "initialize(address,bytes)", // implTemplate, // encode function data for initialize abi.encodeWithSignature("initialize(address,address,address)", multisig, address(this), l1Token) ) ); require(success, string(data)); // map the token l1ToL2Gateway[l1Token] = childToken; // State changes violating CEI pattern emit TokenMapped(messageHash); |
Impact:
This pattern violation could potentially allow a malicious childToken contract to reenter the Predicate contract before it has a chance to update its state, leading to possible reentrancy attacks. Although in the current implementation of the smart contract complex, the pattern does not directly impact the flow of mapping tokens, in cases of malicious tokens or scenarios this practice could come in handy to an adversary.
Recommendation:
To mitigate this risk, the Predicate contracts should adhere to the Checks-Effects-Interactions pattern. This means they should perform all state changes such as (l1ToL2Gateway[l1Token] = childToken) before interacting with external contracts (childToken.call()). This, combined with a non-reentrant modifier, can eliminate the reentrancy attack window to a large extent, if not completely.
Path:
contracts/bridge/core/L1/predicates/**
contracts/bridge/core/L2/predicates/**
contracts/bridge/core/L1/L1BridgeRegistry.sol
contracts/bridge/core/L2/L2BridgeRegistry.sol
Status: Fixed
Description:
The BridgeRegistry and associated predicate contracts do not implement a pause or revoke functionality. This could potentially lead to a situation where, in the event of a detected vulnerability or an ongoing attack, there is no way to immediately halt the execution of the contracts to prevent further damage or loss of funds.
Code-Affected:
The entire contract is potentially vulnerable due to the lack of a pause or revoke functionality.
Impact:
Without a pause or revoke function, the contract is vulnerable to continued exploitation in the event of a detected vulnerability or an ongoing attack. This could lead to a significant loss of funds and could potentially undermine trust in the contract.
Recommendation:
It is highly recommended to implement a pause or revoke function in the L1BridgeRegistry contract and its associated predicate contracts. This function should only be accessible by the contract owner or a designated emergency account. This would allow for immediate action in the event of a detected vulnerability or an ongoing attack, potentially saving significant amounts of funds and preserving the integrity of the contract.
Path:
contracts/bridge/core/L1/predicates/**
contracts/bridge/core/L2/predicates/**
contracts/bridge/core/L1/L1BridgeRegistry.sol
contracts/bridge/core/L2/L2BridgeRegistry.sol
Status: Fixed
Description:
The BridgeRegistry and associated predicate contracts do not implement a recovery functionality. This could potentially lead to a situation where, in the event of an accidental transfer or a bug causing the tokens to be stuck in a contract, there is no way to recover the funds.
Code-Affected:
The entire contract is potentially vulnerable due to the lack of a recovery functionality.
Impact:
Without a recovery function, the contract is vulnerable to permanent loss of funds in the event of an accidental transfer or a bug causing the tokens to be stuck. This could lead to significant loss of funds and could potentially undermine trust in the contract.
Recommendation:
It is recommended to implement a recovery function in the L2NativeTokenPredicate contract and its associated contracts. This function should only be accessible by the contract owner or a designated emergency account. This would allow for immediate action in the event of accidental transfers or bugs causing tokens to be stuck, potentially saving significant amounts of funds and preserving the integrity of the contract.
Path: contracts/bridge/prerequisite/Multisigable.sol
Status: Fixed
Description:
The Multisigable contract does not perform input validation in the __Multisigable_init and modifyMultisig functions. Specifically, it does not check if the input address is a zero address.
Code-Affected:
| function __Multisigable_init(address _multisig) internal { multisig = _multisig; } function modifyMultisig(address _multisig) public requireMultisig { multisig = _multisig; } |
Impact:
Without input validation, the contract is susceptible to accidental or malicious misuse. If a zero address is passed to these functions, it could lead to loss of control over the state variables as no valid Ethereum account corresponds to the zero address.
Recommendation:
Adding input validation checks in these functions is recommended to prevent the assignment of a zero address. This could be done by adding the following checks on top of both functions.
| require(_multisig != address(0), "Multisig address cannot be zero") |
Path:
contracts/bridge/core/L1/L1BridgeRegistry.sol
contracts/bridge/core/L2/L2BridgeRegistry.sol
Status: Fixed
Description:
The functions modifyValidators, removeValidators, and modifyServiceImplementations function in the Registry contracts do not perform a length check for its input array arguments. This could lead to unexpected behavior if the lengths of the _keys and _implementations arrays are not equal.
Code-Affected:
Following is one of the instances in the codebase under the scope of audit that is to be considered while applying such constraint.
| function modifyServiceImplementations(bytes32[] memory _keys, address[] memory _implementations) public requireMultisig { for (uint256 i = 0; i < _keys.length; i++) { implementations[_keys[i]] = _implementations[i]; } } |
Impact:
If the lengths of the _keys and _implementations arrays are not equal, the function could either skip some _keys or attempt to access an out-of-bounds index in the _implementations array, leading to a revert.
Recommendation:
Add a length check at the beginning of the function to ensure that the lengths of the _keys and _implementations arrays are equal. The updated code would look like this:
| require(_keys.length == _implementations.length, "Input arrays must have the same length"); |
on both instances.
Path:
contracts/bridge/core/L1/L1BridgeRegistry.sol
contracts/bridge/core/L2/L2BridgeRegistry.sol
contracts/bridge/prerequisite/Multisig.sol
contracts/bridge/prerequisite/Multisigable.sol
Status: Fixed
Description:
The Registry, Multisig, and Multisigable contracts do not emit events in the above-mentioned crucial functions;
Events are crucial in smart contracts as they provide a way to track changes and updates in the contract state. Without them, monitoring and auditing the contract's activities becomes challenging.
Code-Affected:
| // verified function addMember(address _account) public virtual requireMultisig { members.add(_account); } |
Impact:
The lack of events in these functions makes it difficult to track when a member is added or removed from the multisig and multisigable contracts. This could lead to unnoticed unauthorized changes in the contract's member set and validators being unaware of any ongoing attack.
Recommendation: Emitting events in these functions is recommended to provide an audit trail of when members are added or removed. This could be done by adding emitted events at the end of each state-altering function listed above e.g. emit MemberAdded(_account) in the addMember function.
File:
contracts/bridge/core/L1/predicates/**
contracts/bridge/core/L2/predicates/**
contracts/bridge/core/L1/L1BridgeRegistry.sol
contracts/bridge/core/L2/L2BridgeRegistry.sol
Status: Fixed
Description:
The user-facing external and public functions in the Predicate contracts use memory modifiers for function arguments. However, these arguments could be declared as calldata to save gas, ultimately restricting any manipulation of the inputs, as calldata is cheaper than memory.
Code-Affected:
Following is one of the instances in the codebase under the scope of audit that is to be considered while applying such optimization.
| function mapToken(address[] memory _currentValidators, bytes[] memory _signatures, bytes memory _message) public { ... } |
Recommendation:
Consider using calldata instead of memory for function arguments. This could save gas costs. The updated code would look like this:
| function mapToken(address[] calldata _currentValidators, bytes[] calldata _signatures, bytes calldata _message) public { ... } |
Path: contracts/bridge/core/**
Status: Resolved
Description:
Throughout the codebase under the scope of the audit, the smart contracts use require statements to enforce constraints of the system. Since the release of the Solidity 0.8.4 version, it is now supported that the require statement be translated to an if block with a custom revert error message incurring lower gas costs and improving the readability.
Code-Affected:
Following are a few of many instances in the codebase under the scope of audit that are to be considered while applying such optimization.
| modifier requireOwner() { require(members.contains(msg.sender), "Owner required"); _; } function add(Record storage _record, address _value) internal { if (contains(_record, _value)) return; _record.values.push(_value); _record.indexes[_value] = _record.values.length; } |
Impact:
Without a recovery function, the contract is vulnerable to permanent loss of funds in the event of an accidental transfer or a bug causing the tokens to be stuck. This could lead to a significant loss of funds and could potentially undermine trust in the contract.
Recommendation:
It is highly suggested that all the instances in the user-facing functions that are assumed to handle most of the traffic utilize the below-recommended approach which during the bull markets, the gas cost is controlled by design, and users may not need to think twice before interacting with their favorite protocols.
| modifier requireOwner() { if(!members.contains(msg.sender) revert OwnerRequired(); _; } function add(Record storage _record, address _value) internal { if (contains(_record, _value)) revert RecordExists(); _record.values.push(_value); _record.indexes[_value] = _record.values.length; } |
Developer Response:
“I believe change error format can reduce deployment cost but will not affect to function cost cause a successful transaction will not run into revert segment and of course in application level, we will not allow users to send a reverted transaction”
Auditor Response:
Acknowledged with no further action required.
Path:
contracts/bridge/core/L1/L1BridgeRegistry.sol
contracts/bridge/core/L2/L2BridgeRegistry.sol
Status: Fixed
Description:
The current order of layout in the registry contracts does not follow the best practices suggested by the Solidity style guide. The external functions, which are frequently accessed by users, are discovered later in the bytecode traversal during each function call. This leads to higher gas costs for each transaction.
Code-Affected:
The entire contract layout is relevant to this issue. The specific code is not included here due to its size.
Impact:
The current layout order results in higher gas costs for each transaction, making the contract less efficient and more expensive for users to interact with.
Recommendation:
Following the Solidity style guide's order of layout best practices is recommended. This includes placing the contract's external functions before internal and private ones. By doing so, the external functions will be discovered earlier in the bytecode traversal, reducing the gas costs for each transaction.
The smart contracts provided by the client for audit purposes have been thoroughly analyzed in compliance with the global best practices to date w.r.t cybersecurity vulnerabilities and issues in smart contract code, the details of which are enclosed in this report.
This report is not an endorsement or indictment of the project or team, and they do not in any way guarantee the security of the particular object in context. This report is not considered and should not be interpreted as an influence on the potential economics of the token, its sale, or any other aspect of the project.
Crypto assets/tokens are the results of emerging blockchain technology in the domain of decentralized finance, and they carry with them high levels of technical risk and uncertainty. No report provides any warranty or representation to any third-Party in any respect, including regarding the bug-free nature of code, the business model or proprietors of any such business model, and the legal compliance of any such business. No third party should rely on the reports in any way, including for the purpose of making any decisions to buy or sell any token, product, service, or another asset. Specifically, for the avoidance of doubt, this report does not constitute investment advice, is not intended to be relied upon as investment advice, is not an endorsement of this project or team, and is not a guarantee as to the absolute security of the project.
Smart contracts are deployed and executed on a blockchain. The platform, its programming language, and other software related to the smart contract can have vulnerabilities that can lead to hacks. The scope of our review is limited to a review of the Solidity code and only the Solidity code we note as being within the scope of our review within this report. The Solidity language itself remains under development and is subject to unknown risks and flaws. The review does not extend to the compiler layer or any other areas beyond Solidity that could present security risks.
This audit cannot be considered a sufficient assessment regarding the utility and safety of the code, bug-free status, or any other statements of the contract. While we have done our best in conducting the analysis and producing this report, it is important to note that you should not rely on this report only - we recommend proceeding with several independent audits and a public bug bounty program to ensure the security of smart contracts.
BlockApex (Auditor) was contracted by Borderless Money (Client) for the purpose of conducting a Smart Contract Audit/Code Review. This document presents the findings of our analysis which started on Septemebr 12th, 2022.
| Name |
| Borderless Money |
| Audited by |
| BlockApex |
| Platform |
| Ethereum | Solidity |
| Type of review |
| Manual Code Review | Automated Tools Analysis |
| Methods |
| Architecture Review | Functional Testing | Computer-Aided Verification |
| Git repository/ Commit Hash |
| https://github.com/BorderlessMoney-BOM/contracts/commit/e9765d2811c50b373d91b0b930d6aa2d86ec4a3c |
| Contract |
| https://polygonscan.com/address/0xc59132FBdF8dE8fbE510F568a5D831C991B4fC38#code |
| Website URL |
| https://borderless.money/ |
| Document log |
| Audit Completed: September 16th, 2022 |
The git-repository shared was checked for common code violations along with vulnerability-specific probing to detect major issues/vulnerabilities. Some specific checks are as follows:
| Code review | Code review Functional review | |
| Reentrancy | Unchecked external call | Business Logics Review |
| Ownership Takeover | ERC20 API violation | Functionality Checks |
| Timestamp Dependence | Unchecked math | Access Control & Authorization |
| Gas Limit and Loops | Unsafe type inference | Escrow manipulation |
| DoS with (Unexpected) Throw | Implicit visibility level | Token Supply manipulation |
| DoS with Block Gas Limit | Deployment Consistency | Asset’s integrity |
| Transaction-Ordering Dependence | Repository Consistency | User Balances manipulation |
| Style guide violation | Data Consistency | Kill-Switch Mechanism |
| Costly Loop | Operation Trails & Event Generation |
Borderless Money is a decentralized finance protocol redefining how Social Investments are made, using yield-generating strategies and contributing to social causes. An open, borderless digital society, with borderless money, where the goods, services, technology, information, opportunities, and capital can flow through the borders from one hand to many, fairly, transparently.
The BOM Token codebase was audited using a filtered audit technique. A pair of auditors scanned the codebase in an iterative process spanning over a span of 4 days.
Starting with the recon phase, a basic understanding was developed and the auditors worked on establishing presumptions for the codebase and the relevant documentation/ whitepaper provided or found publicly.
Furthermore, the audit moved on with the manual code reviews with the motive to find logical flaws in the codebase complemented with code optimizations, software and security design patterns, code styles, best practices and identifying false positives that were detected by automated analysis tools.
The analysis indicates that the contract under scope of audit is working properly.
Our team performed a technique called “Filtered Audit”, where the contract was separately audited by two individuals. After a thorough and rigorous process of manual testing, an automated review was carried out using tools like slither for an extensive static analysis and foundry for property testing the invariants of the system. All the flags raised were manually reviewed in collaboration and re-tested to identify the false positives.
Our Team Found
| # of issues | Severity Of the Risk |
| 0 | Critical Risk Issues(s) |
| 0 | High Risk Issues(s) |
| 0 | Medium Risk Issues(s) |
| 0 | Low Risk Issues(s) |
| 0 | Informatory Risk Issues(s) |
| # | Properties | Type | Status |
| 1. | Compliant with ERC20 standard | Custom | Passed |
| 2. | Should mint initial supply to msg.sender on deployment | Custom | Passed |
| 3. | Should be able to approve tokens | Custom | Passed |
| 4. | Should be able to increase allowance | Custom | Passed |
| 5. | Should be able to decrease allowance | Custom | Passed |
| 6. | Should be able to spend approved tokens | Custom | Passed |
| 7. | Should not be able to mint more than initial supply | Custom | Passed |
| 8. | Should update balances of sender and recipient when token transferred | Custom | Passed |
| 9. | Reverts if sender doesn’t holds enough token balance for sending | Custom | Passed |
| 10. | Reverts if spender doesn’t hold enough approval to spend someone’s tokens | Custom | Passed |
| 11. | Functions and state variables visibility should be set explicitly. Visibility levels should be specified consciously. | SWC-100SWC-108 | Passed |
| 12. | Contracts should be deployed with the same compiler version and flags that they have been tested thoroughly. | SWC-101 | Passed |
| 13. | It is recommended to use a recent version of the Solidity compiler. | SWC-102 | Passed |
| 14. | Contracts should be deployed with the same compiler version and flags that they have been tested thoroughly. | SWC-103 | Passed |
| 15. | Ownership takeover should not be possible. All crucial functions should be protected. Users could not affect data that belongs to other users. | CWE-284 | Passed |
| 16. | Race Conditions and Transactions Order Dependency should not be possible. | CWE-114 | Passed |
| 17. | Tokens can be minted only according to rules specified in a whitepaper or any other documentation provided by the customer. | Custom | Passed |
| 18. | Incorrect Inheritance Order which may result in unusual behaviour of smart contract functions | SWC-125 | Passed |
The smart contracts provided by the client for audit purposes have been thoroughly analyzed in compliance with the global best practices till date w.r.t cybersecurity vulnerabilities and issues in smart contract code, the details of which are enclosed in this report.
This report is not an endorsement or indictment of the project or team, and they do not in any way guarantee the security of the particular object in context. This report is not considered, and should not be interpreted as an influence, on the potential economics of the token, its sale or any other aspect of the project.
Crypto assets/tokens are results of the emerging blockchain technology in the domain of decentralized finance and they carry with them high levels of technical risk and uncertainty. No report provides any warranty or representation to any third-Party in any respect, including regarding the bug-free nature of code, the business model or proprietors of any such business model, and the legal compliance of any such business.
No third-party should rely on the reports in any way, including for the purpose of making any decisions to buy or sell any token, product, service or other asset. Specifically, for the avoidance of doubt, this report does not constitute investment advice, is not intended to be relied upon as investment advice, is not an endorsement of this project or team, and it is not a guarantee as to the absolute security of the project.
Smart contracts are deployed and executed on a blockchain. The platform, its programming language, and other software related to the smart contract can have its vulnerabilities that can lead to hacks. The scope of our review is limited to a review of the Solidity code and only the Solidity code we note as being within the scope of our review within this report. The Solidity language itself remains under development and is subject to unknown risks and flaws. The review does not extend to the compiler layer, or any other areas beyond Solidity that could present security risks.
This audit cannot be considered as a sufficient assessment regarding the utility and safety of the code, bug-free status or any other statements of the contract. While we have done our best in conducting the analysis and producing this report, it is important to note that you should not rely on this report only - we recommend proceeding with several independent audits and a public bug bounty program to ensure security of smart contracts.
