Host: Alex, Research Partner at Mint Ventures

Guest: Zhou Yajin, CEO of blockchain security company BlockSec

Recording Date: March 28, 2025

Disclaimer: The content discussed in this podcast does not represent the views of the institutions of the guests, and the projects mentioned do not constitute any investment advice.

BlockSec's Service Scope and Target Clients

Alex: In this episode, we will discuss a topic that is closely related to everyone, which is the security of the crypto world. Before we encounter real risks, we often think we won't become victims of security incidents reported in the news. How to build a firewall for our assets and invest in a secure environment is a prerequisite before we start our crypto journey. In this episode, we have invited Zhou Yajin from the blockchain security company BlockSec to talk to us about crypto security. Please say hello to us, Mr. Zhou.

Zhou Yajin: Hello everyone, I am Zhou Yajin, currently the CEO of BlockSec. I am also a researcher in cyberspace security at Zhejiang University. It's a pleasure to meet you all.

Alex: Alright, let's get into today's main topic. I believe many listeners may not be very familiar with blockchain security companies and security services. Could you please introduce BlockSec to us, what services you provide, and what kind of people or institutions would become your clients?

Zhou Yajin: Sure, BlockSec is a Web3 security company that was founded in 2021 by myself and Professor Wu. When it comes to Web3 security, the first thing that comes to mind is security auditing. In fact, BlockSec's business scope is not limited to security auditing; we also offer a range of other security products and services. Specifically, our services can be divided into three main areas. The first area we refer to as security for on-chain protocols. On-chain protocols are smart contracts deployed on the blockchain for activities such as DeFi or NFTs. How can we ensure the security of these contracts? BlockSec provides security auditing services and security monitoring products. The second area we focus on is asset security. Asset security refers to the assets that users hold, such as those in their contract wallets or invested in on-chain protocols. Ensuring the security of these user assets is also part of BlockSec's service scope. The third area is compliance and regulation. We have noticed that more and more traditional financial institutions are entering the crypto industry. For example, we have recently seen news about traditional banks in the U.S. issuing stablecoin assets on-chain and crypto entering the cross-border payment industry. The entry of these traditional financial institutions into this industry poses a regulatory challenge, as regulators are unsure how to oversee them, and these institutions do not know how to comply. Therefore, we also assist regulatory agencies in overseeing players entering the crypto industry or help traditional institutions entering the crypto space with compliance. This is the overall scope of our business.

Our client base is quite broad. You can think of project parties engaged in decentralized finance or other services on-chain, such as lending platforms or decentralized trading platforms; these project parties are our clients. We can help them conduct security audits before deploying their smart contracts on-chain, reviewing their developed smart contracts for security vulnerabilities. If there are vulnerabilities, they need to be fixed promptly. Additionally, once their protocols are deployed on-chain, we have a 24/7 monitoring platform to monitor their protocol's security risks. If any security risks occur, our platform can promptly notify the protocol and automatically block risks and attacks. Therefore, developers and project parties deploying smart contracts on-chain are one type of typical client for us. The second type of typical client is asset holders, possibly high-net-worth individuals who have assets in contract wallets or invest in on-chain protocols. Our services and products can help them better monitor the security of the protocols they invest in. Like the two sides of a coin, from the perspective of protocol project parties, we can help them improve the security of their protocols. From the perspective of high-net-worth clients investing in their protocols, we can help them monitor the security of the protocols they invest in. If the protocol they invest in has security risks, such as being attacked, they need to be able to withdraw their funds immediately. The third type of client is the regulatory and compliance clients I mentioned earlier, mainly regulatory agencies. For example, the Hong Kong Securities and Futures Commission is also one of our clients, as well as some overseas law enforcement agencies that need to investigate digital currency crimes. They need to use our tools and platforms to facilitate evidence extraction, fund tracing, and other investigative activities. This is basically the overall scope of our business and our client base.

Three Security Recommendations for Crypto

Alex: Understood. Mr. Zhou just talked about the types of clients, their needs, and a general industry situation. The second question may be more relevant to individual investors, especially since many of our listeners are just starting to learn and try investing in Web3. If you have a friend who has just entered the crypto investment field and knows you provide crypto security services, please give him three pieces of advice regarding crypto security. What would those three pieces of advice be?

