NEAR Intents Exploit: Refund Flaw and Security Lessons

Introduction

Between September 29 and October 1, 2026, an attacker exploited deposit refund handling in NEAR Intents to create internal balances without corresponding asset backing. Seven verified withdrawals from the HOT Bridge vault on BNB Chain transferred a total of 3,865,021 USDT. The project's subsequent postmortem attributed the flaw to the NEAR Intents contract and stated that all affected funds were returned on October 2 [1].

Understanding how the refund flaw created a withdrawable balance requires following the deposit through NEAR's asynchronous execution flow. Developers building on NEAR must account for when state becomes committed, who can invoke subsequent steps, and how failures affect the overall flow. Audits must examine these interactions across the complete flow.

Drawing on our experience auditing NEAR contracts and analyzing security incidents, we use this case to examine the security of asynchronous settlement on NEAR. We first introduce the background needed to understand the exploit: NEAR's asynchronous calls and receipts, token transfers and refunds, and the relationship between NEAR Intents and HOT Bridge. The incident analysis then explains the vulnerability and attack sequence, followed by the fixes and fund recovery. Finally, we discuss state management and callback handling, then extend the discussion to account authorization and storage costs.

Background

The analysis that follows relies on three pieces of NEAR-specific context: how asynchronous cross-contract calls are executed, how NEP-141 and NEP-245 handle token transfers and refunds, and how assets on the HOT Omni Balance ledger back the internal balances recorded by NEAR Intents.

Asynchronous Cross-Contract Calls on NEAR

Unlike Ethereum, where contract A calls contract B synchronously and waits for it to return [2], NEAR schedules cross-contract work for later execution. The initiating call, external call, and callback therefore do not share one execution context [3]. Two terms are central to this model:

• Promise: Work that a contract schedules, such as calling another contract or running a callback afterward.

• Receipt: A message the network uses to execute operations and pass results between accounts. An action receipt executes scheduled operations on a target account, while a data receipt carries an execution result to a dependent action receipt [4].

The diagram below shows this call-and-callback flow as three action receipts. In Receipt A, contract A updates its state and creates a Promise to call B. Receipt B executes B's logic. A data receipt, omitted from the diagram, carries B's result to Receipt C, where A's callback processes it. Receipt A can finish and commit its state before B or the callback runs.

Because these action receipts execute independently, the contract can process other requests while it waits. If the callback receipt fails, changes made within that receipt are rolled back, but state committed by the original receipt remains. The failure cannot propagate backward to reverse it, so the application must restore consistency explicitly.

Token Standards and Asynchronous Refund Settlement

NEP-141 and NEP-245 are token standards on NEAR. NEP-141 covers fungible tokens and is broadly comparable to ERC-20 on Ethereum. NEP-245 covers multiple token types and batch operations and is broadly comparable to ERC-1155 [5] [6] [7] [8].

The mapping is not exact. A normal NEAR token transfer sends assets to the destination receiver_id, which may identify an account with or without contract code. In the transfer-and-call flows discussed here, the receiver is a contract account that implements ft_on_transfer() for NEP-141 or mt_on_transfer() for NEP-245. The receiver hook executes in one receipt, and the token contract later runs ft_resolve_transfer() or mt_resolve_transfer() in another receipt to finalize the amount spent and any refund. A flow originating from one user transaction can therefore span several receipts.

From its hook, the receiver reports the amount it did not use. This return value is an input to settlement, not necessarily the final refund. In the near-contract-standards reference implementation of NEP-141, the resolver limits the reported unused amount by both the original transfer and the receiver's available balance. A failed or invalid response is first treated as a request to refund the full transfer amount, after which the same limits are applied [9]. Under NEP-245, the multi-token resolver must reverse the token transfer if the promise chain fails [8]. In either case, a token-level refund does not automatically undo application state that the receiver committed in an earlier receipt.

NEAR Intents and HOT Bridge

NEAR Intents is an intent-based settlement protocol on NEAR. Users deposit assets into intents.near, a contract that records them as internal balances. They can then sign intents to swap or withdraw those balances [10].

HOT Bridge, also called HOT Omni Bridge, provides the cross-chain asset layer. Assets are locked in contracts on external chains, while corresponding omni-assets are minted in the HOT Omni Balance contract on NEAR. HOT Omni Balance implements the NEP-245 token ledger [11].

