[ZK Stack] - Abstract Testnet Bridge not working

[coffeexcoin]

Team or Project

Abstract

Module Affected

• System contracts (era-system-contracts)
• Smart contracts (era-contracts)
• zkEVM (era-zk_evm)
• Server (zksync-era)
• Prover (era-boojum)
• Fee withdrawer (era-fee-withdrawer)
• Block Explorer (clock-explorer)
• Portal - Wallet + Bridge (dapp-portal)
• Other (please specify below)

Rust Version

N/A

Operating System

• Ubuntu
• MacOS
• Windows
• Other (Please specify below)

Issue Description

Multiple users indicating that sepolia Bridge does not seem to be working at this time. I sent a test tx and did not recieve ETH on Abstract Testnet. https://sepolia.etherscan.io/tx/0x45a6732e3ec436e50ce93f7d8ee179e06763a3ae02c7b009856f141e8d2c0760

Expected Behavior

Bridge should function normally

Current Behavior

ETH never appears on Abstract Testnet

Repository Link (if applicable)

No response

Additional Details

No response

Prior Research

• Yes, I searched for similar issues and did not find any matching ones.

[gleenai[bot]]

It appears there was a known issue with long bridging times on the Abstract Testnet, where transactions were not clearing for an extended period. This issue was observed with a delay in bridge transactions from L1 to L2, which should normally clear in about 15 minutes but were delayed for over 30 hours in some cases.

For troubleshooting and ensuring timely delivery of L1 to L2 bridging transactions, you can monitor the status of the transactions through the Block Explorer for the Abstract Testnet. Here is the link to the relevant block that contained all delayed bridging transactions: Block 460163 on Abstract Testnet.

If the issue persists, it might be beneficial to follow up on the ZKsync developers discussions for updates or further assistance.

Your feedback helps us serve you better. If this fully addresses your question, please give it a thumbs up. If it doesn't, please give it a thumbs down. This will inform the community and team so we can improve our support.

[MexicanAce]

Thank you for the report @coffeexcoin , I'm replicating the issue and reaching out to additional resources for further troubleshooting.

[MexicanAce]

@coffeexcoin This should now be resolved. This was resolved by updating the provider (as the other provider was returning errors).

I've confirmed by completing a successful native bridge transfer: https://explorer.testnet.abs.xyz/address/0xF25f95C59f4f1C4010527DAa26e7974cB37c2Ae1

[coffeexcoin]

Thanks, can you elaborate a bit more what provider was updated and what steps are being put in place to help prevent bridge downtimes like this going forward?

[MexicanAce]

Certainly. During the last update, the API provider of eth-watcher was updated to use proxyd. This is used to balance the L1 requests among multiple providers, and it seems to not always properly forward errors - just returning generic 503 instead.

An alert is being added to eth-watcher to catch issues like this in the future: PR here.