DEV Community: Guo Xiang (Harvey) Ng

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

Guo Xiang (Harvey) Ng — Mon, 13 Oct 2025 08:05:28 +0000

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:

Watch for transactions going to known bridge contract addresses
Track when they complete
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%

Surprisingly, almost 4x more people bridge from BSC to Ethereum than the other way around. I expected the opposite - people fleeing expensive Ethereum gas fees for cheaper BSC.

But my experiment showed the reverse. This is probably because of the Trust factor - despite costs, Ethereum is seen as more secure for long-term holdings. As such, people could be farming yields or performing trades on BSC, then bridging profits back to the "safer" Ethereum. This is also probably because Ethereum still has the most mature ecosystem - the major DeFi protocols, NFT marketplaces, and institutional infrastructure are all primarily on mainnet, so people bridge back to access them.

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

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).
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).
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.
“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.

Setting up Blockchain Nodes with AWS Node Runners (Ethereum, Base, BSC)

Guo Xiang (Harvey) Ng — Thu, 07 Aug 2025 04:44:36 +0000

Introduction

Taken from the intro page, AWS Node Runner is an open source project maintained by AWS DLT and blockchain solution architects. You can read more about it here. The project contains deployment and infrastructure blueprints that allows for easy deployment of self-managed blockchain nodes and node clusters on AWS.

*In comparison, there is an AWS service called Amazon Managed Blockchain (AMB) which is a managed service and supports limited blockchain networks. There are also the 3rd party RPC API/Node Providers like Alchemy and Infura.

As Ethereum’s 10 year anniversary was nearing, i decided to embark on a small experiment to try out some node deployments with the AWS Node Runner project. This article documents my learnings and i’m hoping they will be interesting to you :)

Ethereum Single RPC node setup

Ethereum | AWS Blockchain Node Runners

CDK Deploy

Following the instructions in the link above, the first choice to be made was whether to do the single node setup or the HA setup; and of course in the interest of COST for the POC, single node will do for me. The project is based on Typescript AWS CDK and has 2 deployment layers — common components and node resources (consistent across the supported networks). i.e.

npx cdk deploy eth-common
npx cdk deploy eth-single-node --json --outputs-file single-node-deploy.json

The .env file within lib/eth is the only configuration needed:

^Default Config

^What i used, reducing the instance size slightly

Troubleshooting

Even after waiting for some time, RPC responses are returning 0 (hex 0x0) for everything! Whats going on?!

Without exploring the codebase, here’s what i found exploring the deployed server:

^ 2 Docker containers for Consensus client and Execution client.

Read more here on how these 2 clients form an Eth Node: https://ethereum.org/en/developers/docs/nodes-and-clients/

^Execution Container Logs

^Consensus Container Logs

It turns out that Lighthouse is having a critical error loading checkpoint state fromhttps://beaconstate.info/ which was declared by default in the noderunner .env file. After some exploration, it turns out that there’s nothing wrong with the Beacon Chain checkpoint sync endpoint.

Instead, within this file /home/bcuser/docker-compose.yml, i found that the image versions used for both Geth and Lighthouse containers were not the latest!

After updating the versions, removing old containers and creating the new containers, it finally worked:

cd /home/bcuser && sudo docker compose up -d

#the docker template files for the different client combinations are found in /opt/node 
#docker-compose-geth-lighthouse.yml 
#docker-compose-reth-lighthouse.yml

^Consensus Container Logs

^Execution Container Logs

Monitoring Dashboard

The Node Runner blueprint comes with a monitoring dashboard deployed by the CDK:

This 3 hour chart shows how it wasn’t moving for awhile and then finally syncing started. We can see the infrastructure metrics and how many blocks behind the node is.

After a few more hours, the sync is mostly done now:

Base Single RPC node setup — Snapshot Download Nightmare

Base | AWS Blockchain Node Runners

Base is an Ethereum Layer 2, incubated by Coinbase and built on the open-source Optimism OP Stack. Read more here: https://www.coinbase.com/en-gb/developer-platform/discover/protocol-guides/guide-to-base

CDK Deploy

^From Noderunner Base Blueprint page

