On 27 August, Beosin and FCC ANALYTICS hosted the Trusted Digital Finance Forum 2026, bringing together professionals from compliance, digital assets, financial infrastructure, legal and institutional markets under the theme “AI × Blockchain Intelligence.”

🎤 The afternoon opened with keynote perspectives from Colin Chen from Beosin, who shared how blockchain intelligence can support crypto crime investigations and institutional compliance, and Wallace Chow from FCC ANALYTICS, who discussed how AI can strengthen financial crime detection and compliance intelligence.

💬 In the first panel discussion, Mandy K. from AvenirX Labs, Alex Cheng from Beosin, Eugene Wong from Cobo and Wallace Chow from FCC ANALYTICS, moderated by Timothy Law from FCC Analytics, explored institutional-grade compliance as digital assets move further into regulated markets.

The discussion covered investor onboarding, source-of-wealth verification, token and issuer due diligence, cross-chain screening, and suspicious on-chain activity — and how AI and blockchain intelligence can connect identity, fund flows and transaction behaviour more effectively.

💬 The second panel discussion, moderated by Emil Chan from the Hong Kong Digital Finance Association, brought together DC from Antalpha, Veco Lin from Hundsun Ayers Technologies Limited , Jiani Yang from Mankun Law Firm and Adam Zhou from VDX.

The conversation covered AI-powered trading and risk controls, AML surveillance, tokenized assets, stablecoin settlement and cross-border regulation, as well as model risk and accountability when AI or smart contracts are involved in financial decisions.

🔗 Following the panels, Beosin and FCC Analytics presented the Joint Innovation Showcase, “Integrated Compliance Intelligence: Unifying AI and Blockchain for Trusted Digital Finance.”

The showcase demonstrated how AI and blockchain intelligence can connect on-chain risk signals with broader compliance data and workflows to support risk detection, investigation and decision-making.

Across the afternoon, one point came through clearly: institutional adoption requires stronger connections between on-chain data, identity, transaction monitoring, AI-driven analysis and existing compliance systems.

🤝 The conversations continued off stage, with guests exchanging practical experiences and exploring opportunities for collaboration across traditional finance and digital assets.

Thank you to all our speakers, moderators, partners and guests who joined us.
We look forward to continuing the conversation and seeing many of you again at our next event.

This article analyzes the existing mainstream gas fee solutions in the Web3 industry and Tuven Chain’s new solution to provide a reference for blockchain developers and security auditors.

I. Mainstream Gas Fee Solutions

1.1 ERC-4337 (Account Abstraction) Paymaster Mechanism

Paymaster is a special contract defined in the ERC-4337 framework that can pay gas fees on behalf of users when executing UserOperations. This allows users to send transactions without holding the chain’s native tokens, thereby lowering the barrier to entry for new users.

Core workflow of paymaster:

(1) User initiates operation: The user signs and submits a UserOperation in a smart wallet.

(2) Bundling and verification: The Bundler collects multiple operations and sends them to the fee sponsorship contract and the Entrypoint contract.

(3) Paymaster: The Paymaster contract verifies whether it agrees to pay gas for the operation.

(4) Fee settlement: The transaction is executed on-chain, and the Entrypoint deducts native tokens (e.g., ETH) from the Paymaster’s deposit account as gas fees.

(5) Post-transaction compensation: Common fee sponsorship business models include full sponsorship, where the project team fully subsidizes 100% of gas fees for new users or specific activities; token-based fee payment, where users do not have the mainnet native tokens and can use USDT or USDC in their wallets to pay gas, with the Paymaster automatically exchanging them in the background; and conditional fee sponsorship, where the project team sets rules to only sponsor users who hold specific NFTs, complete specific tasks, or use specific in-app tokens.

Limitation: Regular Externally Owned Accounts (EOAs) cannot directly use it. Users need to switch to or upgrade to account abstraction wallets.

1.2 Meta-Transactions and Relayer Mode

This is another solution in blockchain to lower the barrier to entry for users and achieve “gas-free” or fee-sponsored transactions. Meta-transactions refer to users not sending transactions directly to the blockchain, but instead signing a “metadata” message off-chain that contains the operation intent and data with their private key. Relayers are responsible for collecting users’ off-chain signatures, acting as the actual on-chain transaction initiators themselves, paying the gas fees, and broadcasting the transactions to the blockchain.

The core workflow is as follows:

(1) User signing: The user signs the intent locally (e.g., transfer, contract call), consuming no on-chain gas.

(2) Submission to off-chain service: The user sends the signature and data to the relayer (which can be a DApp official server or a third-party service).

(3) Relayer bundling: The relayer encapsulates the signature into a real on-chain transaction, signs it with its own wallet account, and pays the gas fee.

(4) Smart contract verification: After receiving the transaction, the target smart contract parses and verifies the user’s original signature, and executes the corresponding logic upon confirmation.

However, this solution has centralization risks and replay attack issues: if the relayer goes down or deliberately refuses requests from certain users, users will be unable to send transactions; additionally, the relayer can see users’ transaction intents and may exploit this information for front-running. If a user’s signature is obtained by an attacker and the contract lacks validation of Nonce and ChainID, it may lead to replay attacks.

The above solutions do not directly modify the billing logic at the chain consensus execution layer. Tuven Chain attempts to modify the underlying execution logic to enable payment of a fixed-amount gas fee with custom tokens, without requiring users to change their regular wallets or modify applications — that is, to achieve both token substitution for fees and price locking.

II. Tuven Chain Core Implementation Logic

Tuven Chain is forked from Circle’s Arc chain, inheriting Arc’s basic capability for stablecoin gas payment. Its core innovation lies in the reverse reuse of the original blacklist verification mechanism. It constructs a SponsorRegistry registry, combines it with SBT identity credentials to complete user gating, and implements fee deduction and transaction admission logic.

2.1 Core Component: SponsorRegistry.sol / sponsor_registry.rs

SponsorRegistry is a pre-deployed core contract that serves as a global “gas fee plan table,” storing multiple sets of gas billing configurations. The data storage layout is strictly固化, and the execution-layer Rust code directly reads data through storage slots.

// SponsorRegistry.sol — Layout is "frozen"; handler reads directly by slot; order cannot be changed
struct gasPlan {
    address token;          // Which token to use
    uint256 feePerTx;       // How much to charge per transaction
    address feeBeneficiary; // Where to send the fee
}

address public multisig; // slot 0
mapping(uint256 => gasPlan) public plans; // slot 1: planId → plan
mapping(address => uint256) public sourcePlan; // slot 2: SBT → grantable planId
mapping(address => uint256) public userPlan; // slot 3: holder → planId (0 = not in plan)

// Sole write entry: authorized SBT adds/removes an address to/from the list
function setSponsored(address who, bool on) external {
    uint256 plan = sourcePlan[msg.sender]; // caller must be an authorized SBT
    if (plan == 0) revert NotAuthorizedSource();
    userPlan[who] = on ? plan : 0; // on = add to list; off = clear to 0
}

// sponsor_registry.rs — Execution layer reads with the exact same layout; cross-tested and locked
const PLANS_MAPPING_SLOT: u64 = 1;
const USER_PLAN_MAPPING_SLOT: u64 = 3;
// Address calculation: keccak256(key . slot) where plans[planId] = { token, feePerTx, feeBeneficiary }

During settlement, Tuven Chain first checks which plan the user belongs to. If the user is not in a plan (userPlan[you] == 0), they pay the native stablecoin USDX as usual. If they are in a plan, they pay with the token specified by the plan.

It should be noted that USDX is a Circle stablecoin-type contract, but minting/freezing/pause privileges are held by the operator and it is isolated from real USDC. Its “stability” comes from the operator’s policy, not reserve backing.

2.2 Underlying Execution Layer Fee Deduction Logic Modification (handler.rs)

// Imitating "blacklist": performs "non-metered SLOAD" on the plan table, deciding which token to use per transaction
fn charge_sponsored_gas(&self, evm, caller) -> Result {
    journal.load_account(SPONSOR_REGISTRY_ADDRESS)?; // Pre-warm; otherwise cold SLOAD will panic
    let plan_id = sload(REG, compute_user_plan_slot(caller))?;
    if plan_id.is_zero() {
        return Ok(false); // Not in a plan → pay USDX as usual
    }
    let token = sload(REG, compute_plan_slot(plan_id, PLAN_TOKEN_OFFSET))?;
    if token.is_zero() {
        return Err(gas_PLAN_UNCONFIGURED); // Plan not configured → reject, no fallback
    }
    let fee = sload(REG, compute_plan_slot(plan_id, PLAN_FEE_OFFSET))?;
    let bal = sload(token, compute_erc20_balance_slot(caller))?;
    if bal < fee {
        return Err(INSUFFICIENT_gas_TOKEN); // Insufficient membership token → reject
    }
    sstore(token, caller_slot, bal - fee)?; // Deduct fixed fee: paid by the member
    sstore(token, benef_slot, benef_bal + fee)?; // Credit to feeBeneficiary (unrelated to gas)
    Ok(true) // true = paid with membership token; USDX fully waived
}