Zhou Yajin: This is a great question. Friends around me often ask me for security advice; they want to enter this industry but have heard that many people encounter risks. We once joked that if you enter the crypto circle and haven't been phished or scammed, you won't become a seasoned player in this field. Of course, this is a joke, but it does highlight the many risks present in this industry. If I were to give three pieces of advice, the first would definitely be about private key protection. In the crypto field, how to prove you own the funds is essentially by using the private key you possess to prove your ownership of the account. The private key is a string of numbers that is not linked to your personal identity. If this string of numbers is lost or leaked, others can gain control over your funds just like you. This is very different from the real world. In the real world, if your bank password is leaked, you can call the bank to freeze your account, and others cannot withdraw money. However, in the crypto world, if your private key is leaked, the person who has your private key can withdraw your funds from your account without restriction. Generally, there are several ways to protect your private key, such as using hardware wallets, contract wallets, or mobile apps. Each method has its own advantages and disadvantages. Based on my experience and the overall experience of some security friends around me, the basic principle is to write down your private key's mnemonic phrase and store it in a safe, whether that safe is at home or in a bank. Keep it safe and do not move it; you generally won't need it. Then, use a relatively trustworthy device, whether it's a hardware wallet or a phone, to securely store your private key. This phone should be a dedicated device, used only for managing your digital assets. This is the first piece of advice. The second piece of advice is to always have a sense of security and risk awareness when trading on-chain. Essentially, just remember one phrase: "There are no free lunches in the world." We find that users face a significant risk of phishing when trading on-chain. Many well-known KOLs and OGs in the crypto circle have encountered phishing attacks and lost a lot of funds. If an unknown website asks you to connect your wallet to receive so-called airdrop rewards, you need to be very cautious and always have a sense of security awareness. The third piece of advice is that you need to have a basic understanding of crypto asset knowledge. Basic knowledge refers to the concept of authorization in crypto assets, which is different from traditional finance. For example, if you own a type of digital asset, such as USDT or USDC, through on-chain signatures, you can authorize an asset for a contract or another user to use, and this authorization can be achieved by signing a bunch of strange things you don't understand with your wallet. Therefore, when signing wallet signatures, if you don't understand or are deceived into signing an authorization transaction, others can use all your digital assets. So you need to have a basic understanding of authorization to avoid mistakenly signing such transactions. In summary, the basic recommendations are: first, protect your private key and provide some actionable methods; second, always be cautious during on-chain transactions and have security awareness to avoid phishing; third, have a basic understanding of the authorization mechanism in crypto so that you won't mistakenly sign authorization transactions.

Alex: I actually have many high-net-worth friends who are also OGs or veterans in the industry. Logically speaking, they should have some level of the security awareness you mentioned, but every year I hear about some big players getting hacked. There is a saying in the industry that if a professional hacker targets you and knows your wallet has money, if they use all available resources, it is often very difficult to escape. Do you think this saying makes sense? Is it really like that?

Zhou Yajin: This is a very good question. In fact, security issues, especially those involving crypto security, are essentially an unbalanced confrontation. If your wallet has a significant amount of assets, you can easily become a target for directed attacks. Once you become a target, attackers will use a lot of resources, whether social engineering, technical resources, or other means, to design attack methods based on your daily behavior patterns and lifestyle habits. In this situation, it cannot be said to be 100% impossible, but the difficulty of defense is very high because the attacker has used a lot of resources against you, while you only have yourself. So it is a very asymmetric confrontation. In this case, I think the basic principles are: first, as the Chinese saying goes, "wealth should not be revealed," meaning you should not publicly disclose your assets and avoid leaking the relationship between your personal offline identity and your on-chain asset identity. The second point is that even if you are a high-net-worth user and your information may have been leaked, you should try to isolate your assets as much as possible. For example, the assets you use for daily operations should be kept in a dedicated wallet with a maximum of $100,000. If someone targets you, they can only steal this $100,000. Your other significant assets should be kept in a wallet that you generally do not need to use. If you need to use these assets, you should seek help from security experts to review a good operational process and standards to avoid significant risks.

