When "security" becomes the focus once again, how does BIT make trust verifiable?

Recently, a series of security incidents have struck the digital asset industry in quick succession, with multiple attacks and thefts of funds once again pushing platform security to the center of market attention. As attack methods continue to evolve, risk is no longer confined to a single wallet or technical vulnerability, but may involve multiple links including account permissions, private key management, asset transfers, and third-party infrastructure.

For users, a more practical question than "is the platform secure" is: when an anomaly actually occurs, can the platform detect and block the risk earlier? Do key operations have sufficient authorization and checks and balances? As assets further extend to U.S. equities, RWA, and other categories, can the security and risk control systems keep pace with new business boundaries?

Against this backdrop, global digital financial services platform BIT (formerly Matrixport) has officially released the "BIT Trust Whitepaper" V2.0. Centered on security, compliance, transparency, and verifiability, it systematically presents BIT's current risk governance, security architecture, regulatory compliance, and independent verification mechanisms, and further covers regulatory, governance, and transparency arrangements across different business scenarios including U.S. equities, RWA, and asset management.

When a platform carries more and more assets and businesses, how can security and trust scale in tandem?

Before risk actually materializes, what can a platform do?

No platform can eliminate all risk with a single phrase like "secure." For users, what is more worth paying attention to is: is there a line of defense before risk emerges, and is there a mechanism to promptly identify and contain risk when an anomaly occurs?

In the whitepaper, BIT emphasizes that risk management is not merely post-event remediation, but should run through pre-trade assessment, in-trade monitoring, and post-trade handling. In specific business scenarios such as margin financing and collateral, this mechanism is further implemented across due diligence, risk parameter setting, real-time monitoring, risk alerts, and default and liquidation procedures.

These mechanisms ultimately land on the account and asset security that users can more readily perceive. For example, BIT conducts 24-hour dynamic monitoring of high-risk behaviors such as abnormal logins, abnormal devices, and abnormal withdrawals, and triggers alerts, delayed processing, or manual review based on risk levels. What a security system should do is not just "discover after the fact what happened," but identify risk and intervene in a timely manner during the course of an anomaly.

At the level of digital asset protection, most assets are stored in cold wallets; private keys are stored in FIPS 140-3 Level 3 hardware security modules (HSMs) and cannot be accessed or exported in plaintext.

But more critical than technical tools is the question: when business advancement conflicts with security requirements, who has the authority to say "no"?

According to the whitepaper, if a product plan, system architecture, or launch change poses a major security risk, or fails to meet security baselines and compliance requirements, the BIT security team holds a "veto power"; for key operations such as asset transfers, permission changes, and trading instructions, the "four-eyes principle" is applied, requiring at least two authorized personnel to participate jointly.

The logic behind this mechanism is not to promise that risk "will not happen," but to place security ahead of risk as much as possible—identifying anomalies earlier, establishing constraints earlier, and minimizing the impact of single points of failure as much as possible.

From digital assets to U.S. equities, how does security keep pace with new business boundaries?

When business extends from digital assets to areas such as U.S. equities, RWA, and asset management, the meaning of "security" also changes accordingly. What users care about is no longer just whether accounts are secure and how digital assets are stored, but also who operates the business, under what regulation it falls, and which links the assets pass through.

Taking the U.S. equities business as an example, BIT further discloses in the new version of the whitepaper the regulatory, account, clearing, and asset custody arrangements for the relevant business. BIT's securities business is operated by Matrix Gelephu Pte Ltd and is regulated by the Gelephu Financial Services Office (GFSO); the relevant business participates through applicable regulatory and licensing arrangements, client asset protection mechanisms, and licensed third-party financial institutions, providing corresponding compliance and infrastructure support for business operations.

What users see is a single "buy," but behind it is a connection to multiple links including operations, regulation, trade execution, clearing, and asset custody. For financial platforms, the broader the business boundaries, the more necessary it is to extend the corresponding risk governance and compliance mechanisms in tandem, rather than merely adding new product entry points.

The same logic extends to BIT's other businesses. The new version of the whitepaper further supplements the regulatory and governance information of Matrixport Asset Management (MAM), and presents the compliance footprint of BIT Group entities across multiple jurisdictions including Hong Kong, Bhutan, Singapore, Switzerland, the United Kingdom, the United States, and the British Virgin Islands.

From digital assets to traditional financial assets, what BIT presents is not a single-point security mechanism for a particular product, but a risk governance and trust framework that extends as business boundaries expand.

Beyond security, why does trust also need to be "verifiable"?

Risk control addresses how risk is identified and controlled, but for a financial platform covering multiple assets and businesses, merely telling users "we have risk control" is still not enough. If security, compliance, and asset arrangements can only be explained by the platform itself, trust ultimately remains at the level of "believing what the platform says."

Therefore, BIT treats its compliance and regulatory foundation, independent audit and attestation mechanisms, and technical and operational transparency as the three pillars of its overall trust system, allowing "trust" to be further broken down into more specific questions: who regulates the platform? How are assets protected? How is risk controlled? Can these mechanisms be independently verified?

At the audit and attestation level, BIT forms a multi-layered, complementary verification system through mechanisms such as ISO management system audits, SOC independent attestation, annual financial audits, and internal audits, based on the applicable scope of different entities and business lines, avoiding over-reliance on any single audit or attestation mechanism.

Transparency addresses whether information can be seen; verifiability further answers whether such information can be independently checked.

When the industry once again puts "security" in front of all platforms, what truly matters may not be repeating the phrase "we are secure," but whether users can see the mechanisms behind that statement.

Trust does not come from a single promise or a single audit, but more from long-term, sustained institutional operation and external verification. Security needs to operate continuously, and trust needs to be continuously verified.

Link to the full version of the "BIT Trust Whitepaper V2.0": https://www.bit.com/whitepaper