During pre-execution, a USDX prepayment is synthesized to pass native validation; reward_beneficiary then deducts it back, and the beneficiary is not credited with USDX. Otherwise, it would be equivalent to printing money out of thin air per transaction.

Here, a fixed amount of a specific token is deducted per transaction, regardless of the actual computational resources consumed. This setup raises the base fee for the entire chain, and the increased gas costs are borne by regular USDX (non-plan) users — the cost is effectively passed on to them.

2.3 Identity Badge: SoulboundToken.sol / DeployUserland.s.sol

// SoulboundToken.sol — Non-transferable "identity badge" (ERC-5192)
function issue(address to, uint256 id, string uri) external onlyIssuer {
    _safeMint(to, id);
    registry.setSponsored(to, true); // Issuing the badge adds to the plan list
}

function revoke(uint256 id) external onlyIssuer {
    address owner = ownerOf(id);
    _burn(id);
    registry.setSponsored(owner, false); // Revoking the badge removes from the list
}

// Only mint(from=0)/burn(to=0) allowed; all other transfers are blocked — cannot be transferred or sold
function _update(...) internal override returns (address) {
    if (from != address(0) && to != address(0)) revert Soulbound();
    ...
}

// DeployUserland.s.sol — Deployment hands management over to multisig (1-of-2 is private key redundancy, not checks and balances)
registry.setSourcePlan(address(sbt), PLAN_ID); // Authorize SBT to bind to Plan 1
registry.setMultisig(address(multisig)); // Admin handed to management multisig
// Risk: if feeSigner is not explicitly set, it defaults to admin signer (treasury and management share the same private key pair)

Tuven Chain reuses Arc’s existing blacklist mechanism and combines it with SBT identity credentials to complete user gating.

The characteristics of its solution can be summarized as:

(1) Chain-native multi-token gas payment capability: Unlike contract fee sponsorship solutions, the billing logic is implemented on the consensus execution layer, supporting multiple plans in parallel, allowing different identity users to pay fees with different custom tokens.

(2) Fixed per-transaction fee model: Breaking away from the traditional “gas price × computational consumption” pricing model, making transaction fees predictable in advance.

(3) High compatibility with existing infrastructure: No smart accounts or DApp modifications required; regular EOAs like MetaMask can interact directly.

(4) Mechanism reuse: Reuses the chain’s existing blacklist storage read path and transforms it into identity gating.

However, the above convenience is built on a large number of new trust assumptions. Underlying kernel modifications, permission design, economic models, and cross-chain components may carry risks. The original blacklist semantics have been altered: the blocking logic, which originally only targeted transfer scenarios, has been extended to cover regular contract calls, changing the logical boundaries. The specific plan token fee deduction is a newly developed business logic that requires an independent security audit to ensure no vulnerabilities in storage reads/writes and balance calculations, and to avoid serious consequences such as transaction anomalies, chain consensus forks, and abnormal asset deductions.

📅 28 Aug 2026 | 14:00–18:00
📍 Central, Hongkong
🔗 Register: https://luma.com/c1kifbmw

As of now, total losses have surpassed $88 million, with attacks still ongoing. All Coldcard wallet users are advised to transfer their crypto assets to alternative addresses immediately. Below is Beosin’s full technical analysis of the vulnerability and on-chain tracing findings for stolen funds.

I. Vulnerability Technical Analysis

Reviewing the commit history of Coldcard’s firmware source code reveals that in Commit 37e4af5451c260c1e7d429fe8972c4cb5e68ee59, the development team updated configuration code targeting the MK4 series. A key line in mpconfigboard.h reads as follows:

// We have our own version of this code.
#define MICROPY_HW_ENABLE_RNG (0)

Within the MicroPython STM32 framework, this macro controls binding of the default hardware Random Number Generator (RNG) and compilation paths for generic random number utilities. Setting its value to 0 disables the native hardware RNG as the backend for the global rng_get() function.

Developer comments indicate the team intended to implement a custom RNG module. Inspection of the custom rng.h header file only declares two MicroPython object interfaces:

MP_DECLARE_CONST_FUN_OBJ_0(pyb_rng_get_obj);
MP_DECLARE_CONST_FUN_OBJ_1(pyb_rng_get_bytes_obj);
Their corresponding implementation logic is excerpted below:
/// \function pyb_rng_get()
/// Return a 30-bit hardware generated random number: or fail!
STATIC mp_obj_t pyb_rng_get(void){
// Get and return the new random number
return mp_obj_new_int(rng_get_or_fault() >> 2);
}
/// \function rng_get_bytes()
/// Fill a buffer with random bits; caller must provide sized buffer.
STATIC mp_obj_t pyb_rng_get_bytes(mp_obj_t buffer_io) {
mp_buffer_info_t bufinfo;
mp_get_buffer_raise(buffer_io, &bufinfo, MP_BUFFER_WRITE);
mp_uint_t count = bufinfo.len;
if(count < 1) {
mp_raise_ValueError(NULL);
}
// Read 32-bit words and unpack into provided buffer
random_buffer(bufinfo.buf, count);
return mp_const_none;
}
MP_DEFINE_CONST_FUN_OBJ_0(pyb_rng_get_obj, pyb_rng_get);
MP_DEFINE_CONST_FUN_OBJ_1(pyb_rng_get_bytes_obj, pyb_rng_get_bytes);
The underlying rng_get_or_fault() function does interface with the native STM32 hardware RNG peripheral:
static uint32_t rng_get_or_fault(void){
// Enable the RNG peripheral if it's not already enabled
rng_init();
// Wait for a new random number to be ready, takes on the order of 10us
uint32_t start = HAL_GetTick();
while (!(RNG->SR & RNG_SR_DRDY)) {
if (HAL_GetTick() - start >= RNG_TIMEOUT_MS) {
// hardware failure... do not return anything!
mp_raise_OSError(MP_EFAULT);
}
}
// Get and return the new random number
last_value = RNG->DR;
return last_value;
}

This confirms Coldcard’s custom code was theoretically built to leverage hardware RNG, but hardware entropy generation was only triggered when explicitly calling pyb_rng_get* APIs or the internal random_buffer() function.

Wallet creation workflows invoke separate logic defined in shared/seed.py’s wallet initialization function:

async def make_new_wallet(nwords):

# Pick a new random seed.
await ux_dramatic_pause('Generating...', 3)
seed = generate_seed()
words = await approve_word_list(seed, nwords)
if words:
await commit_new_words(words)

This function routes seed generation to Coldcard’s shared/random.py module. Historical iterations of random.py explicitly rely on ngu.random, retaining the following annotation:

# random.py - subset of random module, with no compat, and using crypto-quality rng
# for bytes, use ngu.random.byte(len)
#bytes = ngu.random.bytes

In short, wallet seed generation calls random.bytes instead of the custom pyb.rng() utilities — the bespoke pyb_rng_get_obj implementation does not override the native random.bytes method automatically.

With MICROPY_HW_ENABLE_RNG set to 0, seed generation bypasses hardware RNG entirely and falls back to pyb_rng_yasmarang from micropython/ports/stm32/rng.c:

#if MICROPY_HW_ENABLE_RNG
uint32_t rng_get(void) {
// use STM32 hardware RNG ...
}
#else
// For MCUs that don't have an RNG we still need to provide a rng_get() function
// A pseudo-RNG is not really ideal but we go with it for now.
// Yasmarang random number generator
static uint32_t pyb_rng_yasmarang(void) {
static bool seeded = false;
static uint32_t pad = 0, n = 0;
...
}
uint32_t rng_get(void) {
return pyb_rng_yasmarang();
}
#endif

pyb_rng_yasmarang is a pseudo-random number generator (PRNG), which is cryptographically unsafe for generating hardware wallet recovery seeds. Attackers can brute-force seed values derived from this weak PRNG to recover private keys.

Coinkite has since updated its Makefile to fully exclude the vulnerable stm32/rng.c fallback code:

# Do not compile MicroPython's fallback PRNG. The board-specific rng.c
# provides rng_get(), and this empty object satisfies the upstream object list.
$(BUILD)/rng.o: CFLAGS += -Dpyb_rng_yasmarang=error-do-not-want-this
$(BUILD)/rng.o:
$(ECHO) "SKIP stm32/rng.c"
$(Q)$(CC) $(CFLAGS) -x c -c /dev/null -o $@