Three Most Memorable Security Incidents

Alex: I understand, this advice is indeed very important. Could you share with us the three most memorable security incidents since you started your career? They can be incidents you personally experienced or those involving friends or things you've witnessed.

Zhou Yajin: I can share with you some security incidents that we have personally participated in and that left a deep impression on me. The first example I remember was around February 10, 2023, when an on-chain protocol called the Duck Protocol was attacked. It is a platform that combines lending with other functions. This protocol had a security vulnerability, and hackers exploited it to steal nearly 9 million USD in assets. What makes this incident particularly memorable is that the hacker made a mistake during the attack on the Duck Protocol. When attacking the smart contract, they needed to develop their own smart contract. A smart contract can be understood as a self-operating piece of code. During the attack, the hacker deployed their own attack contract, which completed the entire attack process. However, attackers are human, and as we all know, humans make mistakes. While writing the attack smart contract, they made an error, and there was a vulnerability in the contract that could be exploited. This vulnerability allowed us to extract the funds stored in the attack contract, which were the funds obtained from attacking the Duck Protocol. As a security company, we are constantly following on-chain attack events, and we have an attack detection engine that can sense these attacks in real-time. Coincidentally, when the Duck Protocol was attacked, we detected it immediately. We independently analyzed the security incident, looking into the reasons for the attack and where the vulnerability lay. At the same time, we contacted the project team to help them, advising them on how to patch the vulnerability and how to handle the situation. During this process, we discovered the hacker's vulnerability and informed the project team that it could be exploited. We then worked with the project team to develop a piece of code that allowed us to extract 2.4 million USD from the attacker's contract out of the total 9.5 million USD. This was the first time in the history of blockchain security that we referred to as "hack back," meaning we used the vulnerability to retrieve the stolen funds and return them to the project team. This was a particularly interesting confrontation, and it left a strong impression on me.

Alex: Did you have a prior partnership with the Duck Protocol, or did you only start communicating after this incident?

Zhou Yajin: We actually had no prior partnership; we only contacted them after this incident. I can elaborate on the entire process of handling security incidents. We have an internal security attack engine, and when a security incident occurs, our engine will immediately trigger an alarm, and our internal emergency response team will analyze it together. First, we look at which protocol was attacked, and then we try to contact the project team through various means, whether it's on-chain Twitter or other methods. In the case of the Duck Protocol, we did not have their contact information beforehand. We reached out to the project team via Twitter and assisted them in analyzing the reasons for the attack because many times the project team does not know why they were attacked; they just know that the money in the protocol has disappeared but cannot figure out the reason. This is when a security company needs to assist in the analysis. After the analysis, it involves how to fix the protocol. If the reason is clear, then the vulnerability needs to be patched, and we need to ensure that it is secure after the patch, as well as track the stolen funds, which also requires the assistance of a security company like ours. We will work with the project team throughout the entire emergency response process. Specifically for this case, we had not contacted the project before, but fortunately, during the handling process, we were able to contact them in a timely manner and recover part of the funds. In fact, more cases involve us discovering an attack but being unable to contact the project team.

The second case is also quite interesting, and it occurred in 2023 as well. Our Chinese listeners may be more familiar with this case because it involves a project called ParaSpace. ParaSpace allows users to stake Bored Ape NFTs and borrow other assets. I know that many Chinese OGs are actually holders of Bored Ape NFTs. This protocol had a security vulnerability and was attacked in March 2023. I clearly remember it was around morning or noon Beijing time. After our system issued an early warning, we first contacted the project team to analyze the cause. However, we found that the first attack transaction reported by our system was reverted on-chain, meaning that the attacker did not have enough gas fees, which caused the attack transaction to fail when it was submitted to the blockchain. However, the attack behavior and trace were already exposed on-chain. Our system can also detect what we call "reverse" transactions, which are failed transactions that still appear on-chain. This is the capability of our engine, which can determine that this is an attack transaction. After identifying it, we thought of a way to simulate the attack transaction behavior and automatically generate a similar attack transaction, but this attack is in quotes; we need to replace the profit address in the transaction with our address. In this way, we could rescue the funds that were currently in danger from the protocol and transfer them to our secure account, then contact the project team to return the funds to them. This is similar to saying that the bad guy's knife is about to strike down, but for some reason, the first attempt did not succeed. We could also try to use the same method to withdraw the funds in advance, so that when the attacker attempts to attack again, there would be no funds left in the protocol, and the attack would fail. After coming up with this idea, we actually have an internal system that allows us to quickly automate this process, and we automatically generated an "attack" transaction, submitted it to the blockchain, and withdrew 5 million USD in assets from the ParaSpace protocol, then contacted the project team to return the funds to them. This was also very interesting and marked the highest amount we refer to as a "rescue," which is an action to save on-chain funds. Without this rescue, their assets might have been completely looted.