The integration therefore has three accounting layers: the asset locked on the external chain, its omni-asset representation in HOT Omni Balance, and the user's internal balance in intents.near. These layers must remain consistent.

The diagram below gives an example of a 10-unit deposit and shows the two branches after Intents credits the internal balance. With no deposit action, mt_on_transfer() returns zero unused amounts and does not call a receiver hook. With DepositAction::Notify, Intents calls the receiver and later uses mt_resolve_deposit() to adjust the internal credit from the receiver's response. On the Notify branch, the receiver uses 6 units and reports 4 as unused. HOT Omni Balance's mt_resolve_transfer() returns those 4 units, leaving 6 units in the user's internal balance and 6 units of additional backing in its NEP-245 ledger [12].

Incident Analysis

We examine the incident in three parts: Vulnerability Analysis explains how refund handling could leave internal balances without asset backing; Attack Analysis traces the transactions and receipts that exploited this behavior; Fixes and Recovery covers the changes made and the reported return of funds.

Vulnerability Analysis

The following source analysis is based on the project's reproduction revision 35044fd [13]. Insufficient refund validation could produce an oversized refund event, causing the callback to fail and leaving internal balances inconsistent with the assets held:

• Insufficient refund amount validation. The affected deposit path in intents.near limited the refund by the receiver's balance and request, but omitted the amount deposited in the transfer being resolved. A large existing balance could consequently support a refund much larger than the current deposit.

• Oversized refund event. A batch with long token identifiers and large refund values could produce a serialized MtBurnEvent larger than the log limit. Emitting that event with emit() could abort the refund callback [14]. The limit applies to the event payload, including its arrays and formatting; a large numeric refund alone does not establish that the event will exceed it.

  The deposit event uses the transferred amounts, so small entries can keep that event within the limit. The later refund event uses the amounts accepted by the resolver. Without the deposited-amount cap, checking the original event cannot ensure that the larger refund event will fit.

• Inconsistent refund settlement. Intents' mt_resolve_deposit() callback deducted internal balances and supply within its own receipt. If emitting the refund event caused that receipt to fail, those deductions were rolled back, while the credit committed by the earlier deposit receipt remained. The upstream token contract could then refund the transferred assets, leaving the retained internal credit without corresponding asset backing. Repeating this process could further inflate the unbacked internal balance.

Attack Analysis

The attacker used a token to pad the refund event (the "filler token") and a malicious receiver to trigger oversized refund requests, repeatedly inflating internal balances without corresponding asset backing. The project reports 23 failing deposit transactions in total [1]. Seven verified withdrawals transferred 3,865,021 USDT from the HOT Bridge vault on BNB Chain.

The attack involved multiple transactions. This analysis focuses on 13 key transactions, listed in Appendix A, and organizes them into three functional phases.

• Phase 1: Preparation (Tx 1–4). The attacker obtained the assets needed for testing, deployed the malicious receiver contract, and prefunded its internal filler-token balance.

• Phase 2: Balance Amplification (Tx 5–6). Tx 5 and Tx 6 are the first and last identified amplification transactions, respectively.

• Phase 3: Withdrawals on BNB Chain (Tx 7–13). The attacker used the inflated internal balances to withdraw USDT from the HOT Bridge vault on BNB Chain.

These phases classify the attacker's actions; they are not three non-overlapping time periods. Amplification and withdrawal activity overlapped. The detailed reconstruction below uses Tx 5 and its complete action-receipt outcomes, then checks the seven BNB Chain withdrawals.

The first amplification example used the malicious receiver shown here; later transactions used other malicious receiver accounts. Full addresses and token IDs are listed in Appendix B. All times below are UTC.

Phase 1: Preparation (Tx 1–4)

• Step 1 (Tx 1): At 12:30:44 on September 29, the attacker obtained 10e18 raw units of the BNB Chain USDT representation through HOT Bridge, credited to the attacker's account in HOT Omni Balance. The token ID suffix decodes to the BNB Chain USDT address in Appendix B. With 18 decimals, 10e18 raw units represent 10 USDT.

• Step 2 (Tx 2): The attacker obtained 97e36 + 97 raw units of the filler token through HOT Bridge. The custom token had been created and minted on Osmosis earlier that day, then transferred through Kava and Gonka before being claimed on NEAR; the preparation records are detailed in Appendix C.

• Step 3 (Tx 3): The attacker deployed and initialized the malicious receiver contract.