II. Tracing Stolen Cryptographic Funds

Multiple victim wallets have had their assets drained and consolidated into several intermediate addresses with no subsequent laundering activity detected to date. Leveraging threat intelligence and on-chain behavioral analytics via Beosin Trace, we have identified the following consolidation addresses and their respective BTC holdings:

1. bc1qq85v2c926eg6pgxhwp6q7lf6cnsz80qs3fcu9r — 562 BTC

2. bc1qx76cae2706qd5q576feh7xq8rfcsjpf2htfhe3 — 398.47 BTC

Additional consolidation addresses holding stolen funds with identical on-chain aggregation patterns are listed below, with no further outbound transfers observed:

● bc1q8jy96fe5lf8vfugydnte3cguk92gpev7kwtp3q — 89.62 BTC

● bc1q0rvn88w08j75k4h48lf9fvhan7unjp7vjf5q6m — 64.9 BTC

● bc1qtfrwa4j6rmj9rsgspv6a0yjumkg39js2numu75 — 45.9 BTC

● bc1qmd5m5ktv7m5ffujxv4248fxv36myvdx79n8jp6 — 30.18 BTC

Exploits targeting the Coldcard vulnerability remain active. The Beosin team continues to monitor emerging consolidation addresses and map complete capital flow trajectories.

III. Conclusion

This catastrophic security breach of Coldcard hardware wallets stems from flawed implementation logic in random number generation by the development team. The critical seed generation pipeline relied on an insecure pseudo-random algorithm instead of cryptographically secure hardware entropy sources. Hardware wallet developers must implement comprehensive, full-spectrum code testing and third-party audits throughout product lifecycles. All Coldcard users are urged to migrate their digital assets without delay and closely monitor official security advisories released by Coinkite.

Report link: https://beosin.com/resources/over-88-million-losses-coldcard-hardware-wallet-vulnerability-analysis-and-stolen-fund-tracing

Contact

If you need any blockchain security services, welcome to contact us:

Official Website Twitter Telegram Linkedin

On 21 July 2026, the Financial Action Task Force (FATF) published the Targeted Report on Regulatory Challenges from Decentralised Finance (DeFi). Based on 2026 global virtual asset regulatory implementation survey data, worldwide law enforcement cases, and on-chain crime statistics, the report systematically examines the technical characteristics, criminal risks, and regulatory challenges currently facing the DeFi sector. It also provides comprehensive and actionable compliance guidance for regulators. In this article, Beosin interprets the core contents of the report to help readers quickly grasp the risk landscape and regulatory framework of DeFi.

I. Rapid Expansion of DeFi and Regulatory Lag

The report notes that DeFi has experienced significant growth in recent years. As of 2026, the total value locked (TVL) in DeFi reached USD 86.64 billion, an increase of approximately 85% from 2023. Although DeFi funds still account for a relatively small share of the overall virtual asset market, its growth rate, continued entry of institutional investors, and increasing interconnection with regulated entities have significantly raised its importance in the global financial system.

Since the FATF issued its Updated Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers in 2021, institutional funds have continued to flow into DeFi projects and some of them have grown in functionality and scale to approach traditional financial institutions. However, progress by jurisdictions in implementing Recommendation 15 (R.15) for DeFi businesses has been slow. The 2026 targeted update report shows that the vast majority of jurisdictions have not yet implemented R.15 for DeFi projects falling within regulatory scope:

l Among the 142 participating jurisdictions, only 26 had completed risk assessments for the DeFi sector.

l 132 jurisdictions had not identified any compliant DeFi projects operating within their territory.

l Only 4 jurisdictions had introduced DeFi licensing or registration regimes, and only 2 had actually completed licensing or registration for DeFi projects.

II. Core Characteristics and Risk Threats of DeFi

The report defines DeFi as a financial service system built on blockchain-based automated smart contracts, covering functions such as trading, swapping, lending, and asset management. Users can access DeFi platforms/underlying protocols directly through custodial/non-custodial wallets, or indirectly via virtual asset service providers (VASPs), to conduct peer-to-peer or pooled automated financial transactions.

2.1 Six Key Characteristics of DeFi

(1) Smart Contract Automation: All financial service logic is written into public smart contracts and executed automatically, making it difficult to attribute control and responsibility to a single entity.

(2) Open Source and Composability: Protocol code is largely open source and can be copied and reused by anyone to quickly build similar DeFi products. While this architecture improves efficiency for legitimate users, criminals can use cross-layer, cross-platform, and batch automated contract operations to move funds rapidly, and in combination with unregulated offshore VASPs and OTC desks, amplify money laundering risks.

(3) Algorithmic Market and Risk Control Mechanisms: Automated market makers, liquidity pools, and lending mechanisms can operate without regulated intermediaries. This feature can combine into complex multi-layer transaction chains, making it difficult for traditional compliance tools and on-chain analysis systems to monitor effectively.

(4) Liquidity Provision: Ordinary users can act as liquidity providers and earn fees proportional to their share of funds. Criminals can mix illicit funds into legitimate liquidity pools and earn trading fees.

(5) Permissionless Access: The vast majority of DeFi projects require only a blockchain wallet to use, without any customer due diligence. Anonymous access channels can be exploited by criminals to launder illegal proceeds.

(6) Oracle Dependence: DeFi relies on oracles to obtain external data such as asset prices and interest rates, which support core functions like pricing, collateral valuation, and liquidation. If oracle design, governance, or data sources have vulnerabilities, criminals can manipulate markets, conduct liquidations, and launder illicit gains.

2.2 Derived Financial Crime Risks

Citing real-world cases, the report points out that various financial criminal organisations use DeFi to launder illegal funds and circumvent AML controls at centralised exchanges. The main threat actors include:

l Fraud and Scam Groups: They create fake DeFi investment schemes (Ponzi schemes) or maliciously tamper with smart contracts to steal user assets. For example, the SafeMoon token scam and the Forsage Ponzi scheme, where project teams had absolute control over liquidity pools or treasury funds and misappropriated or distributed investor funds.

l Professional Money Laundering Networks: They exploit DeFi composability through cross-chain bridges, decentralised exchanges (DEXs), and mixers to mix illicit funds with legitimate liquidity pools and conduct complex on-chain hopping to obscure transaction trails.

l Proliferation Financing Networks: North Korean hacker groups have launched numerous cyberattacks against DeFi platforms. For instance, the 2026 hacks of Drift Protocol and KelpDAO resulted in total losses exceeding USD 570 million. Stolen funds were laundered through DeFi protocols and cross-chain bridges.

l Ransomware and Governance Attacks: After receiving cryptocurrency ransoms, ransomware groups quickly use DeFi protocols for swapping and mixing, or even directly exploit smart contract vulnerabilities to steal funds. Many DeFi projects are governed by decentralised autonomous organisations (DAOs), where token holders vote on protocol rule changes. Attackers can use flash loans to gain governance control of a project; after obtaining voting power, they can alter core smart contract parameters, divert funds, or propose malicious proposals to drain pool assets.

2.3 Existing Regulatory Obstacles

l Inconsistent Global Regulatory Frameworks: Most FATF jurisdictions have not implemented R.15 for DeFi projects falling within regulatory scope, and criminals exploit regulatory disparities across countries for regulatory arbitrage.

l General Non‑compliance by Obliged Entities: Most DeFi projects within FATF scope have not completed regulatory registration, have not implemented AML, targeted financial sanctions, or KYC customer due diligence obligations, and lack coordination mechanisms with law enforcement and regulators, hampering effective oversight and investigations.

l Prominent Cybersecurity Vulnerabilities: Smart contract code flaws, insufficient maturity of industry security systems, and malicious exploitation of open‑source code have made DeFi a prime target for hackers. Emerging technologies such as AI and quantum computing are expected to further amplify these cybersecurity risks.

l Decoupling from Centralised Fiat On/Off‑Ramps: Users are increasingly bypassing licensed institutions and compliant VASPs for fiat‑to‑crypto conversions, weakening the risk‑interception role of regulated on/off‑ramp intermediaries — a key regulatory lever.

III. FATF DeFi Regulatory Framework

The report stresses that the FATF adheres to a technology‑neutral principle, focusing on the actual business conduct of DeFi, and adopts a “same business, same risk, same regulation” approach — i.e., if DeFi carries out financial activities covered by FATF Recommendations, it must implement AML/CFT/CPF requirements. For the multi‑layer architecture of the DeFi ecosystem, the report details the applicability of FATF Standards to each layer:

l Settlement Layer (Blockchain): The underlying distributed ledger infrastructure (e.g., Ethereum, Solana) responsible for transaction recording, consensus, and final settlement. Only if the operator of this layer simultaneously conducts VASP‑type financial services does it fall under FATF Standards; the pure underlying blockchain infrastructure itself is not regulated.