However, this security incident also triggered a lot of our reflections because there are many ethical and moral issues involved. For example, we observed an attack, and although we withdrew the funds from the protocol, this was essentially still an attack transaction. We simulated the attacker's behavior, and although it was done with good intentions to withdraw the funds and return them to the project team, it is still technically an attack behavior. This raises compliance and security ethics issues. Our thought process at the time was whether we should intervene when we see a bad person trying to stab a good person or let it develop. I think we chose to intervene, although there are some moral and ethical issues involved. After this incident, we deeply realized that on-chain security cannot rely on the "hack back" method we just discussed to rescue funds. The project team should be informed of the security risks they face as soon as possible; they need to know that their project is under attack, and they can configure some automated operational strategies. When these security incidents occur, our system should inform them so that they can automatically pause the protocol, preventing the attack from succeeding. This way, we can stop the attack, save users' funds, and avoid any ethical risks. This is the entire thought process behind the development of our subsequent Phalcon attack monitoring and blocking product after these two incidents. This is the second significant security incident that stands out in my memory.

Alex: I think I noticed this security incident at the time. You just mentioned protective attacks, and I want to ask a detail: after the revert attack occurred, you must have needed an internal discussion and decision to determine whether to carry out a protective attack. How much time elapsed from discovering this incident to making the decision to protect the funds?

Zhou Yajin: Very quickly. From the moment we became aware of it to the completion of the action took about just a few minutes. The company has already established a very comprehensive security handling process, so once we know about a security incident, we immediately discuss and make decisions. After the decision is made, we have some automated tools, so we can quickly execute the action.

Alex: Understood.

Zhou Yajin: The third case is the Bybit security incident that everyone should have noticed recently, where 1.5 billion USD in assets were stolen in February. This attack is the largest single security incident loss in the security circle to date, and its loss is very different from the two security incidents I mentioned earlier. The first two incidents were caused by contract vulnerabilities, but the Bybit security incident had nothing to do with smart contract vulnerabilities; we refer to it as a long trust chain. In a system with such a large amount of funds and a long trust chain, the attacker found the weakest link through social engineering attacks and completed the attack. Specifically, Bybit used a contract wallet called SAFE, which is a smart contract wallet for managing its assets. SAFE is a multi-signature wallet, which you can think of as a lock that requires three people to open simultaneously in order to access the funds inside. This lock is provided by a project that offers such a contract wallet. You will find that in this system, the trust chain is very long, involving the developers of the SAFE wallet, the operators of the SAFE protocol, and the users who interact with the SAFE wallet through the UI in their browsers, as well as the operators of the SAFE wallet, which are the Bybit employees who hold the three keys or have the authority to operate the funds. You can see that there are many aspects involved here. When we talk about security, the particularly difficult point in security offense and defense is that during defense, you must ensure that your system has no weaknesses because the security level of the system is determined by the shortest board within it. Attackers do not need to break into the well-protected areas of your system; they only need to find the weakest point in your system and launch an attack through that point to complete the entire process. In the Bybit case, the entire attack process was as follows: they likely discovered that this was a targeted attack because they found that the Bybit SAFE wallet, which is the smart contract wallet, contained a significant amount of assets. Their chosen target was the developers of the SAFE wallet because, as we mentioned earlier, anyone who operates must go through the UI provided by SAFE, which is its website, to manage their assets. If I can use social engineering or other means to compromise the developer's computer and have the developer deploy malicious code on the SAFE website, then when anyone goes to the SAFE website to operate their wallet, the actions they see will not match the actual on-chain actions, but normal users will not understand this. For example, when a normal user operates in a bank's app and sees a transfer of 100 yuan, in reality, 900 yuan is being transferred out, but they do not know this because they see a transfer of 100 yuan in the app. If you can compromise the app developer or the SAFE wallet developer, causing the operators to see an interface in the wallet that does not match the actual behavior rules, you can complete the entire attack process. This is how it was accomplished. So how did they gain access to the developer's permissions? Through some social engineering attacks, they ultimately completed the entire attack process. Even when the SAFE developer was compromised, we still had other opportunities. For example, if your wallet could inform you of the signed transaction during the signing process and it was inconsistent with what you saw on the website, there would still be an opportunity. Many banks used to have U-shields, and if you have experience, you will notice that when you press a button on the U-shield, there is a display screen that tells you that you are transferring 500 yuan, and you must confirm or not confirm. You can confirm on the U-shield device. This actually solves the problem because even if my app is compromised, and the app tells you that you transferred 100 yuan, the U-shield will inform you that you transferred 500 yuan when you go to confirm, and you will notice the inconsistency. Specifically in the Bybit case, if the wallet you signed with had such a good reminder capability, it could also prevent such attacks. Unfortunately, in this case, the signing hardware wallet was not particularly well designed. After the SAFE UI was compromised, a malicious upgrade transaction was signed, and the attacker took over the wallet and transferred away 1.5 billion USD. So this is a particularly memorable incident. The insight this incident brings us is that when dealing with large amounts of funds, cross-validation must be done. You cannot trust a single provider or a single point of information. If you rely on a single supplier or a single interface to provide you with information, as long as that is compromised, the system link is lost. Therefore, cross-validation must be done, and there must be a third party to help you verify whether what you see is true. In such cases, the risk can be further reduced.

