DEV Community: Ethan Park

Fix: A Missing .catch() That Crashes Your Entire Node.js Process (ethers.js WebSocket Provider)

Ethan Park — Fri, 21 Aug 2026 16:21:59 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

ethers.js is one of the most widely used Ethereum libraries, with over 3 million weekly downloads on npm. It provides the core infrastructure that thousands of dApps, wallets, and blockchain tools depend on for interacting with EVM chains.

I discovered a bug in the WebSocketProvider that causes uncatchable unhandled rejections — silently crashing production Node.js processes with no way for application code to intercept the error.

Bug Fix or Performance Improvement

The Problem

When a WebSocket provider returns a JSON-RPC error to an eth_subscribe call (auth failure, 5xx behind a gateway, unsupported method), the rejection has no handler and becomes an unhandled rejection that crashes the process.

SocketSubscriber.start() stores the subscribe promise with only a .then():

// Before fix — provider-socket.ts line 63
start(): void {
    this.#filterId = this.#provider.send("eth_subscribe", this.filter).then((filterId) => {;
        this.#provider._register(filterId, this);
        return filterId;
    });
}

start() returns void and #filterId is private — no rejection handler exists and none can be attached from outside. try/catch around contract.on() or provider.on() cannot catch it. The only place it surfaces is process.on('unhandledRejection').

For a long-running event listener, this turns a transient, retryable provider error into a hard process exit.

The Real-World Trigger

This was observed during a provider regional incident. The WebSocket handshake succeeds, the provider reports ready, then eth_subscribe is answered with an error:

Error: could not coalesce error (error={ "code": -32608, "message": "unknown response, status code: 500" },
  payload={ "method": "eth_subscribe", "params": [ "logs", { "address": [...] } ] })

Code

PR: ethers-io/ethers.js#5180

The Fix (Diff)

     start(): void {
-        this.#filterId = this.#provider.send("eth_subscribe", this.filter).then((filterId) => {;
+        const promise = this.#provider.send("eth_subscribe", this.filter).then((filterId) => {
             this.#provider._register(filterId, this);
             return filterId;
+        }, (error) => {
+            if (this.#filterId === promise) { this.#filterId = null; }
+            this.#provider.emit("error", makeError("failed to subscribe", "UNKNOWN_ERROR", {
+                error, info: { filter: this.filter }
+            }));
+            return null as any;
         });
+        this.#filterId = promise;
     }

     stop(): void {
-        (<Promise<number>>(this.#filterId)).then((filterId) => {
-            if (this.#provider.destroyed) { return; }
-            this.#provider.send("eth_unsubscribe", [ filterId ]);
-        });
+        if (this.#filterId != null) {
+            this.#filterId.then((filterId) => {
+                if (filterId == null || this.#provider.destroyed) { return; }
+                this.#provider.send("eth_unsubscribe", [ filterId ]);
+            }).catch(() => { });
+        }
         this.#filterId = null;
     }

My Improvements

Why `.then(onFulfilled, onRejected)` instead of `.catch()`

My first attempt used .catch() with a re-throw to keep the rejection chain:

.catch((error) => {
    this.#provider.emit("error", ...);
    throw error; // Re-throw to preserve the rejection
});

This re-introduced the exact same bug. When .catch() re-throws, it creates a new rejected promise. Since nobody handles that new promise, you get another unhandled rejection — the same crash, just one step further down the chain.

The correct pattern is .then(onFulfilled, onRejected) where onRejected returns null to absorb the rejection. The promise fulfills with null instead of rejecting, so there's nothing unhandled.

Identity Guard for Promise Safety

The onRejected handler sets this.#filterId = null to clean up. But what if start() were called again before the first rejection settles? The stale handler would clobber the new subscription.

I added an identity guard:

if (this.#filterId === promise) { this.#filterId = null; }

This ensures the handler only clears its own promise, never a subsequent one.

Hardening `stop()`

The original stop() had two issues:

No null check on #filterId — calling .then() on null throws
No .catch() — if the subscription had failed, the eth_unsubscribe call would also produce an unhandled rejection
No guard against sending eth_unsubscribe with a null filter ID

Tests Added

Three tests with unhandledRejection process listeners that fail the test if any unhandled rejection occurs:

eth_subscribe rejection emits provider "error" event with correct message
stop() on a failed subscription does not throw
stop() on a failed subscription does not send eth_unsubscribe

Closes #5178. Related to #3924 (the FilterIdSubscriber variant, labelled fixed/complete).

Decoding Ethereum transactions without an ABI

Ethan Park — Sun, 16 Aug 2026 18:28:41 +0000

You're staring at a transaction on Etherscan. The "Input Data" field is a
wall of hex. You don't have the contract's ABI. Now what?

Turns out, you can decode most calldata without an ABI at all. Here's how
it works.

The structure of calldata

Every contract call follows the same format:

0x + [4 bytes function selector] + [ABI-encoded parameters]

The first 4 bytes are the keccak256 hash of the function signature,
truncated. For example:

transfer(address,uint256)
→ keccak256 → 0xa9059cbb...
→ first 4 bytes → 0xa9059cbb

The rest is parameters encoded according to the Solidity ABI spec — uint256
is 32 bytes zero-padded, address is 20 bytes left-padded to 32, dynamic
types get an offset pointer, etc.

Step 1: Extract the selector

const calldata =
'0xa9059cbb000000000000000000000000d8da6bf26964af9d7eed9e03e53415d37aa96045
0000000000000000000000000000000000000000000000000de0b6b3a7640000'

const selector = calldata.slice(0, 10) // '0xa9059cbb'
const params = calldata.slice(10) // everything after

That's it. 4 bytes = 8 hex chars + the 0x prefix = 10 characters.

Step 2: Look up the signature

The 4byte.directory maintains a database of known function signatures
mapped to their selectors. It's a free API:

GET https://www.4byte.directory/api/v1/signatures/?hex_signature=0xa9059cbb

Response:

{
"results": [
{ "text_signature": "transfer(address,uint256)" }
]
}

Now you know the function name and parameter types — without ever seeing
the ABI.

Step 3: Decode the parameters

Once you have the signature transfer(address,uint256), you know the
parameter types. ABI decoding is mechanical:

address → take 32 bytes, last 20 bytes are the address
uint256 → take 32 bytes, interpret as big-endian integer

// Raw params (after selector):
// 000000000000000000000000d8da6bf26964af9d7eed9e03e53415d37aa96045
// 0000000000000000000000000000000000000000000000000de0b6b3a7640000

// Decoded:
// → address: 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045
// → uint256: 1000000000000000000 (1 ETH in wei)

The annoying parts

This is straightforward for simple calls, but it gets messy fast:

Collision: Multiple functions can share a selector. transfer(address,uint256) has 3 entries in 4byte.directory. You need to try decoding with each candidate and see which one doesn't throw.
Dynamic types: string, bytes, and arrays use offset pointers. You have to follow the pointer to find the actual data, then read a length prefix, then the data.
Nested tuples: Solidity structs encode as tuples with recursive offset pointers. A function like exactInputSingle((address,address,uint24,address,uint256,uint256,uint160)) has nested encoding.
No match: Custom errors, proxy calls, or recently deployed contracts might not be in 4byte.directory yet.

Putting it together

I wrote a package that handles all of this — selector lookup, candidate
ranking, ABI decoding with dynamic types, and fallback handling:

import { decodeCalldata } from '@pulsadev/tx-decoder'

const decoded = await decodeCalldata(
'0xa9059cbb000000000000000000000000d8da6bf269...'
)

console.log(decoded)
// {
// name: 'transfer',
// signature: 'transfer(address,uint256)',
// selector: '0xa9059cbb',
// args: ['0xd8dA6BF2...', 1000000000000000000n]
// }

It also handles event logs:

import { decodeLog } from '@pulsadev/tx-decoder'

const event = await decodeLog({
topics: ['0xddf252ad...', '0x000...sender', '0x000...receiver'],
data: '0x0000...amount'
})
// { name: 'Transfer', args: [...] }

And error data from reverted transactions:

import { decodeError } from '@pulsadev/tx-decoder'

decodeError('0x08c379a0...')
// 'Insufficient balance'

Zero dependencies, ~25 KB. Works with any RPC — you don't need ethers or
viem.

The package is @pulsadev/tx-decoder if you want to look at the source. It's
MIT, and the src/ is included in the npm package so you can read every
line.

Ethan Park — Senior Engineer at Pulsa Dev. We build zero-dependency EVM
primitives.

On-chain contract security scanning without API keys

Ethan Park — Sat, 15 Aug 2026 00:31:19 +0000

Every honeypot checker on npm is an API wrapper. GoPlus, honeypot.is, TokenSniffer — they all call someone else's server. If that server goes down, adds a paywall, or starts rate limiting you, your tool is dead.

We wanted something different. A scanner that runs entirely against an RPC endpoint. No API keys. No external services. Just eth_getCode, eth_call, and eth_getStorageAt.

Here's how we built it.

What can you actually check on-chain?

More than you'd think. An EVM contract's bytecode contains function selectors — the first 4 bytes of the keccak256 hash of each function signature. By extracting these selectors from raw bytecode, you can detect:

Mint functions — mint(address,uint256) = 0x40c10f19
Pause/unpause — pause() = 0x8456cb59
Blacklist — blacklist(address) = 0xf9f92be4
Fee manipulation — setTaxFeePercent(uint256) = 0x061c82d0
Owner control — owner() = 0x8da5cb5b, renounceOwnership() = 0x715018a6

The extraction is straightforward. Solidity compilers emit PUSH4 (opcode 0x63) followed by 4 bytes, then EQ (0x14) for the function dispatcher:

for (let i = 0; i < code.length - 10; i += 2) {
  if (code[i] === '6' && code[i + 1] === '3') {
    const sel = code.slice(i + 2, i + 10)
    const lookAhead = code.slice(i + 10, i + 50)
    if (lookAhead.includes('14')) {
      selectors.add(sel.toLowerCase())
    }
  }
}

Match these against a database of known dangerous selectors, and you've got a bytecode-level risk assessment without ever calling an external API.

Proxy detection is trickier than it looks

USDC was our wake-up call. We implemented EIP-1967 storage slot checking:

const IMPLEMENTATION_SLOT = '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc'
const implAddr = await getStorageAt(rpcUrl, address, IMPLEMENTATION_SLOT)

Worked great for most proxies. Then USDC returned zero. Turns out USDC uses a ZeppelinOS proxy pattern with a different storage slot: keccak256("org.zeppelinos.proxy.implementation").

We ended up checking four patterns:

EIP-1167 — minimal proxy bytecode pattern (363d3d373d3d3d363d73...)
EIP-1967 — standard transparent/UUPS proxy storage slot
EIP-897 — implementation() function call
ZeppelinOS — org.zeppelinos.proxy.implementation slot

Each contract only matches one, but you need all four to cover real-world usage.

The EIP-7702 surprise

While testing, we pointed the scanner at Vitalik's address. Expected result: "not a contract." Actual result: it was flagged as a contract.

Turns out Vitalik had set an EIP-7702 delegate designation — a short bytecode starting with 0xef0100 followed by a 20-byte address. It's not a real contract, it's a delegation pointer.

function isContract(bytecode: string): boolean {
  const code = bytecode.startsWith('0x') ? bytecode.slice(2) : bytecode
  if (code.length === 0 || code === '0') return false
  // EIP-7702 delegate designation
  if (code.toLowerCase().startsWith('ef0100') && code.length <= 46) return false
  return true
}

Small edge case, but the kind that matters when you're scanning thousands of addresses.

Honeypot detection via DEX simulation

The most interesting check is honeypot detection. The idea: simulate a buy and sell through a DEX router using eth_call. If the sell reverts, it's a honeypot.

We call swapExactETHForTokensSupportingFeeOnTransferTokens (the fee-on-transfer variant, which handles tax tokens) with a simulation wallet address. If the buy succeeds but the sell fails, the token can't be sold — classic honeypot.

This works without any API because eth_call is a read-only simulation. No gas is spent, no transaction is broadcast. You're just asking the node "what would happen if...?"

Risk scoring

Each check contributes to a 0-100 risk score:

Signal	Points
Honeypot detected	+40
Mint function exists	+15
Blacklist function	+15
Pause function	+10
Transfer fees	+10
No liquidity	+10
Owner not renounced	+5
Proxy contract	+5
Ownership renounced	-10

A score of 0-10 is "safe," 75+ is "critical." It's opinionated, but it gives you a starting point for automated filtering.

What we shipped

The package runs all checks in parallel, supports 7 chains with built-in DEX configurations, and weighs about 28KB with zero dependencies.

import { scanContract } from '@pulsadev/contract-scanner'

const result = await scanContract('0xTokenAddress...', {
  rpcUrl: 'https://ethereum-rpc.publicnode.com',
})

console.log(result.riskLevel)  // 'safe' | 'low' | 'medium' | 'high' | 'critical'
console.log(result.checks.honeypot.isHoneypot)
console.log(result.checks.ownership.isRenounced)
console.log(result.metadata.dangerousFunctions)

Each check is also exported individually, so you can use just the parts you need.

npm: @pulsadev/contract-scanner
GitHub: pulsadev/contract-scanner

If you're building DeFi tooling or security dashboards, I'd love to hear how you're handling on-chain analysis. What checks would you add?