l Asset Layer: Native blockchain tokens (ETH, SOL), stablecoins, and various on‑chain assets, which are the value carriers in DeFi transactions. Entities providing VASP services related to virtual assets are subject to FATF Standards.

l Protocol Layer: Smart contracts embodying financial logic for trading, lending, liquidity pools, etc., which form the core back‑end of DeFi. Smart contract code itself is not regulated, but entities that control the protocol are required to comply with FATF Standards.

l Application Layer: Front‑end websites, apps, wallets, etc., through which ordinary users access the underlying protocols. This layer may operate independently from the protocol layer and be managed by different entities. Entities that operate front‑ends and actively facilitate VASP services are subject to FATF Standards.

l Aggregation Layer: On‑chain/off‑chain aggregation tools that integrate services from multiple protocols for unified display. If the operator provides or facilitates VASP‑type business, it falls under regulation; pure information aggregators that only display market data, price comparisons, and do not handle asset transfers are generally not considered VASPs and need to be assessed case‑by‑case.

3.1 Three Regulatory Types of DeFi

Based on the governance and control structure of the DeFi protocol layer, the FATF divides DeFi arrangements into three categories:

(1) Centralised DeFi: There are identifiable controllers or persons with sufficient influence (e.g., administrators, governance token holders, developers, etc.). Even if such projects market themselves as “decentralised”, as long as control effectively exists, they fall fully within the scope of FATF Standards, and jurisdictions must require them to obtain licences or registration under R.15.

(2) Centralised DeFi Where Controllers Cannot Be Readily Identified: There is de facto control, but due to pseudonymity or other factors, the specific controllers cannot be identified. Such projects fall within FATF regulatory scope. Regulators should use multiple channels to trace the anonymous controlling parties, proactively engage with project operators to require disclosure of beneficial owners. If, after exhausting all reasonable tracing channels, the controllers still cannot be located, regulators may apply the same risk‑mitigation measures as for truly decentralised DeFi, while continuing to monitor for clues about the controllers.

(3) Truly Decentralised DeFi: No one maintains control or exerts sufficient influence over the project. Such projects are outside the scope of FATF Standards. However, because they still pose high risks, regulators need to adopt comprehensive, risk‑based supplementary mitigation measures for indirect management, such as issuing guidance to licensed institutions on cooperation with such projects, specifying pre‑conditions (e.g., enhanced AML controls).

3.2 Criteria for Determining Control of DeFi

Identifying the actual controlling entity of a DeFi business is the core and challenge of DeFi regulation. Regarding what constitutes “control or sufficient influence” over a DeFi project, the report provides detailed explanations in Section 5.3, distinguishing on‑chain and off‑chain indicators to help regulators identify and classify centralised DeFi:

On‑Chain Control Indicators

Upgradeable Contracts and Backdoor Permissions: Support for contract upgrades, proxy patterns, emergency stop functions, with permissions held exclusively by a specific party — these are strong signals of centralised control; emergency functions solely for responding to hacks and fully publicly disclosed may not necessarily equate to control, but undisclosed backdoor permissions operable by a single person pose significant control risks.

Core Parameter Modification Rights: The ability to unilaterally adjust risk thresholds, fees, mining rewards, collateral ratios, and other key economic/operational parameters.

Oracle Control: The ability to select, configure, or replace price data sources, and to manually override oracle price feeds.

Exclusive Control Over Core Smart Contract Infrastructure: Sole possession of deployment keys, contract registries, automated execution nodes, settlement contracts, and other underlying critical components.

Exclusive Fees and Revenue: A specific address consistently collects protocol fees, MEV arbitrage profits, liquidation penalties, or newly issued tokens — direct evidence of ongoing control.

Admin Access Controls: The use of whitelists for liquidity pools or protocol functions, with administrators managing user access rights.

Concentrated Governance Tokens and Voting Monopoly: A small number of wallets hold the vast majority of governance tokens, voting delegation is highly concentrated, and low participation allows a minority to dominate strategic decisions such as upgrades and treasury allocations.

Off‑Chain Control Indicators

Asset Custody and Operational Authority: Control over governance/administrative multisig wallets, upgrade keys, protocol asset custody services, allowing direct intervention in funds and contract security.

Front‑End Operation and Distribution Channel Control: Operation of official websites, mobile apps, and associated wallets — user entry points — enabling modification of user interaction rules.

Control Over Legal Entities: Foundations, laboratories, or operating companies that employ core developers, hold intellectual property, manage treasuries, and pay service providers — exercising substantial influence over project development.

Control Over Development Roadmap and Off‑Chain Infrastructure: Dominance over development priorities, version releases, indexers, data services, automation systems, and other supporting facilities — determining project direction.

Brand and Public Communication Control: Control over official branding, announcements, documentation, risk disclosures, and user education content.

It is important to note that these are not mandatory uniform criteria. Any natural or legal person that can materially decide or influence the core operations, user service rules, or derives significant economic benefit from the project should be considered a controller of a centralised DeFi arrangement. Regulators should make flexible determinations based on the project’s operational and governance structures.

3.3 Global DeFi Regulatory Practices

The report summarises current regulatory approaches from various countries as a standardised reference for implementing R.15:

(1) DeFi Risk Assessment Systems

The U.S. Department of the Treasury conducts DeFi risk assessments, differentiating risks by business types such as DEXs, lending, cross‑chain bridges, and mixers, deconstructing money laundering chains, distinguishing centralised/decentralised entities, and covering fraud, ransomware, sanctions evasion, and other risk types.

Hong Kong continuously assesses DeFi risks through market monitoring, case analysis, and intelligence assessment. The Hong Kong Police Force tracks global DeFi developments, analyses mainstream protocol governance structures, business models, and profit mechanisms, and identifies vulnerabilities that could be exploited for illicit activities.

(2) Smart Contract Certification

France’s ACPR and AMF joint working group proposed smart contract certification standards, exploring the integration of AML/CFT logic directly into smart contracts — e.g., embedded real‑time sanctions lists, zero‑knowledge proof identity verification for access. Certification dimensions cover code security, governance upgrade permissions, execution environment, access controls, lifecycle management, and user protection.

(3) DeFi Regulatory Sandbox

Bermuda has opened a sandbox for low‑risk DeFi projects, with caps on user scale and transaction amounts, mandatory integration with third‑party KYC providers and on‑chain real‑time monitoring systems, with regulators overseeing operations and compliance throughout the pilot.

(4) Front‑End Specific Controls

Japan’s Financial Services Agency (FSA) explicitly requires that front‑end apps and website operators that provide DeFi access to domestic residents be uniformly regulated, mandating risk disclosure and customer due diligence obligations.

(5) Multi‑Agency Coordination

The UK’s FCA, together with the National Economic Crime Centre, has established a multi‑agency mechanism to oversee DeFi, licensed institutions, and VASPs in areas such as fiat on/off‑ramps, product risk assessment, wallet management, customer onboarding, enhanced due diligence, fund transfer rules, and sanctions compliance, achieving early risk intervention and aligning understanding of DeFi‑related risks among regulators and law enforcement.

Singapore’s MAS includes DeFi risks under the regulation of Digital Payment Token Service Providers (DPTSPs), requiring all DPTSPs to conduct enhanced due diligence and monitoring for clients engaging in DeFi and for cooperative business with DeFi projects.

IV. Response Strategies and Regulatory Recommendations

4.1 For National Regulators and Jurisdictions

The FATF provides recommendations to regulators and enforcement agencies across several dimensions — DeFi risk assessment, compliance controls, compliance technology tools, public‑private collaboration, and investigative capabilities — to strengthen AML compliance in DeFi:

Conduct sector‑specific DeFi risk assessments based on local risk scale and market characteristics, integrated into national overall financial risk assessments and VASP sector risk assessments. Assessments should clarify the scale of DeFi ML/TF/PF risks, domestic business coverage, cross‑border transmission, and vulnerabilities at operational/governance/user levels.

Based on risk assessment outcomes, implement proportionate mitigation measures: require centralised DeFi (and encourage decentralised DeFi) to embed AML controls in smart contracts and front‑ends; require financial institutions and VASPs that interface with DeFi to upgrade supporting compliance tools to manage end‑user risks; for high‑risk or non‑cooperative DeFi projects, consider blacklisting, domestic operation bans, or other ultimate measures.

Engage regularly with industry stakeholders (DeFi projects, VASPs, on‑chain analytics firms) to develop AML tools that balance innovation and compliance (digital identity, on‑chain KYC systems).