Personal Experience with Social Engineering Attacks

Alex: You just mentioned a term called "social engineering attack," which not all listeners may understand. Could you explain it?

Zhou Yajin: Social engineering attacks, fully known as social engineering attacks, do not utilize technical means but rather exploit your work habits, interpersonal relationships, and the responsibilities you bear, targeting you with a set of designed attack methods. I can give an example of a social engineering attack that I personally experienced, which will make it easier for everyone to understand. As the CEO of BlockSeo, I often receive various messages, mainly two types: the first type is invitations to participate in podcasts, conferences, and interviews. The second type is from investment institutions that contact you about investment opportunities. I encountered one where someone emailed me from a company email claiming to be from a certain investment institution, hoping to discuss some investment opportunities. Our security sense is quite strong, so we observe their email and domain, and sometimes conduct background checks to look at their company website and investment profile. After doing the background check, I found that it was a fairly legitimate-looking institution, even though I had never heard of it, and I scheduled a meeting with them on Calendar. However, at this point, the first strange phenomenon occurred: when scheduling the meeting on Calendar, they did not provide any meeting link. Normally, when we schedule a meeting, we connect via Zoom, Google Meet, or other meeting software. But they did not provide any meeting link; they just scheduled a time. When it was time for the meeting, I emailed them saying we were about to meet and asked them to send me the meeting link. They immediately sent me a meeting link, and when I clicked on it, I found it strange that they required me to download a software. If you lack experience and feel anxious about the upcoming meeting, they exploit your anxiety by bombarding you with emails. Eager to seize this opportunity, you might install the software without hesitation, but it is actually a malicious video conferencing tool that will steal your private keys stored on your computer. This is a social engineering attack I have personally experienced. You can see that the attacker targeted my position in the company and my responsibilities, using my anxiety before the meeting to launch the attack.

Alex: I saw that there was a notable incident in the industry a couple of days ago, where the founder of a certain protocol said that during an offline gathering, his phone was away from him for about ten minutes, and several million in funds from his phone wallet were stolen. If this attack occurred while his phone was away, would this also be considered a type of social engineering attack?

Zhou Yajin: Yes, I think it falls under social engineering attacks, but it is not quite the typical social engineering attack we usually refer to. In this case, his phone was just away from him for a while; of course, someone might have invited him or approached him primarily to get his phone, but after obtaining the phone, how to unlock it and access the funds inside actually requires strong technical support.

