Vibe Coding a Real-Time ETH-BSC Bridge Monitor utilizing My Own AWS NodeRunner Nodes

Introduction

This is a continuation of the article I wrote previously which detailed my experience deploying standalone blockchain nodes with the AWS Node Runner Project.

After setting up my Ethereum and Binance Smart Chain (BSC) nodes, I wanted to actually use them for something. Not just have them sitting there syncing blocks. I’m not ashamed to admit that Claude gave me the simple idea of a bridge monitor which came from the question: How long does it actually take to bridge assets between Ethereum and BSC?

No one seems to have real data on “bridge congestion” and “delayed transactions”. DefiLlama shows bridge volumes, individual bridge sites show “operational status,” but not transaction-level data. How long does Binance Bridge take vs Multichain vs cBridge? Since I already had the infrastructure running, I figured: why not build a bridge monitor?

Code: https://github.com/guoxiangng/eth-bsc-bridge-monitoring

DISCLAIMER — crypto novice here and this personal project was done for learning and curiosity purposes. Forgive me if there are wrong concepts, approaches or statements mentioned.

The Idea

Bridge transactions work by calling specific smart contracts. When someone bridges USDT from Ethereum to BSC, their transaction goes to a bridge contract address on Ethereum. The bridge then releases funds on BSC.

So to monitor the bridge:

1. Watch for transactions going to known bridge contract addresses
2. Track when they complete
3. Calculate performance metrics

The Build

Detecting Bridge Transactions

I started with the most popular bridges for ETH-BSC transfers:

bridges = {
    'eth': {
        '0x6b7a87899490EcE95443e979cA9485CBE7E71522': 'Multichain Router',
        '0x3ee18B2214AFF97000D974cf647E7C347E8fa585': 'Binance Bridge',
        '0x5427FEFA711Eff984124bFBB1AB6fbf5E3DA1820': 'cBridge',
    },
    'bsc': {
        '0x6b7a87899490EcE95443e979cA9485CBE7E71522': 'Multichain Router',
        '0x841ce48F9446C8E281D3F1444cB859b4A6D0738C': 'cBridge BSC',
    }
}

The monitoring logic was to scan recent blocks, check if any transactions are going to these addresses, and save them to a database.

Problem — The BSC PoA Error

First major roadblock came immediately:

⚠️ Error scanning block 56150636 on bsc: The field extraData is 280 bytes, but should be 32. It is quite likely that you are connected to a POA chain.

Turns out BSC uses Proof of Authority consensus, not Proof of Work like Ethereum. This breaks Web3.py’s default assumptions about block structure.

The Fix: One line of middleware and BSC scanning worked afterwards.

from web3.middleware import geth_poa_middleware

Problem — Everything was Pending

Got a basic terminal-style dashboard working pretty quickly with FastAPI:

It showed transactions being detected! 15 pending, 1 completed. Felt good. Engrossed in dashboard updates, I would only later find out that the numbers also quickly increased (soon it was 1,497 transactions detected) but Zero completions. 0.0m average time. 0% success rate.

The issue was that the status update logic wasn’t right.

It was checking 10 transactions at a time and running only every 30 seconds while using simple time-based logic instead of actual blockchain verification.

The Fixes:

# Check ALL pending transactions (removed LIMIT)
cursor.execute('''
    SELECT tx_hash, created_at, direction, block_number
    FROM transactions 
    WHERE status = 'pending'
''')

# Update MORE FREQUENTLY
if cycle % 3 == 0: # Every 15 seconds, not 30
    self.show_comprehensive_stats()

# Actually verify transaction on-chain
receipt = w3.eth.get_transaction_receipt(tx_hash)

if receipt and receipt['status'] == 1:
    cursor.execute('''
        UPDATE transactions
        SET status = 'completed',
            completed_at = datetime('now'),
            completion_time = ?,
            gas_used = ?
        WHERE tx_hash = ?
    ''', (elapsed, receipt['gasUsed'], tx_hash))

After the fixes, things started looking real:

• 7,956 transactions tracked
• 7,101 completed
• 4.1m average completion time
• Success rates by bridge : Wormhole Token at 92%, cBridge at 76%, etc.

Expanding From 5 Bridges to 20+