Establish standardised rules for determining DeFi control; after identifying actual controllers, mandate full FATF AML controls; conduct policy outreach to clarify compliance obligations for centralised DeFi. If a controlling entity exists but cannot be traced and the project cannot implement compliance measures, treat it as an unregulated project with equivalent mitigation measures, while continuing to trace and applying proportionate penalties as appropriate.

Create clear regulatory pathways to allow licensed institutions to engage compliantly with DeFi while maintaining their own AML integrity; licensed institutions must deploy risk control tools, conduct customer due diligence on DeFi end‑users, and align control intensity with the robustness of the project’s built‑in compliance tools.

Establish ongoing regulatory communication channels suited to local risks — pre‑consultation, innovation hubs, regulatory sandboxes, industry seminars — to clarify compliance expectations before project launch.

Set up mechanisms to identify high‑risk and non‑compliant DeFi projects: public registries, regulatory alerts, risk ratings, to guide market participants towards good practices and improve overall industry order.

Strengthen oversight of key off‑chain infrastructure in the DeFi ecosystem (e.g., front‑end operators) to encourage tools that intercept illicit activities.

Require all DeFi projects operating domestically to designate a responsible contact person for regulatory liaison, supporting law enforcement investigations and addressing current inefficiencies in public‑private cooperation.

Build cross‑agency coordination mechanisms and specialised DeFi investigative capabilities, establish joint analysis and rapid response procedures. Leverage public‑private partnerships and blockchain analytics tools (e.g., Beosin KYT and Beosin Trace) for DeFi investigations: cross‑chain fund tracing, mixer/bridge/multi‑layer contract transaction reconstruction, wallet‑protocol relationship mapping, and smart contract logic deconstruction; tools can automatically identify layered laundering, split transactions, and other suspicious patterns, assisting in wallet owner identification and linking to illicit activities.

4.2 For DeFi Project Teams

(1) Centralised / Identifiable‑Controller DeFi

Complete local regulatory registration/licensing and set up a full internal AML compliance team.

Conduct smart contract security audits before launch and periodically; embed sanctions address blocking and emergency pause functions.

Designate official compliance contacts and proactively provide governance, treasury, and development team information to regulators and enforcement agencies.

Deploy on‑chain real‑time transaction monitoring to identify suspicious activities such as mixing, large cross‑chain splits, governance attacks, and submit STRs proactively.

Implement tiered KYC for front‑end users, with mandatory identity verification for high‑value or high‑risk transactions.

(2) Truly Decentralised DeFi (No Actual Controller)

Proactively integrate industry‑standard compliance tools and engage third‑party KYC providers to reduce abuse by illicit actors without undermining decentralisation; publish complete governance documentation and retain contact details for development and operations teams to assist regulatory investigations.

4.3 For Licensed VASPs and Financial Institutions

When establishing business relationships with centralised DeFi or centralised‑but‑anonymous DeFi, strictly apply R.13 requirements. If all reasonable efforts to locate the controlling entity fail, apply the same risk mitigation measures as for fully decentralised projects.

When interacting with unregulated DeFi projects, put in place robust AML controls, conduct customer due diligence on end‑users of such projects, and continuously verify protocol security and compliance systems.

Share industry intelligence across borders within the legal compliance framework to improve the identification and disruption of illicit fund flows through DeFi.

V. Conclusion

The DeFi market has grown rapidly, offering financial innovation but also carrying significant ML/TF/PF risks, which are amplified by persistent regulatory gaps and exploitation by cybercriminals, fraud organisations, and money laundering networks. This FATF targeted report demonstrates that the “decentralised” label cannot serve as a shield against AML obligations. DeFi regulation requires a “look‑through” review, focusing on the actual economic benefits, governance concentration, and code control of the project. At the same time, regulators, financial institutions, and VASPs interacting with DeFi must adopt more rigorous risk control measures.

Report link: https://www.fatf-gafi.org/content/fatf-gafi/en/publications/Virtualassets/targeted-report-decentralisedfinance-2026.html

Contact

If you need any blockchain security services, welcome to contact us:

Official Website Twitter Telegram Linkedin

As the fervor around Bitcoin ETFs subsides, investors are seeking the next hot project. Prior to the market turbulence caused by the Bitcoin halving event, many cryptocurrency enthusiasts had their eyes on Celestia.

Recently, Celestia’s token TIA has demonstrated remarkable performance, reaching new highs and capturing widespread attention from investors and the cryptocurrency community.

Mustafa Al-Bassam, the co-founder of Celestia, was once a formidable top-tier hacker.

This upward trend has made Celestia a hot topic in the community. However, the project’s popularity in the cryptocurrency ecosystem is also fueled by the controversial background of its founder. CEO Mustafa Al-Bassam was once a core member of the hacker group LulzSec, operating under the hacker alias “tFlow.” During that time, LulzSec conducted high-profile cyber attacks on significant targets such as the Central Intelligence Agency and Sony.

Despite his early involvement in hacking activities, Al-Bassam later pursued a degree in computer science at university, marking the beginning of his transformation. Today, he is dedicated to building Celestia, a novel modular blockchain system. His technical expertise and passion for blockchain have positioned Celestia as a noteworthy project.

While Al-Bassam has openly acknowledged his hacking past, some remain skeptical, fearing that his background might negatively impact the development and security of Celestia. However, others appreciate his technical talent and understanding of blockchain, believing that his experiences bring valuable insights and innovative thinking to the project.

Key Features of Modular Layer1 Blockchain Celestia

Celestia is a modular Layer1 blockchain that focuses on sorting transactions and verifying the availability of published data. The core concept of Celestia is to achieve a modular blockchain architecture, allowing developers to break free from the limitations of a single architecture during the blockchain development process, enabling flexible development based on their needs.

The modularity of Celestia consists of the Execution Layer, Settlement Layer, and Consensus & Data Availability Layer:

1. Execution Layer

Composed of Rollups responsible for executing transactions. Celestia utilizes Rollups to provide diverse options for the Execution Layer. In addition to supporting Optimistic Rollup and zkRollup, Rollup solutions like dYmension, Eclipse, and Fuel, built around Celestia, make it possible to connect the public chain with Cosmos and Solana ecosystem projects.

2. Settlement Layer

Notably, Celestia collaborates with Evmos to develop the Cevmos settlement layer. It will be based on Evmos and construct EVM’s recursive Rollup. Each Rollup built on Cevmos will have a bidirectional bridge with Cevmos, allowing the redeployment of existing Rollup contracts and applications from Ethereum, reducing the effort required for application migration.

3. Consensus & Data Availability Layer

Responsible for data availability and consensus mechanisms. All types of data are transmitted to the Data Availability Layer, where nodes store data in the same format they receive from the Settlement Layer. The system incentivizes nodes to store data using $TIA, and nodes use Reed-Solomon encoding and specialized Namespaced Merkle Trees data structures to ensure data availability.

Promising Projects on Celestia

1. Manta Network

A modular blockchain focused on building ZK applications, providing a scalable and low gas fee environment for ZK Dapps.

Manta Network is the first Ethereum L2 adopting Celestia’s modular data availability solution, significantly reducing user transaction costs and developer barriers.

2. Dymension

A modular blockchain network developed using Cosmos SDK and Celestia solution, ensuring the security and interoperability of RollApps.

Dymension’s modular design includes Execution, Settlement, Consensus, and Data layers, providing flexibility for developers. Celestia serves as the data availability provider for Dymension.

3. Ancient8 Chain

An Ethereum Optimistic rollups gaming chain utilizing Celestia’s data availability solution for high scalability, low transaction costs, and fast transaction confirmation.

Ancient8 evolved from a gaming guild to a Layer2 focused on gaming, attracting more gaming applications and users to the OP Chain ecosystem.

4. AltLayer

Supports existing Rollup solutions like OP Stack, Arbitrum Orbit, ZKStack, and Polygon CDK, defaulting to EVM and WASM.

As a modular extension solution, AltLayer enables developers to quickly launch scalable blockchain networks with three-step transaction processing.

In Conclusion

Built using Cosmos SDK, Celestia stands as a powerful and flexible blockchain application platform. Beosin, a leading global blockchain security team, focuses on providing comprehensive security audits for EVM and Cosmos ecosystem applications, contributing to the overall security of the blockchain ecosystem.

Regardless, Celestia, as an emerging cryptocurrency project, attracts attention due to its intriguing architecture and its controversial leader. Investors will continue to closely monitor Celestia’s development, anticipating its potential to stand out in the competitive cryptocurrency market and bring returns to investors. Beosin is currently capable of providing comprehensive security services for the Celestia ecosystem, establishing best security practices for Celestia ecosystem applications, and enhancing project security measures.

Contact

If you need any blockchain security services, welcome to contact us:

Official Website Beosin EagleEye Twitter Telegram Linkedin