Security Principles When Interacting with Blockchain Protocols

Alex: Understood. We have discussed many representative major security incidents. Now, returning to the ordinary person interacting with blockchain protocols, as you mentioned, many of the projects you previously served were DeFi protocols, and many of us interact with DeFi protocols on-chain. When we interact with these DeFi protocols or other protocols, are there any security principles we need to follow? I believe most ordinary users do not have the ability to read code, and they may not even have the ability to read signature information. In this case, how can we minimize such risks?

Zhou Yajin: I think ordinary users, when engaging in on-chain transactions, should first conduct some background checks on the project parties, which I believe is quite important. If you are investing in an on-chain project with a small amount of funds and a trial-and-error attitude, that might be fine. However, if you are seriously saying that you are an investor looking to invest in an on-chain protocol, given that your capital is relatively large, you may need to conduct thorough due diligence on the project party. This due diligence can be divided into several levels. The first level is to identify who the founders of the project are and whether they are anonymous, as some on-chain protocols are anonymous projects. You need to know the quality of this protocol and who the public-facing founders are, as well as whether they have a history of rug pulls, which is very important. In other words, you should first conduct some background checks on the composition of the protocol and the identity of the founders. The second point is that you need to conduct some background checks on the technical capabilities of the project party. You can check whether the project has been audited by reputable security companies. As you mentioned earlier, many users may not understand technology or code and may not be able to read audit reports, but you can download the audit report and simply review some key points. For example, which auditing firms conducted the audits, what their reputations are, and whether there are any critical security vulnerabilities mentioned in the report. It is not necessarily the case that if the report finds critical security vulnerabilities, the protocol is unsafe; rather, it indicates that the security company is diligent and has identified some vulnerabilities, which can reduce the overall security risk for the project party. This should be viewed dialectically. After conducting background checks on the project party, you should also adopt a gradual approach when interacting with the protocol; do not invest a large amount of funds all at once, as this carries a higher risk. Additionally, you should utilize some professional security tools, such as attack monitoring tools and platforms. If your capital is relatively large, you need to constantly monitor the security risks of the protocols you are investing in. You can use platforms like our Phalcon platform to monitor the overall security of the protocols you are investing in. For users with smaller amounts of capital, I believe the main risk to guard against when conducting on-chain transactions is phishing. After all, the probability of a protocol being attacked is relatively low, but risks such as on-chain phishing and authorization are indeed something ordinary users may encounter at any time. To mitigate these risks, you should not be too greedy; there is no such thing as a free lunch. When interacting, try to confirm that you are on the official website and not a counterfeit one. As for how to confirm that it is the official website, it may still require some ability to collect and organize information. Of course, you can also use some security tools to identify phishing websites. This way, you can avoid some risks.

Alex: I noticed an incident where Binance delisted many project tokens, stating that their operational capabilities did not meet standards, so Binance removed them. The project parties then said that due to various issues, the project would no longer be operated and was in a semi-abandoned state. Now, suppose a user used a DeFi protocol one or two years ago, and currently, there is no one managing the project, and the code upgrade permissions are unknown. In such specific cases, could the lack of proper management of their upgrade permissions lead to hackers or malicious individuals gaining control, thereby threatening the funds in the user's wallet if their previous authorizations were not revoked?

Zhou Yajin: Yes, that is indeed possible. Especially as you mentioned, if a user has authorized their funds to some protocols, and those protocols and smart contracts are no longer maintained, if that authorization is not revoked, there could indeed be security risks. The solution to this issue is that we always recommend ordinary users to regularly review their authorizations. You can revoke those authorizations that you are not using. Many users may not be aware of which project parties they have already authorized. We have developed a tool called the Authorization Diagnosis Tool; you input an address, and we can tell you which protocols that address has authorized. We found that many users have authorized dozens of protocols, many of which are no longer active, and inactive protocols without security upgrades may have security vulnerabilities. As long as there are security vulnerabilities, others can exploit the vulnerabilities of the authorized protocols to steal your funds, which is indeed a significant risk.

