How does Tixl secure its Cross-Chain Bridge v2.0?

Bridges became 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. In today’s Tixl Explained Series, we decided to explain a bit, how we are securing our Cross-Chain Bridge v2.0.

This is what we did and constantly do:

1. Following established coding best practices, use well-proven code patterns & contract templates and learning from mistakes that others did before you.
2. Employing 100% unit test coverage and additional cross-chain-based integration tests that verify that our contracts work as we intended.
3. Letting the smart contract code get audited by a respected audit company. These auditors check code for vulnerabilities for a living.
4. Making your contracts upgradeable. While smart contracts are actually famous for being immutable, this can sometimes bring more problems than pleasure. Imagine all your coins are locked in a contract that had an error in the code & now you can never access it again. It is highly recommended to offer ways to upgrade your codebase. We are all learning a lot every day in the crypto space and this needs to be reflected in our contracts, too.
5. Creating a “bug bounty program”. This is nothing more than offering a financial reward for white hats (=non-malicious hackers) to find bugs in your code. If they find something that is a potential threat, they will get paid for their work.
6. Asking peers, experts & developers of partner companies to check your code. After having spent a few weeks or months working on the same codebase, you can sometimes get blind for very obvious errors.
7. Researching new & upcoming hacks, understand how they managed to bypass security & verify your code against these attack vectors. Would the hacker have been able to bypass your security with the same approach?
8. Researching new security measures, such as monitoring of smart contracts & automatic tasks/transactions that can be executed if prior defined events occur in your smart contract.

There are also some additional measures that we are not disclosing publicly just to maintain a little surprise if a black hat (a hacker) manages to bypass these first layers.

The best results are usually achieved when a lot of smart people work together. We therefore strongly encourage our investors & users with developer experience/knowledge to review our codebase once it’s open sourced. Please let us know if you see any potential for improvement. We will reward you with TXL if you find something that will significantly improve our protocol!

“Imagine us as an old castle (=the bridge contracts), surrounded by several walls and a moat (= the points listed above). Now, the black hat may have a plot of the castle (=the code) & maybe he/she will make it over the moat. But what happens after climbing over the wall, that is our secret, and we intend that it stays that way.”

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

Tixl Ecosystem

Website | Autobahn Network | Cross-Chain Bridge | Tixl Wallet

Follow Tixl

Twitter | Telegram | Medium | Reddit | YouTube | Discord | LinkedIn | Telegram Announcement Channel