On January 17, 2024, according to monitoring data from Beosin’s EagleEye security risk platform, Socket Protocol suffered a call injection attack, leading to a significant theft of funds from authorized users. Currently, the attacker has converted the stolen funds to ETH and stored them in the attacker’s address.

After the attack, Socket’s official confirmation acknowledged the security breach and promptly suspended the affected contracts.

Simultaneously, MetaMask posted on the X platform, stating that MetaMask Bridge users are not affected by the Socket vulnerability. MetaMask emphasized their unique architecture in designing cross-chain bridge contracts to mitigate such attacks.

Vulnerability Analysis

The primary cause of this incident is an insecure call invocation in the performAction function of the Socket contract. Despite the absence of checks on fromToken and toToken parameters, the function effectively restricts token addresses to WETH, excluding other ERC20 addresses, preventing the forgery of these parameters indirectly.

However, a critical flaw in the function lies in the lack of restrictions on the amount parameter. If the caller provides an amount of 0, the function’s check condition will always pass without the need to call WETH’s deposit and withdraw functions. This allows injecting abnormal data through the call, leading to the exploitation of the vulnerability.

Attack Process

Understanding the vulnerability, let’s explore how the attacker executed the attack:

1. Creation of Malicious Contract:

• The attacker initially created a malicious contract to initiate the attack.

2. Queries and Authorization Checks:

• Subsequently, the attacker conducted multiple queries on WETH balances from different addresses.
• Additionally, the attacker checked the authorized quantity for the Socket: Gateway contract associated with each address.
• Following this, the attacker called the Socket: Gateway contract.

3. PerformAction Function Call with transferfrom Signature:

• In the call to the performAction function, the attacker specified the swapExtraData parameter as 0x23b872dd…
• This data corresponds to the function signature of transferfrom, indicating a direct invocation of the token’s transferfrom function.

4. PerformAction Function Call with transferfrom Signature:

• In the call to the performAction function, the attacker specified the swapExtraData parameter as 0x23b872dd…
• This data corresponds to the function signature of transferfrom, indicating a direct invocation of the token’s transferfrom function.

5. WETH Transfer by the Attacker:

• Through numerous operations, the attacker transferred WETH from countless users to their own address.

6. Transfer of Authorized USDT in a Similar Manner:

• The attacker employed a similar method to transfer USDT authorized to the contract to their own address.

7. Involvement of Other Tokens:

• The attack extended to include other tokens such as WBTC, DAI, and MATIC.

As of the time of writing, approximately $3.3 million has been stolen, with some funds exchanged for ETH and stored in the hacker’s address. Beosin Trace continues to monitor the stolen funds.

Socket, in an update on the X platform, states that operations have been restored, affected contracts have been suspended, and the situation is under full control. Interoperability with Bungee bridging and most partner front-end bridging has been reinstated. A detailed analysis of the event and subsequent steps will be announced soon.

Socket issues a reminder: “Be cautious of fake Socket accounts attempting phishing in your replies. Please carefully verify the account before taking any action.”

This incident serves as a reminder to prioritize security. As we enter 2024, numerous security events have already occurred. Beosin, a globally leading blockchain security company, offers a comprehensive range of blockchain security products and services covering code security audits before project launch, real-time security risk monitoring, alerts and prevention, cryptocurrency asset recovery, security compliance KYT/AML, and more. We are committed to the secure development of the Web3 ecosystem. If needed, feel free to contact us.

Contact

If you need any blockchain security services, welcome to contact us:

Official Website Beosin EagleEye Twitter Telegram Linkedin

This article, authored by Beosin’s cooperating lawyer, Will, provides an in-depth analysis of the legal regulatory logic behind the approval of BTC ETFs.

After a challenging decade-long journey of BTC ETF approvals, the dawn of victory finally arrived. In the early hours of January 11, 2024, the U.S. Securities and Exchange Commission (SEC) approved 11 spot BTC ETFs simultaneously. These include Bitwise, Grayscale, Hashdex, BlackRock, Valkyrie, Invesco, Ark, VanEck, WisdomTree, Fidelity, and Franklin.

All credit for this achievement is attributed to Grayscale’s successful lawsuit. On August 29, 2023, a ruling by a U.S. federal court allowed Grayscale to triumph in its lawsuit against the SEC’s rejection of its spot BTC ETF application. This victory expedited the application processes of traditional financial giants like BlackRock and Fidelity, who had applied for BTC ETFs in the preceding months.

This article examines the shift in SEC’s attitude post Grayscale’s victory, the logic behind the approval of BTC ETFs thereafter, and the cautious statements by the SEC regarding other crypto assets, which it still considers as securities, signaling potential market risks.

I. Court Ruling Accelerates SEC Approval Process

The SEC had previously refused BTC ETFs, expressing concerns about fraud and manipulation in the market. All rejected ETF applications cited reasons related to securities laws focusing on “protecting investors from fraudulent and manipulative acts and practices.”

In 2021, the SEC allowed the trading of BTC futures ETFs, stating that futures products are harder to manipulate as they are based on the Chicago Mercantile Exchange (CME). However, Grayscale argued that the logic approving BTC futures ETFs should be the same for spot BTC ETFs, or else all futures BTC ETF applications should be revoked. The court agreed, finding the SEC’s rejection of Grayscale’s application arbitrary and without basis, violating administrative law. This lawsuit led to a complete shift in SEC’s stance, from passive to active review, as mentioned in the 22-page approval document: “This order approves the Proposals on an accelerated basis.”

II. SEC Highlights Risks of BTC ETFs

While ETFs, as longstanding compliant financial products, face no legal obstacles, BTC is the only asset defined by U.S. regulators, especially the SEC, as a “non-security.” What risks do BTC ETFs entail?

In the 22-page approval document, the SEC points out that the risk comes from the uncontrollability of the underlying asset trading market — specifically, the manipulation risk in the BTC spot market.

Though each ETF has signed Surveillance Sharing Agreements with compliant regulatory exchanges like CME to monitor risks in the BTC futures market, the monitoring does not extend to the BTC spot market.

The SEC compared the correlation of BTC prices between Coinbase and Kraken, two crypto exchanges, and CME futures prices since 2021, finding a high correlation. This implies that if fraudulent or manipulative activities occur in the BTC spot market, they are likely to affect the futures market, detectable by CME’s monitoring system, allowing regulatory intervention to control risks.

III. Market Manipulation in the BTC Spot Market

The primary risk of market manipulation in the BTC spot market arises from market makers or participants on centralized exchanges (CEX). If U.S. regulation can cover CEX, then relative risk control can be achieved.

In response, U.S. regulators have implemented on-site regulatory compliance for Coinbase and Kraken, and have taken targeted actions against Binance, the exchange with the highest trading volume, ensuring compliance and control.

IV. Neutral SEC and Cautious Gary Gensler

Thus, the neutral SEC assesses whether the rules submitted by national securities exchanges comply with the Securities Exchange Act and its regulations, considering whether they aim to protect investors and public interests. On January 11, 2024, at 4 a.m., the SEC approved 11 spot BTC ETFs, emphasizing in its press release:

“This SEC ETF approval is limited to ETFs holding one non-security commodity, bitcoin. It should not be construed as the SEC’s willingness to approve listing standards for any other crypto asset securities. The approval does not indicate the SEC’s views on the status of other crypto assets under securities laws or the current status of market participants not complying with securities laws.

As I have said in the past, the vast majority of crypto assets are investment contracts, and therefore, subject to securities laws.

While the SEC is neutral, I want to emphasize that the underlying assets in precious metal ETFs have consumer and industrial uses. In contrast, BTC is primarily a speculative, volatile asset, also used for various illicit activities, including ransomware, money laundering, evading sanctions, and terrorism financing.

Although the SEC approved the listing and trading of spot BTC ETFs today, it does not constitute approval or endorsement of BTC. Investors should exercise caution with products related to BTC and crypto assets.”

V. Pressure on Coinbase — Classifying Cryptographic Assets

Gary Gensler’s speech is explicit: BTC is not a security, and market risks can be controlled, leading to approval. However, other cryptographic assets are securities, a different story unrelated to the approval of BTC ETFs.

This brings us back to Gary Gensler’s consistent avoidance of a direct answer to the question, “What types of cryptographic assets are securities?” This is a matter of regulatory compliance for the three major exchanges, Kraken, Coinbase, and Binance, as well as a political game that the SEC demands U.S. judicial and legislative institutions respond to.

Coinbase has consistently been at the forefront of resisting the SEC, carrying the burden without hesitation. Judge Katherine Polk Failla, who previously referred to ETH as a commodity (Crypto Commodities) in the Uniswap case, responded to the question of whether cryptographic assets are securities by stating, “In this situation, it is not for the court to decide but for Congress to determine,” throwing this ultimate question to the U.S. legislative institution — Congress.