^Similar to Ethereum and all other noderunner blueprints, we just need to configure the .env file and run the 2 layers of cdk deploy. I dropped the instance type from 2xlarge to xlarge and included the private IP of my Ethereum node from the previous section.

Troubleshooting/What goes on in the node?

Notice the IO and the network-in metrics! The node is downloading a base snapshot. During my first try my instance stopped from a cost-saver automation which i did not turn off and the process and script stopped. After locating the script and rerunning it, it restarted the download, wasting a few hours.

I then redeployed the CDK stack, this time declaring a BASE_SNAPSHOT_URL pointing to the latest version (same URL in the end) and tried to let it run its course… After checking in the next day after 17 hours, i noticed the following:

Download progress was about ~700GB
I finally decided to check the download size and it translates to a MASSIVE 4.6TB snapshot
Wget failed due to insufficient disk space. The .env default EBS volume size was 1000GB which apparently was not enough.

At this point i decided i had enough “fun” with Base; that size of EBS racks up quite a hefty sum for exploratory learning.

BNB Smart Chain (BSC) Single RPC node setup

Bsc | AWS Blockchain Node Runners

CDK Deploy

I used a much smaller instance type (4xl->xl), lesser storage (4TB->1TB) and the Fast Snapshot instead of default:

^Default .env

^Modified .env

The fast snapshot is significantly smaller than full:

Deploy CDK stacks:

npx cdk deploy bsc-common
npx cdk deploy bsc-single-node --json --outputs-file single-node-deploy.json

For BSC, i faced no troubles at all with the setup despite downsizing from default configuration. As you can see from the monitoring dashboard below, sync was completed in less than 4 hours (inclusive of fast snapshot download)

Key Takeaways

This quick foray into blockchain nodes was quite an interesting experiment for me. I learned how each blockchain has unique requirements — from Ethereum’s dual-client architecture and sync processes to Base’s massive 4.6TB snapshots and storage requirements. The software stacks are rapidly evolving, requiring constant vigilance for updates. While using managed services for building applications is great, running your own infrastructure has no substitute when the goal is to understand what goes on under the hood (although i only just scratched the surface with this) :)

*On top of Eth and Base, i also read up cursorily on a number of the Noderunner blueprints and unfortunately could not play around with Solana which is a non EVM chain and whose Agave clients generate significant outbound traffic that would blow my budget up (AWS charges for outbound internet data transfer and not inbound).

Breaking the Waterfall: Using Azure DevOps Boards for Agile AWS Infrastructure Delivery

Guo Xiang (Harvey) Ng — Mon, 19 May 2025 16:12:26 +0000

Introduction

After experiencing quite a bit of AWS cloud infrastructure delivery work, I’ve noticed and socialized a persistent challenge: while software development teams have widely embraced agile methodologies, day 1 infrastructure delivery teams often remain trapped in waterfall planning and project status reporting. On the other hand, cloud operations teams may operate in a reactive mode, responding to tickets and service requests with limited capacity for proactive planning or improvements.

The traditional approach to new infrastructure projects typically follows a sequential model: design the architecture, build the foundation, implement the components, and then operate the result. In today’s public cloud-native world, this approach has serious limitations. “Cloud infrastructure” needs to adapt continuously as new workloads are deployed, requirements evolve, and operational insights demand changes.

For tech consultancies/system integrators and small lean cloud operation teams, many IT scopes could fall under the purview of a single squad (i.e. security, networking, observability, DevSecOps, database administration, infrastructure work like systems administration, configuration management and container platform operations) instead of having established siloed teams.

This article aims to share a simplified and generalized agile methodology utilizing Azure DevOps Boards — specifically with the Basic process template — to manage AWS infrastructure delivery in an agile manner. Whether you’re an infrastructure project manager used to waterfall who is looking to adopt agile practices or a cloud engineer wanting to implement self-organization, hopefully this read could help you with a starting point to manage the team and deliver results more efficiently and responsively.

Why Public Cloud Infrastructure Projects Need Agile Approaches

Infrastructure delivery has fundamentally changed with cloud adoption. Consider these shifts:

