A second large Bitcoin deposit made through the official sBTC Bridge has failed to appear in Emily, the backend used to notify sBTC signers about pending deposits, one day after the Stacks team confirmed and manually repaired an apparently similar failure for the same user.
The new case involves 1.26612838 BTC deposited through the official bridge using an Xverse wallet. GitHub issue #2145 was opened on October 10 at 10:11:58 UTC, or 1:11 p.m. Cairo time.
According to the user, Bitcoin transaction 939d0d39aebd4c4251f6d3ce0cb350ae780683a99ce9a984af24e776740709e5 was successfully broadcast, but the relevant deposit output remained unspent when the report was filed. More importantly, querying Emily returned {"nextToken":null,"deposits":[]}, indicating that the backend had no matching deposit record.
The user had not received the corresponding sBTC and asked the project to determine whether the transaction had encountered the same registration problem as an earlier deposit.
As of the latest check, issue #2145 remained open with no response from the sBTC team. That means the second incident is still a user report and should not yet be described as a confirmed Emily failure.
What makes it significant is what happened to the same user less than a day earlier.
Stacks Team Confirmed the First Deposit Was Never Picked Up by Emily
On October 9, the user reported a separate 0.75933450 BTC deposit made through the sBTC Bridge. Bitcoin transaction bdf6d3acd963dcfc0ae0ee52fd464a6d64bbbcc552ade9bcb04d34abdd378da7 had been broadcast, but the deposit remained absent from both Emily and the bridge transaction history.
A responder using the GitHub account werner-stacks investigated and confirmed that the Bitcoin transaction existed but had been “not picked up by Emily.”
The responder described Emily as the backend that sBTC signers rely on to learn about new deposits, manually registered the transaction and said the deposit should subsequently be swept by the signers and converted into sBTC.
More importantly, the response indicated that the failure was not completely unique. The project representative said similar cases had been noticed where a deposit transaction was created but not registered with Emily, adding that the problem was being worked on.
The user later confirmed receiving the sBTC, and issue #2143 was closed as completed.
The user also confirmed that Xverse had been used to sign that first transaction. The second deposit was likewise initiated with Xverse, and the user says both transactions appear to involve the same Bitcoin deposit destination.
Together, the two deposits total 2.02546288 BTC. The first has been resolved; the second had not been publicly acknowledged by the project at the time of review.
Emily Is a Required Handoff Between Bitcoin and the sBTC Signers
The failure mode matters because broadcasting the Bitcoin transaction is only one part of an sBTC deposit.
According to Stacks’ official deposit documentation, a user first creates and broadcasts a Bitcoin transaction containing the deposit. The application then makes an API call referencing that transaction, which triggers Emily and passes the deposit information to the sBTC signer network.
Emily initially records the deposit as pending. The signers can then validate it, vote on it, sweep the Bitcoin deposit output into the signer-controlled aggregate wallet and mint the corresponding sBTC on Stacks.
This creates an important separation between two states that may look identical to a user.
A Bitcoin deposit transaction can be perfectly valid and confirmed on Bitcoin while still failing to progress through the sBTC system if the registration step that tells Emily about the deposit does not occur successfully.
That differs from conventional bridge failures where funds are stolen or the bridge’s backing itself is compromised. There is currently no allegation that the reported sBTC deposits were stolen, that signer keys were compromised or that sBTC lost its Bitcoin backing.
The problem indicated by the first case is operational: Bitcoin reached the intended deposit script, but the system responsible for bringing that deposit into the signer workflow did not register it automatically.
The Unspent Bitcoin Output Provides a Safety Mechanism
The architecture is designed with a fallback for precisely the possibility that a deposit is not processed.
An sBTC deposit contains both a path allowing the signer set to spend the Bitcoin and a time-locked reclaim path allowing the depositor to recover the BTC after the required number of Bitcoin blocks if the signers do not process it.
That means an unregistered deposit is not automatically equivalent to permanently lost Bitcoin.
But the protection does not eliminate the operational problem. Until the deposit is either discovered and processed or becomes reclaimable, the user can be left with BTC locked in an intermediate state and no corresponding sBTC available to use on Stacks.
For a deposit exceeding 1 BTC, that distinction is economically meaningful even if the funds eventually prove recoverable.
Other crypto platforms have faced a similar gap between funds remaining technically safe and users being temporarily unable to access them. Recent reports of stuck crypto withdrawals, for example, have shown that the absence of an asset loss does not make prolonged transaction failures irrelevant to users.
The Second Case Tests Whether Manual Registration Was a One-Off Fix
The first incident alone could have been treated as an isolated failure in the handoff between the bridge interface and Emily.
A second report from the same user, using the same wallet and apparently reproducing the same observable state one day later, changes the question.
The project has already acknowledged that it has seen other deposits created without being registered in Emily. If issue #2145 is ultimately confirmed to have the same cause, it would provide a particularly clear example of the problem recurring immediately after manual remediation.
That does not necessarily implicate Xverse. Both deposits were signed using the wallet, but there is currently no evidence establishing whether the failure occurred in Xverse, the bridge frontend, the call to Emily, Emily itself or another component between transaction creation and deposit registration.
The distinction is important because wallet correlation alone does not identify the failing layer.
The investigation should be able to narrow that down. The Bitcoin transaction provides evidence about whether the deposit itself was constructed and broadcast correctly, while bridge and Emily logs should show whether the registration request was generated, whether it reached the API, and whether the API rejected, dropped or failed to persist it.
A Registration Gap Is Different From a Signer Failure
This is also why describing the problem simply as an sBTC signer failure would be misleading.
The first case suggests the signers may never have been given the opportunity to process the deposit.
If Emily contained no record of the transaction, the signer network’s normal mechanism for discovering pending deposits did not have the information it needed. Once the transaction was manually registered, the signers processed it and the user received the expected sBTC.
That sequence points upstream of final signer execution.
It is analogous to the difference between a payment failing on its underlying network and a platform’s internal infrastructure failing to recognize the payment. A recent pending Bitcoin Lightning transaction raised a similar question about separating network settlement from the state displayed and maintained by the service operating around it.
For bridge systems, those intermediate layers matter because users generally do not interact with signer infrastructure directly. They rely on the bridge application to correctly construct the transaction, notify the backend and surface an accurate transaction state.
The Bigger Risk Is Reliability, Not Evidence of Missing Backing
Nothing in either GitHub report currently suggests an sBTC solvency problem.
sBTC is designed as a 1:1 Bitcoin-backed asset, and the reported deposit BTC remained visible on Bitcoin rather than disappearing into an unexplained destination. That makes this fundamentally different from incidents in which a Bitcoin-backed asset becomes undercollateralized, such as the recent Nomic bridge exploit that left allBTC underbacked.
The concern here is reliability and detection.
If a deposit can be broadcast correctly but silently fail to register with Emily, the system needs a mechanism to identify that mismatch without waiting for a user to inspect an API response, open a GitHub issue and request manual registration.
Bitcoin itself provides a useful source of truth. A monitoring process could theoretically compare valid sBTC-format deposit outputs appearing on Bitcoin against deposits registered in Emily and flag any transaction that exists in one dataset but not the other.
That kind of reconciliation becomes more important as deposit sizes increase. Manual intervention may be acceptable as an emergency recovery path, but it is difficult to treat it as normal bridge infrastructure when users can have substantial amounts of BTC sitting unprocessed.
Issue #2145 Is Now the Key Test
The next development is straightforward.
If the sBTC team confirms that the 1.26612838 BTC transaction was also broadcast correctly but failed to register with Emily, the October 10 case would reinforce the recurring registration problem already acknowledged in issue #2143.
If the second deposit failed for another reason, that would be equally important because the outward symptoms are nearly identical while the underlying cause would be different.
For now, the evidence supports a precise conclusion: one 0.75933450 BTC deposit was officially confirmed to have been broadcast but missed by Emily, was manually registered and subsequently completed. The same user has now reported a second 1.26612838 BTC deposit that was unspent and absent from Emily when issue #2145 was opened.
The second case is not yet confirmed by the project.
But after the team’s admission that similar unregistered deposits have already been observed, another empty Emily response one day later is enough to make the registration layer — rather than Bitcoin settlement itself — the part of the bridge worth watching.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape. You can reach out to him via his social media accounts:
Linkedin: https://www.linkedin.com/in/johan-shamshad-742851262/
X: https://x.com/Yasmine_FX
Investing: https://www.investing.com/members/contributors/279781574