Coder Legion - Recent posts tagged sepolia

🚀 MyZubster: Completing a Real Ethereum Sepolia Marketplace E2E Payment Flow

Sun, 27 Sep 2026 02:50:20 +0000

MyZubster Sepolia E2E — Technical Deep Dive: Debugging the Full Marketplace Payment Pipeline
I have just completed a full end-to-end technical validation of the MyZubster Marketplace ETH payment pipeline on Ethereum Sepolia.
This was not a simple frontend test.
The work involved debugging and validating multiple layers of the system:

React routing
React development server
Webpack Dev Server
browser runtime diagnostics
frontend bundle generation
Cloudflare CDN caching
Cloudflare Tunnel ingress rules
SPA fallback behavior
API/backend routing
authentication/JWT handling
Marketplace order state
payment-intent generation
MetaMask
Ethereum Sepolia
transaction construction
on-chain transaction verification
confirmation tracking
final Marketplace payment state
The interesting part was that several apparently unrelated browser errors were actually symptoms of infrastructure and routing problems.
1. Starting point: the Marketplace Operations route
  The target route was:
  MyZubster Marketplace Operations — Sepolia
  The React application explicitly defines:
  if (path === '/marketplace/scambi') {
  return ;
  }

and the navigation contains:
window.location.href = '/marketplace/scambi';

So the expected application architecture was:
/marketplace

↓

MarketplacePage

/marketplace/scambi

↓

MarketplaceOpsPage

The first task was proving that this code was actually reaching the browser.

Frontend development server investigation
The frontend was running through Create React App:
react-scripts start

The relevant process was:
/usr/bin/node
/root/myzubster-sepolia-e2e/frontend/node_modules/react-scripts/scripts/start.js

The application was bound to:
127.0.0.1:3010

We verified the listener with:
ss -ltnp | grep ':3010'

which returned the React process.
The process tree was also inspected:
sh
└── react-scripts

  └── node
       └── webpack/react development server

This was important because an attempted restart initially produced:
Something is already running on port 3010.

The issue was not that React could not start.
A previous React development process was already occupying the port.

Local route versus public route
We then compared:
http://127.0.0.1:3010/marketplace/scambi

against:
https://sepolia.myzubster.com/marketplace/scambi

Both returned:
HTTP 200
Content-Type: text/html

This initially suggested that the route was fine.
But an HTTP 200 response alone does not prove that the correct React application version is being served.
The next step was therefore to inspect the actual JavaScript bundle.

Runtime instrumentation
A temporary diagnostic marker was inserted into App.js:
console.log('[MYZ-APP-RUNTIME]', {
pathname: window.location.pathname,
path,
marketplaceOps: path === '/marketplace/scambi',
href: window.location.href
});

The browser then reported:
pathname: "/marketplace/scambi"
path: "/marketplace/scambi"
marketplaceOps: true

This established that the browser itself was correctly interpreting:
/marketplace/scambi

as the Marketplace Operations route.
We also inspected the DOM and confirmed that the browser was loading:
/static/js/bundle.js

Bundle-level verification
The bundle was downloaded and searched directly.
The relevant route was found in the compiled JavaScript:
if (path === '/marketplace/scambi')
return MarketplaceOpsPage;

We also searched for:
Paga ETH su Sepolia

and found it.
This was important because it proved that the Marketplace Operations component was not merely present in the source tree.
It was present in the bundle being served.

Cloudflare cache investigation
The next layer was Cloudflare.
The public bundle returned headers such as:
HTTP/2 200
content-type: application/javascript; charset=utf-8
etag: W/"2c9e23-..."
age: 582
cache-control: max-age=14400
cf-cache-status: HIT

The local bundle had a different ETag:
ETag: W/"2c9ec3-..."

This was the key observation.
The local development server had a newer bundle, while Cloudflare was still serving an older cached object.
So the situation was:
SOURCE CODE

↓

React build/dev server

↓

NEW BUNDLE

│
X

Cloudflare cache

↓

OLD BUNDLE

↓

Browser

This can be particularly confusing because:
HTTP 200

does not mean:
latest application version

Targeted Cloudflare cache purge
Instead of performing a full cache purge, the specific asset was targeted:
https://sepolia.myzubster.com/static/js/bundle.js

