Cross-Chain Bridge Security: NEAR Intents Hack Breakdown

In an exploit disclosed on October 1, 2026, an integration bug between NEAR Intents' smart contract and its Omni deposit-and-withdrawal system let an attacker drain about $3.8 million in USDT from a BNB Chain hot wallet over roughly seven hours. It is a case study in how cross-chain bridge security fails. The strangest moment came about 80 minutes in. The attacker sent 650 stolen BNB through CoW Swap and asked for ETH on Ethereum, and the bridging partner on that order was NEAR Intents itself. Its own Ethereum hot wallet then paid the attacker about 185.5 ETH, according to Bitquery's on-chain investigation. The protocol was being robbed on one chain while it helped launder the stolen funds on another.

That detail matters more than the $3.8 million figure. Each transaction can be valid on its own while the system as a whole is failing. This breakdown walks through the NEAR Intents architecture, where the bug sat, how the funds moved, and a four-layer model for judging any bridge design. It also covers what a light-client bridge does and does not fix, and how to evaluate trustless bridge vs custodial trade-offs.

Key Takeaways:NEAR Intents lost about $3.8 million in USDT from a BNB Chain hot wallet in an exploit disclosed on October 1, 2026, per CoinDesk.Reports trace the root cause to an integration failure between the NEAR Intents smart contract and the Omni deposit-and-withdrawal system, not to broken cryptography.The attacker turned about 76% of the stolen value into 34.69 BTC held across four Bitcoin addresses, using Chainflip and THORChain, according to CCN.Intent-based designs don't remove bridge risk; they move it into hot wallets, solver settlement and the code that connects the two.Withdrawal rate limits and checks across sequences of transactions would likely have capped the roughly seven-hour drain far more effectively than another audit of individual functions.

Table of Contents

• What Happened in the NEAR Intents Exploit?
• How Do Intent-Based Bridges Actually Work?
• Where Did the NEAR Intents Bug Sit?
• How Did the Attacker Move $3.8M Across Five Protocols?
• How Do Bridge Hacks Happen? A Four-Layer Model
• Trustless Bridge vs Custodial: What Does Verification Buy You?
• Bridge Exploit Prevention: What Would Have Limited the Damage?
• A Practical Bridge Security Checklist
• Frequently Asked Questions
• Conclusion

What Happened in the NEAR Intents Exploit?

An attacker made unauthorized withdrawals from NEAR Intents' BNB Chain hot wallet and took about $3.8 million in USDT. The exploit was disclosed on October 1, 2026. Some outlets put the total at $3.87 million. Before the incident, NEAR Intents had processed more than $30 billion in cumulative volume across 35 blockchains, CoinDesk reported.

The team's response came in four parts. Cross-chain services were paused on 11 blockchains, and deposits and withdrawals were disabled on several of them. The smart contract bug was patched. The team pledged full reimbursement from its treasury. Law enforcement and blockchain security firms were brought in.

After the team contacted the attacker, the $3.8 million was returned. A statement from NEAR co-founder Illia Polosukhin confirmed this, as reported by Shattered. Reports place the return around October 3, 2026.

Seven hours is a long time for a drain to run. Most of the lessons here come from that number.

How Do Intent-Based Bridges Actually Work?

An intent-based bridge lets a user sign the outcome they want, such as "give me X ETH on Ethereum for my BNB," while independent solvers compete to deliver it. A classic lock-and-mint bridge works differently: it locks the asset on chain A and mints a wrapped version on chain B. NEAR Intents does not need one large collateral pool backing a wrapped token, as Shattered's breakdown notes. It still depends on custody systems and on its smart contracts agreeing about which transactions are authorized.

In broad terms, a cross-chain intent passes through four stages:

1. Deposit. The user sends assets to a deposit address or vault on the source chain. In NEAR Intents, the Omni deposit-and-withdrawal system handles this. It watches external chains and credits balances inside the NEAR-side contract.
2. Intent signing. The user signs a message stating what they give, what they want, the minimum output and a deadline. The signature authorizes a state transition but does not carry it out.
3. Solver matching. Solvers, which are market makers holding inventory on many chains, quote prices. The winning quote is settled atomically in the intents contract by swapping internal balances.
4. Withdrawal. The user's new internal balance is redeemed for a real asset on the destination chain. A withdrawal request has to be turned into a signed transaction that moves funds out of a hot wallet, meaning a wallet whose signing keys are online so withdrawals can happen automatically.

Here is the point most explainers skip. Stage 3 is elegant, auditable on-chain logic. Stages 1 and 4 are where real assets move, and they rely on off-chain watchers, signing infrastructure and hot wallets on every supported chain. "No large collateral pool" is true at the level of design, but in practice the hot wallets are the pool. They are split across chains, which limits the damage from any single breach, but each one is a target worth millions. This structure differs from intent-based security models that block hacker swaps through verification.

