Across Protocol resumed full operations and re-enabled Solana deposits on July 18 after an attack two days earlier exposed capital belonging to a Risk Labs-operated relayer, not customer balances. Across says every pending transfer was completed or refunded and that no users lost funds—a significant distinction in an industry where a bridge failure has often meant a direct loss for depositors.
The incident began at roughly 5:30 a.m. UTC on July 17, when Across said it had been attacked on its Solana deployment. Solana-direction deposits were paused while the team investigated, but the rest of the protocol remained operational. Reporting by The Crypto Times first detailed Across’s statement that the only funds potentially affected were those controlled by the Risk Labs relayer; ChainThink, as carried by KuCoin, later reported that deposits had been restored.
That does not make the event a non-story. Across was breached at a meaningful edge of its cross-chain system, and the size of the relayer loss has not been disclosed. But its immediate customer impact appears to have been contained precisely where an intent-based bridge says risk should land: with the party that chooses to front capital, rather than with the user moving assets between chains.
Across does not operate like a conventional lock-and-mint bridge in which a pooled smart contract holds user deposits and issues a representation of those assets elsewhere. Its relayers compete to fulfill a user’s requested transfer quickly on the destination chain, using their own liquidity, then seek reimbursement through the protocol’s settlement process.
That arrangement brings obvious business risk for a relayer. A relayer must correctly determine that a deposit happened and that a transfer should be filled before it releases its own capital. If that decision is wrong, its balance sheet—not necessarily the user’s deposited assets—takes the initial loss.
Across has promoted that architecture for years as a way to avoid placing an enormous pot of pooled liquidity behind one critical bridge contract. Its January 2025 security material specifically argued that relayers, rather than users, take on transfer and finality risk. The July 17 incident is the most concrete real-world test of that claim so far.
According to Across, the Risk Labs-operated relayer was the affected participant. Risk Labs supports the protocol, but Across describes its relayer network as permissionless rather than as a one-operator system. The important practical outcome for customers is that an in-flight transfer did not become a claim on an underfunded pool: the protocol says it either finished the transfer or issued a refund.
That is a better failure mode than the bridge industry’s most damaging precedents. In a pooled-liquidity exploit, attackers can compromise the assets users have already entrusted to the bridge. In a relayer-side failure, the loss can be isolated to the firm or operator that opted to quote and finance the fill. Risk was not eliminated; it was assigned differently.
Still, the timing puts an April disclosure from Asymmetric Research under a harsh spotlight. In an April 22 write-up, Asymmetric Research described “Across Solana Event Spoofing,” a flaw in the protocol’s Solana-related off-chain handling. The issue could have let an attacker create a misleading deposit signal and persuade relayer software to fill an order even though the underlying deposit had failed.
Asymmetric Research’s explanation turns on an important Solana implementation detail. Ethereum has a standardized, first-class event and receipt model that off-chain services commonly query. Solana applications often reconstruct “events” from transaction traces, instruction data, or program logs retrieved through RPC calls instead.
The security problem is that a failed Solana transaction can still produce logs and other observable execution data. Solana’s own RPC documentation exposes transaction errors separately from the log output. An observer that parses the attractive-looking event data but fails to check the transaction’s final error state can treat an aborted action as evidence that it succeeded.
That is not a failure in Solana’s underlying consensus promise; a failed transaction does not make its state change valid. It is a failure of an off-chain consumer to distinguish diagnostic output from successful state. For bridge operators, market makers, indexers, monitoring agents, and Windows-hosted automation alike, the lesson is familiar: logs are not an authorization decision, and an application event is not proof that a transaction committed.
Asymmetric Research said the April issue had been patched and that no funds were lost at the time. The firm’s disclosure specifically warned that a relayer could otherwise be fooled into paying out on a deposit that did not exist. That description is close enough to the risk Across faced this week that the eventual incident report needs to answer two narrow but vital questions: whether the July attack bypassed the April mitigation, or whether it found a separate flaw in the same trust boundary.
The protocol’s own documentation reflects that complexity. Across tracks deposits through transaction references and deposit data, including support for non-EVM chains such as Solana. Its customer-facing status service distinguishes between transfers that are pending, filled, expired, and refunded. That is useful for users, but it also highlights the amount of off-chain machinery involved in turning a user’s on-chain action into a completed cross-chain payment.
This is where the story becomes relevant beyond crypto trading. Cross-platform systems routinely make the same architectural mistake: an integration receives a signal, assumes it is authoritative, and triggers an irreversible action before verifying the system of record. A payment gateway can trust a webhook without checking settlement. A deployment service can trust a build notification without confirming the artifact. A bridge relayer can trust a parsed transaction trace without verifying the transaction actually succeeded.
The correct control is not merely “listen for fewer events.” It is to bind the payout decision to verified final state, validate the transaction status and required account changes, and make an individual relayer’s maximum exposure small enough that a mistake does not become systemic.
Across’s public statements so far suggest that this last control did its job. The protocol paused the affected deposit route, completed or refunded outstanding transfers, and reopened once it was satisfied operations could resume. It also said it was working with SEAL 911, an incident-response network of security researchers and white hats, to follow attacker-linked addresses.
The missing dollar figure matters. Risk Labs may have absorbed the loss, but relayer capital is still capital required for the network to provide fast fills. If the loss was material, operators and integrators will want to know whether liquidity limits, repayment rules, monitoring thresholds, or relayer admission practices have changed.
Administrators and developers should also watch for concrete remediation rather than broad language about improved safeguards. A useful report will identify the failed validation step, establish whether the April event-spoofing fix was implicated, explain how a malicious transaction reached a payout path, and describe the new invariant that prevents recurrence.
For Across users, the immediate consequence is straightforward: Solana deposits are live again, but the incident has converted an abstract bridge-security promise into a live test case. The architecture protected customers this time. The next milestone is whether the technical report proves it can protect relayers from the same class of failure.
The incident began at roughly 5:30 a.m. UTC on July 17, when Across said it had been attacked on its Solana deployment. Solana-direction deposits were paused while the team investigated, but the rest of the protocol remained operational. Reporting by The Crypto Times first detailed Across’s statement that the only funds potentially affected were those controlled by the Risk Labs relayer; ChainThink, as carried by KuCoin, later reported that deposits had been restored.
That does not make the event a non-story. Across was breached at a meaningful edge of its cross-chain system, and the size of the relayer loss has not been disclosed. But its immediate customer impact appears to have been contained precisely where an intent-based bridge says risk should land: with the party that chooses to front capital, rather than with the user moving assets between chains.
The Relayer Was the Blast Shield
Across does not operate like a conventional lock-and-mint bridge in which a pooled smart contract holds user deposits and issues a representation of those assets elsewhere. Its relayers compete to fulfill a user’s requested transfer quickly on the destination chain, using their own liquidity, then seek reimbursement through the protocol’s settlement process.That arrangement brings obvious business risk for a relayer. A relayer must correctly determine that a deposit happened and that a transfer should be filled before it releases its own capital. If that decision is wrong, its balance sheet—not necessarily the user’s deposited assets—takes the initial loss.
Across has promoted that architecture for years as a way to avoid placing an enormous pot of pooled liquidity behind one critical bridge contract. Its January 2025 security material specifically argued that relayers, rather than users, take on transfer and finality risk. The July 17 incident is the most concrete real-world test of that claim so far.
According to Across, the Risk Labs-operated relayer was the affected participant. Risk Labs supports the protocol, but Across describes its relayer network as permissionless rather than as a one-operator system. The important practical outcome for customers is that an in-flight transfer did not become a claim on an underfunded pool: the protocol says it either finished the transfer or issued a refund.
That is a better failure mode than the bridge industry’s most damaging precedents. In a pooled-liquidity exploit, attackers can compromise the assets users have already entrusted to the bridge. In a relayer-side failure, the loss can be isolated to the firm or operator that opted to quote and finance the fill. Risk was not eliminated; it was assigned differently.
The April Warning Looks Uncomfortably Relevant
Across has not published its promised post-mortem, and it has not publicly confirmed the exact exploit path. Any claim that the July 17 attacker reused a known vulnerability would therefore be premature.Still, the timing puts an April disclosure from Asymmetric Research under a harsh spotlight. In an April 22 write-up, Asymmetric Research described “Across Solana Event Spoofing,” a flaw in the protocol’s Solana-related off-chain handling. The issue could have let an attacker create a misleading deposit signal and persuade relayer software to fill an order even though the underlying deposit had failed.
Asymmetric Research’s explanation turns on an important Solana implementation detail. Ethereum has a standardized, first-class event and receipt model that off-chain services commonly query. Solana applications often reconstruct “events” from transaction traces, instruction data, or program logs retrieved through RPC calls instead.
The security problem is that a failed Solana transaction can still produce logs and other observable execution data. Solana’s own RPC documentation exposes transaction errors separately from the log output. An observer that parses the attractive-looking event data but fails to check the transaction’s final error state can treat an aborted action as evidence that it succeeded.
That is not a failure in Solana’s underlying consensus promise; a failed transaction does not make its state change valid. It is a failure of an off-chain consumer to distinguish diagnostic output from successful state. For bridge operators, market makers, indexers, monitoring agents, and Windows-hosted automation alike, the lesson is familiar: logs are not an authorization decision, and an application event is not proof that a transaction committed.
Asymmetric Research said the April issue had been patched and that no funds were lost at the time. The firm’s disclosure specifically warned that a relayer could otherwise be fooled into paying out on a deposit that did not exist. That description is close enough to the risk Across faced this week that the eventual incident report needs to answer two narrow but vital questions: whether the July attack bypassed the April mitigation, or whether it found a separate flaw in the same trust boundary.
Solana Support Added a New Operational Surface
Across launched in late 2021 with an EVM-focused design. Its Solana expansion created an extra translation layer between an Ethereum-oriented bridge protocol, Solana programs, RPC infrastructure, off-chain relayer software, and the operational rules that decide when money can safely move.The protocol’s own documentation reflects that complexity. Across tracks deposits through transaction references and deposit data, including support for non-EVM chains such as Solana. Its customer-facing status service distinguishes between transfers that are pending, filled, expired, and refunded. That is useful for users, but it also highlights the amount of off-chain machinery involved in turning a user’s on-chain action into a completed cross-chain payment.
This is where the story becomes relevant beyond crypto trading. Cross-platform systems routinely make the same architectural mistake: an integration receives a signal, assumes it is authoritative, and triggers an irreversible action before verifying the system of record. A payment gateway can trust a webhook without checking settlement. A deployment service can trust a build notification without confirming the artifact. A bridge relayer can trust a parsed transaction trace without verifying the transaction actually succeeded.
The correct control is not merely “listen for fewer events.” It is to bind the payout decision to verified final state, validate the transaction status and required account changes, and make an individual relayer’s maximum exposure small enough that a mistake does not become systemic.
Across’s public statements so far suggest that this last control did its job. The protocol paused the affected deposit route, completed or refunded outstanding transfers, and reopened once it was satisfied operations could resume. It also said it was working with SEAL 911, an incident-response network of security researchers and white hats, to follow attacker-linked addresses.
The Post-Mortem Must Be More Than an Assurance
The protocol had previously advertised more than $35 billion in volume without a security incident. As of July 19, that marketing line requires an asterisk. Across can reasonably say user funds were protected during its first publicly disclosed attack, but it cannot say the system escaped unscathed.The missing dollar figure matters. Risk Labs may have absorbed the loss, but relayer capital is still capital required for the network to provide fast fills. If the loss was material, operators and integrators will want to know whether liquidity limits, repayment rules, monitoring thresholds, or relayer admission practices have changed.
Administrators and developers should also watch for concrete remediation rather than broad language about improved safeguards. A useful report will identify the failed validation step, establish whether the April event-spoofing fix was implicated, explain how a malicious transaction reached a payout path, and describe the new invariant that prevents recurrence.
For Across users, the immediate consequence is straightforward: Solana deposits are live again, but the incident has converted an abstract bridge-security promise into a live test case. The architecture protected customers this time. The next milestone is whether the technical report proves it can protect relayers from the same class of failure.
References
- Primary source: Startup Fortune
Published: 2026-07-19T00:29:58+00:00
Across Protocol Got Hacked on Solana and No User Lost a Cent - Startup Fortune
Across Protocol's $34 billion bridge was hacked on Solana July 17, exploiting a fake-deposit bug, but users lost nothing, only Risk Labs did.startupfortune.com - Related coverage: cryptotimes.io
Across Protocol Reports First Attack on Solana After $34B in Bridge Volume
Across Protocol suffered its first Solana attack, but user funds remained safe as Risk Labs' relayer absorbed the loss. Investigation continues.www.cryptotimes.io - Related coverage: pluang.com
Across Protocol's Solana bridge hit by attack; ... | Pluang
Across Protocol confirmed an attack on its Solana bridge deployment, detected early July 17, leading to the disabling of Solana deposits as a precaution. User funds were not affected; only the relayer funds operated by Risk Labs are at risk. This incident highlights ongoing vulnerabilities in...pluang.com - Related coverage: kucoin.com
Across Protocol Confirms Solana Bridge Attack, User Funds Remain Safe | KuCoin
Across Protocol, one of the largest cross-chain bridge platforms in crypto, confirmed on July 17 that its Solana bridge deployment was hit by an attack. The goowww.kucoin.com - Related coverage: gate.com
- Related coverage: across.to
How to Bridge to Solana with Across (Step-By-Step Guide)
Bridge USDC to Solana in seconds with Across. This step-by-step guide shows you how to bridge USDC between Solana and EVM chains—quick, cheap, and secure.across.to