• Step 4 (Tx 4): The attacker transferred 97e36 raw units of the filler token to Intents through HOT Omni Balance's mt_transfer_call(), with msg identifying the malicious receiver. Intents credited the malicious receiver's internal account. This prefunded balance allowed the malicious receiver to support 97 refund requests of 1e36 raw units each during Tx 5.

Phase 2: Balance Amplification (Tx 5–6)

The first amplification transaction, Tx 5, was executed at 16:14:19 on September 29. Its five core action receipts cover the batch transfer, deposit, notification, failed accounting adjustment, and upstream refund. Their identifiers and execution results are listed in Appendix D.

• Step 5 (Tx 5): The attacker called mt_batch_transfer_call() on HOT Omni Balance, targeting Intents. The batch contained 97 entries for the same filler token, each with an amount of 1 raw unit, plus one USDT entry of 10e18 raw units. Intents' mt_on_transfer() recorded all 98 entries for the malicious receiver and emitted an MtMint deposit event. The amount of 1 for each filler entry was deliberate: the deposit path called check_refund() to verify that the initial event and its expected refund overhead fit within the log limit. Small deposited amounts passed this check, while the malicious receiver's much larger refund requests later produced an oversized refund event [13].

• Step 6 (Tx 5): After the internal credit, Intents took the DepositAction::Notify branch and called the malicious receiver's mt_on_transfer() once with all 98 entries. The malicious receiver succeeded and returned 97 refund requests of 1e36 raw units each for the filler entries and a refund request of 0 for the USDT entry.

• Step 7 (Tx 5): Intents' mt_resolve_deposit() accepted all 97 refund requests of 1e36 raw units each because the malicious receiver's internal filler-token balance prefunded in Tx 4 was sufficient to cover them. These large refund values, together with the repeated long token identifier, expanded the MtBurnEvent log to 16,495 bytes, exceeding the 16,384-byte limit. Emitting the event failed, rolling back this receipt's attempted balance deductions while leaving the earlier deposit credit intact.

• Step 8 (Tx 5): HOT Omni Balance's mt_resolve_transfer() received a failed promise result from Intents' mt_resolve_deposit(). It therefore refunded all 98 entries to the attacker at their original transferred amounts, including 10 USDT, despite the malicious receiver's request for a zero USDT refund. The attacker recovered the assets while the malicious receiver retained the corresponding internal credit in Intents.

The attacker repeated this process to further inflate internal balances. Tx 6 used a different malicious receiver and triggered the same log-length failure.

Phase 3: Withdrawals on BNB Chain (Tx 7–13)

• Step 9 (Tx 7–13): The attacker used the inflated internal balance to request withdrawals through HOT Bridge. On BNB Chain, the seven transactions listed as Tx 7–13 in Appendix A transferred USDT from the HOT Bridge vault to the attacker-controlled BNB recipient.

The first two small withdrawals total 21 USDT. The following five total 3,865,000 USDT, giving 3,865,021 USDT across all seven transactions. These amounts come from the token's transfer logs and its 18-decimal precision. The BNB Chain timestamps describe destination-chain transfers and should be kept separate from NEAR deposit or withdrawal-request timestamps.

Fixes and Recovery

The team reports that a fix was deployed on October 2 [1]. The corrected refund calculation caps each refund at the amount deposited in the current transfer, while retaining the limits imposed by the requested amount and the available internal balance [15]:

let refund_amount = requested_refund.min(*deposited).min(balance_left);

This prevents a large balance from earlier deposits from supporting an oversized refund for a later, smaller deposit.

The team subsequently removed deposit notifications on October 7 [1], closing the path through which a malicious receiver could supply refund requests. PR #374 records this removal [16]. The postmortem also reports an additional safeguard: monitoring now compares total internal user balances with the contract's actual token holdings and automatically pauses the contract when they diverge [1].

On fund recovery, the project announced on October 2 that all funds had been returned [17]. Its subsequent postmortem confirmed that all affected users had been made whole [1].

Security Considerations for NEAR Smart Contracts

The incident provides a starting point for examining state consistency across NEAR's asynchronous receipts. Building on this analysis and our NEAR audit experience, this section covers three areas: asynchronous execution, account authorization through access keys, and storage costs. The latter two extend the discussion to how applications delegate authority and fund persistent state. The focus is on risks shaped by these NEAR mechanisms and the concrete checks they require during development and auditing; general security practices are included where they help explain or address those risks.

Asynchronous Execution

