[{"data":1,"prerenderedAt":117},["ShallowReactive",2],{"blog-archive:all":3},{"categories":4,"articles":13},[5,9],{"name":6,"slug":7,"articleCount":8},"Research","research",21,{"name":10,"slug":11,"articleCount":12},"Product Updates","product-updates",23,{"items":14,"total":114,"page":115,"pageSize":116},[15,28,39,49,59,68,78,86,95,104],{"slug":16,"category":7,"categoryLabel":6,"subcategoryLabel":17,"authorName":18,"title":19,"excerpt":20,"contentHtml":21,"coverUrl":22,"publishedAt":23,"updatedAt":24,"readTime":25,"cover":22,"hasCover":26,"coverAlt":27},"near-intents-exploit-analysis-how-3-865m-usdt-was-withdrawn-through-omni-s-cross-chain-infrastructure-da7ed3","Incident Analysis","Olivia","NEAR Intents Exploit Analysis: How 3.865M USDT Was Withdrawn Through Omni's Cross-Chain Infrastructure","On October 1, 2026, NEAR Intents disclosed a security incident involving approximately $3.8 million in assets. The exploit affected the interaction between its Omni deposit and withdrawal infrastructure and the NEAR Intents smart contracts, allowing an attacker to withdraw funds from a vault on BNB Chain.","\u003Cp class=\"docx-align-justify\">On October 1, 2026, NEAR Intents disclosed a security incident involving approximately $3.8 million in assets. The exploit affected the interaction between its Omni deposit and withdrawal infrastructure and the NEAR Intents smart contracts, allowing an attacker to withdraw funds from a vault on BNB Chain.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">On-chain records show that the activity began on September 30. The attacker first executed two small test withdrawals before making five larger withdrawals over approximately six hours, extracting a total of 3,865,000 USDT. Each transaction carried a withdrawal proof in the expected format and was accepted by the vault contract.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Following the incident, NEAR Intents suspended certain cross-chain services and patched the affected contracts. On October 2, project lead Alex Shevchenko announced that the stolen funds had been fully returned.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Although the funds were recovered, the incident raises important questions about how cross-chain systems manage withdrawal authorization, asset balances, and settlement across different networks.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">This analysis examines the publicly documented Omni Bridge architecture, the observed transaction sequence, and the security checks that matter when multiple contracts and validators are responsible for a single cross-chain withdrawal.\u003C\u002Fp>\n\u003Ch2>1. How Omni Bridge Handles Cross-Chain Withdrawals\u003C\u002Fh2>\n\u003Cp class=\"docx-align-justify\">NEAR Intents uses an intent-based execution model that allows users to exchange assets across networks by submitting signed transaction intents.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The related Omni infrastructure manages assets through contracts deployed on supported blockchains and an accounting system operating on NEAR.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">According to the public HOT Omni Bridge documentation, the architecture consists of three main components.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">\u003Cstrong>Locker Contracts\u003C\u002Fstrong> hold assets deposited on supported networks and release them when valid withdrawal requests are submitted. On EVM-compatible chains, these contracts manage ERC-20 transfers, verify withdrawal signatures, and execute asset releases.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">\u003Cstrong>HOT Omni Balance\u003C\u002Fstrong> maintains cross-chain asset balances on NEAR. It handles token minting, burning, and transfers, and serves as a source of accounting state for deposits and withdrawals.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">\u003Cstrong>HOT MPC Validators\u003C\u002Fstrong> verify cross-chain events and withdrawal records before producing signed proofs. Destination-chain contracts use these proofs to determine whether a withdrawal has been authorized.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">During a normal deposit, a user transfers assets to a Locker contract on the source chain. The contract records the deposit and assigns a nonce. Once validators confirm the deposit, the corresponding balance can be credited or minted on NEAR.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Withdrawals follow the reverse process.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">A user submits a withdrawal request on NEAR. Omni Balance processes the corresponding balance deduction or token burn, records the withdrawal, and assigns a nonce. After validators verify the record, they generate a signed withdrawal proof.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The user or an execution service then submits the withdrawal parameters and signature to the destination-chain Locker, which verifies the proof and nonce before releasing the assets.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The documented flow can be summarized as:\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">\u003Ccode>Withdrawal Intent → Balance Debit\u002FBurn → Withdrawal Record → MPC Signature → Locker Verification → Asset Release\u003C\u002Fcode>\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">One important aspect of this architecture is the separation between \u003Cstrong>asset accounting and final settlement\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The destination-chain Locker relies on the withdrawal proof it receives, while the user's complete asset entitlement is maintained by upstream components.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The security of this process therefore depends on the upstream system generating withdrawal records that accurately reflect authorized changes in user balances.\u003C\u002Fp>\n\u003Ch2>2. Attack Timeline: Seven Withdrawals From the BNB Chain Vault\u003C\u002Fh2>\n\u003Cp class=\"docx-align-justify\">According to the public on-chain investigation, the attacker-controlled addresses began preparing for the exploit on September 28, including a 10 USDT deposit into the targeted vault.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">On September 30, the attacker executed two small test withdrawals of 10 USDT and 11 USDT. Both were successful.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The attacker then proceeded with five larger withdrawals.\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Time (UTC)\u003C\u002Fth>\n\u003Cth align=\"right\">Amount\u003C\u002Fth>\n\u003Cth>Transaction\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Sep 30, 18:57\u003C\u002Ftd>\n\u003Ctd align=\"right\">10 USDT\u003C\u002Ftd>\n\u003Ctd>Test withdrawal\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Sep 30, 20:05\u003C\u002Ftd>\n\u003Ctd align=\"right\">11 USDT\u003C\u002Ftd>\n\u003Ctd>Test withdrawal\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Sep 30, 23:54\u003C\u002Ftd>\n\u003Ctd align=\"right\">800,000 USDT\u003C\u002Ftd>\n\u003Ctd>\u003Ca href=\"https:\u002F\u002Fexplorer.bitquery.io\u002Fbsc\u002Ftx\u002F0x9fe58e031f73bbd880c782bc9e7446bcda32cadb304a729209871a4a81856c4c\" rel=\"nofollow\">0x9fe58e…6c4c\u003C\u002Fa>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Oct 1, 00:24\u003C\u002Ftd>\n\u003Ctd align=\"right\">1,200,000 USDT\u003C\u002Ftd>\n\u003Ctd>\u003Ca href=\"https:\u002F\u002Fexplorer.bitquery.io\u002Fbsc\u002Ftx\u002F0x0381265d6a1bb09de899f49f410a8b907cd548358a7e3c91076c3a52656b8220\" rel=\"nofollow\">0x038126…8220\u003C\u002Fa>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Oct 1, 00:50\u003C\u002Ftd>\n\u003Ctd align=\"right\">1,500,000 USDT\u003C\u002Ftd>\n\u003Ctd>\u003Ca href=\"https:\u002F\u002Fexplorer.bitquery.io\u002Fbsc\u002Ftx\u002F0x69d1c68c7e961a0199d3c9f3b6a31cb168ed775ef34b51a42762253ac1efcceb\" rel=\"nofollow\">0x69d1c6…cceb\u003C\u002Fa>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Oct 1, 01:46\u003C\u002Ftd>\n\u003Ctd align=\"right\">330,000 USDT\u003C\u002Ftd>\n\u003Ctd>\u003Ca href=\"https:\u002F\u002Fexplorer.bitquery.io\u002Fbsc\u002Ftx\u002F0x9c10b967da0c85631ec105e3b322c0a851fcd01b69ff58f860e5cce003a\" rel=\"nofollow\">0x9c10b9…003a\u003C\u002Fa>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Oct 1, 06:08\u003C\u002Ftd>\n\u003Ctd align=\"right\">35,000 USDT\u003C\u002Ftd>\n\u003Ctd>\u003Ca href=\"https:\u002F\u002Fexplorer.bitquery.io\u002Fbsc\u002Ftx\u002F0x16ddfa695b9525662b8e57c35723f44af89b4e7fc2dedc3634f730caf8b90c02\" rel=\"nofollow\">0x16ddfa…0c02\u003C\u002Fa>\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp class=\"docx-align-justify\">The five larger transactions totaled 3,865,000 USDT, with another 21 USDT withdrawn during the initial tests. The approximately $3.8 million figure reported by the project was an initial estimate.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The investigation also found that only 10 USDT in previous BNB Chain deposits could be traced to the attacker-related addresses.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">However, this does not establish the full balance held by those addresses within the cross-chain system. Assets may have originated from other supported networks, earlier transfers, or cross-chain swaps.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The more relevant finding is that all seven withdrawals used proofs with the expected structure, and the destination-chain vault accepted the requests.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The BNB Chain transactions establish that the funds were released. They do not, by themselves, explain why the upstream system generated or accepted the corresponding withdrawal authorizations.\u003C\u002Fp>\n\u003Ch2>3. Signed Withdrawals: What Does the Vault Actually Verify?\u003C\u002Fh2>\n\u003Cp class=\"docx-align-justify\">In Omni's documented architecture, a destination-chain Locker verifies a signed withdrawal proof before releasing funds.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The public HOT Protocol EVM repository includes a relevant \u003Ccode>MetaWallet\u003C\u002Fcode> implementation with withdrawal execution, signature verification, and nonce management.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">According to the published implementation, the contract uses ECDSA signature verification and a configured \u003Ccode>verifyAddress\u003C\u002Fcode> to determine whether the submitted proof comes from an authorized signer.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The withdrawal data includes information such as the asset, recipient, amount, and nonce. The contract also checks whether a nonce has already been used.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Each of these checks serves a different purpose.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Signature verification establishes whether the authorization satisfies the contract's cryptographic requirements.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Nonce validation prevents the same withdrawal authorization from being executed more than once within its defined scope.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Parameter binding ensures that a valid proof cannot be reused for a different recipient, asset, amount, or execution environment.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">However, a successfully verified signature does not necessarily establish that the underlying withdrawal is economically valid.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Consider a case where an upstream component incorrectly approves a withdrawal that is not supported by the user's available balance.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">If that withdrawal is recorded and signed through an otherwise authorized process, the destination-chain contract may still accept the proof and release the requested assets.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">From the Locker's perspective, the signature satisfies its authorization rules. Whether the corresponding assets were correctly deducted from the user's balance depends on the upstream verification process.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">This creates a trust boundary between \u003Cstrong>withdrawal authorization and asset accounting\u003C\u002Fstrong>.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">It is an important area for cross-chain security reviews because the destination-chain contract generally cannot reconstruct every relevant balance change from another network.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">This is an architectural risk scenario, not a confirmed description of how the NEAR Intents exploit was executed. The available evidence does not establish that the MPC validators incorrectly signed a withdrawal, that a signature was forged, or that the nonce mechanism failed.\u003C\u002Fp>\n\u003Ch2>4. Root Cause: What Has Been Confirmed?\u003C\u002Fh2>\n\u003Cp class=\"docx-align-justify\">NEAR Intents confirmed that the vulnerability involved the interaction between Omni's deposit and withdrawal infrastructure and the NEAR Intents smart contracts.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Based on the public architecture, three areas are particularly relevant to the technical investigation.\u003C\u002Fp>\n\u003Ch3>Withdrawal Authorization and Balance Accounting\u003C\u002Fh3>\n\u003Cp class=\"docx-align-justify\">A valid withdrawal should correspond to an authorized deduction or burn of the user's assets.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Before generating a withdrawal proof, the system needs to establish that the user has sufficient available funds and that the corresponding accounting operation has been completed according to protocol rules.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Where multiple contracts maintain balances or withdrawal records, the system must also ensure that account identifiers, asset types, amounts, and state versions remain consistent.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Any discrepancy between the record used to authorize a withdrawal and the balance state supporting it can create an opportunity for incorrect settlement.\u003C\u002Fp>\n\u003Ch3>Withdrawal Proof Generation and Verification\u003C\u002Fh3>\n\u003Cp class=\"docx-align-justify\">The HOT Omni Bridge documentation describes a process in which validators inspect withdrawal records, generate signatures, and submit those proofs for verification on the destination chain.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">A security review needs to examine which contract state validators read, which parameters are covered by each signature, and whether a previously signed request can be modified, revoked, or executed more than once.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Fields such as \u003Ccode>chainId\u003C\u002Fcode>, \u003Ccode>token\u003C\u002Fcode>, \u003Ccode>amount\u003C\u002Fcode>, \u003Ccode>recipient\u003C\u002Fcode>, and \u003Ccode>nonce\u003C\u002Fcode> should be bound to the correct authorization context.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The precise set of signed fields must be verified against the deployed implementation. The presence of a field in an application-level withdrawal request does not automatically mean it is included in the signed message.\u003C\u002Fp>\n\u003Ch3>Settlement Consistency\u003C\u002Fh3>\n\u003Cp class=\"docx-align-justify\">A correctly formatted withdrawal proof must correspond to an authorized asset movement within the cross-chain system.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The protocol needs to prevent duplicate settlement and ensure that the same underlying asset entitlement cannot be used repeatedly.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">This becomes particularly important when cross-chain messages are delayed, transactions are retried, state updates arrive out of order, or only part of a multi-step withdrawal succeeds.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">These conditions need to be addressed at the protocol level because different components may observe and process state changes at different times.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">As of this analysis, a complete technical post-mortem identifying the vulnerable function and full exploitation conditions has not been independently verified.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The confirmed root-cause scope therefore remains the interaction issue between the Omni infrastructure and the NEAR Intents contracts.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The available evidence does not justify attributing the incident specifically to signature forgery, MPC key compromise, nonce replay, or a particular balance-update bug.\u003C\u002Fp>\n\u003Ch2>5. Tracing the Stolen Funds Across Networks\u003C\u002Fh2>\n\u003Cp class=\"docx-align-justify\">After withdrawing USDT from the BNB Chain vault, the attacker converted the assets into BNB and distributed them across newly created wallets.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">According to the public investigation snapshot taken on October 1 at 14:30 UTC, a substantial portion of the funds had moved toward Bitcoin and centralized exchanges.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Approximately 34.69 BTC was identified across four Bitcoin wallets, representing around 76% of the stolen value at the exchange rates used in the investigation. Approximately $802,000 was also traced to KuCoin-related deposit addresses.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Another notable detail is that the attacker reportedly processed approximately $822,000 through NEAR Intents' own cross-chain swapping service during the incident.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Some of those operations involved transferring around 750 BNB to the same BNB Chain vault associated with the exploit, then receiving ETH or BTC through the normal cross-chain exchange process.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">These swaps were part of the subsequent movement of funds. Their execution alone does not establish that the original vulnerability was exploited again.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Cross-chain fund tracing requires correlating source-chain transfers, swap orders, destination-chain receipts, and transaction timestamps.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Where complete swap records are unavailable, matching amounts and timestamps can support an investigation, but they cannot independently prove every step in a transfer path.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The reported destinations also reflect funds observed at different stages of movement. They should not be treated as mutually exclusive balances or added together as separate losses.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Most importantly, the October 1 snapshot describes the movement of funds before recovery. It does not represent their final ownership or location.\u003C\u002Fp>\n\u003Ch2>6. Incident Response and Recovery\u003C\u002Fh2>\n\u003Cp class=\"docx-align-justify\">On October 1, NEAR Intents acknowledged the security incident and stated that the relevant contract issue had been patched.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Certain deposit and withdrawal services remained suspended while the team continued its response to the affected Omni infrastructure.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">On October 2, NEAR Intents project lead Alex Shevchenko announced that the approximately $3.8 million in stolen funds had been fully returned and that the related investigation would be closed.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Subsequent public reporting identified a return transaction of approximately 34.6 BTC to a Bitcoin address designated by the project.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The complete return paths for the remaining assets have not been independently reconstructed from the publicly available information. Accordingly, the full recovery is presented here as the project's confirmed statement, with the directly observable Bitcoin transaction treated separately.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The incident affected infrastructure supporting NEAR Intents' cross-chain deposit and withdrawal operations.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">There is no public evidence in the reviewed material that NEAR's underlying consensus network was compromised or that the NEAR native token suffered a corresponding protocol-level vulnerability.\u003C\u002Fp>\n\u003Ch2>7. ScaleBit Security Insight: What Should a Cross-Chain Security Audit Cover?\u003C\u002Fh2>\n\u003Cp class=\"docx-align-justify\">The NEAR Intents incident involved several components that participate in the same asset transfer: vault contracts on different networks, a shared accounting system on NEAR, withdrawal proof generation, and final settlement.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">A Cross-Chain Security Audit should examine these components as a complete execution flow.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">\u003Ccode>Deposit → Balance Accounting → Withdrawal Authorization → Settlement\u003C\u002Fcode>\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Several security invariants are particularly important.\u003C\u002Fp>\n\u003Ch3>Withdrawal Authorization Consistency\u003C\u002Fh3>\n\u003Cp class=\"docx-align-justify\">Every authorized withdrawal should correspond to a valid asset debit or burn.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The recipient, token, amount, and destination network in the withdrawal proof must match the transaction being settled.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Testing should cover concurrent requests, multiple accounts, different assets, and changes in authorization state while withdrawals are pending.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Where different components maintain separate records, the audit also needs to establish how those records are reconciled.\u003C\u002Fp>\n\u003Ch3>Nonce Uniqueness and Replay Protection\u003C\u002Fh3>\n\u003Cp class=\"docx-align-justify\">Each withdrawal nonce should be unique within its intended authorization domain and unusable after successful settlement.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The review should also verify that signatures are bound to the correct chain, contract, asset, and recipient.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">This matters when a protocol deploys similar contracts across multiple networks or supports several withdrawal paths using shared signing infrastructure.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">A valid proof must not become executable in an unintended context.\u003C\u002Fp>\n\u003Ch3>Cross-Chain Asset Conservation\u003C\u002Fh3>\n\u003Cp class=\"docx-align-justify\">The assets released through cross-chain settlement must remain consistent with valid changes in user balances and the system's available reserves.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Testing should cover individual withdrawals as well as aggregate asset accounting across networks.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Message delays, failed transactions, retries, and different execution orders must not allow the same asset entitlement to support multiple successful withdrawals.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Asset Conservation testing is particularly important when deposits and withdrawals are processed asynchronously.\u003C\u002Fp>\n\u003Ch3>Failure-State Testing and PoC Verification\u003C\u002Fh3>\n\u003Cp class=\"docx-align-justify\">Cross-chain systems need to be tested beyond their normal execution paths.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Relevant cases include a withdrawal request that has been recorded but not yet signed, a signed proof awaiting execution on the destination chain, a failed settlement transaction that is subsequently retried, or a change in upstream state after a proof has already been issued.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">These scenarios can be examined using state-transition testing, Fuzz Testing, and PoC Verification.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">The goal is to verify that different components preserve their security invariants even when messages, transactions, and state updates occur in unexpected sequences.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">For more complex protocols, testing should also account for validator configuration changes, contract upgrades, and the interaction between old and new withdrawal states.\u003C\u002Fp>\n\u003Ch2>8. Conclusion\u003C\u002Fh2>\n\u003Cp class=\"docx-align-justify\">The funds involved in the NEAR Intents incident have been reported as fully recovered, but the disclosed vulnerability involved a critical part of cross-chain infrastructure.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">In systems that rely on external validators and cross-chain messages, signature verification, balance accounting, and settlement need to remain consistent throughout the withdrawal process.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">When these responsibilities are distributed across multiple contracts or networks, security testing must examine how they interact under both normal and abnormal execution conditions.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">ScaleBit, a sub-brand of BitsLab, focuses on vulnerabilities in DeFi protocols, cross-chain infrastructure, and complex smart contract interactions.\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">Our Smart Contract Security Audit work covers authorization logic, cross-contract execution paths, asset accounting, state consistency, and PoC-based vulnerability verification [\u003Ca href=\"https:\u002F\u002Fwww.bitslab.xyz\u002Ffaq\" rel=\"nofollow\">BitsLab AI\u003C\u002Fa>].\u003C\u002Fp>\n\u003Cp class=\"docx-align-justify\">For teams building or upgrading cross-chain and DeFi protocols, learn more about our security research and audit services at \u003Ca href=\"https:\u002F\u002Fwww.scalebit.xyz\u002F\" rel=\"nofollow\">ScaleBit\u003C\u002Fa> and \u003Ca href=\"https:\u002F\u002Fwww.bitslab.xyz\u002Faudit\" rel=\"nofollow\">BitsLab\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>References\u003C\u002Fh2>\n\u003Col>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fx.com\u002Fnear_intents\u002Fstatus\u002F2105642219357241796\" rel=\"nofollow\">NEAR Intents: Public Incident Announcement\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fhot-dao\u002Fdocs\u002Fblob\u002Fmain\u002Fomni-tokens\u002FREADME.md\" rel=\"nofollow\">HOT Omni Bridge: Architecture and Deposit\u002FWithdrawal Documentation\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fhot-dao\u002Fdocs\u002Fblob\u002Fmain\u002Fhot-omni-balance.md\" rel=\"nofollow\">HOT Omni Balance Documentation\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fhot-dao\u002Fomni-wallet-solidity\" rel=\"nofollow\">HOT Protocol: EVM Contract Repository\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fbitquery.io\u002Finvestigations\u002Fnear-intents-hack\" rel=\"nofollow\">NEAR Intents: Cross-Chain Fund Flow Investigation\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fwww.tokenpost.com\u002Fnews\u002Ftechnology\u002F26772\" rel=\"nofollow\">October 2: Recovery Announcement and Follow-Up Reporting\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Fol>","\u002Fmedia\u002Fscalebit\u002F2026\u002F10\u002F6b1b022207b53d63371b43ccf4de7f9a.png","2026-10-09T02:25:59Z","2026-10-09T10:25:59Z","13 min read",true,"NEAR Intents Exploit Analysis: How 3.865M USDT Was Withdrawn Through Omni's Cross-Chain Infrastructure cover image",{"slug":29,"category":7,"categoryLabel":6,"subcategoryLabel":30,"authorName":18,"title":31,"excerpt":32,"contentHtml":33,"coverUrl":34,"publishedAt":35,"updatedAt":36,"readTime":37,"cover":34,"hasCover":26,"coverAlt":38},"forced-transfer-is-not-a-backdoor-how-should-we-audit-legitimate-bypass-in-rwa-protocols-d1c885","Industry Research","Forced Transfer Is Not a Backdoor: How Should We Audit “Legitimate Bypass” in RWA Protocols?","In traditional crypto security reviews, seeing that an admin can move user funds is usually an immediate centralization red flag. In RWA systems, however, that conclusion does not always hold.","\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">In traditional crypto security reviews, seeing that an \u003Cstrong>admin can move user funds\u003C\u002Fstrong> is usually an immediate centralization red flag. In RWA systems, however, that conclusion does not always hold.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">ERC-7943 explicitly defines capabilities such as \u003Cstrong>forcedTransfer()\u003C\u002Fstrong>, \u003Cstrong>setFrozenTokens()\u003C\u002Fstrong>, \u003Cstrong>canSend()\u003C\u002Fstrong>, \u003Cstrong>canReceive()\u003C\u002Fstrong>, and \u003Cstrong>canTransfer()\u003C\u002Fstrong>. Freezing, forced transfer, and asset recovery are not necessarily hidden backdoors added by an implementation team; they may be explicit requirements of a regulated-token specification.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">This is a class of RWA risk that ScaleBit believes deserves a different audit model. When an “exception” is part of the specification itself, the security question is no longer whether the exception exists. The real question is:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">If a privileged path is intentionally allowed to bypass certain rules, which invariants may legitimately diverge—and which invariants must remain non-bypassable?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">1. Forced Transfer Creates a Second Legitimate State Machine\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">A conventional token transfer roughly follows one semantic path:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>Holder Authorization → Transfer Conditions → Balance \u002F Ownership Transition\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">An RWA token may expose another equally legitimate path:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>Privileged Authority → Enforcement Conditions → Balance \u002F Ownership Transition\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Both modify the same asset state, but they do not necessarily share the same preconditions.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Under some ERC-7943 permission models, for example, \u003Cstrong>forcedTransfer() \u003C\u002Fstrong>may legitimately bypass the normal \u003Cstrong>canTransfer() \u003C\u002Fstrong>path. But permission to bypass one transfer restriction does not imply that every other safety property may disappear with it.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">A more useful review model is therefore to separate invariants into two categories:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-14\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-14\">\u003Cimg alt=\"111111\" src=\"\u002Fmedia\u002Fscalebit\u002F2026\u002F08\u002Fdcb1b043cd8bb17a50493540a8389b51.jpg\" style=\"width: 414.6pt\">\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">An \u003Cstrong>onlyRole(AGENT) \u003C\u002Fstrong>check tells us who may enter the privileged path.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">It does not tell us:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Which security properties must still hold after that privileged state transition completes?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Privileged-path security is therefore not about eliminating semantic differences between normal and enforcement flows. It is about ensuring that:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Semantic divergence is strictly limited to what the specification actually requires.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">2. When frozen > balance Is Not an Accounting Bug\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">ERC-7943 contains a particularly counterintuitive state requirement: the frozen amount may exceed the account’s current balance.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">A Solidity auditor may instinctively assume an invariant such as:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>frozen(account) ≤ balanceOf(account)\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">For a regulated token, however, that assumption may be incorrect.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Suppose an address currently holds 10 tokens, but an enforcement authority intends to restrict not only the current balance, but also future assets received by that address.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">If the system only allows:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>frozen = 10\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">and the account later receives another 90 tokens:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>balance = 100\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>frozen  = 10\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">those additional 90 tokens may become transferable.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">A valid enforcement state may therefore instead be:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>balance = 10\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>frozen  = 100\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Here, frozen no longer means merely:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">the portion of the current balance that is frozen.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">It behaves more like:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>a policy constraint over both current and future asset state.\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">That distinction changes implementation-level security assumptions immediately.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">For example:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-14\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-14\">\u003Cimg alt=\"222222\" src=\"\u002Fmedia\u002Fscalebit\u002F2026\u002F08\u002Fb1d80f1cbc6a95042f39483b1e4fb03f.jpg\" style=\"width: 414.3pt\">\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">may underflow or revert whenever frozen > balance.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">If permission-query functions are also expected to remain non-reverting under valid states, the implementation must explicitly handle this case, for example:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-14\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-14\">\u003Cimg alt=\"图像2026-8-26 16.06\" src=\"\u002Fmedia\u002Fscalebit\u002F2026\u002F08\u002F0833773e6ec6954e56d93466f4f27cde.jpg\" style=\"width: 414.9pt\">\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">This illustrates an important RWA audit principle:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Do not infer invariants from variable names. Derive them from the state semantics defined by the specification.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">The same rule applies to forced-transfer ordering.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">If an ERC-721 or ERC-1155 enforcement path updates frozen accounting and also triggers a recipient callback, the relevant state should be reconciled before the external interaction. Otherwise, reentrancy may observe an intermediate state such as:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>Ownership = New State\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>Frozen Accounting = Old State\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">The failure here is not excessive administrative power.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">It is a violation of state consistency.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Authorization semantics may diverge. State-observation semantics still need to remain coherent.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Or more simply:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Bypass permission does not imply bypass ordering constraints.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">3. Revocability Propagates Through the Composability Graph\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Forced transfer is not only a property of the token contract itself. It also changes the assumptions made by every downstream protocol that integrates the asset.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Traditional DeFi frequently relies on an implicit assumption:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Assets held by a protocol can only leave through that protocol’s own state machine.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">For a revocable RWA, this assumption no longer necessarily holds.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Consider a vault holding $10 million of an RWA token. If the issuer or enforcement authority can alter the vault’s token balance outside the vault’s own logic, then even a perfectly implemented vault may experience:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-14\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-14\">\u003Cimg alt=\"44444\" src=\"\u002Fmedia\u002Fscalebit\u002F2026\u002F08\u002Fdd3125cd0cf3468c7b224980c8c4a71c.jpg\" style=\"width: 415.2pt\">\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">For a bridge, the implication may be even more fundamental.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Suppose its backing invariant is:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>Wrapped Supply ≤ Assets Locked in Custody\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">If locked assets can leave custody through a privileged token-level path that the bridge does not control, then the bridge’s backing invariant now depends on issuer authority.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">This leads to a broader security property:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>Revocability is a composability property.\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">When a protocol integrates a revocable asset, it inherits part of the issuer’s privileged state machine.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">That does not mean revocable RWAs are unsuitable for DeFi. It means integration reviews must ask additional questions:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Who can change protocol-held balances externally?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Does internal accounting observe those changes immediately?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Does the protocol assume custody = exclusive control?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Which solvency or backing invariants depend on that assumption?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">From ScaleBit’s perspective, this is particularly important because the vulnerability may not exist in either contract independently. It may emerge from a composability assumption mismatch between the RWA token and the downstream protocol.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">4. Move From Privileged Roles to a Privileged Transition Matrix\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">The previous analysis can be translated directly into a more practical review framework.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Instead of stopping at who holds AGENT_ROLE, whether that role is protected by a multisig, or whether the administrator is properly restricted, security reviews should compare the normal and enforcement paths explicitly.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">A Privileged Transition Matrix can make those differences visible:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-14\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-14\">\u003Cimg alt=\"55555\" src=\"\u002Fmedia\u002Fscalebit\u002F2026\u002F08\u002F020ec4b0e64f840026ec32d0adadb41a.jpg\" style=\"width: 415.1pt\">\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">The real objective is to distinguish:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>Intentional Enforcement Semantics\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">from:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">\u003Cstrong>\u003Cem>Accidental Security Bypass\u003C\u002Fem>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Implementation note: not every privileged action needs the same delay model\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Changes that modify the rules themselves—adding enforcement authorities, upgrading compliance modules, or expanding the scope of forced transfer—generally benefit from high-friction controls such as multisigs and timelocks.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Executing an already-defined emergency freeze may require faster action, because excessive delay can itself create an escape window.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">A useful principle is:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Changing authority should be slow; exercising existing authority can be fast only when the execution scope is tightly bounded.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Faster execution should therefore come with narrower limits around recipient, amount, asset, operator, and auditability.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-18\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-18\">Conclusion\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">When the exception becomes the specification, the exception needs its own security semantics.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">One of the fundamental differences between RWA systems and traditional DeFi is that behaviors considered exceptional in permissionless tokens may be explicit protocol requirements in regulated assets.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">forcedTransfer() is not necessarily a backdoor.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">frozen > balance is not necessarily an accounting bug.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Bypassing holder authorization is not necessarily an authorization vulnerability.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">The real failure occurs when:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">A privileged path bypasses an invariant that the specification never intended it to bypass.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">This is why ScaleBit believes RWA privilege reviews should not stop at:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Who has privilege?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">They should continue with:\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">What semantics does that privilege create?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Which invariants may diverge?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Which invariants must survive?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Which downstream protocols\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">silently assume they survive?\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">Once an exception path becomes part of the protocol specification, it can no longer be treated as a special admin function and reviewed in isolation.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">It is a second asset state machine—and it should be audited as one.\u003C\u002Fspan>\u003C\u002Fp>\u003Cp class=\"docx-align-justify docx-size-12\" style=\"line-height: 1.5; margin-top: 0pt; margin-bottom: 24pt\">\u003Cspan class=\"docx-size-12\">For RWA security, the goal is not to eliminate privilege at all costs. It is to ensure that every privileged action has a clear, bounded, and verifiable semantic boundary.\u003C\u002Fspan>\u003C\u002Fp>","\u002Fmedia\u002Fscalebit\u002F2026\u002F08\u002F379beee09c5161a2faf84aa2ca2a1f3b.jpg","2026-08-26T08:16:32Z","2026-08-26T16:22:17Z","7 min read","Forced Transfer Is Not a Backdoor: How Should We Audit “Legitimate Bypass” in RWA Protocols? cover image",{"slug":40,"category":7,"categoryLabel":6,"subcategoryLabel":17,"authorName":41,"title":42,"excerpt":43,"contentHtml":44,"coverUrl":45,"seoTitle":42,"seoDescription":43,"seoImageUrl":45,"publishedAt":46,"updatedAt":47,"readTime":37,"cover":45,"hasCover":26,"coverAlt":48},"bitslab-scalebit-security-team-discovers-a-zero-day-vulnerability-capable-of-transferring-all-assets-from-uniswap-wallet","ScaleBit","BitsLab's ScaleBit Security Team Discovers a Zero-Day Vulnerability Capable of Transferring All Assets from Uniswap Wallet","Recently, the ScaleBit security team under BitsLab identified a vulnerability in the iOS version of the Uniswap Wallet, which BitsLab has named the \"Unauthorized Access to Mnemonic Phrases\" vulnerability.","\u003Cp>In October 2024, the ScaleBit Security Team, part of BitsLab, identified a vulnerability in the Uniswap iOS wallet, which was named “Unauthorized Access to Mnemonic Phrases”. This flaw enables attackers with physical access to a device to bypass the wallet’s authentication mechanisms and directly retrieve mnemonic phrases stored on the device.\u003C\u002Fp>\n\u003Cp>This vulnerability implies that anyone with access to an unlocked device can extract the wallet’s mnemonic phrases in under three minutes. In everyday scenarios, temporarily lending a phone is not uncommon, especially among couples or friends. However, under the impact of this vulnerability, such seemingly innocuous actions could lead to the unintended exposure of wallet mnemonic phrases.\u003C\u002Fp>\n\u003Ch2 id=\"1-Background-Information\">1.Background Information\u003C\u002Fh2>\n\u003Cp>Mnemonic phrases are critical credentials in the blockchain ecosystem, enabling access to and management of on-chain assets. Their exposure can lead directly to the loss of user funds. The discovery of this vulnerability highlights significant security weaknesses in the user authentication processes and key storage mechanisms of certain wallets.\u003C\u002Fp>\n\u003Cp>It is worth noting that this vulnerability remains unaddressed in the latest version of the Uniswap Wallet available on the App Store (Version 1.42). We strongly advise all Uniswap Wallet users to remain vigilant and avoid lending their devices to others to prevent potential threats to their asset security. Additionally, users should closely monitor updates to the Uniswap Wallet and promptly install any patched versions.\u003C\u002Fp>\n\u003Cp>We deeply understand the potential security risks this issue poses to user assets. Since October of last year, we have repeatedly urged the Uniswap team to address the issue, but our concerns have not received the attention they deserve. Therefore, we have decided to publicly disclose this vulnerability to raise awareness among users and developers about its severity and to encourage stronger security practices.\u003C\u002Fp>\n\u003Cp>We firmly oppose any form of malicious exploitation and remain committed to providing professional security audits to safeguard the healthy development of the blockchain ecosystem.\u003C\u002Fp>\n\u003Ch2 id=\"2-Vulnerability-Analysis\">2.Vulnerability Analysis\u003C\u002Fh2>\n\u003Cp>2.1 In similar products such as Metamask and Unisat wallets, mnemonic phrases are typically encrypted using symmetric encryption algorithms like AES-256-CBC. However, in the authentication process of the Uniswap Wallet, likely aiming to enhance user experience, only FaceID verification is provided. Users can access the wallet, initiate transactions, or view mnemonic phrases after FaceID authentication, without being prompted to enter a password.\u003C\u002Fp>\n\u003Cp>This indicates that mnemonic phrases are either stored without encryption or encrypted using a fixed key. Upon reviewing the source code, it was confirmed that no effective encryption measures were applied during the storage of mnemonic phrases.\u003C\u002Fp>\n\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fgithub.com\u002FUniswap\u002Finterface\u002Fblob\u002Fa1f64eb8de1f43673917fdb599f99158aa90ceb4\u002Fapps\u002Fmobile\u002Fios\u002FUniswap\u002FRNEthersRs\u002FRNEthersRS.swift#L119-L129\">https:\u002F\u002Fgithub.com\u002FUniswap\u002Finterface\u002Fblob\u002Fa1f64eb8de1f43673917fdb599f99158aa90ceb4\u002Fapps\u002Fmobile\u002Fios\u002FUniswap\u002FRNEthersRs\u002FRNEthersRS.swift#L119-L129\u003C\u002Fa> \u003C\u002Fp>\n\u003Cp>In this implementation, mnemonic phrases are stored in the Keychain via the keychain.set method without any additional encryption measures. Although iOS Keychain provides certain underlying encryption and access control mechanisms, such as accessibleWhenUnlockedThisDeviceOnly, these protections primarily rely on system-level security features rather than application-level encryption. As a result, they are insufficient to fully ensure the security of mnemonic phrases.\u003C\u002Fp>\n\u003Cp>2.2 When users uninstall the wallet application directly, the mnemonic phrases stored on the device are neither deleted nor encrypted. However, the FaceID verification toggle within the wallet is reset, further compromising security.\u003C\u002Fp>\n\u003Cp>2.3 Uniswap Wallet supports encrypting mnemonic phrases and uploading them to iCloud, as well as recovering them from iCloud. Additionally, the app provides a recovery page. When in recovery mode, the application retrieves and displays a list of mnemonic phrases available for recovery.\u003C\u002Fp>\n\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fgithub.com\u002FUniswap\u002Finterface\u002Fblob\u002Ff1dfab33d1e13f0b2c7790516b03620d703ddea5\u002Fapps\u002Fmobile\u002Fsrc\u002Fscreens\u002FAppLoadingScreen.tsx#L206\">https:\u002F\u002Fgithub.com\u002FUniswap\u002Finterface\u002Fblob\u002Ff1dfab33d1e13f0b2c7790516b03620d703ddea5\u002Fapps\u002Fmobile\u002Fsrc\u002Fscreens\u002FAppLoadingScreen.tsx#L206\u003C\u002Fa>\u003C\u002Fp>\n\u003Cp>However, the conditions for triggering recovery mode are not limited to retrieving mnemonic phrases from iCloud. When the number of locally stored mnemonic phrases exceeds one, the recovery page is also displayed. In this scenario, the application may inadvertently expose multiple unencrypted mnemonic phrases.\u003C\u002Fp>\n\u003Cp>This design creates a convenient attack vector for malicious actors. However, even without recovery mode, the core issue of storing mnemonic phrases unencrypted remains. Attackers could leverage other methods to directly extract unencrypted mnemonic phrases stored on the device. Such methods typically require more advanced exploitation conditions, such as jailbreaking the device to gain full access to system files or sideloading a modified application.\u003C\u002Fp>\n\u003Cp>The unencrypted storage of mnemonic phrases thus serves as a critical entry point for potential attacks. Ensuring that mnemonic phrases are stored locally with robust encryption is essential to preventing the leakage of sensitive information.\u003C\u002Fp>\n\u003Ch2 id=\"3-PoC\">3.PoC\u003C\u002Fh2>\n\u003Cp>3.1 Install the Uniswap Wallet, Create a Wallet, Enable All Authentication Settings.\u003C\u002Fp>\n\u003Cp>Record the Wallet’s Mnemonic Phrase:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2025\u002F01\u002F9dd6a5757fa267c794f2e1721b4774a1.png\" alt=\"Figure1\" title=\"Figure1\">\u003C\u002Fp>\n\u003Cp>Enable All Authentication Settings:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2025\u002F01\u002F4b84d602b2b3ef88f9063b596a24c39b.png\" alt=\"Figure2\" title=\"Figure2\">\u003C\u002Fp>\n\u003Cp>3.2 Uninstall and Reinstall the Uniswap Wallet, Create a New Wallet.\u003C\u002Fp>\n\u003Cp>3.3 Uninstall the wallet once more and reinstall it.\u003C\u002Fp>\n\u003Cp>At this stage, the conditions to trigger the OnDeviceRecovery page are met, as the number of mnemonic phrases stored on the device exceeds one.\u003C\u002Fp>\n\u003Cp>Upon entering recovery mode, the wallet displays the Recovery Page, revealing all previously stored unencrypted mnemonic phrases from the device.\u003C\u002Fp>\n\u003Cp>This process exposes the user’s mnemonic phrases, demonstrating a significant design flaw in the Uniswap Wallet’s handling of mnemonic storage and recovery mechanisms.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2025\u002F01\u002Fcc87cb78a2172fd35c31bc6873b28ee4.png\" alt=\"Figure3\" title=\"Figure3\">\u003C\u002Fp>\n\u003Cp>3.4 Verify one of the mnemonic phrases retrieved in recovery mode and confirm that it matches the mnemonic phrase created during the first wallet setup.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2025\u002F01\u002F835d31cdec72e7e706e4a6fa4ad7a565.png\" alt=\"Figure4\" title=\"Figure4\">\u003C\u002Fp>\n\u003Ch2 id=\"4-TimeLine\">4.TimeLine\u003C\u002Fh2>\n\u003Cp>The vulnerability was submitted via Cantina on October 21, 2024. On November 28, 2024, the project team responded that while exploiting the vulnerability requires physical access to an unlocked device, the Likelihood might be downgraded, but the Impact remains high. They stated plans to confirm the issue and propose a solution. On December 5, 2024, the project team further replied that this was a known issue and refused to offer any reward.\u003C\u002Fp>\n\u003Cp>The timeline is as follows:\u003C\u002Fp>\n\u003Cp>October 21, 2024: The vulnerability was submitted via Cantina.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2025\u002F01\u002Fa51a1e26230beb21510984d8f4facf4f.png\" alt=\"Figure5\" title=\"Figure5\">\u003C\u002Fp>\n\u003Cp>November 28, 2024: The project team acknowledged the impact and planned to propose a solution.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2025\u002F01\u002Fbbe16f778e76836ce801fd3a1ccb49ff.png\" alt=\"Figure6\" title=\"Figure6\">\u003C\u002Fp>\n\u003Cp>December 5, 2024: The project team stated that the vulnerability was already known and refused to provide a bounty.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2025\u002F01\u002F3e1d8566215a791fd61d068fd7ac0703.png\" alt=\"Figure7\" title=\"Figure7\">\u003C\u002Fp>\n\u003Cp>We reached out to the Uniswap team on December 18, 2024, and January 2, 2025, repeatedly urging them to address this issue promptly or disclose it to users. However, we received no response.\u003C\u002Fp>\n\u003Cp>We firmly believe that users have the right to be informed about potential security risks to their assets. Given that this vulnerability has remained unpatched and users are unaware of it, we have decided to disclose the issue publicly. We informed the Uniswap team of our disclosure plan one week ago.\u003C\u002Fp>\n\u003Ch2 id=\"5-5-Summary\">5.5.Summary\u003C\u002Fh2>\n\u003Cp>The root cause of this vulnerability lies in flawed design choices in the storage and access mechanisms for mnemonic phrases. The mnemonics are not effectively encrypted at the application layer, and the unreasonable conditions for triggering the recovery page allow attackers with physical access to a device to bypass the wallet’s authentication mechanism and directly retrieve the wallet’s mnemonic phrases.\u003C\u002Fp>\n\u003Cp>This vulnerability persists in the latest version of Uniswap Wallet (Version 1.42), posing a potential risk to all users of the wallet. Therefore, users must take extra precautions to secure their devices physically, avoid disclosing unlock passwords, and refrain from lending their devices to others.\u003C\u002Fp>\n\u003Cp>This incident also highlights the importance of prioritizing user asset security when designing wallet applications. Mnemonic phrases, as critical credentials for accessing and managing on-chain assets, must be adequately protected. Developers are advised to implement robust encryption at the application layer, such as encrypting mnemonic phrases using AES-256-CBC, and deriving encryption keys with user passwords via PBKDF2 or Argon2.\u003C\u002Fp>\n\u003Cp>At the same time, ordinary users should enhance their security awareness by properly safeguarding their mnemonics, choosing wallets that have undergone rigorous security audits, and ensuring that these wallets implement strong encryption and robust security mechanisms. Users should avoid using wallets with unverified or unknown security standards to manage their assets.\u003C\u002Fp>\n\u003Cp>Through this disclosure, we aim to raise awareness among developers and users about wallet security. Only through collaborative efforts—developers strengthening security designs, users improving security practices, and security teams contributing technical expertise—can we build a safer and more reliable blockchain ecosystem.\u003C\u002Fp>","\u002Fmedia\u002Fscalebit\u002F2025\u002F01\u002Fca78b6f0ba7830d01cb615ca07a9e9d5.png","2025-01-10T03:15:00Z","2026-08-19T16:35:04Z","BitsLab's ScaleBit Security Team Discovers a Zero-Day Vulnerability Capable of Transferring All Assets from Uniswap Wallet cover image",{"slug":50,"category":7,"categoryLabel":6,"subcategoryLabel":30,"authorName":41,"title":51,"excerpt":52,"contentHtml":53,"coverUrl":54,"seoTitle":51,"seoDescription":55,"seoImageUrl":54,"publishedAt":56,"updatedAt":47,"readTime":57,"cover":54,"hasCover":26,"coverAlt":58},"scalebit-selection-a-look-at-the-bitcoin-ecosystem-in-2024-scaling-technologies-and-security-incident-summary","ScaleBit Selection A Look at the Bitcoin Ecosystem in 2024 Scaling Technologies and Security Incident Summary","Bitcoin has evolved beyond being just a cryptocurrency, with its ecosystem expanding into Layer 2 solutions and applications that enhance transaction efficiency and support emerging fields like smart contracts, DeFi, and NFTs. However, this growth has introduced security challenges, including vulnerabilities, attacks, and technical flaws that threaten asset safety and network stability. This article by ScaleBit explores Bitcoin's ecosystem development, its security challenges, and strategies for ensuring a secure and reliable future.","\u003Ch2 id=\"Introduction\">Introduction\u003C\u002Fh2>\n\u003Cp>With the continuous development of blockchain technology, Bitcoin has evolved beyond being just a cryptocurrency. Its ecosystem is constantly expanding and deepening. The Bitcoin scaling ecosystem includes a variety of Layer 2 solutions and applications, which enhance Bitcoin’s transaction speed and efficiency and support emerging fields such as smart contracts, decentralized finance (DeFi), and non-fungible tokens (NFTs). These innovations have broadened Bitcoin’s use cases, moving beyond value storage and peer-to-peer payments to cater to more complex and diverse needs, thus driving progress across the blockchain industry.\u003C\u002Fp>\n\u003Cp>However, with this expansion, security issues have gradually emerged. New technologies and applications bring about more potential risks and challenges. Ensuring the system’s security while enhancing functionality has become a critical concern. Security vulnerabilities, attack incidents, and technical flaws threaten not only the safety of users’ assets but also the overall stability and trustworthiness of the Bitcoin network. In this article, ScaleBit, under the BitsLab umbrella, will delve into the development of Bitcoin’s expanding ecosystem, the security incidents it faces, and prospects for improving security. By analyzing current technological solutions and security challenges, the aim is to provide valuable insights and recommendations for the continued development of the Bitcoin ecosystem, ensuring that it remains highly secure and reliable as it expands.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F12\u002F34ab0402273f9d452f3c0131a8d2fdc6.jpg\" alt=\"Banner\" title=\"Banner\">\u003C\u002Fp>\n\u003Ch2 id=\"The-Bitcoin-Extended-Ecosystem\">The Bitcoin Extended Ecosystem\u003C\u002Fh2>\n\u003Ch3 id=\"What-is-the-Bitcoin-Extended-Ecosystem\">What is the Bitcoin Extended Ecosystem?\u003C\u002Fh3>\n\u003Cp>The Bitcoin Extended Ecosystem refers to the various solutions and application ecosystems developed around Bitcoin’s foundational network. While Bitcoin was initially designed primarily for peer-to-peer payments and as a store of value, advancements in blockchain technology have spurred the Bitcoin community and developers to explore ways to enhance its functionality. These efforts focus on smart contracts, decentralized finance (DeFi), non-fungible tokens (NFTs), and more efficient transaction scaling solutions.\u003C\u002Fp>\n\u003Ch3 id=\"How-Does-the-Bitcoin-Extended-Ecosystem-Operate\">How Does the Bitcoin Extended Ecosystem Operate?\u003C\u002Fh3>\n\u003Cp>The Bitcoin Extended Ecosystem operates through various scaling technologies and protocols built on top of or alongside the Bitcoin mainnet. These innovations enable Bitcoin to support a broader array of applications. Critical technologies within the ecosystem include:\u003C\u002Fp>\n\u003Cp>(1) Lightning Network\u003C\u002Fp>\n\u003Cp>The Lightning Network is one of the most mature and widely used Layer 2 solutions for Bitcoin. By establishing payment channels, it moves a large number of small transactions off-chain, significantly increasing Bitcoin’s transaction speed and reducing transaction fees.\u003C\u002Fp>\n\u003Cp>Trends:\u003Cbr>The Lightning Network’s infrastructure is continually evolving, with improved user experience and a growing number of merchants supporting Lightning payments.\u003C\u002Fp>\n\u003Cp>Challenges:\u003Cbr>Liquidity management and routing efficiency remain areas needing further optimization, particularly for high-value transaction scenarios.\u003Cbr>These efforts highlight the potential for Bitcoin to transcend its original limitations and embrace a more versatile role within the blockchain ecosystem.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F12\u002F57e024a291cf7747d2583e517ccff363.png\" alt=\"Figure1\" title=\"Figure1\">\u003C\u002Fp>\n\u003Cp>(2) Liquid Network (LQ)\u003C\u002Fp>\n\u003Cp>The Liquid Network is a sidechain built on the open-source Elements blockchain platform, designed to enable faster transactions between exchanges and institutions. Governed by a distributed federation of Bitcoin companies, exchanges, and other stakeholders, Liquid Network employs a two-way peg mechanism to convert BTC to L-BTC and vice versa.\u003C\u002Fp>\n\u003Cp>Liquid supports confidential transactions and tokenization, making it suitable for enterprise applications. If Bitcoin is the value layer of the internet, and the Lightning Network serves as the peer-to-peer payment network within Bitcoin-driven financial systems, then Liquid acts as the financial layer, adding multi-asset support and financial tools such as securities and commodities.\u003C\u002Fp>\n\u003Cp>Compared to Lightning, Liquid facilitates larger and more complex transactions, such as asset issuance and trading (e.g., securities and stablecoins). While Lightning primarily provides privacy through off-chain transactions, Liquid has built-in confidential transaction features that obscure transaction amounts and asset types. Lightning excels in small-scale payments and everyday transactions, whereas Liquid is better suited for institutional finance, asset issuance, and cross-border transactions.\u003C\u002Fp>\n\u003Cp>Over 50 exchanges have adopted the Liquid Network, enabling billions of dollars in transactions. This demonstrates its effectiveness in enhancing Bitcoin’s utility for institutional trading. The Liquid Network provides faster settlement times for exchanges, improving market liquidity and allowing institutions to operate more securely and efficiently.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F12\u002F3677e81049a0178a6ca5fe56d238f786.png\" alt=\"Figure2\" title=\"Figure2\">\u003C\u002Fp>\n\u003Cp>(3) Rootstock Framework (RBTC)\u003C\u002Fp>\n\u003Cp>Since its inception in 2015, Rootstock (RSK) has been the longest-running Bitcoin sidechain, with its mainnet launched in 2018. Rootstock is able to combine Bitcoin’s Proof-of-Work (PoW) security with Ethereum’s smart contract functionality. As an open-source, EVM-compatible Bitcoin Layer 2 solution, Rootstock provides an entry point for a growing ecosystem of decentralized applications (dApps) while striving for realizing fully trustless.\u003C\u002Fp>\n\u003Cp>Like Liquid, Rootstock employs a two-way peg mechanism, enabling seamless swaps between BTC and RBTC. RBTC is the native currency of the RSK blockchain and is used to pay miners to process transactions and execute contracts. While Liquid focuses on fast and private transactions and asset issuance, Rootstock extends Bitcoin’s capabilities into DeFi and dApp ecosystems through smart contracts.\u003C\u002Fp>\n\u003Cp>As of this writing, Rootstock’s total value locked (TVL) exceeds $170 million, with a market capitalization of $380 million.\u003C\u002Fp>\n\u003Cp>(4) B² Network\u003C\u002Fp>\n\u003Cp>The B² Network features a dual-layer architecture comprising a Rollup Layer and a Data Availability (DA) Layer, redefining how users perceive Bitcoin Layer 2 solutions.\u003C\u002Fp>\n\u003Cp>Rollup Layer (ZK-Rollup):\u003Cbr>B² Network uses a ZK-Rollup framework with a zkEVM solution to execute transactions and generate proofs within the Layer 2 network. User transactions are processed and stored in the Rollup Layer, where user states are also maintained. Batch proposals and generated zero-knowledge proofs are forwarded to the Data Availability Layer for storage and verification.\u003C\u002Fp>\n\u003Cp>Data Availability Layer:\u003Cbr>The DA Layer includes distributed storage, B² nodes, and the Bitcoin network. It handles the permanent storage of Rollup data, validates zero-knowledge proofs, and executes final confirmations on Bitcoin.\u003C\u002Fp>\n\u003Cp>Distributed storage:\u003Cbr>Distributed storage is a critical component of the B² Network, serving as a repository for ZK-Rollup transactions and their related proofs. With decentralizing storage, the network enhances security, reduces single points of failure, and ensures data immutability.\u003C\u002Fp>\n\u003Cp>To guarantee data availability, B² writes a Tapscript script into every Bitcoin block on the Bitcoin network. This script anchors the Rollup’s data path and zero-knowledge proof stored in decentralized storage, ensuring data validity. This process is cost-efficient, producing six transactions per hour. Users verify the data by comparing transactions and Taproot script data on Bitcoin Layer 1, ensuring the ultimate reliability of the Rollup data.\u003C\u002Fp>\n\u003Cp>This innovative design enhances Bitcoin’s Layer 2 infrastructure, enabling scalable and secure solutions while leveraging the robustness of the Bitcoin network.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F12\u002Fb335d83bd62752563ea3d799732f2d61.png\" alt=\"Figure3\" title=\"Figure3\">\u003C\u002Fp>\n\u003Cp>(5) Stacks Protocol (STX)\u003C\u002Fp>\n\u003Cp>Launched on its mainnet in 2018 under Blockstack, Stacks has grown into a leading Bitcoin Layer 2 solution.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F12\u002Fa7ec12172e34429dedbf7f352710c5b4.png\" alt=\"Figure4\" title=\"Figure4\">\u003C\u002Fp>\n\u003Cp>Stacks directly connects to Bitcoin, enabling the creation of smart contracts, dApps, and NFTs on the Bitcoin network. This significantly extends Bitcoin’s capabilities, transforming it from a simple store of value into a more versatile platform. Stacks employs a unique Proof of Transfer (PoX) consensus mechanism, which links its security directly to Bitcoin without requiring any modifications to Bitcoin itself.\u003C\u002Fp>\n\u003Cp>With a total value locked (TVL) exceeding $99 million, Stacks boasts a well-established infrastructure and a rapidly growing developer community, solidifying its position as a key player in the Bitcoin Layer 2 ecosystem.\u003C\u002Fp>\n\u003Cp>(6) Babylon\u003C\u002Fp>\n\u003Cp>Babylon envisions extending Bitcoin’s security to safeguard the decentralized world. By leveraging three key aspects of Bitcoin— timestamping service, block space, and asset value, Babylon transmits Bitcoin’s security to numerous Proof-of-Stake (PoS) chains, creating a more robust and unified ecosystem.\u003C\u002Fp>\n\u003Cp>Babylon’s Bitcoin staking protocol employs a remote staking approach that overcomes the limitations of Bitcoin’s lack of smart contract functionality. This is achieved through cryptographic innovations, consensus protocol advancements, and optimized use of Bitcoin’s scripting language. The protocol allows Bitcoin holders to stake their BTC securely without bridging to PoS chains while providing these chains with comprehensive slashable security guarantees. This eliminates the need for bridging, wrapping, or custodial staked BTC.\u003C\u002Fp>\n\u003Cp>A core feature of Babylon is its BTC Timestamp Protocol, which timestamps events from other blockchains onto Bitcoin, ensuring that these events benefit from Bitcoin’s timestamp security, just like Bitcoin transactions. This effectively leverages Bitcoin as a timestamp server. The BTC Timestamp Protocol facilitates fast stake withdrawals, composable trust, and reduced security costs, maximizing liquidity for Bitcoin holders.\u003C\u002Fp>\n\u003Cp>Designed as a modular plugin, the protocol is compatible with various PoS consensus algorithms and is a foundational layer for building robust reset protocols. Babylon’s innovative design enhances Bitcoin’s utility while strengthening security across the decentralized ecosystem.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F12\u002Fe1c74d5902e2bea2ade760649850aab4.png\" alt=\"Figure5\" title=\"Figure5\">\u003C\u002Fp>\n\u003Ch2 id=\"Security-Incidents-in-the-Bitcoin-Expansion-Ecosystem\">Security Incidents in the Bitcoin Expansion Ecosystem\u003C\u002Fh2>\n\u003Cp>In October 2023, a potential security vulnerability was identified in Bitcoin’s scaling solution, the Lightning Network. Developer Antoine Riard disclosed details of the vulnerability after its discovery.\u003C\u002Fp>\n\u003Cp>This vulnerability, referred to as a “replacement cycling attack,” poses a risk to the security of funds flowing through the Lightning Network. It could result in transaction delays or failures, potentially leading to fund losses within Lightning Network channels.\u003C\u002Fp>\n\u003Cp>This incident highlights that security must always be a top priority in the rapidly evolving scaling ecosystem. Developers and the community need to continuously monitor and improve existing scaling solutions to guard against potential security threats and ensure the safety of user funds.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F12\u002Ff34a3cc0ab95b94c82d76436c019141e.jpg\" alt=\"Figure6\" title=\"Figure6\">\u003C\u002Fp>\n\u003Ch2 id=\"Security-Outlook-for-the-Bitcoin-Expansion-Ecosystem\">Security Outlook for the Bitcoin Expansion Ecosystem\u003C\u002Fh2>\n\u003Cp>Despite the significant progress made by the Bitcoin scaling ecosystem in improving transaction efficiency and functional diversity, its security still requires ongoing enhancement. This section will explore the future development directions and challenges of security in the Bitcoin scaling ecosystem.\u003C\u002Fp>\n\u003Cp>The Bitcoin expansion ecosystem aims to address the main chain’s transaction throughput issues while maintaining security and decentralization.\u003C\u002Fp>\n\u003Cp>Trust Models for Off-Chain Transactions:\u003Cbr>The Bitcoin expansion ecosystem leverages off-chain technologies to enhance transaction speed. Developers must ensure the trust mechanisms for off-chain transactions are sufficiently robust. For instance, the bidirectional payment channels in the Lightning Network require multi-signature technology and secure channel closure processes to prevent fund freezing or loss.\u003C\u002Fp>\n\u003Cp>Privacy and Transparency:\u003Cbr>The Lightning Network allows channel transactions to be conducted privately, enhancing user privacy and increasing regulatory challenges and the risk of malicious behavior. Layer 2 networks need to balance privacy and transparency by selectively disclosing certain transaction records to improve regulatory compliance.\u003C\u002Fp>\n\u003Cp>User Experience and Security:\u003Cbr>The complexity of the expansion ecosystem increases the difficulty of user operations. For example, managing channels in the Lightning Network may be unfriendly to ordinary users, raising the risk of operational errors. The Bitcoin expansion ecosystem can address these issues by designing more user-friendly interfaces and simplifying tools to improve the user experience and reduce security risks.\u003C\u002Fp>\n\u003Ch2 id=\"Conclusion\">Conclusion\u003C\u002Fh2>\n\u003Cp>The Bitcoin scaling ecosystem, through various Layer 2 solutions and innovative protocols, has significantly enhanced the functionality and transaction efficiency of the Bitcoin network, driving the development of emerging fields such as smart contracts, DeFi, and NFTs.\u003C\u002Fp>\n\u003Cp>However, as the ecosystem continues to expand, security issues have gradually emerged and must be given high attention by developers and the community. In the future, as the Bitcoin scaling ecosystem strives for higher transaction throughput and more diverse applications, it must continuously strengthen security mechanisms, optimize the user experience, balance privacy with transparency, and ensure broader and more robust development based on decentralization and security.\u003C\u002Fp>\n\u003Ch2 id=\"About-ScaleBit\">About ScaleBit\u003C\u002Fh2>\n\u003Cp>ScaleBit, a security subsidiary brand under BitsLab, is a blockchain security team providing solutions for Web3 mass adoption. With expertise in scaling technologies such as blockchain cross-chain solutions and zero-knowledge proofs (ZKP), we primarily offer detailed and cutting-edge security audits for ZKP, Bitcoin Layer 2, and cross-chain applications.\u003C\u002Fp>\n\u003Cp>The ScaleBit team consists of security experts with extensive experience in both academia and industry, dedicated to ensuring security for large-scale applications within scalable blockchain ecosystems.\u003C\u002Fp>\n\u003Ch2 id=\"About-BitsLab\">About BitsLab\u003C\u002Fh2>\n\u003Cp>BitsLab is a security organization committed to safeguarding and building the emerging Web3 ecosystem. Its vision is to become a highly respected Web3 security institution within the industry and among users. BitsLab operates three subsidiary brands: MoveBit, ScaleBit, and TonBit.\u003C\u002Fp>\n\u003Cp>BitsLab focuses on infrastructure development and security audits for emerging ecosystems, covering, but not limited to, ecosystems such as Sui, Aptos, TON, Linea, BNB Chain, Soneium, Starknet, Movement, Monad, Internet Computer, and Solana. Additionally, BitsLab demonstrates deep professional expertise in auditing various programming languages, including Circom, Halo2, Move, Cairo, Tact, FunC, Vyper, and Solidity.\u003C\u002Fp>\n\u003Cp>The BitsLab team is composed of top vulnerability research experts who have won multiple international CTF awards and have discovered critical vulnerabilities in well-known projects such as TON, Aptos, Sui, Nervos, OKX, and Cosmos.\u003C\u002Fp>\n\u003Cp>Visit BitsLab Official Website: \u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fbitslab.xyz\u002F\">https:\u002F\u002Fbitslab.xyz\u002F\u003C\u002Fa>\u003Cbr>Visit ScaleBit Official Website: \u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fwww.scalebit.xyz\u002F\">https:\u002F\u002Fwww.scalebit.xyz\u002F\u003C\u002Fa>\u003Cbr>BitsLab Official Twitter: \u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fx.com\u002F0xbitslab\">https:\u002F\u002Fx.com\u002F0xbitslab\u003C\u002Fa>\u003Cbr>Join the Official Telegram Community: \u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Ft.me\u002FBitsLabHQ\">https:\u002F\u002Ft.me\u002FBitsLabHQ\u003C\u002Fa>\u003C\u002Fp>","\u002Fmedia\u002Fscalebit\u002F2024\u002F12\u002F34ab0402273f9d452f3c0131a8d2fdc6.jpg","Bitcoin has evolved beyond being just a cryptocurrency, with its ecosystem expanding into Layer 2 solutions and applications that enhance transaction efficiency and support emerging fields like smart contracts, DeFi, and NFTs. However, this growth has introduced security challenges, including vulnerabilities, attacks, ","2024-12-20T03:15:00Z","11 min read","ScaleBit Selection A Look at the Bitcoin Ecosystem in 2024 Scaling Technologies and Security Incident Summary cover image",{"slug":60,"category":7,"categoryLabel":6,"subcategoryLabel":30,"authorName":41,"title":61,"excerpt":62,"contentHtml":63,"coverUrl":64,"seoTitle":61,"seoDescription":62,"seoImageUrl":64,"publishedAt":65,"updatedAt":47,"readTime":66,"cover":64,"hasCover":26,"coverAlt":67},"untold-story-of-bitcoin-layer-2-20240813","From Sovereign Rollup to zk-Rollup | Untold Story of Bitcoin Layer 2","Explore the evolution of Bitcoin Layer 2 solutions from Sovereign Rollups to zk-Rollups. Understand the controversies surrounding Citrea and BitVM, and delve into the latest advancements in ZKP technology and Sovereign Rollups.","\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F08\u002F5fb60a34391d429c4491b567c681330a.jpg\" alt=\"Untold-Story-of-Bitcoin-Layer-2\" title=\"From Sovereign Rollup to zk-Rollup: Untold Story of Bitcoin Layer 2\">\u003C\u002Fp>\n\u003Cp>Recently, Citrea, which claims to be the first Bitcoin Layer 2 project utilizing the zk-Rollup scheme, has come under scrutiny from the community just as it is about to launch on the devnet. The community members have accused Citrea of employing deceptive rhetoric to excessively hype their project. In this controversy, it is undoubtedly the best time to examine Citrea and BitVM.\u003C\u002Fp>\n\u003Cp>The origin of all this lies in the success of Zero-Knowledge Proofs (ZKP) on Ethereum-based Layer 2 solutions, prompting many to wonder if ZKP could be similarly utilized for Bitcoin Layer 2. Many developers, particularly the most critical ones, are pessimistic about the development of Bitcoin Layer 2, and their concerns are quite justified. Traditional Layer 2 solutions, such as Ethereum’s optimistic and zk-rollup, operate by off-chain computation and on-chain verification, which compresses data of the first layer and expands computational resources. However, since the Bitcoin network does not support complex logic validation, this approach is difficult to implement. Therefore, most Bitcoin Layer 2 projects claiming to utilize zero-knowledge proof have adopted a model known as Sovereign Rollup.\u003C\u002Fp>\n\u003Ch2 id=\"The-Sovereign-Rollup\">The Sovereign Rollup\u003C\u002Fh2>\n\u003Cp>In essence, the key to Sovereign Rollup is that the Bitcoin network is solely responsible for storing crucial commitment data as inscriptions within the Bitcoin Network, while all verifications are conducted off-chain (client verification). In a nutshell, data in the Bitcoin network is meaningless to a participant who is unaware of the rules. However, if participants understand how this data is used, any user can set up their node. From this perspective, Sovereign Rollup indeed holds significant positive implications—it meets some basic requirements of a Layer 2 network, such as the finality of data being protected by Bitcoin consensus, while also allowing for decentralized interpretation of Layer 2 data.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F08\u002F920bc53255097d089c5cc021f4f4dbdc.png\" alt=\"How-sovereign-rollup-works\" title=\"How sovereign rollup works: save proof on-chain, verified off-chain.\">\u003Cbr>\u003Cem>How sovereign rollup works: save proof on-chain, verified off-chain.\u003C\u002Fem>\u003C\u002Fp>\n\u003Cp>This approach might seem like a compromise compared to the first, but it is a subject of considerable debate. Many proponents of this approach believe that Bitcoin does not need to mimic Ethereum: supporters of the first approach are still viewing Bitcoin through an Ethereum lens, that is, they believe that both data storage and verification should occur on Layer 1. However, this is not necessary since data verification can significantly waste the efficiency of Layer 1. Ideally, any smart contract should be executed by only one node, and other nodes would only need to verify the result and its corresponding proof. There are better answers than requiring all Layer 1 nodes to perform verification. As far as we know, several projects have already implemented the concept of sovereignty, including Stacks, Bison, etc.\u003C\u002Fp>\n\u003Cp>This philosophy is at the core of Sovereign Rollup, based on the concept of client-side verification. Whether seen as a compromise or an innovation, just as the community was preparing to embrace a Bitcoin-specific Layer 2 technological path, BitVM was born.\u003C\u002Fp>\n\u003Ch2 id=\"BitVM\">BitVM\u003C\u002Fh2>\n\u003Cp>BitVM remains a mystery to most of the community: it seems to propose a solution for conducting ZKP verification on Layer 1, yet this solution eventually requires execution via an optimistic rollup method. Early iterations of BitVM even suggested simulating a CPU on Bitcoin to facilitate any conceivable computation, akin to building a computer using Redstone in Minecraft. These peculiar claims were scoffed at by many, who opted for more practical approaches like DLC or custodial accounts to ensure the security of Layer 2 assets. However, some projects believe that BitVM represents the future of Layer 2 and have invested heavily in research, including today’s focal point, Citrea. Understanding exactly what BitVM is, becomes crucial.\u003C\u002Fp>\n\u003Cp>To unravel the truth about BitVM, we will adopt the most direct approach: analyzing the BitVM Github Repository. At its core, the BitVM repository includes:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>A virtual environment for running Bitcoin Script.\u003C\u002Fli>\n\u003Cli>Auxiliary functions for assembling Bitcoin Script scripts.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>The current construction of BitVM primarily involves combining Bitcoin’s opcodes to facilitate more complex computations, rather than using OP_XOR to build computational components as mentioned in its initial versions. This is a more pragmatic approach. Let’s examine a relatively simple example to see how BitVM works: performing uint32-type integer calculations by combining opcodes.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F08\u002Fdf511d3fabb454eb59f353774696648d.png\" alt=\"bitvm\" title=\"BitVM is kinda like a Lego: formed by basic opcode.\">\u003Cbr>\u003Cem>BitVM is kinda like a Lego: formed by basic opcode.\u003C\u002Fem>\u003C\u002Fp>\n\u003Cp>In this example, we can identify two distinct elements: Opcodes and a series of new, encapsulated Opcodes. The ones prefixed with OP_ are native Bitcoin script Opcodes, while functions like u8_add_carry represent new Opcodes customized by BitVM. Clearly, the function u32_add itself is also used in the construction of further Opcodes.\u003C\u002Fp>\n\u003Cp>This may sound somewhat simplistic, but these functionalities should not be underestimated. They actually form the foundation for further constructing Zero-Knowledge Proofs (ZKP); through calculations with u32, one can progressively build up to BN254 computations, eventually leading to a proof construction system. From what can be seen in the repository, they have achieved many noteworthy accomplishments: they have managed to build verification functions based on Groth16, indicating they are close to ultimately constructing a usable ZKP system.\u003C\u002Fp>\n\u003Ch2 id=\"Citrea-Devnet-And-BitVM\">Citrea Devnet And BitVM\u003C\u002Fh2>\n\u003Cp>After gaining insight into the current status of BitVM, we naturally rejoice at its progress, which has significant positive implications for the entire Bitcoin Layer 2 ecosystem. However, we also notice a certain asynchrony between the explosive growth of Bitcoin Layer 2 and the development pace of BitVM. In a nutshell, projects claiming to utilize BitVM should more accurately be understood as “intending to use BitVM,” since, despite encouraging results, it is not yet ready for commercial deployment. In this context, Citrea’s claim to be the first Bitcoin-based zk-rollup inevitably sparks controversy.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F08\u002F84f1e7772a12041c4966a78065eab848.png\" alt=\"citrea\" title=\"When BitVM is incomplete, Citrea is a typical sovereign rollup\">\u003Cbr>\u003Cem>When BitVM is incomplete, Citrea is a typical sovereign rollup\u003C\u002Fem>\u003C\u002Fp>\n\u003Cp>Our primary concern is the current relationship between Citrea, BitVM, and ZKP. The best approach remains to delve into the Citrea project’s code to observe their progress. After analyzing their devnet repository, we discovered some interesting findings:\u003C\u002Fp>\n\u003Ch2 id=\"Sovereign-not-BitVM\">Sovereign, not BitVM\u003C\u002Fh2>\n\u003Cp>Currently, Citrea remains a typical Sovereign Rollup and has not achieved equivalence to Ethereum’s Layer 2 zk-rollup. In their recent devnet announcement, also mentioned that BitVM and their core component, Clementine, are not yet complete. The present state is such that Citrea’s network maintains the account states as a Merkle tree root, and on Bitcoin, this Merkle root change along with its corresponding ZKPs are recorded through Inscriptions. Importantly, inscribing on the Bitcoin network is unrestricted; hence, these ZKPs and the Merkle tree root need to be proactively verified by Citrea’s nodes. Meanwhile, Bitcoin only finalizes its state but does not ensure its correctness. Unfortunately, Citrea is still a typical Sovereign Rollup; its integration of BitVM is limited to the off-chain verification of ZKPs. Their bridge is in the traditional multisig-based manner.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F08\u002Fa88866703d0ba9a5f3314c7bcfb7a01b.png\" alt=\"Sovereign-approach\" title=\"Sovereign approach: inscription in Bitcoin does not ensure the correctness of proof\">\u003Cbr>\u003Cem>Sovereign approach: inscription in Bitcoin does not ensure the correctness of proof\u003C\u002Fem>\u003C\u002Fp>\n\u003Ch2 id=\"RISC-ZERO\">RISC ZERO\u003C\u002Fh2>\n\u003Cp>Besides the argument in BitVM, we also care about how ZKP is adopted in Cirtea devnet, and if there is anything new. For their ZKPs and zkEVM segment, Citrea utilizes an SDK provided by RISC ZERO as their construction foundation. RISC ZERO, a newer ZKP solution that emerged in 2022, shares a vision very similar to Cairo, to enable any generic computation with ZKPs through the creation of a zkVM. However, unlike Cairo, RISC ZERO is not a language in itself; it can be directly built using an SDK available in Rust, then computed through its custom zkVM. Apart from RISC ZERO, the Cairo VM based on zk-STARKs is also favored by Bitcoin Layer 2 projects like Bison. We have noticed this trending situation that projects adopting this model of general computation + zkVM, replacing the older model of zk language + zk Prover + zk Verifier. This shift is because Bitcoin currently cannot provide a zk Verifier, making the direct use of a zkVM undoubtedly a more economical and efficient approach for Sovereign Rollups.\u003C\u002Fp>\n\u003Ch2 id=\"Conclusion\">Conclusion\u003C\u002Fh2>\n\u003Cp>Regarding the recent controversy surrounding Citrea devnet, their team has clearly indicated that their compatibility with BitVM is not yet complete; this conclusion implies that a rollup fully inheriting Bitcoin’s security has not yet emerged. However, in observing the entire project, we have also witnessed ongoing innovation based on Bitcoin Layer 2, while the new projects still attempting the BitVM approach like Alpenlabs and Bitlayer. These developments continue to drive us to track and analyze the progress of Rollups within Bitcoin persistently.\u003C\u002Fp>\n\u003Ch2 id=\"About-ScaleBit\">About ScaleBit\u003C\u002Fh2>\n\u003Cp>ScaleBit, a subsidiary brand of BitsLab, is a blockchain security team that provides security solutions for Mass Adoption of Web3. With expertise in scaling technologies like Bitcoin Layer 2, Zero-Knowledge proofs, and blockchain interoperability, it provides meticulous and cutting-edge security audits for blockchain applications. The team comprises security professionals with extensive experience in both academia and enterprise.\u003C\u002Fp>\n\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fwww.scalebit.xyz\u002F?type=getAudit\">Requests a quote\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fwww.scalebit.xyz\u002F\">Website\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Ftwitter.com\u002Fscalebit_\">Twitter\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Ft.me\u002F@BitsLabHQ\">Telegram\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>","\u002Fmedia\u002Fscalebit\u002F2024\u002F08\u002F5fb60a34391d429c4491b567c681330a.jpg","2024-08-13T08:00:00Z","8 min read","From Sovereign Rollup to zk-Rollup | Untold Story of Bitcoin Layer 2 cover image",{"slug":69,"category":11,"categoryLabel":10,"subcategoryLabel":70,"authorName":41,"title":71,"excerpt":72,"contentHtml":73,"coverUrl":74,"seoTitle":71,"seoDescription":72,"seoImageUrl":74,"publishedAt":75,"updatedAt":47,"readTime":76,"cover":74,"hasCover":26,"coverAlt":77},"scalebit-completes-audit-of-bitsmiley","Products & Services","ScaleBit Completes Audit of bitSmiley","ScaleBit has completed comprehensive audits of bitSmiley's smart contracts and token, enhancing security and trust in Bitcoin-based DeFi services. Learn more about the audit results.","\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F9f12f47dc4dae0ddbf0c1ed9bfd35a75.jpg\" alt=\"ScaleBit-Completes-Audit-of-bitSmiley\" title=\"ScaleBit Completes Audit of bitSmiley\">\u003C\u002Fp>\n\u003Cp>ScaleBit, a leader in blockchain security auditing, is pleased to announce the successful completion of a thorough audit of bitSmiley, a cutting-edge protocol operating under the Fintegra framework on the Bitcoin blockchain. This audit reaffirms bitSmiley’s commitment to providing secure and robust decentralized financial services.\u003C\u002Fp>\n\u003Cp>BitSmiley is a protocol based on the Bitcoin blockchain under the Fintegra framework. It consists of three main components: a decentralized overcollateralized stablecoin protocol, a native trustless lending protocol, and a derivatives protocol. These components work together to provide a comprehensive financial ecosystem on the Bitcoin blockchain, enhancing its functionality and utility in the decentralized finance (DeFi) space.\u003C\u002Fp>\n\u003Cp>The detailed findings from the audits are publicly available, providing transparency:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\n\u003Cp>bitSmiley Smart Contract Audit Report:\u003Cbr>\u003Ca href=\"https:\u002F\u002Fscalebit.xyz\u002Freports\u002FBitsmiley-Smart-Contract-Final-Audit-Report.pdf\">https:\u002F\u002Fscalebit.xyz\u002Freports\u002FBitsmiley-Smart-Contract-Final-Audit-Report.pdf\u003C\u002Fa>\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\n\u003Cp>bitSmiley Token Audit Report:\u003Cbr>\u003Ca href=\"https:\u002F\u002Fscalebit.xyz\u002Freports\u002F20240618-Bitsmiley-Token-Final-Audit-Report.pdf\">https:\u002F\u002Fscalebit.xyz\u002Freports\u002F20240618-Bitsmiley-Token-Final-Audit-Report.pdf\u003C\u002Fa>\u003C\u002Fp>\n\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"About-ScaleBit\">About ScaleBit\u003C\u002Fh2>\n\u003Cp>ScaleBit, a subsidiary brand of BitsLab, is a blockchain security team that provides security solutions for Mass Adoption of Web3. With expertise in scaling technologies like Bitcoin Layer 2, Zero-Knowledge proofs, and blockchain interoperability, it provides meticulous and cutting-edge security audits for blockchain applications. The team comprises security professionals with extensive experience in both academia and enterprise.\u003C\u002Fp>\n\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fwww.scalebit.xyz\u002F?type=getAudit\">Requests a quote\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fwww.scalebit.xyz\u002F\">Website\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Ftwitter.com\u002Fscalebit_\">Twitter\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Ft.me\u002F@BitsLabHQ\">Telegram\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>","\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F9f12f47dc4dae0ddbf0c1ed9bfd35a75.jpg","2024-06-24T04:00:00Z","1 min read","ScaleBit Completes Audit of bitSmiley cover image",{"slug":79,"category":11,"categoryLabel":10,"subcategoryLabel":70,"authorName":41,"title":80,"excerpt":81,"contentHtml":82,"coverUrl":83,"seoTitle":80,"seoDescription":81,"seoImageUrl":83,"publishedAt":84,"updatedAt":47,"readTime":76,"cover":83,"hasCover":26,"coverAlt":85},"scalebit-completes-audit-of-kiloex","ScaleBit Completes Audit of KiloEx","ScaleBit has successfully completed a comprehensive audit of KiloEx, a decentralized exchange known for its rapid trading and innovative liquidity solutions, ensuring high security and functionality. Read the full audit report for more details.","\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F7c92f53355dfdc3ea2c87c2cfe8235e3.jpg\" alt=\"ScaleBit-Completes-Audit-of-KiloEx\" title=\"ScaleBit Completes Audit of KiloEx\">\u003C\u002Fp>\n\u003Cp>ScaleBit, a leading blockchain security firm, is proud to announce the successful completion of a comprehensive audit of KiloEx, a decentralized exchange renowned for its fast trading capabilities and innovative liquidity solutions. This audit ensures that KiloEx meets the highest security and functionality standards, reaffirming its commitment to providing a secure and efficient trading environment.\u003C\u002Fp>\n\u003Cp>Backed by Binance Labs, Foresight Ventures, and Manta Network, KiloEx is a decentralized exchange that merges the speed and real-time capabilities traders need with the security and benefits that liquidity providers value.\u003C\u002Fp>\n\u003Cp>The full audit report, detailing the scope, methodology, and examination results, is available to the public. It can be accessed here: \u003Ca href=\"https:\u002F\u002Fscalebit.xyz\u002Freports\u002FKilo---Vault2-Final-Audit-Report.pdf\">https:\u002F\u002Fscalebit.xyz\u002Freports\u002FKilo---Vault2-Final-Audit-Report.pdf\u003C\u002Fa>\u003C\u002Fp>\n\u003Ch2 id=\"About-ScaleBit\">About ScaleBit\u003C\u002Fh2>\n\u003Cp>ScaleBit, a subsidiary brand of BitsLab, is a blockchain security team that provides security solutions for Mass Adoption of Web3. With expertise in scaling technologies like Bitcoin Layer 2, Zero-Knowledge proofs, and blockchain interoperability, it provides meticulous and cutting-edge security audits for blockchain applications. The team comprises security professionals with extensive experience in both academia and enterprise.\u003C\u002Fp>\n\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fwww.scalebit.xyz\u002F?type=getAudit\">Requests a quote\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fwww.scalebit.xyz\u002F\">Website\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Ftwitter.com\u002Fscalebit_\">Twitter\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Ft.me\u002F@BitsLabHQ\">Telegram\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>","\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F7c92f53355dfdc3ea2c87c2cfe8235e3.jpg","2024-06-24T02:00:00Z","ScaleBit Completes Audit of KiloEx cover image",{"slug":87,"category":7,"categoryLabel":6,"subcategoryLabel":17,"authorName":41,"title":88,"excerpt":89,"contentHtml":90,"coverUrl":91,"seoTitle":88,"seoDescription":89,"seoImageUrl":91,"publishedAt":92,"updatedAt":47,"readTime":93,"cover":91,"hasCover":26,"coverAlt":94},"best-solana-security-practices-guide","Best Solana Security Practices: A Comprehensive Guide for Developers","Discover essential Solana security practices to enhance your blockchain development. Learn about account validation, secure coding, and preventing vulnerabilities to leverage Solana's high throughput and low latency for innovative decentralized applications.","\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F5fb6aff597a23763f734baddf4dbe1ae.jpg\" alt=\"solana-security-practices-guide\" title=\"Solana Security Practices\">\u003C\u002Fp>\n\u003Cp>Solana stands as a high-performance blockchain designed to facilitate decentralized applications and crypto-currencies. It employs a unique consensus mechanism known as Proof of History (PoH), combined with the efficiency of Proof of Stake (PoS), to enhance the network’s scalability. Through this hybrid protocol, Solana achieves remarkable speeds and efficiency, processing thousands of transactions per second while maintaining lower transaction costs.\u003C\u002Fp>\n\u003Cp>The architecture of Solana not only ensures rapid processing but also maintains a high degree of security and decentralization. Solana’s innovative approach is exemplified by its ability to support smart contracts and decentralized finance (DeFi) applications, making it a competitive player in the blockchain space.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F5334c3ad00fd5823f22be19ad198c685.png\" alt=\"solana-ecosystem-map\" title=\"Solana Ecosystem Map\">\u003C\u002Fp>\n\u003Cp>When diving into Solana development, it’s imperative to consider the following advice. These recommendations are pivotal for refining code, bolstering security, and harmonizing with the unique features of Solana. By following these best practices, developers can boost code efficiency, strengthen security protocols, and fully leverage the distinctive elements of Solana’s architecture. This adherence to guidelines ensures that developers can take full advantage of Solana’s high throughput and low latency capabilities, paving the way for innovative and scalable decentralized applications.\u003C\u002Fp>\n\u003Ch2 id=\"0X00-Solana-Specific-Issues\">0X00: Solana Specific Issues\u003C\u002Fh2>\n\u003Ch3 id=\"CHECK-THE-ACCOUNT\">CHECK THE ACCOUNT\u003C\u002Fh3>\n\u003Cp>In Solana, since all accounts are provided as inputs when invoking a Solana program, users can supply arbitrary accounts and there’s no built-in stopping a malicious user from doing so with fake data. Therefore, Solana programs must check the validity of the input accounts.\u003C\u002Fp>\n\u003Ch3 id=\"1-Account-ownership-validation\">1. Account ownership validation\u003C\u002Fh3>\n\u003Cp>If I could only tell you one piece of advice about Solana auditing, it would be:\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Always CHECK THE OWNERSHIP!\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>The designated public key is the exclusive identifier permitted to modify the data of the account in question. Ownership of the account by any individual or entity other than the anticipated owner introduces the risk of the presence of malevolent data, rendering the account unreliable for secure transactions. It is imperative that the integrity of account ownership is verified to maintain trust within the system.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002Fa5af7f2f38afb12f990982683f08b4cc.png\" alt=\"solana-attack\" title=\"Solana Attack\">\u003C\u002Fp>\n\u003Ch4 id=\"Example\">Example\u003C\u002Fh4>\n\u003Cp>The vulnerable code segment:\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F3dd65685277178b007ca80a8b0b51559.png\" alt=\"solana-attack-example-1\" title=\"Solana Attack Example 1\">\u003C\u002Fp>\n\u003Cp>This is a common refund function. It first takes out each required account and deserializes them into instances.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002Fa20019c94fddd1e067b8ffe4ba163e7b.png\" alt=\"solana-attack-example-2\" title=\"Solana Attack Example 2\">\u003C\u002Fp>\n\u003Cp>The config object is particularly important. It records the admin information. Only by passing the check can the business logic continue to be executed.\u003C\u002Fp>\n\u003Cp>But here’s the problem: you don’t know who created the config. In fact, in this \u003Cstrong>unpack()\u003C\u002Fstrong> function, it doesn’t check who created the account. So we always have to check who the owner of the account is – make sure it comes from a safe creator.\u003C\u002Fp>\n\u003Cp>The fixed code:\u003Cbr>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F87dc3c02b9be364dbc8528a1f73f9a21.png\" alt=\"solana-attack-example-3\" title=\"Solana Attack Example 3\">\u003C\u002Fp>\n\u003Ch3 id=\"2-Account-state-validation\">2. Account state validation\u003C\u002Fh3>\n\u003Cp>Omitting validation for account state or data is a critical error that developers might inadvertently commit. Take, for instance, the Solana token-lending program, where a reserve’s data linked to a specific lending market is defined by a given structure. The initialization of the reserve will trigger the creation of these fields.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F4e8b9c4913ad855dd7fd8017fdb99136.png\" alt=\"solana-attack-example-4\" title=\"Solana Attack Example 4\">\u003C\u002Fp>\n\u003Ch4 id=\"Example-1\">Example\u003C\u002Fh4>\n\u003Cp>On August 19, 2021, at 12:40 GMT, a security breach was identified in the Solend smart contract. An attacker exploited a vulnerability in the authentication check of the \u003Cstrong>UpdateReserveConfig ()\u003C\u002Fstrong> function. This manipulation made accounts with outstanding loans vulnerable to liquidation and artificially increased the borrow Annual Percentage Yield (APY) to an exorbitant 250% across all markets. Fortunately, the Solend team promptly detected and thwarted the malicious attempt, ensuring no funds were compromised. Although five users experienced liquidation due to this incident, they were fully compensated with approximately \\$16,000 from the liquidator’s excess profits.\u003C\u002Fp>\n\u003Cp>The vulnerable code segment:\u003Cbr>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F26664b580fa1f0b8d3d9378531100639.png\" alt=\"solana-attack-example-5\" title=\"Solana Attack Example 5\">\u003C\u002Fp>\n\u003Cp>Can you see the problem?\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Lending pool may not match config.\u003C\u002Fstrong> The checks above were insufficient, as the attacker was able to pass in any lending market they created and owned but change other lending pool configration.In addition to paying attention to the ownership of the accounts, we also need to pay attention to the status and consistency of the accounts.\u003C\u002Fp>\n\u003Cp>The fixed code:\u003Cbr>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002Ff50d72d86d1098ac2b50f9324c22b92b.png\" alt=\"solana-attack-example-6\" title=\"Solana Attack Example 6\">\u003C\u002Fp>\n\u003Ch3 id=\"3-Account-types-check\">3. Account types check\u003C\u002Fh3>\n\u003Cp>The problem is always like this: the user can pass in any account. When the data in the account is deserialized into a type, no one knows what type the bytes is. It all depends on how you deserialize. Sometimes this kind of problem just causes the smart contract to not work, and sometimes some genius hackers will construct some serious damage attacks.\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F94753c055388f942c8a6882a1d4368b6.png\" alt=\"solana-attack-example-7\" title=\"Solana Attack Example 7\">\u003C\u002Fp>\n\u003Ch4 id=\"Example-2\">Example\u003C\u002Fh4>\n\u003Cp>The vulnerable code segment:\u003Cbr>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F45832ee9802735932468ecd96ff6e37b.png\" alt=\"solana-attack-example-8\" title=\"Solana Attack Example 8\">\u003C\u002Fp>\n\u003Cp>We provide a common attack idea, let’s say the same bytes can be deserialized to \u003Cstrong>TypeA\u003C\u002Fstrong> or \u003Cstrong>TpyeB\u003C\u002Fstrong>:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\n\u003Cp>\u003Cstrong>TypeA (config)\u003C\u002Fstrong> is easy to create in the program.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\n\u003Cp>\u003Cstrong>TypeB (User)\u003C\u002Fstrong> is difficult to construct because it may involve the management of funds and permissions.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\n\u003Cp>We will construct \u003Cstrong>typeA\u003C\u002Fstrong> to convert it into \u003Cstrong>typeB\u003C\u002Fstrong>. In this way, we can use this created account to pass the program check and construct some permissions and fund theft.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002Fd42d13281a241920aea8336da4bb7bbb.png\" alt=\"solana-attack-example-9\" title=\"Solana Attack Example 9\">\u003C\u002Fp>\n\u003Cp>When we create a new account, we set the TYPE field to a unique value for that type of account. Our deserialization function must also verify the type, and it will throw an error if the account does not have the type we expect\u003C\u002Fp>\n\u003Ch2 id=\"0x01-General-Issues\">0x01: General Issues\u003C\u002Fh2>\n\u003Ch3 id=\"1-Integer-overflow-or-underflow\">1. Integer overflow or underflow\u003C\u002Fh3>\n\u003Cp>When programming, it is very important to consider computational overflow. Most programming languages may encounter overflow issues when dealing with large numbers or high-precision operations. Simply using basic arithmetic operators such as addition (+), subtraction (-), multiplication (*), and division (\u002F) can lead to unexpected results, especially when the values operated on exceed the range that the language’s data types can represent.\u003C\u002Fp>\n\u003Ch4 id=\"Example-3\">Example\u003C\u002Fh4>\n\u003Cp>The vulnerable code segment:\u003Cbr>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002Fad99a43c40b19186d0b493ca65168d35.png\" alt=\"solana-attack-example-10\" title=\"Solana Attack Example 10\">\u003C\u002Fp>\n\u003Cp>To avoid the risk mentioned above, it is recommended to use safer mathematical libraries for computation. These libraries typically provide mechanisms to prevent overflow, are capable of handling large number operations, and ensure the accuracy and reliability of the computational results. For example, they may use special data types or algorithms to extend the range of numerical representation, or provide additional checks during operations to capture potential overflows.\u003C\u002Fp>\n\u003Cp>The fixed code:\u003Cbr>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002Faa4aef9adbcc97ef9ac852edb776dd0c.png\" alt=\"solana-attack-example-11\" title=\"Solana Attack Example 11\">\u003C\u002Fp>\n\u003Ch3 id=\"2-Verify-Program-ID\">2. Verify Program ID\u003C\u002Fh3>\n\u003Cp>It is essential to meticulously identify and examine the CPI (cross-program call) code logic within the program. This involves ensuring that the code rigorously incorporates a verification check for the target program’s identifier when executing CPI. Such a check is paramount in confirming the authenticity and integrity of the target program. It acts as a safeguard against unauthorized or malicious entities attempting to invoke the program, thereby preserving the security and reliability of the system.\u003C\u002Fp>\n\u003Ch4 id=\"Example-4\">Example\u003C\u002Fh4>\n\u003Cp>The vulnerable code segment:\u003Cbr>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F7d63132e0dc56e553602aa4c555ec15e.png\" alt=\"solana-attack-example-12\" title=\"Solana Attack Example 12\">\u003C\u002Fp>\n\u003Cp>Ensuring that this verification step is in place is a critical aspect of security, as it helps maintain the trustworthiness of cross-program interactions within the software environment.\u003C\u002Fp>\n\u003Cp>The fixed code:\u003Cbr>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F759e178a6f40786dd0e4e034f5cfb3b4.png\" alt=\"solana-attack-example-13\" title=\"Solana Attack Example 13\">\u003C\u002Fp>\n\u003Ch3 id=\"3-Initialization-Front-Running\">3. Initialization Front Running\u003C\u002Fh3>\n\u003Cp>When initializing the contract administrator’s permissions, you may face a scenario where the address of the first call to this function is set as the administrator. This method may face a preemptive attack, causing the administrator’s settings to not be executed as expected. The attack in this scenario can be deduced into many situations.\u003Cbr>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F88e90998df4aced1146ff40c81cf2496.png\" alt=\"solana-attack-example-14\" title=\"Solana Attack Example 14\">\u003C\u002Fp>\n\u003Ch4 id=\"Example-5\">Example\u003C\u002Fh4>\n\u003Cp>Let’s say I have a PDA which maintains the global state of my program. This is like a singleton. And the following snippets of code initialize it.\u003C\u002Fp>\n\u003Cp>The vulnerable code segment:\u003Cbr>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002Ffa6843dadadd2738705253333ad70097.png\" alt=\"solana-attack-example-15\" title=\"Solana Attack Example 15\">\u003C\u002Fp>\n\u003Cp>And here is the struct part:\u003Cbr>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F710154598c1f79340452d128617909ac.png\" alt=\"solana-attack-example-16\" title=\"Solana Attack Example 16\">\u003C\u002Fp>\n\u003Cp>We should set more comprehensive permission checks for functions like these where the initial call is completely different from the rest of the calls.\u003C\u002Fp>\n\u003Cp>The fixed code:\u003Cbr>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F75f8929b3ab3b6fd6273a5a89d0cbed8.png\" alt=\"solana-attack-example-17\" title=\"Solana Attack Example 17\">\u003C\u002Fp>\n\u003Ch2 id=\"0x02-Real-Case-Scenario\">0x02: Real Case Scenario\u003C\u002Fh2>\n\u003Ch3 id=\"1-Check-Security-Dependency-Chain\">1. Check Security Dependency Chain\u003C\u002Fh3>\n\u003Cp>Once a function needs to interact with multiple contracts, there will be multiple address inputs. We need to confirm whether the constraints of these addresses are correct, and more importantly:\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Once the data security of a certain type needs to be guaranteed by another type, then this type must be safe. Otherwise, all these security dependencies will become invalid.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Ch4 id=\"Example-6\">Example\u003C\u002Fh4>\n\u003Cp>The Brrr program bug allowed attackers to mint \\$CASH tokens at minimal cost by exploiting unchecked Bank accounts and using fake accounts to bypass collateral requirements. This compromised the integrity of the \\$CASH minting process, which should have been secured by Arrow LP tokens as collateral.\u003C\u002Fp>\n\u003Cp>The vulnerable code segment:\u003Cbr>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F4fbb7667c476c53298bfef9451adddc9.png\" alt=\"solana-attack-example-18\" title=\"Solana Attack Example 18\">\u003C\u002Fp>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002Fbcb03ffa8c17100f6fb820b73769ffdd.png\" alt=\"solana-attack-example-19\" title=\"Solana Attack Example 19\">\u003C\u002Fp>\n\u003Cp>It can be seen that\u003C\u002Fp>\n\u003Col>\n\u003Cli>\n\u003Cp>The \u003Cstrong>crate_mint\u003C\u002Fstrong> check depends on \u003Cstrong>crate_token.mint\u003C\u002Fstrong>,\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\n\u003Cp>The \u003Cstrong>crate_token\u003C\u002Fstrong> check depends on \u003Cstrong>crate_collateral_tokens.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\n\u003Cp>However, \u003Cstrong>crate_collateral\u003C\u002Fstrong> does not make more checks in the structure. It can be forged in the security source, so all addresses that rely on it as a security check can be forged.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F698ff9596c7d864e5c6eecc963500941.png\" alt=\"solana-attack-example-20\" title=\"Solana Attack Example 20\">\u003C\u002Fp>\n\u003Cp>Once type3 is unsafe then \u003Cstrong>all relative addresses are under risk.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Repair suggestions: sort out security dependencies and ensure that your security sources are checked.\u003C\u002Fp>\n\u003Ch3 id=\"2-Uncheck-Status-of-Account\">2. Uncheck Status of Account\u003C\u002Fh3>\n\u003Cp>Once the input address is not type-checked, it may be executed successfully in unrelated functions, which may cause serious consequences.\u003C\u002Fp>\n\u003Ch4 id=\"Example-7\">Example\u003C\u002Fh4>\n\u003Cp>The vulnerable code segment:\u003Cbr>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F0e266096f2ace2397a5aca74fbf8bc37.png\" alt=\"solana-attack-example-21\" title=\"Solana Attack Example 21\">\u003C\u002Fp>\n\u003Cp>For an address like candy_machine, it is not type checked, but only checked for contract source. This may cause all addresses created by this contract to pass this part of the check. Once the same field is modified in \u003Cstrong>TypeA\u003C\u002Fstrong> and \u003Cstrong>TypeB\u003C\u002Fstrong>, this may lead to asset loss.Or If the function does not check the user’s initialization status,it can exploit this problem and perform what is known as a re-initialization attack.\u003C\u002Fp>\n\u003Cp>Repair suggestion: If you want to use an address as a parameter, please ensure its type or status to avoid function misuse or attack.\u003C\u002Fp>\n\u003Ch3 id=\"3-Protocol-Vulnerabilities\">3. Protocol Vulnerabilities\u003C\u002Fh3>\n\u003Cp>Now we need to jump out of smart contracts and look at security issues at a higher level. Many problems come from specific business logic design rather than implementation. There is no universal review procedure for protocol vulnerabilities, so we can only focus on the protocol itself.\u003C\u002Fp>\n\u003Cp>What I can tell you is that vulnerabilities most often occur near judgment statements. Judgment and jump are generally used in protocols to handle some different situations. At this time, we need to think in a certain direction and consider constructing some special situations to bypass or enter these functions, which may cause exceptions. Based on these exceptions, we can consider constructing attack methods.\u003C\u002Fp>\n\u003Ch4 id=\"Example-8\">Example\u003C\u002Fh4>\n\u003Cp>The vulnerable code segment:\u003C\u002Fp>\n\u003Cp>This function is used to calculate the asset value and borrowing of a market position. When the account is default, it exits.\u003Cbr>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F0d1dadfa705ac26af6b97df1518199d8.png\" alt=\"solana-attack-example-22\" title=\"Solana Attack Example 22\">\u003C\u002Fp>\n\u003Cp>The introduction of the new feature that allows the closing of accounts, specifically through the  \u003Cstrong>close_loan_account\u003C\u002Fstrong> and \u003Cstrong>close_collateral_account\u003C\u002Fstrong> instructions, has led to a critical issue. When these instructions are executed, they reset the \u003Cstrong>pos.account\u003C\u002Fstrong> to \u003Cstrong>Pubkey::default()\u003C\u002Fstrong>. This change causes the system to overlook any subsequent loans and collateral linked to the first \u003Cstrong>Pubkey::default()\u003C\u002Fstrong> it encounters, leading to miscalculations in loan and collateral values.\u003C\u002Fp>\n\u003Cp>Ensure a thorough review of the protocol.\u003C\u002Fp>\n\u003Ch2 id=\"conclusion\">conclusion\u003C\u002Fh2>\n\u003Cp>In conclusion, adhering to the best practices in Solana development is not just beneficial; it’s essential for crafting robust and efficient decentralized applications. By fine-tuning code, fortifying security measures, and aligning with Solana’s architecture, developers can harness the full potential of its rapid processing and minimal delay. This commitment to excellence sets the stage for a new era of decentralized solutions that are not only innovative but also scalable and reliable, ensuring a strong foundation for the future of blockchain technology.\u003C\u002Fp>\n\u003Ch2 id=\"About-ScaleBit\">About ScaleBit\u003C\u002Fh2>\n\u003Cp>ScaleBit, a subsidiary brand of BitsLab, is a blockchain security team that provides security solutions for Mass Adoption of Web3. With expertise in scaling technologies like Bitcoin Layer 2, Zero-Knowledge proofs, and blockchain interoperability, it provides meticulous and cutting-edge security audits for blockchain applications. The team comprises security professionals with extensive experience in both academia and enterprise.\u003C\u002Fp>\n\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fwww.scalebit.xyz\u002F?type=getAudit\">Requests a quote\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fwww.scalebit.xyz\u002F\">Website\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Ftwitter.com\u002Fscalebit_\">Twitter\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Ft.me\u002F@BitsLabHQ\">Telegram\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>","\u002Fmedia\u002Fscalebit\u002F2024\u002F06\u002F5fb6aff597a23763f734baddf4dbe1ae.jpg","2024-06-14T10:00:00Z","10 min read","Best Solana Security Practices: A Comprehensive Guide for Developers cover image",{"slug":96,"category":7,"categoryLabel":6,"subcategoryLabel":30,"authorName":41,"title":97,"excerpt":98,"contentHtml":99,"coverUrl":100,"seoTitle":97,"seoDescription":101,"seoImageUrl":100,"publishedAt":102,"updatedAt":47,"readTime":93,"cover":100,"hasCover":26,"coverAlt":103},"exploring-security-and-potential-of-dlcs-discreet-log-contracts","Exploring the Security and Potential of DLCs (Discreet Log Contracts)","Discreet Log Contracts (DLCs) are a type of Bitcoin smart contract gaining traction for their potential in Bitcoin lending and cross-chain transactions. This article explores DLC technology, its applications, and key security issues, emphasizing the importance of reliable oracles and proper implementation to avoid risks.","\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F05\u002Fc34c3013664e1d4ec50f725e1542ee0e.png\" alt=\"exploring-security-and-potential-of-dlcs\" title=\"Exploring the Security and Potential of DLCs\">\u003C\u002Fp>\n\u003Chr>\n\u003Cp>\u003Cem>This article is co-authored by ScaleBit, \u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fwww.dlc.link\u002F\">DLC.Link\u003C\u002Fa>, and \u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fbisonlabs.io\u002F\">Bison Labs\u003C\u002Fa>.\u003C\u002Fem>\u003C\u002Fp>\n\u003Cp>Discreet Log Contracts (DLCs) have been around since 2020, gaining traction over the past few years. The concept has recently been reignited as multiple projects explore Bitcoin Layer-2 solutions. Developers envision DLCs’ potential in Bitcoin lending, cross-chain transactions, and more complex custom contracts. Given these expectations, most people refer to DLCs as Bitcoin smart contracts. However, the Bitcoin network cannot handle complex logic verification. Therefore, DLCs should be understood as an agreement with predictable outcomes and a finite state space. Overhyping DLC’s capabilities and applying them in inappropriate scenarios may introduce unpredictable risks to projects.\u003C\u002Fp>\n\u003Cp>In this article, we provide an overview of the DLC technology from a security perspective, enumerate its current common use cases, and analyze potential security issues that may arise.\u003C\u002Fp>\n\u003Ch2 id=\"The-Basics-of-DLCs\">The Basics of DLCs\u003C\u002Fh2>\n\u003Cp>DLCs are specifications that allow Bitcoin scripts to determine how the final scripts should be unlocked based on data inside the Bitcoin network (such as timestamps and hash values) or from an external oracle.\u003C\u002Fp>\n\u003Ch3 id=\"Example-1-Bitcoin-Price-Bet\">Example 1: Bitcoin Price Bet\u003C\u002Fh3>\n\u003Cp>Alice and Bob agree to a bet on Bitcoin’s price movement. They set the conditions that if Bitcoin’s price exceeds \\$65,000 within the next two weeks, Bob will pay Alice \\$100. Conversely, if the price falls below \\$65,000, Alice will pay Bob \\$100. Instead of involving a third party to hold their funds, they use a DLC to enter into the agreement, allowing them to manage the bet directly between themselves with their funds. The agreement can be divided into three steps:\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 1: Initial Contract\u003C\u002Fstrong>\u003Cbr>First, Alice and Bob will jointly create a 2-of-2 multi-sig address A and fund it with \\$100 each.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 2: Contract Execution Transactions\u003C\u002Fstrong>\u003Cbr>Next, Alice and Bob, along with an oracle\u002Freferee, construct two transactions using the funds in the multi-sig address, according to the possible outcomes. These two transactions are called Contract Execution Transactions (CETs). Both transactions require unlocking with a 3-of-3 multisig, where both parties to the transaction have provided two signatures, and the third signature will be provided by the oracle based on the final result.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 3: Reveal\u003C\u002Fstrong>\u003Cbr>After obtaining the result, the oracle will reveal the signature of one of the transactions, allowing Alice and Bob to execute the transaction according to the result.\u003C\u002Fp>\n\u003Cp>This simple example illustrates the essence of a DLC: Because each outcome corresponds to a separate transaction, a DLC cannot handle overly complex transactions or allow too many participants to join. These characteristics determine its relatively limited functionality.\u003C\u002Fp>\n\u003Ch3 id=\"Example-2-Timed-Automatic-Unlock-Contract\">Example 2: Timed Automatic Unlock Contract\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Step 1: Initial Contract Creation\u003C\u002Fstrong>\u003Cbr>First, Alice creates a smart contract and deposits a certain amount of funds into it. This contract includes a timer function, set to automatically unlock the funds after a specified future time point.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 2: Optional Early Unlock Mechanism\u003C\u002Fstrong>\u003Cbr>Bob does not participate directly in the deposit of funds but is authorized to unlock these funds early under specific conditions. These conditions could be a predetermined event such as a request from Alice or certain criteria met as judged by the contract’s internal logic.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Step 3: Fund Unlock\u003C\u002Fstrong>\u003Cbr>If Bob does not exercise the early unlock function under the established conditions, the contract’s timer will automatically execute when the predetermined time is reached, returning the funds to Alice. If Bob triggers the early unlock mechanism and meets the conditions set by the contract, the funds can be released to Alice earlier or handled according to other stipulations in the contract.\u003C\u002Fp>\n\u003Cp>In the next section, we will discuss some scenarios and projects currently using DLCs.\u003C\u002Fp>\n\u003Ch2 id=\"The-DLC-Bridge\">The DLC Bridge\u003C\u002Fh2>\n\u003Cp>The most well-known and typical implementation of the DLC concept is managing cross-chain assets. Projects, such as DLC.Link and Bison Lab, are ambitious in their aspirations for DLCs, aiming to leverage it to create a superior cross-chain value transfer method compared to traditional bridges. Traditional cross-chain solutions require users to transfer funds to a specific address, which is almost entirely controlled by the project team. Despite increasing the credibility of such solutions through multi-signature and decentralized networks, they still cannot avoid the risk of collective malfeasance or non-responsiveness by wallet owners, leading to asset loss for participants.\u003C\u002Fp>\n\u003Cp>DLCs offer a different approach to cross-chain transactions. Simply put, DLC must also be executed through a specific address, similar to a cross-chain bridge. However, the difference lies in the fact that the controller of the DLC is an oracle, not any participant of the assets. This is why many claim that DLCs can achieve trustless, decentralized asset cross-chain transactions. However, this assertion sounds somewhat peculiar because from the previous description, DLCs seem not much different from a multi-signature account. To understand this better, let’s consider a simple example: suppose Alice and Bob are betting on the weather outside the room, but since the room has no windows, they can only ask a third person, Charlie to referee their bet. Unfortunately, Charlie is actually Alice’s friend, so Bob must be very careful when asking.\u003C\u002Fp>\n\u003Col>\n\u003Cli>Bob asks Charlie, “Alice and I are having a bet. If it rains, Alice wins, and if it’s sunny, I win. Please tell me the exact weather.” The result is obvious: regardless of the actual weather outside, Charlie might collude with Alice to influence the outcome.\u003C\u002Fli>\n\u003Cli>Bob asks Charlie, “Please tell me what the weather is outside.” If Charlie doesn’t know anything about the bet, he will likely describe the actual situation.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Through this example, we can clearly understand the difference between oracles and typical asset participants. Oracles are responsible for providing accurate descriptions but do not necessarily understand the potential outcomes of these descriptions. While implementations may vary between projects, they generally follow a similar approach. In the case of DLCs bridges, when any participant adds assets, such as 1 BTC to the DLC, they receive 1 dlcBTC. When participants attempt to unlock their BTC, the oracle determines if they can provide assets equal to or greater than 1 dlcBTC. If they can, the oracle signs, allowing the participant to unlock their BTC. Compared to project parties, oracles are relatively more trustworthy. Firstly, because DLC addresses are created jointly by users and oracles, the oracle cannot steal these assets. Secondly, oracles are indifferent to specific actions and focus solely on real information, reducing potential conflicts of interest. Therefore, using DLCs to construct a novel cross-chain bridge model indeed offers unique advantages.\u003C\u002Fp>\n\u003Ch2 id=\"The-Security-Concern\">The Security Concern\u003C\u002Fh2>\n\u003Cp>Indeed, ideally, using DLCs could make the cross-chain process safer and give users more autonomy over their cross-chain assets. However, this is only in an ideal scenario. Given that current solutions based on DLCs are not yet very mature, we believe it is necessary to highlight some security concerns. We consider the most noteworthy aspects to be the reliability of oracles, the introduction of hash time locks, and the on-chain\u002Foff-chain deployment issue.\u003C\u002Fp>\n\u003Ch3 id=\"1-Reliability-of-Oracles\">1. Reliability of Oracles\u003C\u002Fh3>\n\u003Cp>This issue can be considered the most important and challenging aspect of DLCs applications. As mentioned earlier, a perfect oracle should have zero knowledge of the state of the DLC and only respond to queries for information. However, in reality, since Bitcoin is completely transparent, oracles can actively gather information about the DLC and potentially collude with other participants. Meanwhile, oracles need to provide public keys for the DLC script, further increasing the possibility of oracle interference with the normal functioning of the DLC.\u003C\u002Fp>\n\u003Cp>There are two different levels of this issue. The first level is relatively easier to address, namely that oracles should not participate in the creation process of the DLC. Specifically, participants should request oracles to generate a series of public keys, referred to as a public key box. Each public key would have a pre-negotiated rule, and if the conditions are met, the oracle would sign it. This way, participants can directly use these public keys to generate DLC without the direct involvement of oracles in the DLC creation process.\u003C\u002Fp>\n\u003Cp>The second level is relatively more difficult to solve, namely that oracles should not be able to access a DLC information. This is very difficult to achieve but poses significant potential risks. There is one imperfect way to achieve this. The first method is to use Schnorr signatures, requiring multiple oracles to sign the same information. Because actively querying the DLC script and providing incorrect information is equivalent to being a malicious node, increasing the number of nodes in the network and using threshold signatures can greatly reduce the likelihood of success for malicious nodes. Before more reliable solutions emerge, this paper believes that the security of multi-signature oracles is essential.\u003C\u002Fp>\n\u003Ch3 id=\"2-Introduction-of-Hash-Time-Locks\">2. Introduction of Hash Time Locks\u003C\u002Fh3>\n\u003Cp>Hash time locks (HTLCs) play a crucial role in ensuring the security and trustlessness of cross-chain transactions. These cryptographic constructs enable conditional payments between parties, where funds are released only when certain conditions, such as a pre-image of a hash, are met within a specified time frame. The use of traditional hash time locks to manage DLC scripts in lending-related DLC scenarios encourages users to engage in fast transactions. However, by incorporating HTLCs into DLC protocols, it adds an extra layer of security by enforcing time-bound commitments and preventing participants from unfairly locking or accessing funds. As mentioned earlier, oracles provide a series of public keys as conditions for unlocking DLC. It’s important to note that since each public key corresponds to specific information (such as the rise or fall of Bitcoin), the same public key may be used in multiple DLCs. Therefore, when setting hash time locks, it’s crucial not to use content related to oracle’s public keys for construction.\u003C\u002Fp>\n\u003Cp>Furthermore, since DLCs often involve conditional judgments, careful attention is needed to ensure that DLCs do not unfairly impact the unlocking process for both parties. For example, while Party A may be able to unlock assets, Party B may face restrictions due to certain DLC limitations, leading to unjust outcomes. Therefore, thorough consideration of these factors is essential to mitigate potential security vulnerabilities in lending-related DLC transactions.\u003C\u002Fp>\n\u003Ch3 id=\"3-User’s-Involvement\">3. User’s Involvement\u003C\u002Fh3>\n\u003Cp>User involvement in DLCs introduces a key security feature by making the original asset holders trusted, essential participants in any transfer of assets. By requiring the asset holder’s signature for any movement of funds, this approach ensures that assets can only be transferred with the user’s explicit authorization, significantly enhancing security.\u003C\u002Fp>\n\u003Cp>This method leverages the concept of user-controlled security, where the user is the final authority in validating and approving transactions. In practice, this means that any transaction attempt that lacks the direct consent of the user, evidenced through their unique digital signature, is automatically rejected. This reduces the risk of unauthorized access and asset transfer, as malicious actors would need to compromise the user’s private keys to initiate a transaction, a significantly more challenging feat.\u003C\u002Fp>\n\u003Cp>Furthermore, incorporating user signatures into the transaction process not only mitigates risks related to external threats but also enhances the accountability of all parties involved in the DLC. It provides a transparent mechanism for tracking asset movements, ensuring that each step of the transaction is recorded and verifiable.\u003C\u002Fp>\n\u003Cp>By implementing such a security measure, DLC protocols can foster a higher degree of trust and reliability in cross-chain transactions, thereby encouraging broader adoption and utilization of these technologies in various financial sectors.\u003C\u002Fp>\n\u003Ch2 id=\"Conclusion\">Conclusion\u003C\u002Fh2>\n\u003Cp>Although DLCs have been around for some time and have become more flexible and powerful with the Taproot upgrade, their security has not undergone extensive testing. We are pleased to see DLC technology regain attention and spark a technical frenzy, but the potential security issues cannot be ignored. We will continue to monitor the development of DLCs and provide ongoing insights and analysis.\u003C\u002Fp>\n\u003Cp>\u003Cem>This article is co-authored by ScaleBit, \u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fwww.dlc.link\u002F\">DLC.Link\u003C\u002Fa>, and \u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fbisonlabs.io\u002F\">Bison Labs\u003C\u002Fa>.\u003C\u002Fem>\u003C\u002Fp>\n\u003Ch2 id=\"About-ScaleBit\">About ScaleBit\u003C\u002Fh2>\n\u003Cp>ScaleBit, a subsidiary brand of BitsLab, is a blockchain security team that provides security solutions for Mass Adoption of Web3. With expertise in scaling technologies like Bitcoin Layer 2, Zero-Knowledge proofs, and blockchain interoperability, it provides meticulous and cutting-edge security audits for blockchain applications. The team comprises security professionals with extensive experience in both academia and enterprise.\u003C\u002Fp>\n\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fwww.scalebit.xyz\u002F?type=getAudit\">Requests a quote\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fwww.scalebit.xyz\u002F\">Website\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Ftwitter.com\u002Fscalebit_\">Twitter\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Ft.me\u002F@BitsLabHQ\">Telegram\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>","\u002Fmedia\u002Fscalebit\u002F2024\u002F05\u002Fc34c3013664e1d4ec50f725e1542ee0e.png","Discreet Log Contracts (DLCs) are a type of Bitcoin smart contract gaining traction for their potential in Bitcoin lending and cross-chain transactions. This article explores DLC technology, its applications, and key security issues, emphasizing the importance of reliable oracles and proper implementation to avoid risk","2024-05-29T10:00:00Z","Exploring the Security and Potential of DLCs (Discreet Log Contracts) cover image",{"slug":105,"category":11,"categoryLabel":10,"subcategoryLabel":106,"authorName":41,"title":107,"excerpt":108,"contentHtml":109,"coverUrl":110,"seoTitle":107,"seoDescription":108,"seoImageUrl":110,"publishedAt":111,"updatedAt":47,"readTime":112,"cover":110,"hasCover":26,"coverAlt":113},"scaling-bitcoin-together-in-hong-kong","Announcements","Scaling Bitcoin Together Event Set to Unite Bitcoin Leaders in Hong Kong","Join the 'Scaling Bitcoin Together' event on May 11, 2024, in Hong Kong, part of Bitcoin Asia Week. Explore Bitcoin's future with top experts discussing scalability, DeFi, and cross-chain solutions. Register now to connect with leaders from Citrea, Particle Network, and ScaleBit.","\u003Cp>\u003Cimg src=\"\u002Fmedia\u002Fscalebit\u002F2024\u002F05\u002F4b8e8aab2866b0d43542c4240229ff64.jpg\" alt=\"scaling-bitcoin-together\" title=\"Scaling Bitcoin Together\">\u003C\u002Fp>\n\u003Cp>As a part of Bitcoin Asia Week 2024, the “Scaling Bitcoin Together” event will take place on May 11, 2024, in Hong Kong. This event will bring together top blockchain experts to discuss how to grow the Bitcoin ecosystem.\u003C\u002Fp>\n\u003Cp>The “Scaling Bitcoin Together” aims to foster discussions that propel the development of the Bitcoin ecosystem. The event will feature a series of keynotes, panel discussions, and networking opportunities, focusing on critical topics such as Bitcoin East & West, Bitcoin Scalability, and Bitcoin DeFi.\u003C\u002Fp>\n\u003Ch2 id=\"Distinguished-Co-hosts\">Distinguished Co-hosts\u003C\u002Fh2>\n\u003Cp>This year’s event boasts a distinguished line-up of co-hosts, including (sort from A - Z):\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\n\u003Cp>Citrea: Known for being the first rollup that enhances the capabilities of Bitcoin block space with zero-knowledge technology. With Citrea, developers can leverage Bitcoin as the foundation for diverse on-chain applications, from DeFi to private transfers.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\n\u003Cp>Particle Network: Recognized as the Modular L1 Powering Chain Abstraction, Particle Network is dedicated to enhancing interchain operability and facilitating efficient blockchain ecosystems.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003Cli>\n\u003Cp>ScaleBit: A leader in blockchain security auditing, ScaleBit specializes in emerging ecosystems such as ZKP, Bitcoin, Layer 2, and Cross-chain applications, ensuring the highest standards of security and reliability.\u003C\u002Fp>\n\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3 id=\"All-star-Participants\">All-star Participants:\u003C\u002Fh3>\n\u003Col>\n\u003Cli>\n\u003Cstrong>VC Partners\u003C\u002Fstrong>: Hashkey Capital, Spartan Group\u003C\u002Fli>\n\u003Cli>\n\u003Cstrong>Strategy Partner\u003C\u002Fstrong>: BTC Security Lab\u003C\u002Fli>\n\u003Cli>\n\u003Cstrong>Orange Sponsor\u003C\u002Fstrong>: BeL2\u003C\u002Fli>\n\u003Cli>\n\u003Cstrong>Lemon Sponsors\u003C\u002Fstrong>: Lorenz​o, ZKM \u003C\u002Fli>\n\u003Cli>\n\u003Cstrong>Lime Sponsors\u003C\u002Fstrong>: CoreDAO, Glyph Exchange, Rollux, Thesis, Velar\u003C\u002Fli>\n\u003Cli>\n\u003Cstrong>Supporters\u003C\u002Fstrong>: Bitcoin.com, Bitcoin Insider, Comma3 Venture, CoinSpeaker, CoinVoice, GM Web3, SheFi, Serotonin, TechFlow, Verse\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2 id=\"Why-Attend\">Why Attend?\u003C\u002Fh2>\n\u003Cp>“Scaling Bitcoin Together” offers a vital platform for anyone involved in the blockchain sector and Bitcoin ecosystem. It provides deep insights into the future of Bitcoin and its applications, making it a must-attend event for developers, investors, and users looking to stay ahead in the rapidly evolving scalability landscape.\u003C\u002Fp>\n\u003Cp>To learn more about the event and how to register, please visit: \u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Flu.ma\u002Fscaling-bitcoin-hk-2024\">https:\u002F\u002Flu.ma\u002Fscaling-bitcoin-hk-2024\u003C\u002Fa>\u003C\u002Fp>\n\u003Ch2 id=\"About-ScaleBit\">About ScaleBit\u003C\u002Fh2>\n\u003Cp>ScaleBit, a subsidiary brand of BitsLab, is a blockchain security team that provides security solutions for Mass Adoption of Web3. With expertise in scaling technologies like Bitcoin Layer 2, Zero-Knowledge proofs, and blockchain interoperability, it provides meticulous and cutting-edge security audits for blockchain applications. The team comprises security professionals with extensive experience in both academia and enterprise.\u003C\u002Fp>\n\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fwww.scalebit.xyz\u002F?type=getAudit\">Requests a quote\u003C\u002Fa>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Website: \u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Fwww.scalebit.xyz\u002F\">https:\u002F\u002Fwww.scalebit.xyz\u002F\u003C\u002Fa>\n\u003C\u002Fli>\n\u003Cli>Twitter: \u003Ca target=\"_blank\" rel=\"noopener\" href=\"https:\u002F\u002Ftwitter.com\u002Fscalebit_\">https:\u002F\u002Ftwitter.com\u002Fscalebit_\u003C\u002Fa>\n\u003C\u002Fli>\n\u003C\u002Ful>","\u002Fmedia\u002Fscalebit\u002F2024\u002F05\u002F4b8e8aab2866b0d43542c4240229ff64.jpg","2024-05-07T08:00:00Z","2 min read","Scaling Bitcoin Together Event Set to Unite Bitcoin Leaders in Hong Kong cover image",44,1,10,1792473986982]