Alex: Understood. Regarding interaction security, I have another question. In the past, we have seen that some attacked DeFi protocols, as well as other protocols, have shown that the number of hacks or attacks on DEXs is relatively lower compared to lending or staking protocols. Is this related to the types of smart contracts of these two categories of protocols, or are there other reasons?

Zhou Yajin: You are correct. Relatively speaking, the security risks of DEXs are lower than those of other lending, yield farming, and some financial derivative protocols. This is primarily because DEX protocols are relatively simple; the protocols in on-chain DEXs are based on the constant product formula, such as xy=k. Of course, Uniswap V3 is slightly different, but the core principle is still the constant product formula. First, the protocol is simple, and secondly, there is a very good reference model, which is Uniswap; many DEXs are forks of Uniswap, so they only need to make simple modifications to deploy an on-chain DEX. Therefore, the overall security risk exposure is relatively lower. However, for lending, yield farming, or other leveraged lending protocols with more complex functions, the design of the protocols themselves is more complicated. For example, when creating a lending platform, it may sound simple: I deposit asset A and borrow asset B, and as long as I manage the overall health of the assets, it should be fine. However, if you need to support various types of collateral assets and their price fluctuations, and if you want to support leverage, you must ensure that users can repay their loans while maintaining overall health. The complexity of the protocol design leads to a higher probability of these protocols being attacked. I think that is the first reason. The second reason is that DEXs do not hold funds; the funds in DEXs are provided by liquidity providers, meaning the liquidity is provided by users. When you use a DEX, you simply swap tokens; you put in token A, and immediately receive token B, so your assets are not actually in the DEX's pool. Even if the DEX's pool is attacked, most users will not suffer losses; the losses will be borne by those providing liquidity. In contrast, on lending platforms and other platforms, your assets are actually held there, and you are over-collateralized. If you are using other more complex protocols, they inherently retain a lot of user assets, and when they are attacked, the affected user base will also be relatively large. I think that is the second reason.

We have also observed that historically, DEXs have not been immune to attacks. The reasons for their attacks are relatively simple. First, the risk exposure of DEXs lies in authorizations, as you need to authorize your tokens to the DEX's routing contract when swapping. Although the routing contract does not hold funds, if there are any vulnerabilities that allow arbitrary execution within the routing contract, it could potentially drain the funds of all users who have authorized the DEX. We found that the major losses caused by vulnerabilities in DEXs are primarily of this type, but such vulnerabilities are relatively easy to detect. As long as a competent auditor is involved, they can usually identify these issues quite easily.

Alex: So in the case of the authorization vulnerability you just mentioned, if an auditing company discovers that a DEX has arbitrary execution permissions, they would generally advise that this is unreasonable or remind everyone of this issue in their report?

Zhou Yajin: Yes, this would definitely be a vulnerability and would be considered unreasonable. If a security company audits it, they must have this fixed, as it is a very critical vulnerability.

Current Status and Potential of the Blockchain Security Industry

Alex: OK, we have discussed many specific issues regarding security offense and defense, as well as how to protect personal asset security. Now, let's talk about the last question of the day regarding the blockchain security industry. As you mentioned, in 2021 and 2022, due to the boom in DeFi, the customer base of the blockchain security industry was very large. What is the current scale of the security industry as of this year, and what is its development status and profit level?

Zhou Yajin: This is a great question because in the blockchain security industry, you need to constantly understand the current stage of the industry and where the ceiling is in order to better develop your company. Currently, there is no recognized data indicating the market cap of the entire blockchain security industry. However, there are some reports online, or they have made their own estimates, suggesting that the overall scale of the blockchain security industry is around 3 billion USD per year. This scale is relatively small compared to the traditional cybersecurity industry. For example, in 2024, the entire traditional cybersecurity market is expected to be around 100 billion USD. Comparing 100 billion USD to 3 billion USD shows a significant gap. I believe this is related to the current development status of the entire industry, as blockchain security essentially serves as a security product and service for the blockchain industry, which is still in its early stages. For instance, a relatively prosperous period was during the DeFi Summer when some new innovations emerged. In the past year or two, after the financial innovation boom of DeFi Summer, it seems that there has not been anything particularly innovative coming in, leading to a bottleneck in the overall scale of the blockchain industry. I remember that during its peak in 2022, the total value locked (TVL) in blockchain security reached its highest level of around 177 billion USD, which is over 100 billion USD. However, before participating in this program, I checked the data, and the current total TVL is 99 billion USD, meaning it is just over half of its peak, indicating that the development of our blockchain industry seems to have encountered a bottleneck.