through Cloudflare's cache purge interface.
Cloudflare Dashboard
After the purge, a cache-busting request returned:
cf-cache-status: MISS

and the public ETag changed to the current bundle's ETag.
This established that Cloudflare was now fetching the updated asset from the origin.

WebSocket error from Webpack Dev Server
The browser was also reporting:
Firefox cannot establish a connection to
ws://127.0.0.1:3010/ws

This initially looked alarming because the public site was being accessed through:
https://sepolia.myzubster.com

while the Webpack development client was attempting to establish a WebSocket against:
127.0.0.1:3010

The important distinction is that this is development-server HMR/WebSocket infrastructure, not the Marketplace HTTP/API request itself.
The application bundle was nevertheless loading and executing.
The browser continued to report:
MYZ-APP-RUNTIME

and:
marketplaceOps: true

so the WebSocket failure was not the root cause of the Marketplace API problem.

The real API problem
The more significant error appeared when testing:
/api/marketplace/orders/mine

The browser expected JSON.
Instead, it received:
HTTP 200
Content-Type: text/html

with:
<!DOCTYPE html>

This immediately explained:
JSON.parse:
unexpected character at line 1 column 1

The frontend wasn't receiving malformed JSON.
It wasn't receiving JSON at all.
It was receiving the React application's HTML.
This is a classic SPA/API routing failure.

Why this happened
The Cloudflare Tunnel configuration originally routed:
sepolia.myzubster.com
```
↓
```
127.0.0.1:3010

But the backend API was actually listening on:
127.0.0.1:5010

Therefore:
GET /api/marketplace/orders/mine

was effectively becoming:
Cloudflare

↓

Frontend :3010

↓

React index.html

instead of:
Cloudflare

↓

Backend :5010

↓

JSON API

