Across Protocol lifted its Solana deposit freeze on July 18, roughly 24 hours after an attacker exploited its Solana integration to siphon funds from a relay operator. Not a single cent of user money was lost, the team said—a claim that, if the eventual post-mortem holds up, would distinguish this incident from a decade of bridge disasters that vaporized depositor assets outright.

What happened

At around 5:30 a.m. UTC on July 17, Across detected suspicious activity targeting its Solana deployment. The protocol immediately paused all Solana-direction deposits while the investigation began. Trading and transfers on other chains continued uninterrupted. By the next day, deposits were live again, and every in‑flight transaction had either been completed on the destination chain or fully refunded to the user’s wallet.

According to statements first reported by The Crypto Times and later confirmed by Across, the attacker had manufactured a fake deposit signal. That signal tricked a relayer—a third‑party liquidity provider that fronts capital to speed up cross‑chain transfers—into releasing its own funds to fill what it thought was a legitimate order. The underlying Solana transaction had actually failed, but because Solana’s execution environment lets even failed programs emit log data, the relayer’s off‑chain software saw what it interpreted as a valid event and paid out.

The affected relayer was operated by Risk Labs, the organization that supports Across’s development. Across has not yet disclosed the dollar value of the loss, nor has it named the attacker. It says it is working with SEAL 911, an incident‑response collective of security researchers and white hats, to track the associated wallet addresses.

Why user funds were never in danger

Across uses an intent‑based bridging model rather than the pooled liquidity design common in earlier bridges. When you initiate a transfer, you don’t lock your assets into a giant smart‑contract vault. Instead, relayers compete to fulfill your order immediately using their own capital, and they seek reimbursement through a separate settlement process later. That architecture means the relayer—not the depositor—carries the initial validation risk.

In this attack, the relayer misjudged a deposit event and lost its own inventory. Because no user funds had been drawn into that flawed settlement, depositors saw their transfers completed or refunded without any gap. Across has described its relay network as permissionless, implying that many independent operators exist, though Risk Labs happened to be the one caught this time.

This containment stands in stark contrast to the bridge industry’s most infamous exploits. The 2022 Ronin hack drained about $625 million from a small set of validator‐controlled keys. The Wormhole exploit that same year took roughly $325 million straight out of pool contracts. In both cases, users who had entrusted assets to the bridge became unsecured creditors overnight. Across’s relayer‑first risk model doesn’t eliminate the possibility of a loss—it just changes whose balance sheet takes the damage.

An April warning that now looks prescient

On April 22, security firm Asymmetric Research published a detailed disclosure titled “Across Solana Event Spoofing.” The write‑up described a vulnerability that could allow an attacker to manipulate off‑chain relay software by creating a transaction that appears to succeed but ultimately fails. The root cause: Solana doesn’t have a native, first‑class “event” system like Ethereum. Instead, applications rely on parsing transaction logs and traces retrieved through RPC calls to reconstruct what happened on‑chain. A failed Solana transaction can still spit out logs, and if an off‑chain consumer checks only the log output and ignores the transaction’s final error status, it could be duped into believing a deposit occurred when it didn’t.

Asymmetric Research said the bug had been patched and that no funds were lost at the time. But the description aligns uncomfortably with the July 17 incident. Across hasn’t yet confirmed whether the recent attack bypassed the April fix or exploited a separate hole in the same trust boundary. That question is now the single most important item for the forthcoming post‑mortem to answer. Either scenario carries implications: if the original patch held and a new flaw was found, then the integration surface is still not mature; if the patch failed, then the original mitigation strategy was insufficient.

What this means for Solana developers—and Windows IT

This is not just a crypto story. The same class of failure happens routinely in traditional software when one system treats unverified output as a source of truth. A payment gateway that trusts a webhook without checking settlement. A deployment service that acts on a build notification without confirming the artifact. A Windows service that parses an event log entry without verifying the return code of the process that generated it.

For developers building cross‑chain applications, Solana’s execution model imposes a specific burden: you cannot treat on‑chain logs as authorization. The only reliable proof that a state change occurred is the transaction’s confirmation status and the final account data. Relayer operators, indexers, wallet backends, and monitoring agents all must verify that a transaction actually committed before triggering an irreversible action. That means checking err fields in RPC responses, replay‑checking signatures, and—crucially—designing withdrawal logic so that a single mis‑verification cannot drain the entire system.

Windows administrators and IT pros who run blockchain‑connected automation (for example, custom scripts that monitor on‑chain events to trigger corporate crypto payments) should take note. If your tooling relies on parse‑and‑react patterns against Solana logs, now is the time to audit that code. The April disclosure and the July attack together provide a practical cheat sheet for what to inspect.

For everyday Windows users who hold crypto in self‑custody wallets and occasionally use bridges like Across, the immediate takeaway is simpler: the protocol’s design did what it promised. If you initiated a Solana transfer between July 17 and July 18, check your wallet history to confirm the outcome. Across insists everything was handled, but a personal audit never hurts. Also, watch for phishing attempts. Attackers often impersonate support teams in the hours after a high‑profile incident.

How we got here

Across launched in late 2021 as an EVM‑focused bridge and expanded to Solana via its V4 upgrade. The Solana integration brought a new set of operational complexities: a different virtual machine, a different event model, and a different set of RPC providers. The protocol’s own documentation acknowledges that relayers on Solana must handle fill‑and‑repayment logic specific to the Solana Virtual Machine.

Before July 17, Across had publicly marketed more than $35 billion in bridged volume without a security incident. That marketing line now needs an asterisk. The protocol can truthfully say users were protected during its first publicly disclosed attack, but it can no longer claim a spotless record. The challenge going forward is whether it can harden the relayer interface enough to prevent a repeat—and whether other Solana‑connected protocols will learn from this before their own relayer‑style logic gets tested.

What to do now

  1. If you are an Across user: Verify your recent Solana transfers. The protocol says all pending transactions were completed or refunded, but it’s wise to check your wallet. Be alert for phishing emails or social‑media messages claiming to be from Across support. The real team will never ask for your seed phrase or private key.

  2. If you are a developer or relayer operator: Review your Solana RPC consumption code. Ensure you parse transaction status (meta.err and meta.status) and never treat a program log alone as proof of success. Re‑examine the April 2026 Asymmetric Research disclosure for the specific patterns that can be spoofed. If you maintain a bridge, relayer, or wallet backend, run a focused code audit on the path that triggers fund releases.

  3. If you manage automated systems: Apply the same principle to any process that reacts to external events—blockchain or otherwise. Confirm the authoritative source of truth before taking irreversible action. In Windows environments, this might mean checking process exit codes rather than trusting log messages; in blockchain contexts, it means checking transaction confirmation.

What to watch next

Across has promised a full post‑mortem. The report must answer two critical questions: whether the April event‑spoofing fix played a role in the July attack, and precisely what additional controls are being implemented. The dollar amount of the relayer loss will also be a signal—not of user harm, but of whether the relayer network’s economics can absorb such shocks without liquidity degradation. For the broader Solana ecosystem, this incident puts a spotlight on tooling. If projects continue to rely on trace‑based event reconstruction, the industry will need stronger shared standards for verifying finality. Across’s response could become a template, or it could be a warning that one safe user outcome isn’t enough to declare victory.