Rosen Bridge Rejects Forged rsBTC Transfers From Cardano to Bitcoin

Repeated attempts to forge rsBTC transfers from Cardano to Bitcoin were rejected by Rosen Bridge after an attacker resumed activity first detected earlier this week. During a Cardano Over Coffee X Space, Rosen Bridge co-founder Joseph Armeanio said the requests appeared shortly after the recent Wanchain incident but failed the protocol’s verification process.

The incident tested infrastructure used to move Bitcoin liquidity between Cardano and other supported networks. Rosen has not identified the attacker or published evidence connecting the attempts to the actor responsible for the Wanchain exploit.

Rosen Bridge Rejects Forged rsBTC Transactions

Rosen Bridge initially reported that its infrastructure had faced an unsuccessful attack. The team said no damage had occurred, although fabricated events could leave reporting permits stuck and require changes to the Watcher and Guard applications.

The project later confirmed in a second official update that the attack had resumed. The attacker was attempting to create forged rsBTC transactions representing transfers from Cardano to Bitcoin, but the requests did not pass Rosen’s verification process.

rsBTC is Rosen’s tokenized representation of Bitcoin on supported networks. Cardano users can receive rsBTC through the bridge, transfer it between compatible wallets and use it within applications that support the asset while retaining a route back to the Bitcoin network.

Armeanio said the fabricated requests began shortly after the Wanchain bridge incident involving 515 million NIGHT. He did not claim that the same attacker was responsible for both events, and Rosen has not attributed the activity to Lazarus Group or any other identified organization.

He also avoided presenting the result as an exceptional achievement for the protocol. Rejecting fabricated transactions, he said, is a basic security requirement for any cross-chain bridge. The attempted attack instead provided a live test of Rosen’s security assumptions and identified parts of the supporting software that require additional hardening.

Watchers and Guards Provide Two Verification Layers

Rosen Bridge is an open-source cross-chain protocol that uses Ergo as its coordination and auditing hub. Its infrastructure supports transfers involving Cardano, Bitcoin, Ergo, Dogecoin and other integrated networks.

The protocol separates monitoring and transaction authorization between two groups, Watchers and Guards.

Watchers independently monitor activity on supported blockchains and report bridge-related events to Ergo. Each blockchain has its own group of Watchers, which collectively operates as a cross-chain oracle for Rosen.

A finalized event report can only be created after enough distinct Watchers submit matching information. According to Rosen’s architecture, a small group of faulty or malicious Watchers cannot independently produce a valid report.

Anyone meeting the collateral requirements can operate a Watcher. Participants allocate ERG and $RSN, obtain reporting permits and receive rewards for accurately reporting settled transfers. Permits used for fraudulent reporting can be seized, creating a financial penalty for submitting fabricated events.

Guards provide the second verification layer. Each Guard independently checks the event reported by the Watchers before the group agrees on the exact payment transaction. Guards do not rely on another Guard’s verification when conducting their own review, which is intended to prevent one incorrect decision from spreading through the group.

The final transaction requires signatures from a quorum of Guards. A single Guard or a smaller malicious group therefore cannot independently authorize an arbitrary payment. Their authority is also restricted through multisignature contracts and wallets, while each Guard locks $RSN as collateral that can be lost in cases of malicious behavior.

Rosen’s documented process continues with the submission and auditing of the final signed transaction. Events and payments are reviewed to prevent duplicate execution, while fraudulent Watcher reports can be removed and the associated permits penalized.

Armeanio said these security assumptions remained intact during the attack. The forged requests were not converted into approved Bitcoin payments, although they created the operational issue involving stuck reporting permits.

Rosen Plans Watcher and Guard Fixes After the Attack

Rosen has confirmed that changes are required in both its Watcher and Guard software. The team described the fixes as necessary but not urgent because the existing verification layers continued to reject the fabricated requests.

A detailed technical postmortem has not been published. Rosen has not disclosed how many requests were submitted, how they were constructed or the precise stage at which each attempt was rejected. The project has also not announced a release date for the Watcher and Guard updates.

Armeanio connected the incident to the broader growth of automated blockchain security testing. He said advanced language models can reduce the time and cost required to review public code, generate repeated attack attempts and modify inputs while searching for weaknesses.

He did not state that artificial intelligence had been confirmed as part of the Rosen attack. His comments addressed a wider security environment in which automated tools allow researchers and attackers to examine larger portions of open-source infrastructure and repeat potential exploits at a lower cost.

Cross-chain bridges carry additional exposure because they combine on-chain contracts, off-chain monitoring, event interpretation, transaction authorization and key management across multiple networks. An attacker does not need to compromise Cardano or Bitcoin directly if bridge infrastructure can be persuaded to treat a fabricated event as valid.

In this case, Rosen’s Watchers and Guards prevented the forged Cardano-to-Bitcoin requests from reaching payment execution. The software changes now being prepared will address the stuck permits and reinforce the two components that processed the attack traffic.