Where Did the NEAR Intents Bug Sit?

The vulnerability came from a failed integration between the NEAR Intents smart contract and the Omni deposit-and-withdrawal system, and it allowed unauthorized withdrawals from the BNB Chain vault. This is according to the team's post-incident statement reported by U.Today via TradingView. No signature scheme was broken and no consensus failed. The fault was in how two components agreed on what counts as an authorized withdrawal.

The full technical post-mortem had not been published as of October 5, 2026, so we won't guess at the exact line of code. Bridge design history does show which kinds of integration bugs produce this result. They work as a review checklist for any protocol that pairs a contract with a custody layer:

• Authorization mismatch: the custody signer trusts a withdrawal event without checking that the contract debited a matching balance. Both sides believe the other one did the check.
• Replay or double-processing: one valid withdrawal message is processed more than once because nonces or message IDs are tracked inconsistently across the two layers.
• Encoding or decimals drift: the two sides parse amounts, token IDs or destination addresses differently. BNB Chain USDT uses 18 decimals, while USDT on many other chains uses 6, which is a classic trap.
• Stale state on upgrade: one component is upgraded and the other keeps running against assumptions the upgrade no longer meets. Nomad's 2022 failure, covered below, is the textbook case.

All four have one thing in common. Unit tests and single-contract audits rarely catch them, because each component passes its own specification. The bug only exists where the two meet. That is why integration seams deserve as much review attention as the cryptography. Understanding validator security and Bitcoin bridge risks helps when you're looking for those seams.

How Did the Attacker Move $3.8M Across Five Protocols?

The attacker converted stolen USDT to BNB, split it across dozens of new wallets, sent it through at least five cross-chain venues, and ended up mostly in Bitcoin. The sequence below is reconstructed from Bitquery's transaction-level investigation and CCN's fund-tracing report.

Phase 1: The drain

The attacker used the contract-Omni bug to make unauthorized withdrawals of USDT from the BNB Chain hot wallet. This went on for roughly seven hours, and nothing automatic stopped it.

Phase 2: Splitting the funds

The USDT was swapped to BNB and spread across newly created wallets. On-chain tracing cited by CCN counts about 32 of them, though that exact number has not been independently confirmed. Splitting the funds this way makes each transfer less conspicuous and lets the attacker run many laundering routes at once.

Phase 3: The self-referential loop

At about the 80-minute mark, 650 BNB went through CoW Swap with ETH on Ethereum requested. Bitquery identified NEAR Intents as the bridging partner on that order, and it paid about 185.5 ETH from its own Ethereum hot wallet. Roughly an hour later the pattern repeated: a direct deposit of 100 BNB, followed by 91.7 ETH in payouts, per Bitquery.

From the protocol's point of view, these were well-formed orders backed by real BNB. The system had no way of knowing that the BNB had left its own vault minutes earlier. CCN summed it up: automated cross-chain systems "execute seemingly valid orders without inherently knowing the economic history of every asset."

Phase 4: Exit to Bitcoin

The ETH was swapped to BTC through Chainflip, which completed 17 swaps before it started rejecting the attacker's requests. The attacker then moved to THORChain. In the end, 34.69 BTC, about 76% of the stolen value, sat across four Bitcoin addresses. As of the October 1 snapshot, none of those coins had moved. A likely reason for choosing Bitcoin as the exit asset is that, unlike USDT or USDC, it has no issuer that can freeze balances. Chainflip's rejections after 17 swaps also show that screening at the venue level works, but only once the attacker's addresses have been flagged.

How Do Bridge Hacks Happen? A Four-Layer Model

Bridge hacks happen when any one of four layers fails: message verification, authorization logic, custody, or operational monitoring. Bridges have long been crypto's most expensive attack surface. Chainalysis estimated that about $2 billion was stolen in 13 cross-chain bridge hacks in 2022, according to its 2022 analysis. Most post-mortems just say "a bug." Sorting each failure into one of these layers tells you more:

1. Verification layer: how does chain B know an event happened on chain A? The options are validator signatures, a multisig, an MPC committee, an optimistic fraud window, or a light client that checks the source chain's consensus itself.
2. Authorization layer: once an event is verified, does the contract correctly turn it into exactly one mint or withdrawal of the correct amount to the correct address?
3. Custody layer: who controls the locked assets, and what happens if those keys or that code is compromised?
4. Operations layer: rate limits, pause mechanisms, anomaly detection, upgrade controls. This layer decides whether an exploit costs $50,000 or $500 million.