1. State Management Across Receipts

On NEAR, cross-contract calls and their callbacks execute in separate receipts, and a later failure does not automatically undo state committed earlier. Contracts can also process other requests while calls are pending, making the timing and isolation of state updates critical to keeping internal balances consistent with actual assets. Three common scenarios illustrate these risks:

• Delayed Balance Deduction: If the spendable balance is not deducted or reserved until the callback, the same funds may be used again before the transfer settles.

• Premature Deposit Credit: Crediting spendable funds before external processing finishes creates two risks:

  • Spending Before Settlement: Users may spend the credited funds while the external call is still pending, before settlement is finalized.
  • Retained Credit After Callback Failure: If the refund callback fails, the upstream token contract may return the assets while the internal credit committed earlier remains. The NEAR Intents incident demonstrated this risk.

• Shared-State Overwrites: If pending requests share a variable for the user or amount, a later request may overwrite information needed by an earlier request's callback. A refund may then be associated with the wrong user or amount.

Suggestions. Because cross-contract flows on NEAR are not atomic across receipts, the timing of balance updates, the isolation of pending requests, and recovery from call and callback failures need to be considered during both development and auditing. Deduct or reserve funds before initiating withdrawals, and restore the balance only once if the transfer fails. For deposits, prevent users from spending funds before settlement is finalized, and ensure that refunded assets do not leave spendable internal credit behind, including when the settlement callback itself fails. Keep a separate record of the user, amount, and settlement state for each pending request. Verify these behaviors across successful and failed calls, callback failures, interleaved requests, and repeated settlement attempts.

2. Callback in Cross-Contract Calls

NEAR contracts use promises to schedule cross-contract calls and callbacks to handle their results. Callback access and failure handling determine whether subsequent accounting or settlement runs as intended. Two risks follow:

• Unrestricted callback access: A callback must be exposed as a callable contract method, but that exposure also makes it reachable by external callers unless access is restricted. An attacker may invoke an unprotected callback with fabricated parameters, causing accounting or settlement logic to run without the intended preceding operation.

• Failed callbacks: NEAR contracts use .then() to attach callbacks that process cross-contract call results and perform any required completion or recovery logic. If the callback itself fails, its own state changes are reverted, but earlier successful receipts remain committed, leading to inconsistent state settlements.

Suggestions. Restrict callbacks to the contract itself using #[private] [18]. Allocate sufficient gas for the callback and bound the work and log output it may produce. Handle failed promise results and malformed return data explicitly. Because a failed callback cannot commit its own recovery changes, record any pending settlement state needed for recovery in an earlier receipt. Verify that callback failure leaves no unbacked spendable credit and that recovery cannot settle the same operation twice.

Account Authorization

NEAR provides fine-grained account authorization through two types of access keys [19]: Function-Call and Full Access keys.

If a user authorizes a website with a Function-Call key, the site can call permitted methods on the permitted receiver without obtaining a new wallet signature for each operation. The runtime enforces that scope and rejects calls with a nonzero attached deposit for this key type [20].

Within that scope, the account identity does not distinguish an operation signed using the delegated key from one individually approved by the user. A sensitive method that relies only on that identity may allow a malicious site to initiate transfers, withdrawals, or permission changes if those methods are included in the authorization.

Suggestions. Review the sensitive methods reachable through restricted keys and the authorization required for each operation. Requiring exactly 1 yoctoNEAR with #[payable] and assert_one_yocto() excludes the restricted key's direct transaction path. Retain the application's own identity and permission checks: the deposit requirement does not prove human initiation, since software can hold a Full Access key and another contract can attach NEAR.

Storage Costs

NEAR requires a contract to reserve NEAR for its stored data, so growing state reduces the funds available for other operations [21]. The risks depend on who pays for that growth:

• Protocol-Funded Storage: If users can create records without paying and growth is unbounded, repeated low-cost calls can increase the contract's storage commitment and consume its available funds.

• User-Funded Storage: Charging users requires both complete fee coverage and accurate measurement:

  • Fee Bypasses: An alternative entry point may create records without collecting the fee required by the usual registration or write path.
  • Incorrect Usage Attribution: env::storage_usage() measures the entire contract's storage. Saving a baseline before an external call and comparing it in a later receipt can include unrelated writes or deletions, causing the charge to overstate or understate the user's own storage change.