Continuous Evolution: Infrastructure is no longer “built once and forgotten.” AWS environments continuously evolve as new services become available and as business/non-functional requirements change.
Infrastructure as Code: With tools like Terraform, CloudFormation, and CDK, infrastructure changes can be versioned, tested, and deployed using the same agile principles as application code.
Mixed Work Types: As mentioned earlier, Cloud delivery/operations teams might need to simultaneously handle planned infrastructure development, operational support, security improvements, platform feature requests across many IT domains.
Cross-Team Dependencies: Cloud infrastructure/operations teams have complex dependencies with multiple application teams, security teams, and third parties all with different timelines.

These factors make the traditional waterfall approach increasingly ineffective. When infrastructure projects follow rigid phases, they struggle to adapt to changing requirements, can’t easily incorporate operational learnings, and create bottlenecks for application teams.

The most relevant point for myself is point 3 on managing mixed workstream types. For a day 1 tech consultancy team, traditional project management approaches often fail to account for this mix, focusing only on planned development work while treating the rest as distractions or incomplete planned development work.

In this approach, we explicitly acknowledge all these work types and use Azure DevOps boards to visualize them and make informed decisions while providing an actual view and history of the work on the ground for management if required.

Azure Devops Board

While Azure Devops has many features including integration with code version control systems, pipelines, artifact repository, we want to focus on the project management and agile tooling which is its Kanban Boards feature. Let’s get into it and set up a beginner friendly board and i’ll ‘talk’ through my thought process of how to utilize it.

Create a new project and select the ‘Basic’ Work Item Process Template.

There are 4 default processes currently and basic is the most lightweight and is in selective preview currently:

The simplicity of the Basic process template (with just Epics, Issues, and Tasks) makes it accessible for infrastructure-focused teams who do not wish to follow scrum or over-complicate the agile process, but need better tracking than spreadsheets or emails provide.

Epic-Level Organization

You can use Functional/Technical domain areas as epics such as “network security”, “infra compliance/hardening” or “Architecture” but this will create never-ending buckets of work which prevents tracking at epic level (go-ahead if the team is small and tracking at issue level is good enough for getting started).

Else, we want to organize our epics as time-bound, completable milestones. This approach maintains the essential agile principle that epics should eventually reach a “done” state.

Consider the following sample epic categories for either capturing AWS infrastructure milestones or value stream/capability additions:

“MVP Landing Zone Implementation” / “Establish Secure Multi-Account Foundation”
“Establish Infrastructure Provisioning pipelines and tooling”
“Production Network Deployment” / Epics that encompass the deployment of all resources for specific network zones (accounts/VPCs)
“Security Controls Baseline”
“Setup Container Orchestration Platform” / “Setup Kubernetes / Nomad cluster baseline”
“System Monitoring Baseline with Cloudwatch/Dynatrace”
“Creation of baseline EC2 golden images” / Other way to establish baseline Server capabilities (i.e. Remote access, vulnerability scan, patching)
Consider a dedicated “Ongoing Operational Support” epic to capture smaller operational tasks, bug fixes, and workload support activities that don’t naturally fit under specific capability epics (just so those issues can have a parent)

Issue Classification and Management

Under each epic, issues represent the actual units of work. In the Basic process template, the “Issue” work item type is versatile enough to handle various kinds of infrastructure work.

Explore issue creation in different ways:

Team Self-Creation: Good engineers identify and create issues proactively
Tech Lead Assignment: Tech lead/PM can choose to assign the entire epic to good engineers with ownership or assign at the issue level as well (please don’t micromanage by assigning tasks :X )
Service Requests: Application teams can submit requests through integrated channels (*see below)
Monitoring Alerts: Automated creation from monitoring systems for operational issues

The approach you choose should align with your team’s maturity level, culture and ability. Teams with experienced engineers who understand the broader architectural context can benefit from more self management.

*Azure DevOps doesn’t natively function as an ITSM tool but it can be integrated with platforms like ServiceNow or Jira to automatically create work items from service requests. Other Microsoft native options include Teams, Forms and Outlook Email.

Organizing Work Through Tagging

It is worth exploring a simple dual-layer tagging system to enable filtering and organization of 1.Technical Domain 2.Work Type. |

Consider the non-exhaustive example list below.