However, at the same time, we have also discovered new potential in this industry, which is that traditional financial institutions are slowly entering this sector. There are some signals indicating the entry of traditional financial institutions, such as traditional banks issuing stablecoins on-chain in compliance with regulations. Traditional payment providers like Stripe are supporting crypto payments. Some cross-border payments are using crypto to solve the payment issues faced by traditional cross-border e-commerce. Therefore, we find that although there hasn't been innovation like that during the DeFi Summer of 2021 and 2022 that led to new highs in TVL, traditional financial institutions and merchants with real scenario needs are entering this industry. Their entry will bring about the compliance of the entire industry. For an industry to grow significantly, it must develop in compliance with regulatory frameworks and systems. I believe this is an opportunity we can see in the past year or two. Overall, the blockchain security industry is still relatively small and in its early stages. However, with the entry of traditional financial institutions and increasing regulation and compliance, I believe there is significant potential for growth, which is my observation.

The Moat of Leading Security Companies

Alex: Alright. I have a strong impression that during 2021 and 2022, blockchain security companies, especially those doing smart contract audits, were very profitable. It even felt like some well-known security companies would prioritize your audit if you could get in line faster. What do you think are the main moats of those leading security companies?

Zhou Yajin: I think there are a few points. The first point is brand and trust. Especially in security auditing, it is a service that requires a strong brand recognition. As you mentioned, during the better market conditions, audits were in high demand, and there could be long wait times. In fact, today, leading security auditing companies are still in this situation; it’s not that a project can just come in for an audit and immediately have resources available. Leading security companies with brand effects are still in a state of supply not meeting demand. Therefore, I believe one moat is the brand and trust—how to establish a good brand image in the blockchain security industry and the trust that comes with that brand, whether that trust comes from users, project parties, or other participants, is very important. The second point is the need for innovative security technologies. Besides solving blockchain security issues and providing security audits, are there really no other supplementary solutions needed? Security audits can only address the security review of a project's smart contract before it is deployed on-chain. However, once the project is live, the project party may change parameters or make daily configurations and upgrades without conducting audits due to queuing or cost considerations, leading to many security issues after the smart contract is deployed for various reasons. We cannot rely solely on security audits to solve these problems; we need some innovative security technologies and products to address these issues. This is also what I think sets BlockSec apart from other blockchain security firms. In addition to providing security audit services for smart contracts before protocol launch, we also have a platform that can monitor and block attacks on smart contracts after they go live. This is the only blockchain security company globally that combines smart auditing and attack monitoring, covering the entire lifecycle of smart contracts. This is very important; you need to have innovative security technologies and products that can help users truly solve problems in this market. The third point is compliance, regulation, and the impact of geopolitical factors. The crypto industry will ultimately need to develop under compliance and regulation to have the potential for large-scale growth opportunities. This viewpoint is not universally accepted, but after spending many years in this industry, we can see that for the industry to develop, it must be in the sunlight, under a framework of compliance and regulation, to attract traditional capital into this sector. In this context, it is essential to prepare compliance and regulatory products and services in advance. Compliance and regulatory products and services require a deep understanding of the regulatory policies and compliance requirements of this industry, which can then be transformed into product offerings. Additionally, the so-called impact of geopolitical factors means that when some regions choose suppliers, there are indeed geopolitical considerations. For example, regulatory agencies in Hong Kong may prefer products from non-U.S. suppliers. Therefore, when you have a deep understanding of regulatory policies and compliance, along with good products, and can also consider geopolitical influences, I believe this constitutes the moat for blockchain security companies.

Alex: Understood. Today, we have discussed many dimensions of crypto security, from specific security incidents to principles that everyone needs to pay attention to regarding security, as well as the overall development scale of the industry, among other topics. Thank you very much, Zhou Yajin, for joining our program today to share these insights. I hope we can have more opportunities to discuss related topics in the future.

Zhou Yajin: Thank you, Alex.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。