Suggestions. Storage funding, write-path coverage, and usage attribution need to be considered together. Charge for new storage or explicitly bound the protocol's subsidy and capacity. Check every write path for fee bypasses. Measure an operation's storage change within the same receipt where possible; when accounting spans receipts, separate unrelated changes before attributing usage to an individual user.

Conclusion

On NEAR, a successful receipt can leave lasting state even when a later callback fails. Unlike a synchronous call chain on Ethereum, the cross-receipt flow has no shared rollback boundary. Applications must therefore account for the state and assets that remain after each possible failure.

In NEAR Intents, the token refund completed while the corresponding internal credit survived a failed accounting adjustment. Insufficient refund validation made the refund event large enough to trigger that failure. The case demonstrates that returning assets at the token layer can still leave an application with an unbacked, spendable balance.

For similar asynchronous flows, development and auditing should track which state changes survive each possible failure, whether pending balances can be spent, and how incomplete settlements can be recovered without duplicate credits or refunds. Each receipt must be examined together with the earlier state it depends on and the later operations it schedules.

Beyond settlement, access-key permissions and storage funding deserve explicit review: delegated calls must stay within the intended authority, and user-driven state growth must have a defined payer or limit.

References

[1] NEAR Intents postmortem, October 16, 2026

[2] Ethereum.org: Smart Contract Security

[3] NEAR Docs: Cross-Contract Calls

[4] NEAR RuntimeSpec: Receipts

[5] ERC-20: Token Standard

[6] ERC-1155: Multi Token Standard

[7] NEP-141: Fungible Token Standard

[8] NEP-245: Multi Token Standard

[9] NEAR SDK fungible token implementation

[10] NEAR Docs: Integrate with NEAR Intents

[11] HOT Bridge architecture and HOT Omni Balance

[12] NEP-245 deposit flow, reproduction revision 35044fd

[13] Deposit resolver, reproduction revision 35044fd

[14] Oversized-refund regression test, merged revision 0c1a530

[15] Refund bounds in the current Intents source, accessed October 26, 2026

[16] PR #374: Remove notifications on deposits

[17] NEAR Intents recovery statement, October 2, 2026

[18] NEAR Docs: Private Callbacks

[19] NEAR Docs: Access Keys

[20] NEAR RuntimeSpec: Function call access key validations

[21] NEAR Docs: Storage Cost Attacks

Appendix

A. Transaction Timeline {#appendix-verified-transaction-timeline}

This appendix preserves the transaction numbering used in the original investigation. It lists the four preparation transactions, the first and last identified amplification transactions, and the seven BNB Chain withdrawals. It is not a complete list of all 23 failing deposit transactions reported by the project. All times are UTC; phases classify actions and may overlap in time.

B. Accounts and Token Identifiers {#appendix-accounts-and-token-identifiers}

The original investigation attributes both cross-chain addresses below to the attacker. The chain records independently establish their roles as the NEAR sender and BNB Chain withdrawal recipient. The malicious receiver listed here is the account used in Tx 5; later amplification transactions used other malicious receiver accounts.

C. Filler Token Creation and Bridge Transfers {#appendix-filler-token-origin}

The filler token originated as a custom Osmosis TokenFactory asset. Its creation, minting, and subsequent transfers link it to the attack preparation. All times below are UTC on September 29, 2026; the NEAR claim is Tx 2 in Appendix A.

The same Osmosis account created, minted, and sent the token. Both IBC transfers carry the memo hot intents ctf filler. The minted amount, 97e36 + 97 raw units, matches both transfers, the Gonka bridge deposit, and the NEAR claim. The recipient in the Osmosis transfer is the sender of the Kava transfer, whose recipient is the sender of the Gonka bridge deposit. Together, these records indicate that the token was created as part of the attack preparation.

The Gonka denom trace records the IBC path transfer/channel-5/transfer/channel-1 and the original Osmosis asset identifier:

Base58-decoding the contract_id in NEAR Tx 2 produces the Gonka IBC denomination above. The Gonka bridge deposit and NEAR claim share nonce 1790691367000000007133; the source deposit's recipient hash also matches the SHA-256 hash of the attacker's NEAR account ID. These fields connect the source deposit to the NEAR credit. The term filler token describes this asset's role in enlarging the refund event.

D. Tx 5 Receipt Details {#appendix-tx5-receipts}

The five core action receipts below correspond to Steps 5–8. Step 5 includes both the initial HOT Omni Balance transfer and the Intents deposit receipt.