Technical Domain Tags:

networking: VPC, routing, firewalls, Certificates, IoT
security: IAM, security groups, compliance controls
compute: EC2, container platforms, serverless
storage: S3, EBS
monitoring: CloudWatch, metrics, alerting
sysad: Patch Management, Windows Active Directory, Backup Management
middleware: Configuration
logging: Cloudwatch, log transformation, syslog, splunk

Work Type Tags:

new-build: Net new infrastructure builds
enhancement: Improvements to existing builds
support-task: Tasks supporting application teams
bug-fix: Issues that need remediation
compliance: Regulatory or security compliance work
cost-optimization: Cost reduction efforts

Kanban Board Configuration

Let’s configure the Azure DevOps board with columns that represent our workflow:

To Do: Identified work yet to be assigned/picked up
Doing: Currently being worked on
(Optional) Blocked/Pending: Cannot be completed due to factors beyond the team’s control
(Optional) Review/Validation: Initial implementation completed but require review/testing/validation to be sure it meets the DoD
(Optional) To be propagated/replicated: Generic Solution/mechanisms implemented and tested to have worked but need to be replicated for multiple workloads/accounts/automations/etc.
Done: Completed work

For infrastructure teams, the Review/Validation column is particularly important, as it represents the time between technical completion and confirmation that the infrastructure is working as intended in the actual environment.

Sample Board Illustration

Here’s a sample board for illustration purposes for the completely uninitiated. It doesn’t include the optional workflow states mentioned earlier.

To modify and include more workflow columns, navigate to

>Settings>Column>Add Column

It can then look like this if you choose to add additional columns:

*If you would like a script to generate the 5 epics, 10 issues and 10 tasks above at one go. Here is a link to the PS file:

https://github.com/guoxiangng/azure-devops-board-templates

Using Swimlanes for Work Types

Azure DevOps boards support swimlanes, which we use to separate different types of work visually. This gives the team immediate visibility into how much effort is going into each category:

New Capability: Brand new infrastructure components
Enhancement: Improvements to existing infrastructure
Operational: Work related to running the platform
Urgent/Unplanned: Critical fixes or urgent requests

With this visualization, it becomes immediately apparent if one type of work is consuming too much capacity or if critical work is not progressing quickly enough.

This approach to swimlanes complements our epic structure by allowing us to see work types across all epics. While an epic might focus on a specific capability (like “Implement Secure Container Platform”), the swimlanes show us how that epic’s work is distributed across new features, enhancements, and operational tasks.

Here’s how you can add swimlanes on Azure Devops Board:

Common Challenges and Key Lessons Learned

These are some challenges from my experience and research (online and asking around):

Estimation Difficulty: Infrastructure tasks varied significantly in complexity, making categorization of issues/tasks for work estimation challenging.
Operational Interruptions: Unpredictable operational issues/management escalations still can disrupt planned work or disrespect the Agile Process.
Cross-Team Coordination: Coordinating dependencies with other teams required additional communication channels (and infrastructure blockers can take quite long to resolve if other teams work by waterfall and had a planning gap)

Key lessons learned:

Start Simple: Begin with basic board usage and gradually introduce more agile practices as the team adapts.
Make All Work Visible: Ensure operational and support work appears on the board alongside planned development.
Adapt Planning: Adjust capacity allocations based on emerging needs rather than sticking rigidly to initial plans. (i.e. adapt whether to have sprints and standups based on team maturity, adapt sprint duration based on agreed service SLAs, adapt sprint planning approaches to protect the team from management/app team expectations)
Experiment and Optimize the Process: With the metrics at hand and query-able, try to define ways to measure success and optimize for work process improvements.

Concluding Remarks

With all this said, remember that the best methodology is the one that fits your team’s culture, capabilities, and constraints. Use this approach as a starting point, but always adapt it to your specific context and improve on processes over time.

Lastly, once again this article is for the uninitiated… and may not be relevant for seasoned operations teams with their own ITSM tooling nor for well-oiled co-located teams with clear role delineations.

If you made it to the end, hope you got something out of the read. There are many more features that Azure Devops Boards and similar Project Management Softwares provide. Have fun exploring!