However, the legislative process in Congress will be lengthy, and the year 2024, being an election year, is eagerly anticipated.

VI. GM BTC ETF

Regardless of the SEC’s theatrics, the approval of the BTC ETF holds immense historical significance. It allows us, with our dreams of crypto punk ideals or overnight fortunes, to immerse ourselves in it, adding a vibrant color to the rushing currents of history.

As Wang Chuan puts it, “January 10, 2024, in the significance of world monetary history, looking back in the future, perhaps it can be compared with August 13, 1971 (Nixon’s announcement of the gold standard decoupling), and January 18, 1871 (German unification, leading European countries and the United States to join the gold standard system successively within a few years).”

Contact

If you need any blockchain security services, welcome to contact us:

Official Website Beosin EagleEye Twitter Telegram Linkedin

In 2024, the surging momentum of Sui has ignited the first spark in the Move ecosystem.

Firstly, a nearly 70% surge in the past week has brought attention back to this shining star in the Move ecosystem. According to DefiLlama data, Sui’s Total Value Locked (TVL) has reached $327 million, with a 6.76% increase in the last 24 hours and a remarkable 73.19% surge in the past 7 days. The current top three protocols by on-chain TVL are Cetus ($62.44 million), NAVI Protocol ($61.42 million), and Scallop Lend ($54.96 million).

As a key player in the Move ecosystem, Sui is committed to promoting the security, interoperability, and sustainable development of digital assets. The Beosin research team will once again explore the opportunities for Sui in 2024 from a security perspective.

Is the Strong Momentum of Sui a Solana Killer or ETH Killer?

Sui, created by Mysten Labs, is a high-performance blockchain that enables developers to build low-latency, high-throughput applications on Sui. Mysten Labs, founded by Evan Cheng, former head of Facebook’s Novi project, raised $36 million in December 2021 and secured a valuation of over $2 billion with a $300 million funding round in September 2022.

Sui’s distinctive feature is its object-centric data model. Each object stores a global, unique ID, metadata of the owner, a version number (increments with each object call), and Binary Canonical Serialization data, as shown in the diagram below:

Due to the object-based data model, Sui can group transactions based on the interdependence of objects in different transactions. This allows for parallel processing of multiple transactions on different nodes.

Sui categorizes objects into owned objects and shared objects.

For transactions containing only owned objects (e.g., tokens and NFTs), Sui uses the Byzantine Consistent Broadcast (BCB) consensus algorithm to confirm transactions. The BCB consensus algorithm involves validators voting on whether to package transactions, with the transaction initiator then tallying the votes. Validators subsequently verify the tally to decide whether to package the transactions. This algorithm’s advantage lies in the tally process being executed on the client side, reducing communication time between validator nodes and quickly confirming transactions.

For transactions involving shared objects, used in applications like DeFi, NFT trading markets, and games that require frequent user interactions, Sui utilizes the Narwhal and Bullshark protocols for sorting and verification. Narwhal serves as Sui’s transaction memory pool, responsible for checking pending transactions and generating a directed acyclic graph path traversal for these transactions. Bullshark reaches consensus on a specific directed acyclic graph traversal, thereby confirming the specific order of these transactions.

Based on this design, Sui has achieved a maximum tested Transactions Per Second (TPS) of 297,000, with transaction confirmation taking approximately 480 milliseconds, demonstrating excellent performance.

Advantages of Sui Compared to Solana and Ethereum

1. Safer Underlying Design

Sui supports Move smart contracts, which undergo byte verification before execution. Move language features a built-in bytecode verifier to check resource, type, and memory safety, helping prevent common errors and malicious code attacks before contract execution.

2. Native Resource Safety

Sui’s object-centric data model allows developers to set permissions and program resources using keywords like copy, drop, store, and key. In contrast, Solana lacks native resource safety, requiring individual contracts to implement resource safety.

3. Greater Emphasis on User Security

Sui provides transaction pre-execution services, allowing wallet service providers to inform users of contract execution results and permissions before transaction signing. This helps users clearly understand the potential consequences of transactions when interacting with dApps, significantly reducing fraud risks.

What Opportunities are there for the Top Three Projects on Sui to Participate?

1. Cetus

Cetus aims to develop a flexible and powerful primary liquidity network, facilitating asset trading for Aptos and Sui. The protocol focuses on liquidity with incentives and a range of interoperable operational modules to provide the best trading experience and efficiency for consumers in the DeFi ecosystem. Some liquidity pools in Cetus receive official liquidity incentives from Sui, offering CETUS rewards alongside SUI token rewards.

2. NAVI Protocol

NAVI Protocol offers lending services for mainstream tokens, stablecoins, and CETUS tokens. Innovative features like automatic leverage vaults and isolation mode enable users to leverage their assets with minimal risk for new trading opportunities. NAVI supports digital assets at different risk levels, and its advanced security features ensure fund protection and mitigate systemic risks. NAVI has collaborated with OKX DeFi to launch an additional yield service, offering users up to 35% APY for USDC deposits, with a total pool of 50,000 USDC and 100,000 CETUS.

3. Scallop Lend

Scallop Lend is the largest lending protocol in the Sui ecosystem and the first DeFi protocol officially funded by the Sui Foundation. Similar to NAVI Protocol, Scallop Lend provides lending services for eight tokens and offers an SDK for professional traders. Scallop Lend completed its airdrop snapshot on January 1, 2024, initiating the first phase of the airdrop.

Users who missed the first phase of the airdrop can continue using Scallop Lend’s lending services to receive rewards in the second phase of the airdrop.

Beosin Launches Security Audit Services for Move Smart Contracts

Beosin’s collaboration with Sui began last year, and the Beosin security team discovered vulnerabilities in multiple public chains. One particularly interesting vulnerability, discovered in Sui’s p2p protocol, causing denial-of-service issues leading to node crashes due to memory exhaustion. This denial-of-service vulnerability, caused by an ancient attack method known as a “memory bomb,” is detailed in Beosin’s discovery of a severe-level vulnerability in Move VM.

Potential Vulnerabilities in Move Contracts

1. Supply Chain Security Awareness: Developers using Aptos, Sui, or other frameworks based on Move should maintain a certain level of security awareness to ensure supply chain security.
2. Function Permission Issues: Careful delineation of permissions for function calls is crucial, especially for critical functions related to governance, as improper authorization can impact fund security.
3. Logic Issues in Design and Implementation: Attention should be paid to logical issues in business logic during design and code implementation. For example, Beosin conducted research on Move’s version of flash loans, as detailed in Web3 Technical Research | Differences between Solidity Flash Loan Implementation and Move and Rust Flash Loan Implementation.
4. Module Upgrades: Move projects should be cautious when upgrading modules, as the code owner remains unchangeable after initial deployment, and the deployer’s address permanently holds upgrade permissions.

Move Contract Audit Service and Audit Items

Beosin’s security team launched a security audit service for Move smart contracts at the end of 2022, aiming to proactively identify and assist project teams in addressing security risks within their projects, ensuring the safety of both users and project assets. The main security audit items include:

• Overflow vulnerabilities
• Replay attacks
• Insecure random number generation
• Transaction order dependencies
• Denial-of-service vulnerabilities
• Access control issues
• Improper permissions
• Business design flaws
• Business implementation issues
• Manipulable token prices
• Arbitrage attacks
• Gas optimization
• Security of third-party modules
• Capability security
• Resource security
• Upgrade security
• Centralization risks

For detailed information on Beosin’s Move smart contract security audit service, you can refer to “Beosin | Official Launch of Security Audit Service for Move Smart Contracts, Examining Move Language from a Security Perspective (Part 1)”.

In addition, Beosin introduced the Move Lint static analysis tool in 2023, aiding developers in automating the discovery of potential security vulnerabilities within contracts, pinpointing the origin of vulnerabilities, and enhancing the overall security of contracts. For more details, you can refer to “Beosin launched the Move Lint static detection tool to improve the security of Sui smart contract development through best practices”.

Will Sui Achieve Faster Growth in 2024?

The Move smart contract language is designed to be secure and reliable, aiming to avoid vulnerabilities and security risks present in traditional smart contract languages like Solidity. This design choice makes Sui’s contracts more trustworthy and secure, providing users with better assurance.

Sui is gearing up for growth in 2024, emphasizing ecosystem development as one of its strategies. With a Total Value Locked (TVL) of $327 million, Sui demonstrates user trust and engagement, indicating rapid growth in its ecosystem and a continuous increase in users. Additionally, Sui ranks among the top three in on-chain TVL for non-EVM chains, alongside protocols like Cetus, NAVI Protocol, and Scallop Lend, collectively propelling the development of the Move ecosystem.