Historical figures are from the Rekt News leaderboard and the Chainalysis report above. In this sample, the largest losses come from compromised keys (Ronin, Harmony) and broken verification (Wormhole, BNB). Authorization and upgrade bugs (Nomad, Poly, NEAR Intents) vary widely in cost, and how much they end up costing depends mostly on the operations layer.

Trustless Bridge vs Custodial: What Does Verification Buy You?

A trustless bridge checks the source chain's consensus on-chain, while a custodial bridge asks you to trust whoever holds the keys. The difference shows up in what an attack costs. To fool a 5-of-9 multisig, you need five private keys. To fool a Bitcoin light client, you need to produce proof-of-work equal to the confirmation depth the bridge requires.

How does an SPV light client verify a Bitcoin transaction?

Simplified Payment Verification, described in Section 8 of the Bitcoin whitepaper, lets a verifier confirm that a transaction is in a block without downloading the whole block. In a bridge contract it works like this:

1. Relayers submit 80-byte Bitcoin block headers. Each one contains a version, the previous block hash, a Merkle root, a timestamp, nBits (the difficulty target) and a nonce.
2. The contract checks that double-SHA-256 of each header falls below the target encoded in nBits, that each header links to its parent, and that difficulty adjusts correctly. It follows the chain with the most cumulative work.
3. A user proves a deposit with a Merkle branch: the sibling hashes along the path from their transaction ID up to the header's Merkle root. That is about log₂(n) hashes, or roughly 12 for a block with 4,000 transactions.
4. Funds are released only once the block is buried under the required number of confirmations.

Forging this means mining valid blocks faster than the honest network. Every block spent on a fake chain also gives up the 3.125 BTC subsidy that has applied since the April 2024 halving. No key can be phished to get around it.

This is the model TeleSwap uses for Bitcoin. Nothing is minted without a verified Bitcoin transaction: a deposit's SPV proof has to check out against the on-chain light client before TeleBTC, a 1:1 BTC representation, is issued. Custody of the BTC side is collateral-backed and slashable. It does not rest on a multisig committee or a centralized custodian. As of October 5, 2026, the protocol has bridged $503.0M across 534,252 bridge transactions on 12 networks, per TeleSwap network stats. The design is documented at teleswap.xyz/docs.

One caveat that marketing pages usually leave out: a light client secures layer 1 of the four-layer model, not all four. Wormhole and BNB Token Hub both had cryptographic verification and still failed, because the code that implemented the verification was wrong. Verification by proof greatly reduces the key-compromise risk behind the largest bridge losses. Authorization logic still has to be correct, custody still has to be bounded, and operational limits still have to exist. A team that says otherwise is selling, not engineering. Confirmation depth should also scale with value: six confirmations may be fine for $10,000 and not enough for $10 million.

Bridge Exploit Prevention: What Would Have Limited the Damage?

The most effective protection against a bug like NEAR Intents' is a withdrawal rate limit enforced at the custody layer, independent of the contract logic. Audits look for bugs. Rate limits assume bugs exist and cap what they can cost. Five controls stand out from this incident and the wider record of bridge hacks.

1. Per-chain, per-asset outflow caps

A hot wallet should not be able to send more than a set amount per time window without a delay or human sign-off. The check has to live in the signer, not the contract, so that a contract bug cannot get around it:

// enforced inside the custody signer, not the intents contract
window = currentEpoch(1 hour)
if outflow[chain][asset][window] + amount > cap[chain][asset]:
    enqueue(withdrawal, delay = 6 hours)   // allow time for human review
    alert(security_oncall)
else:
    outflow[chain][asset][window] += amount
    sign(withdrawal)

A $500,000 hourly cap on BNB Chain USDT could have turned a seven-hour, $3.8M drain into a capped and queued event caught within the first window.

2. Cross-layer accounting invariants

The custody layer should keep its own running ledger and refuse any withdrawal that would push total outflows above verified deposits plus solver inventory for that chain. If the contract and the custodian disagree, the safe default is to stop.

3. Sequence-level anomaly detection

The self-referential loop got through because each order was checked on its own. Taint tracking, where the system notes that incoming BNB came from addresses that just withdrew from its own vault, would have flagged the CoW Swap order immediately. Chainflip's rejection after 17 swaps shows that this kind of screening is practical.

4. Automatic circuit breakers

Pausing 11 chains was the right response, but it was manual. Breakers that trip on velocity (for example, hot wallet balance dropping more than X% in Y minutes) take human reaction time out of the loop.

5. Upgrade isolation

Changes to either the contract or the custody layer should go through integration tests that run both components together against adversarial inputs. Testing each one separately misses this class of bug. Nomad's zero-root initialization is the cautionary example.

A Practical Bridge Security Checklist

Before you route meaningful value through any bridge, find out which of the four layers you are trusting and how losses are capped. These questions apply whether you are a user moving BTC or a developer choosing a provider:

• Verification: does the destination chain check source-chain consensus (light client/SPV), or does it accept signatures from a committee? If it's a committee, how many signers are there and who runs them?
• Custody: are assets in hot wallets, a multisig, MPC, or collateral-backed slashable positions? What is the most that can leave in one hour?
• Operations: is there a public pause mechanism, a rate limit and an incident history? NEAR Intents' transparent disclosure and reimbursement pledge count in its favor.
• Exposure: split large transfers. A bridge that's safe for $5,000 may not be safe for $5 million, especially on confirmation-based systems.
• Stablecoin routes: if you're bridging BTC into stablecoins, for example BTC to USDT without KYC or a direct route like BTC to USDT on BNB Smart Chain, check how the BTC leg is verified, not only the swap leg.

For integrators, the most important single question for a provider is: "What stops your hot wallet from being emptied if your contract has a bug?" If the answer is "our audits," keep looking.

Frequently Asked Questions

What caused the NEAR Intents hack?

The NEAR Intents hack was caused by a failed integration between its smart contract and the Omni deposit-and-withdrawal system, which allowed unauthorized withdrawals from a BNB Chain hot wallet. About $3.8M in USDT was drained in an exploit disclosed on October 1, 2026. No cryptographic primitive was broken. The two components disagreed about which withdrawals were authorized. It is a bridge security exploit occurring at the integration seam, the point where two separately built components meet.

Were NEAR Intents users reimbursed?

The team pledged full reimbursement from its treasury, and the attacker later returned the $3.8M after the team made contact. NEAR co-founder Illia Polosukhin confirmed the return. The team also patched the bug and paused cross-chain services on 11 chains while it investigated.

Are intent-based bridges safer than lock-and-mint bridges?

Not by default. Intent-based bridges move risk around rather than removing it. They avoid one large collateral pool behind a wrapped token, but they still depend on hot wallets on every chain and on the code linking settlement to custody. The NEAR Intents exploit hit exactly that link. The key difference between intent-based and traditional lock-and-mint designs is where the custody risk concentrates, not whether it disappears.

What is the difference between a trustless bridge and a custodial bridge?

A trustless bridge checks source-chain events on-chain with cryptographic proofs (such as SPV for Bitcoin), while a custodial bridge relies on a party or committee holding private keys. Light-client bridges check block headers and Merkle proofs, so forging a deposit means producing real proof-of-work. Custodial and multisig bridges can be drained by stealing enough keys, as the roughly $624M Ronin hack in 2022 showed. Trustless bridges shift the attack surface from key management to contract code correctness.

How can bridges prevent exploits like the NEAR Intents hack?

The best protection is per-chain withdrawal rate limits enforced at the custody layer, separate from the smart contract. Other controls include cross-layer accounting invariants that check deposits match withdrawals, automatic circuit breakers triggered by drain velocity, taint tracking on incoming assets to flag self-referential loops, and integration tests that exercise the contract and custody layers together. These operational controls decide whether a bug costs thousands or millions.

Why did the attacker convert the stolen funds to Bitcoin?

The reports don't state a motive, but a likely reason is that BTC has no issuer that can freeze it, unlike USDT or USDC. About 76% of the stolen value ended up as 34.69 BTC across four addresses, after swaps through Chainflip (which rejected later requests) and THORChain. As of the October 1 snapshot, those Bitcoin addresses had not spent the funds.

Can light-client bridges be hacked?

Yes, through implementation bugs, though not through key theft. A correctly built SPV light client makes forging deposits as costly as mining Bitcoin blocks. Bugs in proof parsing, authorization logic or upgrades can still be exploited. Wormhole (guardian signature checks) and BNB Token Hub (Merkle proof verification) both lost hundreds of millions because their verification code was flawed. Proof-based verification is only as strong as the code that implements it, which is why code correctness matters even in trustless designs.

Conclusion

The NEAR Intents exploit was small by bridge-hack standards and ended with the funds returned, but it shows a lot. A bug where the contract meets the custody layer drained a hot wallet for about seven hours, and the protocol's own Ethereum vault paid the attacker 185.5 ETH along the way. In cross-chain bridge security, every transaction can be valid while the overall sequence is plainly an attack.

Three takeaways. First, judge bridges across all four layers (verification, authorization, custody, operations), not just whatever the marketing page calls "trustless." Second, verifying the source chain with a light client removes the key-compromise risk behind the largest bridge losses, but it doesn't replace correct code or bounded custody. Third, rate limits and circuit breakers decide whether a bug costs thousands or millions.

If you move Bitcoin across chains, check how the BTC leg is verified before you send it. See how SPV light-client verification and collateral-backed, slashable custody work in practice at teleswap.xyz, or read the full protocol design at teleswap.xyz/docs.