Cross-Chain Bridge Security — How We Protect Against Hacks

Bridges have become a popular target for hackers since they usually require tokens (that should be bridged into another network) to be locked in one, or several, of their smart contracts. We have all seen how other bridges in the industry have been hacked and millions in funds stolen.

Most crypto bridges work with a minter/burn functionality, where projects must partner and grant the bridge a minter role of their token to provide bridging services. As a result, projects are exposed to a high risk of hackers minting an unlimited amount of their tokens and making them unusable. The Cross-Chain Bridge tackles this risk by using liquidity pools.

Learn more about the Cross-Chain Bridge’s security practices to protect its Pools from hackers below.

Current Procedures:

• Follow established coding best practices, use well-proven code patterns & contract templates, and learn from mistakes others made before you.
• Very high coverage with unit testing and additional cross-chain integration testing to ensure our contracts work as intended.
• Allowing the smart contract code to be audited by a respected audit company. These auditors check code for vulnerabilities for a living. See the results of our latest Audits by Chainsulting & Haechi.
• We are aware that upgradeable contracts are also an attack vector. At this stage, upgradeable contracts make sense, but we are working towards phasing them out once the core is closer to completion. Currently, only a GnosisSafe is granted to perform an upgrade, and only a few members are whitelisted for the multi-signatures. The next step will be to make use of TimelockController for delayed deployments. The goal is to avoid upgrades in the future. Ultimately, the plan is to hand over power to a DAO.
• Creating a “bug bounty program.” This means simply offering a financial reward for white hats, i.e., “friendly” hackers, to find bugs in our code. If they find something potentially threatening, they get paid for their work.
• Getting experts & developers of partner companies to check our code. Working for long periods on the same codebase makes it easier to miss errors, and having external parties look specifically for mistakes makes sense.
• Researching new & upcoming hacks, understand how they manage to bypass security & verify our code against these attack vectors. Would the hacker have been able to evade our security using the same approach?
• Researching new security measures, such as monitoring of smart contracts & automatic tasks/transactions that can be executed before defined events occur in our smart contract.

There are also additional measures that we are not disclosing publicly to maintain a second line of defence if a hacker manages to bypass these first layers of protection. “Imagine us as an old castle (the bridge contracts), surrounded by several walls and a moat (the points/procedures listed above). Now, the black hat may have a plan of the castle (the code) & they may make it over the moat. But what happens after climbing over the wall is our secret, and we intend to keep it that way.” Daniel Bläcker, Smart Contract Developer at Cross-Chain Bridge.

The best results are achieved when many smart people work together. We, therefore, strongly encourage our investors & users with developer experience/knowledge to review our codebase here. We will reward you with BRIDGE if you find something that significantly improves our protocol! Please let us know if you see any potential for improvement.

In conclusion, our bridging protocol technology is robust and focused on user security. Due to the nature of the DeFi world, we are prepared as best we can against different attack scenarios and take protecting the Bridge very seriously. This is key to connecting the largest blockchains and offering the best experience in a multichain world. Join our community in Discord and tell us what you think!

Did you like this article? Let us know, hold the clap button and & give us up to 50 claps.

Cross-Chain Bridge | Discord Community | Twitter | FAQs & Tutorials