Let’s eagerly anticipate Sui’s development in 2024.

Contact

If you need any blockchain security services, welcome to contact us:

Official Website Beosin EagleEye Twitter Telegram Linkedin

Sei Network, which launched its mainnet in August 2023, began to explode after several months of silence. Currently, Sei liquidity staking has exceeded $3.5 million and network TVL has exceeded $11 million.

Previously, Sei, together with Beosin and Alibaba Cloud, successfully held the hackathon, Code Sei: Powering New Gaming and DeFi Exchanges. Beosin also completed the audit of Kryptonite, Sei’s liquidity staking project, to enhance the security of Sei ecosystem.

In 2024, Sei is about to launch a very important upgrade, Sei V2, which will improve the performance of parallel processing and introduce EVM into Sei. In this article, Beosin will analyze the technical features, the code implementation, and ecosystem of Sei Network to help you understand the potential opportunities of Sei and its ecosystem.

Sei Features

As a Layer 1 that supports order book and focused trading, Sei provides a built-in central limit order book (CLOB) module. Developers can use Sei’s built-in order module to quickly launch and customize order book trading Dapps for spot, derivatives, options, etc. At the same time, Sei’s parallel design provides a fast, high-throughput network for its ecosystem.

How does Sei improve the processing speed of transactions?

1. Support Compressed Blocks

In most blockchain networks, validators propose blocks and then send hashes and blocks to other validators, which creates a certain waiting time. As shown below:

Sei allows its validators to send blocks containing only transaction hashes to its network. After other validators receive a block containing only the transaction hash, they will first construct the block based on the records in their local memory pool. If the corresponding transaction information does not exist in the memory pool, the validators will wait for subsequent blocks containing detailed transaction contents to arrive for validation.

2. Parallel Processing of Transactions

For blockchain networks that execute transactions sequentially, when a block is proposed, validators need to wait for a certain length of time without actually processing the block. As shown on the left:

Sei Network processes blocks in the pre-voting and pre-commit phases in parallel through validators. Parallel processing reduces latency and increases throughput.

The code implementation of Sei parallel processing is shown in the figure below. In the ProcessTxs function, Sei will process the transactions. There are two types of processing: parallel processing and sequential processing. For multiple related transactions (by judging whether the key-value pairs storing transaction information overlap), Sei will process related transactions sequentially; for non-related transactions, it will process them in parallel.

During parallel transaction processing, we see that Sei uses Golang’s goroutine to process multiple transactions in parallel. The current design cannot process too many transactions in parallel. For example, if thousands of transactions are processed in parallel by Sei’s nodes at the same time, there is a high probability that consistency problems will occur. Therefore, Sei V2 needs to upgrade in parallel processing.

Parallel EVM

What is Parallel EVM?

EVM is the virtual machine for Ethereum to process transactions related to smart contracts. To ensure network security, EVM transactions must be executed sequentially. The design of sequential execution avoids the complexity and conflicts of parallel execution, but also limits the performance of the associated blockchain network.

As a result, the concept of parallel EVM was proposed.

The design of parallel EVM will allow different transactions in EVM to be conducted simultaneously, greatly improving EVM processing speed and network throughput. The current solution is to use high-performance (itself supports parallel transactions) new blockchains such as Solana, Aptos, and Seito be compatible with EVM. Among them, Sei’s parallel EVM attracts the most market attention.

Sei V2 Upgrade

Sei will implement parallel EVM in the V2 to be launched in 2024, supporting the execution and interaction of Cosmwasm smart contracts and EVM smart contracts. The following are the key points of the Sei V2 upgrade:

1. Optimistic parallelization: allows concurrent transaction processing, significantly improving throughput and efficiency. If a state conflict occurs, transactions are reprocessed sequentially to maintain data integrity.

2. EVM compatible: enables developers to deploy existing EVM smart contracts on Sei without changing any code, simplifying the transition to Sei v2 and improving interoperability.

3.Geth compatibility: Sei nodes will integrate Geth to handle transactions for EVM smart contracts in the future network and make any updates through the special interface created by Sei for EVM.

4.SeiDB: Sei will improve its storage layer, using more efficient data structures and databases to enhance IO performance, facilitate easier synchronization of new nodes and improve scalability.

5.Enhanced performance: Fast transaction processing with 390 milliseconds block time and finality, and high throughput of 28,300 batch transactions per second, with lower transaction costs.

The upgrade of Sei v2 will integrate the advantages of Ethereum and looks forward to providing a super-optimized execution layer that is fully compatible with the existing EVM ecosystem to attract more users and developers into the Sei ecosystem.

Sei Contract Security Advice

If developers plan to build Sei ecological applications, they will use CosmWasm to build smart contracts. Beosin recommends that developers follow the following security practices to improve the contract security of their projects:

1. Be prepared for an attack. Developers need to consider how to face attacks and fix vulnerabilities. Therefore, developers need to build upgradable smart contracts and develop risk response plans.

2. Pay attention to the deserialization addr type. CosmWasm’s addr type is not validated after deserialization, indicating that the addr type has unexpected deserialization properties. Therefore, it is recommended to specify the type and verify it after deserializing addr.

3. Pay attention to overflow. In the CosmWasm contract, developers need to pay attention to the risk of integer overflow or division by zero. It is recommended that developers use CosmWasm’s Uint256 and Uint512 types and use the math function full_mul() that does not overflow.

4. Pay attention to infinite loops. The CosmWasm contract may get stuck in an infinite loop by calling itself back in the ACK handler. If developers transfer data packets between two CosmWasm contracts, they should be aware that this may lead to an infinite loop and consume a large amount of gas fees.

Sei Ecosystem

1. Wallet

Currently, the wallets that specifically support the Sei network include Compass Wallet and Fin Wallet. There are 14 wallets compatible with the Sei network, such as OKX Wallet and the wallets Keplr and Leap Wallet that originally supported the Cosmos ecosystem.

Safety Advice:

(1) It is recommended that users avoid using wallet projects that have not been audited and have not been running for a long time.

(2) To protect the assets of the wallet, the most important thing is to keep the mnemonic phrases and private keys safely.

(3) When interacting with Sei projects, signature is one of the security risks that require the most attention. Users need to check whether the transaction information is correct before signing the transaction. For example, a hacker can trick users into using cosmos.bank.v1beta1.MsgSend to transfer tokens to the hacker’s address.

2. Kryptonite

Kryptonite is the largest liquidity staking protocol in the Sei ecosystem. Users can stake Sei tokens on its platform to obtain stSei and earn an annualized return of 5.54%. Currently, users can also stake Seilor/Sei’s LP tokens and stSei/SEIYAN’s LP tokens to obtain rewards from related tokens. Beosin has previously completed a contract audit of Kryptonite to improve the security of its staking business.

In the future, Kryptonite will launch the kUSD stablecoin, and users can mint it by staking Sei, BTC, ETH and other assets, which will provide more liquidity for the Sei ecosystem.

3. Yaka Finance

Yaka Finance is committed to building a multi-functional DEX and providing users with a variety of DeFi services such as trading, liquidity mining, and Launchpad. Its goal is to become the liquidity hub of the Sei ecosystem.

Previously, Yaka Finance won the first place in the DeFi track in the Code Sei: Powering New Gaming and Defi Exchanges hackathon organized by Sei, Beosin and Alibaba Cloud.

Yaka Finance is currently in the test network stage and has launched an airdrop incentive program, attracting more than 15,000 users to participate in its testing.

4. Pallet Exchange

Pallet Exchange is the NFT trading platform of the Sei ecosystem, with a current daily trading volume of up to 1.23 million Sei (approximately $1 million). Pallet Exchange will charge a 2% fee for NFT tradings on its platform to maintain the operation of the platform.

Currently, the NFT series that have attracted much attention in the Sei Ecosystem include WeBump, The Colony, Seiyans, Seinsei, etc. Because the Sei ecosystem is in the early stages of development, users need to pay attention to the liquidity risks of related NFTs.

Conclusion

As a high-performance Layer 1 focused on transactions, Sei optimizes the generation and processing of blocks. At present, Sei ecosystem is growing rapidly. As the parallel EVM narrative continues, the upgrade of Sei V2 will solve the current bottleneck of Sei, attracting more attention from the market and more developers entering the Sei ecosystem.

As a leading Web3 security company, Sei and Beosin have launched further ecological cooperation to support smart contract security audits of Sei ecosystem. At present, Beosin has completed the contract audit of Kryptonite, the largest liquidity staking platform in the Sei ecosystem. In the future, Beosin will provide security services for more Sei ecosystem projects to help the safe development of the Sei ecosystem.

Contact

If you need any blockchain security services, welcome to contact us:

Official Website Beosin EagleEye Twitter Telegram Linkedin