Correcting Cloudflare ingress
The ingress configuration was changed to explicitly separate API traffic:
- hostname: sepolia.myzubster.com
  path: /api/*
  service: http://127.0.0.1:5010

hostname: sepolia.myzubster.com
service: http://127.0.0.1:3010

The routing architecture became:

                     Cloudflare Tunnel
                            │
              sepolia.myzubster.com
                            │
                ┌───────────┴───────────┐
                │                       │
             /api/*                   /*
                │                       │
                ▼                       ▼
           Backend :5010          Frontend :3010
                │                       │
                ▼                       ▼
              JSON                  React SPA

The configuration was validated:
Validating rules from /root/.cloudflared/config.yml
OK

Discovering how Cloudflared was actually managed
An attempt to restart:
systemctl restart cloudflared

failed because:
cloudflared.service not found

We then traced the process:
systemd
└── PM2

  └── cloudflared

PM2 showed:
id: 4
name: cloudflared
status: online

and the command:
/usr/local/bin/cloudflared tunnel
--config /root/.cloudflared/config.yml
--protocol http2
run myzubster

Therefore the correct restart mechanism was:
pm2 restart 4

or:
pm2 restart cloudflared

This is another useful operational lesson: before restarting infrastructure, identify which process manager actually owns it.

API routing verification
After the Tunnel configuration was corrected, the same public endpoint:
https://sepolia.myzubster.com/api/marketplace/orders/mine

returned:
HTTP/2 401
Content-Type: application/json

with:
{
"success": false,
"message": "Token di autenticazione mancante o non valido"
}

This was exactly what we wanted from an unauthenticated request.
The important change was:
Before
200
text/html
React index.html

After
401
application/json
Backend authentication response

A 401 here was actually evidence that routing was fixed.

Authenticated Marketplace order
Using the authenticated browser session:
fetch('/api/marketplace/orders/mine', {
headers: {
Authorization:
Bearer ${localStorage.getItem('myzubster-token')}
},
cache: 'no-store'
})

the backend returned the actual test order.
The order was:
ID:
6ab870ffc33da1e61579745d

with:
status: ACCEPTED

and:
payment.status: AWAITING_PAYMENT

The order snapshot contained:
title:
MyZubster Sepolia ETH E2E Test

price:
0.0001

currency:
ETH

exchangeMode:
payment

At this stage the Marketplace order existed correctly, but the blockchain payment had not yet been made.

Payment-intent endpoint debugging
The frontend initially attempted:
/api/marketplace/orders/{id}/payment-intent

which returned:
404
Cannot GET /api/marketplace/orders/.../payment-intent

The actual endpoint was:
/api/marketplace/orders/{id}/payment/eth-intent

For the E2E order:
/api/marketplace/orders/6ab870ffc33da1e61579745d/payment/eth-intent

the backend returned:
HTTP 200
Content-Type: application/json

with the complete payment intent.

Payment intent structure
The backend returned:
{
"success": true,
"data": {
"asset": "ETH",
"network": "sepolia",
"chainId": 11155111,
"chainHex": "0xaa36a7",
"expectedSender": "0xB15707286c4dFC6f642fcDf217419b2665e1847a",
"expectedRecipient": "0x14d751a54E8617C5A9DF87972dC980827fA91e4d",
"expectedAmountWei": "100000000000000",
"expectedAmountEth": "0.0001",
"minConfirmations": 3,
"paymentStatus": "AWAITING_PAYMENT",
"txId": null,
"testnet": true
}
}

This establishes several critical properties.
Network
Sepolia

Chain
11155111

Amount
100000000000000 wei

which corresponds to:
0.0001 ETH

Required confirmation depth
3

Expected sender
0xB15707286c4dFC6f642fcDf217419b2665e1847a

Expected recipient
0x14d751a54E8617C5A9DF87972dC980827fA91e4d

MetaMask and testnet funding
When attempting to execute the transaction, MetaMask correctly identified that the wallet did not initially have enough SepoliaETH to cover the transaction and network fees.
This is an important distinction in E2E testing:
Payment amount
+
Gas fee

both require testnet funds.
The test wallet was subsequently funded using a Sepolia faucet.
Once the wallet had sufficient SepoliaETH, the transaction could be submitted.

Transaction execution
MetaMask was used to submit:
0.0001 SepoliaETH

from:
0xB15707286c4dFC6f642fcDf217419b2665e1847a

to:
0x14d751a54E8617C5A9DF87972dC980827fA91e4d

The transaction was submitted on:
Ethereum Sepolia
Chain ID: 11155111

The Marketplace immediately entered:
PAYMENT: CONFIRMING

rather than incorrectly assuming that the payment was already final.

Confirmation tracking
The UI displayed:
Confirmations: 0

immediately after transaction submission.
This is an important state distinction:
transaction submitted

≠

payment finalized

The backend continued checking the blockchain until the required confirmation depth was reached.
The configured threshold was:
3 confirmations

Server-side verification
The final payment state was not determined solely by the frontend or by MetaMask.
The verification process used the payment intent as the expected source of truth.
Conceptually:
Expected sender
│
├───────────────┐
Expected recipient │
│ │
Expected amount │
│ ▼
Expected network → Blockchain transaction
```
              │
              ▼
         Verification
              │
       ┌──────┴──────┐
       │             │
    Valid?       Confirmations
       │             │
       └──────┬──────┘
              ▼
             PAID
```

The final transaction satisfied the expected payment parameters.

Final transaction state
The Marketplace eventually showed:
PAYMENT: PAID

with:
Amount:
0.0001 ETH

Network:
Ethereum Sepolia

Confirmations:
3

and the transaction evidence:
TX:
0xae0b...5af9f94c37

The final sender and recipient matched the payment intent.

Complete state transition
The entire Marketplace payment state machine was demonstrated:
┌──────────────────────┐
│ ACCEPTED │
└──────────┬───────────┘
```
   │
   ▼
```
┌──────────────────────┐
│ AWAITING_PAYMENT │
└──────────┬───────────┘
```
   │
   │ MetaMask transaction
   ▼
```
┌──────────────────────┐
│ CONFIRMING │
│ confirmations: 0 │
└──────────┬───────────┘
```
   │
   │ blockchain
   │ confirmations
   ▼
```
┌──────────────────────┐
│ CONFIRMING │
│ confirmations: 3 │
└──────────┬───────────┘
```
   │
   ▼
```
┌──────────────────────┐
│ PAID │
└──────────────────────┘

This is substantially more meaningful than a mocked frontend payment.

Problems encountered and resolved
The E2E test exposed several independent technical problems.
Problem 1 — Existing React process
Something is already running on port 3010

Resolution: identify the existing react-scripts process and manage the correct process.
Problem 2 — Stale Cloudflare bundle
cf-cache-status: HIT
age: 582

with an outdated ETag.
Resolution: targeted Cloudflare cache purge.
Problem 3 — Webpack development WebSocket
ws://127.0.0.1:3010/ws

could not be reached from the public browser.
Resolution: identified as development-server/HMR infrastructure rather than the Marketplace API failure.
Problem 4 — API returned HTML
/api/marketplace/orders/mine

returned:
200 text/html

instead of JSON.
Resolution: separate /api/* from frontend routing in Cloudflare Tunnel.
Problem 5 — Wrong payment-intent endpoint
The frontend attempted:
/payment-intent

while the backend exposed:
/payment/eth-intent

Resolution: use the correct endpoint.
Problem 6 — Missing SepoliaETH
MetaMask reported insufficient funds for network fees.
Resolution: fund the Sepolia test wallet through a faucet.

What makes this a real E2E test?
A useful distinction is:
Mocked test
Click Pay
↓
setState(PAID)

versus:
This test
Marketplace order

↓

authenticated API

↓

payment intent

↓

MetaMask

↓

real Sepolia transaction

↓

Ethereum network

↓

transaction confirmation

↓

server-side verification

↓

3 confirmations

↓

PAID

The second flow crosses actual system boundaries.

Infrastructure architecture after the fixes
The final architecture is:

                 INTERNET
                    │
                    ▼
             Cloudflare Edge
                    │
                    ▼
          Cloudflare Tunnel
                    │
     ┌──────────────┴──────────────┐
     │                             │
 /api/*                         /*
     │                             │
     ▼                             ▼

┌──────────────┐ ┌──────────────┐
│ Backend │ │ React │
│ 127.0.0.1 │ │ 127.0.0.1 │
│ :5010 │ │ :3010 │
└──────┬───────┘ └──────┬───────┘

     │                            │
     ▼                            ▼

Marketplace API Marketplace UI

     │
     ▼

Payment Intent

     │
     ▼
  MetaMask
     │
     ▼

Ethereum Sepolia

     │
     ▼

Blockchain TX

     │
     ▼

Server Verification

     │
     ▼
    PAID

Useful debugging methodology
One of the biggest takeaways from this test is that debugging a Web3 application is not limited to the blockchain.
The actual dependency chain was:
Browser
↓
React
↓
Webpack
↓
HTTP
↓
Cloudflare
↓
Tunnel
↓
Backend
↓
JWT
↓
Marketplace
↓
Payment intent
↓
MetaMask
↓
Ethereum
↓
Verification

A failure anywhere in this chain can manifest as a completely misleading browser error.
For example:
JSON.parse error

looked like a frontend parsing bug.
The real problem was:
Cloudflare routing

↓

React index.html

↓

JSON.parse("<!DOCTYPE html>")

Likewise:
HTTP 200

looked successful.
But:
200 + text/html

was actually evidence of a routing failure.

Live demonstration
The complete Marketplace Operations interface is available here:
MyZubster Marketplace Operations — Sepolia
The public Sepolia environment:
MyZubster Sepolia Environment
The blockchain can be independently inspected through:
Ethereum Sepolia Etherscan
The completed transaction can be located using the transaction hash displayed by the Marketplace payment verification panel:
0xae0b...5af9f94c37
Final technical checklist
[✓] React frontend running
[✓] Marketplace route detected
[✓] MarketplaceOpsPage present in bundle
[✓] Runtime diagnostics verified
[✓] Public bundle verified
[✓] Cloudflare stale cache identified
[✓] Cloudflare cache purged
[✓] Frontend served current bundle
[✓] API routing issue identified
[✓] /api/* routed to backend :5010
[✓] Frontend routes remain on :3010
[✓] Cloudflare Tunnel configuration validated
[✓] PM2 cloudflared process identified
[✓] cloudflared restarted correctly
[✓] Unauthenticated API returns JSON 401
[✓] Authenticated orders endpoint works
[✓] Marketplace order retrieved
[✓] ETH payment intent generated
[✓] Sepolia chain ID verified
[✓] Sender verified
[✓] Recipient verified
[✓] Amount verified
[✓] MetaMask transaction executed
[✓] Sepolia transaction confirmed
[✓] Server-side verification completed
[✓] 3 confirmations reached
[✓] Payment transitioned to PAID

Conclusion
The most important result of this work is not simply that 0.0001 SepoliaETH was transferred.
The important result is that the entire distributed system was exercised and debugged across its real boundaries.
We started with frontend routing and a browser that was not behaving as expected.
We then traced the problem through:
React
→ Webpack Dev Server
→ browser bundle
→ Cloudflare cache
→ Cloudflare Tunnel
→ API routing
→ backend authentication
→ Marketplace order
→ payment intent
→ MetaMask
→ Ethereum Sepolia
→ blockchain confirmations
→ server-side verification

The final state was:
Marketplace Order

    │
    ▼
  ACCEPTED
    │
    ▼

Payment Intent

    │
    ▼

MetaMask / Sepolia

    │
    ▼

Blockchain TX

    │
    ▼

3 Confirmations

    │
    ▼

Server Verification

    │
    ▼
   PAID

The MyZubster Sepolia ETH Marketplace payment pipeline has therefore been successfully exercised end-to-end against a real Sepolia blockchain transaction.

MyZubster #Web3 #Ethereum #Sepolia #Blockchain #React #NodeJS #Express #MetaMask #Cloudflare #CloudflareTunnel #DevOps #E2E #IntegrationTesting #API #JWT #OpenSource #Marketplace #PaymentInfrastructure #SoftwareEngineering

Debugging 6.5 Million PM2 Restarts: Stabilizing MyZubster Sepolia and I-ECO-01

Sat, 26 Sep 2026 14:17:31 +0000

Debugging 6.5 Million PM2 Restarts: Stabilizing MyZubster Sepolia and I-ECO-01

Today I completed a significant infrastructure debugging session across the MyZubster Sepolia E2E environment and the I-ECO-01 / UrbanLab backend.

What initially looked like a few unrelated configuration problems turned into a useful example of why production debugging needs to happen layer by layer.

The work involved Node.js, PM2, MongoDB, Google OAuth 2.0, Cloudflare, Socket.IO, and a Linux VPS.

Here is what happened, what was broken, and how it was fixed.

1. Google OAuth Was Reaching the Backend — But Authentication Still Failed

The first problem appeared in the Google social-login flow.

The authorization request itself looked correct.

Google was receiving the expected client ID and redirect URI:

https://sepolia.myzubster.com/api/auth/social/google/callback

The callback also reached the backend correctly.

Debug instrumentation confirmed:

hasCode: true

hasState: true

hasError: false

So the browser redirect, public route, OAuth state and callback routing were all working.

The failure happened one step later: during the authorization-code exchange.

The backend logged:

401 invalid_client

and Google reported that the provided client secret was invalid.

That was an important distinction.

The problem was not the redirect URI.

It was not Cloudflare.

It was not Express routing.

It was not the OAuth state.

It was not the frontend.

The OAuth client credential itself was wrong.

After correcting the configuration, the backend reached:

OAUTH-CALLBACK-ENTER

followed by:

OAUTH-CALLBACK-SUCCESS

The server-side Google OAuth flow was working.

2. The `.env` File Was Correct — The Running Process Was Not

The next issue was more subtle.

The .env file contained:

FRONTEND_URL=https://sepolia.myzubster.com

and:

GATEWAY_PUBLIC_URL=https://sepolia.myzubster.com

Yet after successful OAuth authentication, the application could still redirect toward an old Vercel deployment.

This highlighted an important operational detail:

Changing .env does not automatically mean a long-running process is using the new values.

I inspected the configuration at several levels:

.env
Node + dotenv
PM2 process configuration
actual process environment
OAuth redirect generation
backend logs

The active PM2 environment was then aligned with the Sepolia deployment:

FRONTEND_URL=https://sepolia.myzubster.com

PUBLIC_APP_URL=https://sepolia.myzubster.com

GATEWAY_PUBLIC_URL=https://sepolia.myzubster.com

After that, the active process environment was verified directly.

3. Then I Found a Process With More Than 6.5 Million Restarts

While checking the rest of the VPS, another issue appeared.

The UrbanLab / I-ECO-01 PM2 process was shown as online, but its restart counter was enormous:

6,548,384 restarts

That immediately suggested a crash/restart loop.

This is one of the reasons I do not treat:

PM2 status = online

as proof that an application is healthy.

A process can start, crash immediately, restart automatically and still repeatedly appear online when inspected at the wrong moment.

4. Finding the Root Cause

PM2 was executing:

/opt/I-ECO-01/server.js

I inspected the server entrypoint and found these dependencies:

dotenv

express

cors

helmet

mongoose

http

socket.io

winston

Then I compared those requirements against package.json.

The project only declared:

cors

dotenv

express

mongoose

The logs confirmed the immediate failure:

Error: Cannot find module 'helmet'

The server crashed at:

const helmet = require('helmet');

Because PM2 automatically restarted the process, the cycle repeated continuously.

5. Fixing the Dependency Graph

Instead of installing only the first missing package and waiting for the next crash, I inspected all external imports in the server entrypoint.

Three npm dependencies were missing:

helmet

socket.io

winston

http did not require installation because it is part of Node.js itself.

The missing dependencies were installed and persisted to package.json.

The resulting application dependencies now include:

Express
CORS
dotenv
Helmet
Mongoose
Socket.IO
Winston

Each new module was then tested independently with require() before restarting the service.

All modules loaded successfully.

6. Application Startup Was Not Enough — I Tested Stability

After restarting UrbanLab, the application successfully initialized its Escrow controller.

The server reported:

Server started on port 5002

MongoDB connected successfully.

The health endpoint:

http://127.0.0.1:5002/health

returned:

status: ok

service: I-ECO-01

mongodb: connected

But I still did not consider the problem solved.

The original issue was a restart loop, so the correct test was to verify process stability over time.

Before the stability test:

PID = 1026452

restarts = 6548384

After 15 seconds:

PID = 1026452

restarts = 6548384

Same PID.

Same restart counter.

The loop had stopped.

7. Escrow Infrastructure Is Running Again

Once the dependency problem was resolved, the I-ECO-01 Escrow controller initialized with:

Threshold: 2/3

Timeout: 24 hours

Fee: 0.5%

The service also initialized its HTTP API and WebSocket infrastructure.

MongoDB remained connected and the health endpoint continued responding successfully.

So the service moved from an uncontrolled crash loop to an operational backend.

8. Old Logs Can Be Misleading

One interesting detail appeared after the repair.

Running:

pm2 logs urbanlab

still displayed:

Cannot find module 'helmet'

At first glance, that could suggest that the problem still existed.

But those entries were historical.

The current process had already successfully loaded Helmet, initialized the application, connected to MongoDB and remained alive with the same PID.

This is why timestamps, process IDs, restart counters and health checks matter when reading operational logs.

A log file can contain a real error that is no longer a current error.

9. What I Verified

By the end of the session:

Google OAuth provider: operational

Google OAuth callback: operational

OAuth authorization-code exchange: successful

OAuth state handling: verified

Sepolia public URL configuration: corrected

PM2 runtime environment: verified

I-ECO-01 Node.js dependencies: repaired

UrbanLab restart loop: stopped

MongoDB: connected

Health endpoint: healthy

Escrow controller: initialized

2-of-3 multisig configuration: loaded

Socket.IO: initialized

PM2/systemd environment: verified

10. The Main Lessons

This debugging session reinforced several useful principles.

`online` does not mean healthy

A process manager tells you about process state.

An application health endpoint tells you about application state.

You often need both.

`.env` does not equal runtime environment

Always verify what the running process actually sees.

This is especially important when using PM2, containers, systemd or other long-running process managers.

Debug OAuth one stage at a time

OAuth involves multiple independent stages:

authorization request → provider consent → callback → state verification → authorization-code exchange → profile retrieval → application session → frontend redirect.

Logging each boundary makes failures much easier to isolate.

Fix dependency problems systematically

When one require() fails, inspect the entire entrypoint instead of repeatedly installing dependencies one crash at a time.

Verify the original failure condition

The problem was a restart loop.

Therefore, successful startup alone was not enough.

The actual success condition was:

same PID + unchanged restart counter + healthy endpoint over time.

Final Result

The MyZubster Sepolia environment is now significantly more stable.

Google OAuth can successfully complete its backend authentication flow.

The Sepolia runtime URLs are correctly propagated to the active backend process.

I-ECO-01 is connected to MongoDB.

The Escrow service is initialized.

And, most importantly, a Node.js service that had accumulated more than 6.5 million PM2 restarts is now staying alive.

Sometimes the most useful development work is not adding another feature.

It is understanding exactly why the existing system is failing — and proving that the fix actually removed the failure.

Stack: Node.js · Express · MongoDB · PM2 · Google OAuth 2.0 · Socket.IO · Cloudflare · Linux · Sepolia

NodeJS #DevOps #WebDevelopment #BackendDevelopment #Debugging #PM2 #MongoDB #OAuth2 #GoogleOAuth #SocketIO #Web3 #Sepolia #Cloudflare #Linux #MyZubster #CoderLegion

Building a Real MetaMask + Ethereum Sepolia Payment Flow for MyZubster

Fri, 25 Sep 2026 05:53:49 +0000

Building a Real MetaMask + Ethereum Sepolia Payment Flow for MyZubster

I’ve been working on the next stage of the MyZubster Marketplace: connecting authenticated users, MetaMask wallets, signed marketplace requests, and real blockchain payment verification.

The target flow is:

MyZubster account
→ verified MetaMask wallet
→ signed marketplace request
→ seller acceptance
→ Ethereum Sepolia payment
→ server-side verification
→ PAID
→ COMPLETED

This week we reached an important milestone: real wallet ownership verification is working end-to-end.

What is working now

We created a completely isolated E2E environment on the VPS instead of experimenting directly in production.

The test stack currently runs as:

React frontend
127.0.0.1:3010

    ↓ proxy

MyZubster backend
127.0.0.1:5010

↓

MongoDB + Ethereum Sepolia RPC

The environment stays private. Instead of exposing the development ports publicly, I access the React frontend from my local machine using an SSH tunnel.

That also means I can use the real MetaMask browser extension against the remote test backend.

Real MetaMask verification

The first working flow is:

Authenticated MyZubster user

↓

Connect MetaMask

↓

Backend generates challenge

↓

MetaMask personal_sign

↓

Backend verifies signature

↓

Wallet becomes VERIFIED

And this is now working with a real wallet.

The UI successfully reached:

Verified · 0xBBBc51B471…03f514bCBb

with confirmation that the wallet was linked to the MyZubster account.

The important detail is that this is not a payment.

personal_sign is only being used to prove wallet ownership.

No ETH is transferred and no gas is consumed.

Authentication and wallet ownership are separate

One thing I wanted to preserve in the architecture is a strict distinction between platform identity and blockchain identity.

A user first authenticates with MyZubster, currently through mechanisms such as Google or GitHub OAuth.

MetaMask then proves control of an EVM address.

So:

AUTHENTICATED ≠ WALLET VERIFIED

And later:

WALLET VERIFIED
≠ REQUEST SIGNED
≠ TX SUBMITTED
≠ PAID
≠ COMPLETED

Those states should never collapse into a single “connected” status.

An interesting network detail

The wallet verification test happened while MetaMask was on:

chainId 84532

which is Base Sepolia.

The Marketplace payment system itself targets:

Ethereum Sepolia
chainId 11155111
0xaa36a7

That is intentional.

Wallet ownership verification proves control of an EVM address.

The actual payment step independently checks the required network and can request MetaMask to switch to Ethereum Sepolia before sending anything.

Signed Marketplace requests

The next layer is already implemented.

When a Buyer requests a real Marketplace listing, MyZubster can generate an order-specific challenge.

The Buyer signs it with MetaMask:

Marketplace listing

↓

Order challenge

↓

personal_sign

↓

Signature verification

↓

Signed request

Again, this does not move funds.

It creates cryptographic evidence that the verified Buyer wallet approved that specific request.

The Seller can then see wallet evidence before deciding whether to accept the order.

The payment architecture

After Seller acceptance, the server creates an ETH payment intent.

That intent defines the expected:

sender
recipient
amount
chain

The frontend then verifies that the currently selected MetaMask account matches the Buyer wallet.

It also verifies Ethereum Sepolia.

Only then can it call:

ethereum.request({
method: "eth_sendTransaction",
...
})

MetaMask still requires explicit approval from the user.

MyZubster never receives the private key.

A transaction hash is not proof of payment

This is probably the part of the architecture I care most about.

The browser submitting a transaction hash does not automatically change the order to PAID.

The backend independently checks the blockchain through the Sepolia RPC.

It verifies things such as:

correct sender
correct recipient
correct network
correct amount
successful transaction
minimum confirmations

The lifecycle can therefore look like:

TX_SUBMITTED

↓

CONFIRMING

↓

3 confirmations

↓

PAID

If something does not match, the verifier can reject the transaction instead.

What has actually been tested

So far the real environment has validated the isolated VPS deployment, frontend/backend proxy, Ethereum Sepolia RPC access, SSH browser access, OAuth-authenticated MyZubster session, MetaMask detection, wallet connection, real personal_sign, server-side signature verification, and successful wallet linking.

The blockchain payment code exists, but I am deliberately not calling the whole Marketplace payment flow complete yet.

What remains

The next E2E test needs two actors:

Seller account + Seller MetaMask wallet

Buyer account + Buyer MetaMask wallet

The Seller will create an ETH listing.

The Buyer will sign a request.

The Seller will inspect and accept it.

The Buyer will then submit a real Ethereum Sepolia transaction using test ETH.

Finally, the backend should independently detect and verify the transaction before changing the order to:

PAID

and eventually:

COMPLETED

After the happy path works, we still need negative tests for wrong wallets, wrong networks, wrong recipients, incorrect amounts, failed transactions, insufficient confirmations, and reused transaction hashes.

Why I’m building it this way

I don’t want “Connect Wallet” to become a magic button that implicitly means identity, authorization, payment, and settlement.

Each operation should have its own proof.

OAuth
→ proves the MyZubster account

Wallet signature
→ proves control of the address

Order signature
→ proves approval of the request

Blockchain transaction
→ proves value movement

Server verifier
→ proves that the transaction matches the order

That makes the system more complex than a simple wallet-connect demo, but it also makes the trust model much clearer.

The first major milestone is now working:

a real authenticated MyZubster user can connect MetaMask, sign an off-chain challenge, and have their EVM wallet independently verified and linked by the backend.

Next stop: the first complete Buyer → Seller transaction on Ethereum Sepolia.

Coder Legion - Recent posts tagged sepolia

🚀 MyZubster: Completing a Real Ethereum Sepolia Marketplace E2E Payment Flow

MyZubster #Web3 #Ethereum #Sepolia #Blockchain #React #NodeJS #Express #MetaMask #Cloudflare #CloudflareTunnel #DevOps #E2E #IntegrationTesting #API #JWT #OpenSource #Marketplace #PaymentInfrastructure #SoftwareEngineering

Debugging 6.5 Million PM2 Restarts: Stabilizing MyZubster Sepolia and I-ECO-01

Debugging 6.5 Million PM2 Restarts: Stabilizing MyZubster Sepolia and I-ECO-01

1. Google OAuth Was Reaching the Backend — But Authentication Still Failed

2. The .env File Was Correct — The Running Process Was Not

3. Then I Found a Process With More Than 6.5 Million Restarts

4. Finding the Root Cause

5. Fixing the Dependency Graph

6. Application Startup Was Not Enough — I Tested Stability

7. Escrow Infrastructure Is Running Again

8. Old Logs Can Be Misleading

9. What I Verified

10. The Main Lessons

online does not mean healthy

.env does not equal runtime environment

Debug OAuth one stage at a time

Fix dependency problems systematically

Verify the original failure condition

Final Result

NodeJS #DevOps #WebDevelopment #BackendDevelopment #Debugging #PM2 #MongoDB #OAuth2 #GoogleOAuth #SocketIO #Web3 #Sepolia #Cloudflare #Linux #MyZubster #CoderLegion

Building a Real MetaMask + Ethereum Sepolia Payment Flow for MyZubster

2. The `.env` File Was Correct — The Running Process Was Not

`online` does not mean healthy

`.env` does not equal runtime environment