The initial version only monitored 5 bridge contracts. But there are actually dozens of bridges operating between ETH and BSC. I expanded the contract list to include:

        self.bridges = {
            'eth': {
                # Multichain (AnySwap) - Multiple contracts
                '0x6b7a87899490EcE95443e979cA9485CBE7E71522': 'Multichain Router',
                '0x533e3c0e6b48010873B947bddC4721b1bDFF9648': 'Multichain USDT',
                '0x765277EebeCA2e31912C9946eAe1021199B39C61': 'Multichain ETH',
                '0xC564EE9f21Ed8A2d8E7e76c085740d5e4c5FaFbE': 'Multichain USDC',
                # Binance Bridge
                '0x3ee18B2214AFF97000D974cf647E7C347E8fa585': 'Binance Bridge',
                '0xfA0F307783AC21C39E939ACFF795e27b650F6e68': 'Binance Token Hub',
                # cBridge (Celer) 
                # ... +15 more from Wormhole Portal Bridge, Stargate (LayerZero), Synapse Bridge, Hop Protocol, Across Protocol, deBridge, Connext
            },

            'bsc': {
                # Multichain on BSC
                '0x6b7a87899490EcE95443e979cA9485CBE7E71522': 'Multichain Router',
                '0x533e3c0e6b48010873B947bddC4721b1bDFF9648': 'Multichain USDT',
                '0xC564EE9f21Ed8A2d8E7e76c085740d5e4c5FaFbE': 'Multichain USDC',
                # Binance Bridge BSC side
                '0x0000000000000000000000000000000000001004': 'BSC Token Hub',
                '0x533e3c0e6b48010873B947bddC4721b1bDFF9648': 'BSC Bridge',
                # cBridge BSC + many more from Wormhole BSCStargate BSC, Synapse BSC, deBridge BSC, Orbit Bridge
            }
        }

This immediately improved detection and catching of transactions manyfold.

Adding Some Performance Analytics

With real data flowing in, I could start getting the answer of which Bridge is the fastest!

Looking at the dashboard:

• Synapse Bridge : 3.4m avg, 100% success
• Stargate : 3.7m avg, 13% success
• cBridge Main : 3.3m avg, 74% success
• Potential ETH Bridge : 4.1m avg, 90% success

Cleaning up the Database

As features were added, new database columns were needed which owuld cause errors when old code tried to save transactions with new fields that didn’t exist yet:

❌ Save error: table transactions has no column named token_symbol

I added a clean_db_setup.py that wipes the database and starts fresh with a comprehensive schema.

Adding Stuck Transaction Alerts

Detecting potentially stuck transactions seemed useful:

The red alert box at the top shows transactions that have been pending for >30 minutes. In real use, you’d want notifications when your specific transaction gets stuck.

The Findings (About Bridge Performance)

Based on my only few hours long experiment, these are the conclusions:

• Fastest : cBridge at ~3.3 minutes
• Most Reliable : Synapse at 100% success rate
• Slowest : Some “Potential” bridges at 30+ minutes

Looking at the direction analysis:

• ETH → BSC : 465 transactions
• BSC → ETH : 1,819 transactions
• Overall success rate : 97%

More people bridge FROM Ethereum TO BSC than the reverse. Makes sense — gas fees on Ethereum push people to move assets to cheaper chains.

Summary of my Experimental Setup

You can find the Personal project code here: https://github.com/guoxiangng/eth-bsc-bridge-monitoring

There’s more information in the readme. The simple setup does the following:

Monitor Process:

• Scans both ETH and BSC chains every 5 seconds
• Monitors 20+ bridge contracts
• Checks last 10 blocks for new transactions
• Updates transaction statuses every 15 seconds
• Saves everything to SQLite

Dashboard:

• FastAPI serving on port 8000
• Auto-refreshes every 30 seconds
• Shows performance comparison across bridges
• Pagination for viewing all transactions
• Filtering by bridge, status, direction

Server Resources:

Running comfortably on the same EC2 instances as the Ethereum AWS Node Runner node.

Concluding Thoughts

1. Flexibility of using my own Nodes Using my own nodes provided the flexibility of tweaking the blockchain scanning frequency however I felt like and having no API delays at all. Using managed providers comes with API call/credit based pricing model potentially with rate limits or API quotas as well. (Although it probably still costs more to manage own nodes in production; we ought to do our own cost analysis).
2. Transaction Volume Actually seeing 1,000+ transactions across the monitored bridges in a short period of time was really surprising. The ETH-BSC corridor is way more active than I thought (although it’s not like I have much of any frame of reference).
3. Success Rates Vary A LOT Some bridges show 100% success, others 70–80%. Not sure if this is real or issues with my completion detection logic; but i’m not going to investigate further :P.
4. “Potential” Bridges A significant chunk of transactions I’m detecting are to DEX routers (“Potential” bridges), not direct bridge contracts. These might be bridge-related (some bridges route through DEXes), or might be noise. Need better filtering.