The recent series of security incidents has once again brought the digital asset industry back to a familiar question: What truly constitutes 'security' for a platform?
In early September, a major security incident occurred on the Bitcoin sidechain Liquid Network. Attackers exploited a validation vulnerability in the Elements software, leading to the transfer of approximately 4,000 BTC, worth around $320 million at the time of the incident. Notably, the related PAK and Federation keys themselves were not compromised. This brings to light a more worthy question for discussion: When the keys themselves are not breached, how can an asset transfer that should never have happened still pass through the system?
Similar risks have also emerged in other areas. In August, attackers exploited a critical security vulnerability in Cosmos EVM to attack multiple networks, with six networks actually exploited. The related vulnerability had previously been reported through a bug bounty program. In July, Triple-A fell victim to a social engineering attack where attackers obtained personnel credentials and further accessed the operational environment, ultimately resulting in the transfer of some company-owned assets. However, as client funds were independently stored in trust accounts and isolated from the compromised operational environment, they were not affected.
The causes of these three incidents are different, yet they collectively point to a more realistic issue: Security incidents may be difficult to completely avoid, but when a single link in the code, personnel, or permissions chain is breached, where exactly will the risk stop?
The real thing to guard against is not just 'being breached,' but how far the risk can go.
A more pertinent question than 'whether there was an attack' is: After the first line of defense fails, how much further can the attacker go? If one account is compromised, is that sufficient to perform critical asset operations? If one permission is breached, can they continue to access more core systems? When issues arise in the online environment, how much core asset is truly exposed in the attack path?
This is also a key insight from the recent incidents: The ultimate impact of an attack depends not only on what the attacker breached, but also on how many layers of defense remain in the system after the breach.
If the compromise of a single account can directly access core permissions, or if a problem in the online environment can directly affect a large amount of core assets, then any weak link can be rapidly amplified. Conversely, if there are multiple layers of isolation between permissions, critical operations, risk monitoring, and asset storage, a single breach may not necessarily escalate into a total compromise.
In other words, measuring a platform's security capability is not just about 'whether the first door can be held,' but also about: after the first door is breached, how many doors are left behind it.
Following the attack chain, where are BIT's 'next doors'?
Recently, the global digital financial services platform BIT (formerly Matrixport) released the "BIT Trust Whitepaper" V2.0 (https://www.bit.com/whitepaper). If we re-examine this whitepaper along the question of 'what happens after the first line of defense fails,' one noteworthy aspect is that BIT's security system does not rely on any single line of defense. Instead, it establishes multiple layers of protection between identity, permissions, operations, and assets.
For example, obtaining account credentials does not mean an attacker has all the permissions needed to complete critical asset operations. The whitepaper discloses that BIT limits the systems and operations employees can access based on the principle of least privilege; critical operations involving asset transfers, account security, permission changes, and the generation and approval of transaction instructions require the participation of at least two authorized personnel. This layered approach also extends to institutional-grade digital asset custody scenarios, as exemplified by Cactus Custody.
Successfully passing identity verification does not mean subsequent operations get a continuous 'green light.' BIT conducts ongoing monitoring for behaviors such as abnormal logins, abnormal devices, and abnormal withdrawals. On the asset side, the majority of digital assets are stored in cold wallets, further reducing the exposure of core assets when issues arise in the online environment.
Looking at these mechanisms together, BIT's security logic becomes more intuitive: a compromised identity does not equal obtaining all permissions; obtaining one permission does not equal the ability to independently complete critical operations; passing identity verification does not mean subsequent behaviors are no longer subject to risk assessment; and problems in the online environment do not mean all core assets are simultaneously exposed.
What truly determines how far an attack can ultimately go are precisely these 'does not equal' conditions. This does not mean any attack can be completely avoided, but it does mean that even if one line of defense is breached, there are still opportunities to detect anomalies, restrict permissions, or isolate risks.
The gap in security often lies in what happens after the first door is breached.
When risk is discovered, who has the real authority to press the 'stop button'?
However, having a few more technical lines of defense is not everything. In the Cosmos EVM incident, a noteworthy detail is that the related vulnerability had been reported through a bug bounty program, but based on the information available at the time, it was initially assessed as not leading to the loss of funds in known production network configurations.
This also exposes another often-overlooked issue: Discovering a risk does not mean it has been accurately assessed and adequately addressed.
After a vulnerability is submitted, who determines its severity? If the security team deems the risk unacceptable, do they have the authority to prevent the product from going live? When business progress conflicts with security judgment, who has the final say?
The "BIT Trust Whitepaper" V2.0 discloses that when product plans, requirements, architecture, or launch changes pose significant security risks or do not meet security baselines and compliance requirements, the security team holds a 'one-vote veto' right. They can suspend related activities and require rectification and re-review before proceeding.
The truly noteworthy aspect of this mechanism is not just an additional layer of approval, but that it answers a very practical question: When risk truly emerges, is there someone with the authority to say 'no.' For a security system, the ability to discover problems is important, but ensuring that security judgments can genuinely influence business decisions is equally crucial in determining whether a line of defense is merely written in policy or can truly function effectively.
As business becomes more complex, 'security' is no longer just about assets in a wallet.
As digital financial platforms begin to simultaneously connect different types of assets and financial infrastructure, such as digital assets, U.S. stocks, and RWAs, security issues also extend beyond the wallet and account levels. Who handles the assets, which institutions they pass through, and where they are cleared and held also become important parts of users' risk assessment.
This is also where the "BIT Trust Whitepaper" V2.0 further elaborates on the security and trust system. Beyond risk control and security measures, the whitepaper also discloses the regulatory, audit, and independent verification arrangements corresponding to different business entities. This allows external parties to better assess: who is responsible for what, which mechanisms can be verified, and to what extent these mechanisms cover.
Taking BIT's U.S. stock business as an example, its securities business is operated by Matrix Gelephu Pte. Ltd. and is regulated by the GFSO. The related business also connects to U.S. licensed financial institutions and corresponding clearing and custody infrastructure.
For ordinary users, these seemingly complex financial arrangements can ultimately be boiled down to a few simple questions: Who handles my assets? Through which steps? What are the respective responsibilities of the different institutions? Can the identities and regulatory statuses of these institutions be checked?
This is where 'verifiability' truly becomes meaningful—security cannot rely solely on what a platform claims; it also depends on what users and the outside world can verify.
Looking back at the Liquid Network, Cosmos EVM, and Triple-A incidents, the entry points are completely different, yet they all remind the market: No single line of defense should be assumed to never fail. What truly creates a gap in security may not be a single security technology itself, but who can establish sufficient isolation and checks and balances between identity, permissions, operations, assets, and organizational decision-making, making it harder for a local breach to escalate into a total compromise.
From this perspective, what is noteworthy about the "BIT Trust Whitepaper" V2.0 is not just how many security measures it lists, but whether these measures can form a complete defense system: if one link fails, there is another layer; if the next layer fails, there is still an opportunity to continue identifying, blocking, and isolating risks.
For digital asset platforms, 'never being attacked' may be a difficult promise to make permanently. But another thing can be continuously built: True security is ensuring that even if one line of defense fails, a single breach does not easily escalate into a total compromise. And when these lines of defense not only exist but can also be continuously verified by the outside world, 'trust' is no longer just a statement made by the platform itself.
