DEV Community: Superwavvy

Stop Getting Distracted and Missing Your 2x's!

Superwavvy — Fri, 25 Sep 2026 15:12:32 +0000

Let’s be honest. We’ve all been there. You spend hours scanning DexScreener, finally ape into a low-cap Solana gem, and then you look away for 10 minutes to do something else. You come back, and it's already up 300% without you. Or worse, it rugged while you were gone.

I got tired of losing money because I couldn’t stare at a chart 24/7. So, I built a solution for me and my friends.

Introducing the Multiples Alert Bot.

It’s a simple Telegram bot that does one thing perfectly: it watches your tokens and yells at you when they hit your targets. No more constant refreshing. No more missed pumps.

Here is what makes it different:

· Market Cap Focused: Price means nothing in memecoins. We track Market Cap (MC). If you paste a CA at a $100k MC, you get alerted at $200k, $500k, etc.
· Custom Milestones: By default, it tracks 2x. But with a tap of a button, you can set it to 5x, 10x, or punch in a custom sequence like 3x, 6x, 9x.
· Whipsaw Protection: Memecoins bounce. If your token hits 2x and drops back down, the bot won't spam you. It only resets the alert if it drops significantly (10% below the target).
· The 0.5x Safety Net: If the token dumps to half of your entry MC, it sends you one single "Get out now" alert. No spam, just the cold hard truth.

How to use it:
You literally just paste a Solana Contract Address (CA) into the chat. The bot scans it, logs the base MC, and starts checking the price every 15 seconds. You can track tickers too, and manage all your tokens with a simple /list command.

I’m currently opening up beta access to a small group of 3-10 people to stress-test it before I deploy it to a dedicated server.

If you’re tired of missing your multiples and want to give it a spin, drop a comment or DM me on Twitter @ytnwavvy. Let’s catch some pumps.

Building a CEX/DEX Alert Bot on Android: When Your Code Works, but Your Network Doesn't

Superwavvy — Tue, 22 Sep 2026 15:54:23 +0000

I have a confession: my mobile network almost made me quit this project.

Over the past week, I've been building a suite of DeFi monitoring tools that run entirely on my Android phone using Termux. The latest addition is a Price Alert Bot that monitors Centralized Exchange (CEX) prices against Decentralized Exchange (DEX) prices on Arbitrum, and watches for stablecoin depegs.

It runs 24/7 in the background, sends alerts to my Telegram, and caught a real 0.60% spread on AAVE just yesterday.

But getting here was a war. I dealt with Ethers v6 breaking changes, "ghost pools" showing fake 262% spreads, and a mobile ISP that actively blocks crypto APIs.

Here is the story of how I built it, and the exact fixes for the errors that almost broke me.

1. The Ethers v6 Trap (And the RPC Mix-up)

If you're migrating from Ethers v5 to v6, brace yourself. The first error I hit was:

TypeError: Cannot read properties of undefined (reading 'JsonRpcProvider')

In v6, the providers namespace was removed. Your syntax changes from new ethers.providers.JsonRpcProvider() to new ethers.JsonRpcProvider().

But the real facepalm moment? I was using an Ethereum Mainnet Alchemy RPC URL for a bot querying Arbitrum contracts. The provider was timing out trying to find contracts that didn't exist on the wrong chain.

Fix: Always create a dedicated Arbitrum app in your Alchemy dashboard, and hardcode the chain ID to prevent mobile timeouts:

const provider = new ethers.JsonRpcProvider(ARBITRUM_RPC, {
    chainId: 42161,
    name: 'arbitrum'
});

2. The Case of the 262% "Ghost" Spread

When I first built the price comparison logic, I used Uniswap V2 and SushiSwap. My bot immediately alerted me to a 262% arbitrage opportunity for WETH.

It was a trap. Uniswap V2 and SushiSwap are ghost towns on Arbitrum. The pools are practically empty, which completely distorts the math.

Fix: Before calculating a price, query the pool's liquidity directly. If it's below a certain threshold (e.g., $50k), skip it entirely.

const pairContract = new ethers.Contract(pairAddress, PAIR_ABI, provider);
const reserves = await pairContract.getReserves();
// Check if reserves are sufficient before proceeding

3. The Camelot V3 Conundrum

Once I switched to Uniswap V3 and Camelot V3, I hit a wall with Camelot. It's built on the Algebra protocol, meaning standard Uniswap V3 ABIs fail.

Uniswap V3 uses getPool(tokenA, tokenB, fee). Camelot uses poolByPair(tokenA, tokenB) with no fee parameter. If you don't account for this, your quotes will revert with execution reverted.

Fix: Use the correct factory ABI, and remember to compare BigInts correctly (0n vs 0).

4. The Mobile ISP Boss Fight

Here is the part that almost broke me. My bot was perfect, but it kept throwing these errors:

CEX Error: getaddrinfo ENOTFOUND api.bybit.com
JsonRpcProvider failed to detect network and cannot start up

My mobile carrier was actively blocking specific crypto exchange APIs and timing out the RPC connections.

Fix: Cloudflare WARP (1.1.1.1). I turned it on, and instantly, every ENOTFOUND error vanished. The bot was finally reaching Bybit and Uniswap without any issues.

5. The Final Architecture

The bot now does three things every 2 hours:

1. Price Targets: Alerts me if UNI or AAVE crosses a specific USD threshold.
2. CEX/DEX Spread: Compares Bybit/Coinbase prices against Uniswap V3 on Arbitrum. If the spread is >0.5%, it pings my Telegram.
3. Depeg Monitoring: Checks USDT and DAI against USDC on Arbitrum. If they deviate by >0.5%, I get an emergency alert.

Conclusion

Building DeFi tools on a mobile phone is chaotic, but it's the best way to learn about real-world infrastructure. You learn to handle rate limits, ISP blocks, and AMM math quirks that you'd never encounter in a sandboxed environment.

The entire codebase is open source. You can check it out on GitHub: github.com/superwavvy/price-alert-bot

Next up: I'm tackling the execution layer.

Have you ever run a bot on mobile? How do you handle ISP blocks? Let me know in the comments!

Also check my previous articles, thanks!
Click here

Building a Multi-DEX Arbitrage Scanner on Arbitrum: When APIs Fail, Query the Blockchain

Superwavvy — Wed, 16 Sep 2026 08:07:17 +0000

I decided to challenge myself, so I built two DeFi monitoring bots that worked flawlessly. Then I tried to add a third: an arbitrage detector then I hit a wall so hard I almost gave up.

This is the story of what went wrong, why it went wrong, and how querying smart contracts directly solved every problem that free APIs created.

The Plan (That Didn't Work)

Simple idea: monitor prices on Uniswap and Sushiswap, find discrepancies, alert on profit opportunities.

I started with what seemed logical: use the 1inch API. Free tier, no keys needed, returns aggregate prices across all DEXs in one call.

async function getPrices(tokenAddresses) {
  const url = `https://api.1inch.com/price/v1.1/${CHAIN_ID}`;

  const response = await axios.post(url, {
    tokens: tokenAddresses,
    currency: 'USD'
  });
  return response.data;
}

Neat, right? One line of logic. One API call. Done.

Except it wasn't.

Problem 1: The 402 That Wouldn't Stop

First test run: API error: timeout of 5000ms exceeded

Second test run: API error: Request failed with status code 402 (Payment Required)

Third run: Same 402.

The 1inch API free tier was rejecting my requests. Either I was rate-limited or the endpoint didn't support the way I was querying it. Either way, the API was unreliable for what I needed.

The lesson: Free APIs have hard limits that don't care about your timeline. When they hit that limit, you're blocked.

Problem 2: The Alchemy RPC Timeout

Okay, skip 1inch. I then used Alchemy's RPC directly with ethers.js. Queried the contracts myself.

const provider = new ethers.providers.JsonRpcProvider(
  `https://arb-mainnet.g.alchemy.com/v2/${process.env.ALCHEMY_API_KEY}`
);

const blockNumber = await provider.getBlockNumber();

Neat concept. Direct blockchain access. No middleman API.

Except Alchemy's RPC to Arbitrum kept timing out.

30 seconds of waiting. Nothing. Then: JsonRpcProvider failed to detect network and cannot start up

I had the right Alchemy key, the right RPC endpoint, everything looked correct. But Alchemy's Arbitrum endpoint was flaky from Termux on my phone's internet.

The lesson: Even paid providers have reliability issues when you're querying from unconventional environments.

Problem 3: The Wrong Chain

After hours of debugging, I realized something: my .env file had an Alchemy key for Ethereum Mainnet, not Arbitrum.

I was trying to query Arbitrum with an Ethereum endpoint. No wonder it was timing out.

After hours of debugging, I caught it then hardcoded the Arbitrum chain ID and moved on.

const CHAIN_ID = 42161; // Arbitrum
const provider = new ethers.JsonRpcProvider(
  `https://arb-mainnet.g.alchemy.com/v2/${ARBITRUM_API_KEY}`
);

The lesson: Simple mistakes kill hours. Always verify your configuration matches your target chain.

Problem 4: The Phantom Arbitrage (Ghost Pools)

Data started flowing. I saw spreads like:

Uniswap V3: 1 WETH = $2269 USDC
Sushiswap: 1 WETH = $626 USDC

A 262% difference. Free money, right?

Wrong. Sushiswap doesn't have real liquidity on Arbitrum. It's a ghost town. The contract exists, but there's no actual trading happening. The "price" the contract returned was meaningless.

This is called a phantom arbitrage — a spread that looks profitable until you realize one side of the trade has zero liquidity.

The fix: Before calculating profit, check if the pool actually has liquidity.

const uniswapLiquidity = await factoryContract.getPool(
  TOKEN_A,
  TOKEN_B,
  FEE_TIER
);

// If liquidity is 0, skip this pair
if (uniswapLiquidity.liquidity === 0n) {
  console.log('Dead pool, skipping');
  return null;
}

The lesson: Prices without liquidity are hallucinations. You need both.

Problem 5: The Uniswap V3 Quoter Address Mismatch

Uniswap V3 has a QuoterV2 contract. It gives you exact prices based on trade size.

I was using the Ethereum Mainnet QuoterV2 address on Arbitrum. Different chain, different address, different contract. It failed silently.

// WRONG - Ethereum address
const QUOTER = '0x61fFE014bA17989E8aBf2F2B629bDA3dB2e02C00';

// RIGHT - Arbitrum address
const QUOTER = '0x61ffE014ba17989E8aBf2F2b629BdA3Db2e02C00';

The point: Chain-specific addresses matter. Copy-pasting from Ethereum docs broke everything.

The fix: Use Uniswap's official contract addresses for each chain, or query the factory directly.

Problem 6: Camelot V3 Uses Different ABIs

Uniswap V3 works one way. Camelot (another DEX on Arbitrum) uses the same Uniswap v3-compatible interface but with slightly different function signatures.

My Uniswap V3 code crashed on Camelot because the ABI expected different return values.

// Uniswap V3 QuoterV2
const response = await quoter.quoteExactInputSingle({
  tokenIn,
  tokenOut,
  fee,
  amountIn
});

// Camelot V3 (Algebra protocol)
// Different function name, different return structure
const response = await quoter.quoteExactInputSingle({
  tokenIn,
  tokenOut,
  amountIn
});
// Returns 4 values, not 1

The lesson: Even "compatible" protocols have subtle differences. You need to test against each one.

The Solution: Query Contracts Directly

After all this, I realised something simple: forget APIs. Query the DEX contracts directly.

const { ethers } = require('ethers');

const provider = new ethers.JsonRpcProvider(
  'https://arb1.arbitrum.io:8545'
);

// Get Uniswap V3 factory
const factoryAbi = ['function getPool(address,address,uint24) view returns (address)'];
const factory = new ethers.Contract(
  '0x1F98431c8aD98523631AE4a59f267346ea3113F8',
  factoryAbi,
  provider
);

// Query the pool directly
const poolAddress = await factory.getPool(
  WETH_ADDRESS,
  USDC_ADDRESS,
  FEE_3000
);

// Check if pool exists and has liquidity
const poolAbi = ['function liquidity() view returns (uint128)'];
const pool = new ethers.Contract(poolAddress, poolAbi, provider);
const liquidity = await pool.liquidity();

if (liquidity === 0n) {
  console.log('No liquidity, skip');
}

No API rate limits. No timeouts. No phantom spreads. Just blockchain data.

The cost? You have to understand smart contract ABIs and know which addresses to query. But once you know the contracts, it's rock solid.

The Trade-off

APIs are convenient until they're not. They ease complexity, handle rate limiting, and return clean JSON. But they fail at inconvenient times, have hard limits, and cost money at scale.

Direct contract queries are slower to set up but more reliable once working. You talk to the source of truth (the blockchain) instead of a middleman's interpretation of it.

For a bot running 24/7 on my phone with limited bandwidth, direct queries won.

What's Running Now

The arbitrage detector queries:

Uniswap V3 (checks liquidity + gets quotes)
Camelot V3 (different ABI, but same idea)
Filters out dead pools
Calculates spread after fees
Alerts only on >0.3% spreads (to account for gas)

async function checkArbitrage() {
  const wethPool = await getPoolLiquidity(WETH, USDC, uniswap);
  if (wethPool.liquidity === 0n) return;

  const uniPrice = await getPrice(wethPool);
  const camelotPrice = await getPrice(await getPoolLiquidity(WETH, USDC, camelot));

  const spread = ((uniPrice - camelotPrice) / camelotPrice) * 100;

  if (spread > 0.3) {
    // Alert: profitable opportunity
    await sendAlert(`Spread: ${spread}% | Buy on Camelot, sell on Uniswap`);
  }
}

Running on Arbitrum. No API complaints. No timeouts. Real data every 5 minutes.

The Real Lesson

Building production bots taught me something that tutorials don't: constraints are features.

Being limited to free APIs, running from a phone on mobile data, and targeting an L2 that most devs ignore forced me to think about reliability instead of convenience.

The code is messier because it accounts for multiple DEX ABIs, liquidity checks, and contract-specific quirks. But it's more honest about what the blockchain actually looks like.

APIs smooth over these details. Sometimes that's helpful. But when the bot needs to run 24/7, you need to know the real shape of the thing you're monitoring.

That's why I query contracts directly now.

Running on: Arbitrum, Ethers.js v6, Alchemy RPC (Arbitrum), Termux on Android, real data.

Current spreads: Uniswap V3 vs Camelot V3 on WETH/USDC. Threshold: 0.3% (after fees).

Next: 30 days of data collection and pattern analysis, while I try to incorporate either telegram/discord notifications into the codebase to alert for arbitrage opportunities.

5 Errors I Hit Building DeFi Bots (And How to Fix Them)

Superwavvy — Sat, 12 Sep 2026 08:00:31 +0000

Building production bots on free APIs sounds cool in theory. In practice, you hit walls immediately. Here are the 5 real errors I encountered while building two Ethereum monitoring bots, and exactly how I fixed them.

Error 1: Alchemy Event Listeners Timeout After 5 Minutes

The Problem:
I started monitoring Aave liquidations using ethers.js event listeners on free-tier Alchemy.

provider.on(filter, (log) => {
  console.log("Liquidation detected:", log);
});

Worked perfectly for 5 minutes. Then the WebSocket died. No error message. Just silence. Listener stopped working forever.

Why it happens:
Free-tier Alchemy (and most providers) have timeout limits on WebSocket connections. Idle connections get dropped. No reconnect logic on the free tier.

The Fix:
Stop using event listeners. Use polling instead.

async function pollLiquidations() {
  const currentBlock = await provider.getBlockNumber();
  const logs = await provider.getLogs({
    address: AAVE_LENDING_POOL,
    topics: [LIQUIDATION_CALL_TOPIC],
    fromBlock: currentBlock - 9,
    toBlock: currentBlock
  });

  logs.forEach(log => handleLiquidation(log));
}

// Poll every 15 minutes
setInterval(pollLiquidations, 15 * 60 * 1000);

The lesson: On free tier, reliability > real-time. Polling every 15 minutes that works beats real-time listeners that disconnect.

Error 2: CoinGecko Rate Limit 429 (Too Many Requests)

The Problem:
I wanted to track 5 tokens: UNI, AAVE, USDC, DAI, USDT.

const tokens = ['UNI', 'AAVE', 'USDC', 'DAI', 'USDT'];

async function getPrices() {
  const prices = await Promise.all(
    tokens.map(token => 
      axios.get(`https://api.coingecko.com/api/v3/simple/price?ids=${token}...`)
    )
  );
}

// Check every 15 minutes
setInterval(getPrices, 15 * 60 * 1000);

After a day, I got slammed with 429 errors. CoinGecko rate-limited me. Price alerts stopped working.

Why it happens:
Free-tier CoinGecko allows ~5 requests per second, but daily limits kick in after 50 concurrent calls per minute. 5 tokens × 96 checks/day = 480 calls. You hit the limit.

The Fix:
Reduce frequency OR reduce tokens. I chose frequency.

const tokens = ['UNI', 'AAVE']; // 2 tokens only

// Check every 2 hours (not 15 mins)
// 2 tokens × 12 checks/day = 24 calls. Under limit.
setInterval(getPrices, 2 * 60 * 60 * 1000);

Still catches all meaningful moves (5%+ happens in hours, not minutes).

The lesson: APIs are precious on free tier. Reduce scope, not reliability. 2 tokens checked reliably > 5 tokens checked intermittently.

Error 3: Supabase RLS "New Row Violates Row-Level Security Policy"

The Problem:
Bots ran fine for 2 days. Then suddenly:

Supabase error: new row violates row-level security policy for table "price_history"

Both bots stopped writing data. Data collection halted. Silent failure.

Why it happens:
I had Row-Level Security (RLS) enabled but forgot to disable it for anonymous (public) access. When the bots tried to INSERT with anon key, RLS rejected them.

// This would fail
const { error } = await supabase
  .from('price_history')
  .insert([{ symbol: 'UNI', price: 5.94 }])

The Fix:
Disable RLS on the tables (if you're the only user):

ALTER TABLE price_history DISABLE ROW LEVEL SECURITY;
ALTER TABLE liquidations DISABLE ROW LEVEL SECURITY;

Or enable RLS but create a policy:

CREATE POLICY "Enable insert for all" ON price_history
  FOR INSERT WITH CHECK (true);

The lesson: RLS is security theater on hobby projects. Disable it for free tier. Enable it when you have real users.

Error 4: "Cannot Find Module" In Termux File Creation

The Problem:
I created a data analysis script but it wouldn't run:

$ node data-analysis.js

Error: Cannot find module '/data/data/com.termux/files/home/data-analysis.js'

File seemed to exist, but Node couldn't find it. Turned out the file never actually created properly.

Why it happens:
When copying files to Termux , file paths get weird. The tool thinks it created the file, but Termux didn't actually receive it.

The Fix:
Create files directly in Termux using nano:

nano data-analysis.js

Paste content, save with Ctrl+X → Y → Enter.

Verify with:

ls ~/*.js

The lesson: Don't rely on external file creation tools for Termux. Nano is slower but reliable.

Error 5: Can't Exit tmux On Mobile Keyboard

The Problem:
I attach to a tmux session to check bot output:

tmux attach -t price-alert

See the output, want to exit. Try Ctrl+B then D. Nothing happens. Keyboard doesn't register the key combo properly on mobile.

Stuck in the session. No escape.

Why it happens:
Mobile on-screen keyboards don't register modifier key combos well (Ctrl+B, Alt+X, etc). Long-press + tap doesn't work reliably.

The Fix:
Don't attach at all. Use capture-pane instead:

tmux capture-pane -t price-alert -p

Shows last output without entering the session. No exit needed. No stuck state.

For killing a session if you DO get stuck:

# In a new terminal
tmux kill-session -t price-alert

The lesson: Avoid interactive sessions on mobile. Use read-only commands instead.

The Pattern

All 5 errors follow the same theme:

Free tier + unconventional setup (mobile, no servers) = constraints.

The fix isn't "pay more" or "use better tools." It's work within constraints:

Event listeners die → use polling
Rate limits hit → reduce scope
RLS blocks → disable it
File creation fails → use native tools
Keyboard combos don't work → avoid them

That's the real lesson. Not the specific fixes, but the mindset: I'm not building for ideal conditions. I'm building for free APIs, free databases, and a phone running Linux.

Ship anyway.

Running on: Termux (Android), free-tier Alchemy, free-tier CoinGecko, Supabase free tier, tmux

Timeline: Sept 1-12, 2026. Two weeks into production.

Building a DeFi Monitoring System: 2 Bots, Real Data, Real Insights

Superwavvy — Thu, 10 Sep 2026 09:54:22 +0000

I started building on-chain tools in September with a simple goal: learn blockchain development while creating something useful. Two weeks later, I had two production bots collecting real Ethereum data. Here's what I built, why, and what the data tells us.

The Problem

DeFi moves fast. Token prices swing 5-10% in hours. Liquidations happen constantly. If you're monitoring these manually, you're always behind. I wanted to automate the watching and get instant alerts.

But more importantly, I wanted to understand how it works by building it myself.

The System

Two complementary bots:

Price Alert Bot — Monitors token prices every 2 hours, sends Telegram alerts on 5%+ moves
Liquidation Detector — Polls Aave every 15 minutes, sends Discord alerts when liquidations happen

Both feed into Supabase PostgreSQL for persistence and analysis.

Everything runs 24/7 on Termux (Node.js on my Android phone) in tmux sessions. No cloud servers. No DevOps overhead.

Building It

Price Alert Bot

The concept is simple: fetch prices, compare to history, alert on meaningful moves.

const price = await getPriceFromCoingecko('UNI');
const lastPrice = await loadFromSupabase('UNI');
const changePercent = ((price - lastPrice) / lastPrice) * 100;

if (Math.abs(changePercent) >= 5) {
  await sendTelegramAlert(`📈 UNI moved ${changePercent}%`);
}

The harder part: avoiding API limits. CoinGecko free tier is strict. I learned that checking every 15 minutes (96 calls/day per token) hits limits fast. Solution: check every 2 hours instead (12 calls/day per token). Still catches all meaningful moves.

Liquidation Detector

Liquidations are blockchain events. When someone's collateral drops below their debt threshold, Aave liquidates them. The event fires on-chain instantly.

I tried event listeners first (like traditional blockchain monitoring). Free-tier Alchemy killed the connection after 5 minutes with timeouts.

Switched to polling instead: query the last 9 blocks every 15 minutes (under Alchemy's 10-block free-tier limit). More reliable, same result.

const logs = await provider.getLogs({
  address: AAVE_LENDING_POOL,
  topics: [LIQUIDATION_CALL_TOPIC],
  fromBlock: currentBlock - 9,
  toBlock: currentBlock
});

logs.forEach(log => {
  // Parse event data, store to Supabase, send Discord alert
});

Real Data: 2 Weeks In

Running both bots for 2 weeks gives us actual insights:

Price Analysis

UNI (74 price records):

Range: $5.68 - $7.20
Volatility: 26.76%
Change: +2.21%

AAVE (18 records):

Range: $124.48 - $129.57
Volatility: 4.09%
Change: -3.53%

Key insight: UNI is way more volatile than AAVE. If you're building a risk model, token volatility matters. A 5% alert threshold for UNI catches real moves. Same threshold for AAVE would fire constantly.

Liquidation Analysis

Liquidations detected: 0 (so far)

This might sound like a failure. It's not. Aave is well-capitalized. Most positions are healthy. Liquidations spike during crashes (March 2020, May 2022). Right now, markets are calm.

But the data tells us: The detector is working correctly. It's querying the right contract, decoding events properly, storing to Supabase. When crashes come, we'll have real-time visibility.

Architecture Lessons

Why Supabase?

Serverless PostgreSQL. Free tier gets 500MB + unlimited read/write to a point. Perfect for side projects. Both bots share one project with separate tables.

Deduplication is built in: tx_hash UNIQUE prevents storing the same liquidation twice.

Why Polling Over Events?

Event listeners sound better (real-time vs. 15-minute latency). But free-tier providers are unreliable. Polling every 15 minutes is more stable than event listeners that disconnect every 5 minutes.

The tradeoff: real-time vs. reliability. I chose reliability.

Running on Your Phone

My laptop stays off. My phone runs 24/7. Termux lets me run Node.js on Android like a normal Linux environment. I use tmux to keep both bots alive in background sessions that survive disconnects and phone restarts.

To start the bots:

tmux new-session -d -s price-alert "node price-alert-bot.js"
tmux new-session -d -s liquidation "node liquidation-detector.js"

Check they're running:

tmux list-sessions

View live output anytime:

tmux attach -t price-alert

(Exit with Ctrl+B then D — doesn't kill the process)

That's it. Both bots run in the background forever. My phone is now a DeFi monitoring station.

Open Source

Both bots are on GitHub:

Price Alert Bot: github.com/superwavvy/price-alert-bot
Liquidation Detector: github.com/superwavvy/liquidation-detector

No monetization yet. Just sharing what works.

Conclusion

DeFi moves fast. Building fast is how you keep up. I built two monitoring bots in 2 weeks, deployed them to production (my phone), collected real data, and learned more about blockchain than any course could teach.

The data is boring right now (0 liquidations, 2% price movement). But boring data on a working system beats exciting theories on a broken one.

Running on: Termux (Android), Node.js v26, Supabase, Alchemy API (free tier), CoinGecko API (free tier)

Tools: ethers.js v6, axios, node-cron, tmux

Timeline: Sept 1 - Sept 10, 2026. Full time learning, part-time earning.

Building a DeFi Price Alert Bot: What I Learned Building a Production System on My Phone

Superwavvy — Wed, 02 Sep 2026 20:33:16 +0000

TL;DR: I built a price monitoring bot for Ethereum tokens that runs on my phone and costs $0/month. Monitors any token, sends instant Telegram alerts, logs everything to Supabase. Here's what I learned about DeFi automation, databases, and building real systems under constraints.

The Problem

You're a trader. You watch 5 altcoins. Market moves 20% while you sleep.

You miss it.

Existing solutions suck:

TradingView: $10-100/month
Binance alerts: Lag, limited tokens
Manual monitoring: Burnout guaranteed

What if you built your own?

That's this project.

Architecture Decisions (The Foundation)

Before coding, I made 8 key decisions:

1. Price Check Frequency: 15 Minutes

Every 1-min check for 100 tokens = 144k API calls/day (too much)
15 min = 192 calls/day (well within free tier)
Sufficient to catch real moves, not micro-movements

2. Data Source: CoinGecko + Alchemy

CoinGecko: Free price feeds, no auth needed
Alchemy: Setup for future on-chain reads (liquidity, swaps, etc.)
Fallback strategy built in

3. Storage: Supabase PostgreSQL

Why not Firebase or local JSON?

SQL = powerful queries later
Managed PostgreSQL = no server ops
Free tier: 500MB + generous API
RLS (Row Level Security) for safety

4. Token Management: JSON Config

Simple, human-editable, version-controllable. Can add tokens without redeploying.

5. Triggers: Both % Changes + Price Targets

% changes catch momentum (alert if ±5%, ±10%, ±25%)
Price targets catch ranges (buy @ $X, sell @ $Y)
Having both = flexibility

6. Alerts: Telegram

Instant push notifications (can't miss)
Works on any device
Rich formatting support
Free and reliable

7. Error Handling: Alert on Critical Failures

Don't fail silently. Don't spam every error. Alert when >50% of checks fail.

8. Deployment: Termux on Phone

Zero server costs
Always online (phone on charger)
Can deploy and code from same device

Lesson: Spend 30 mins deciding architecture. Saves hours of rework.

The Tech Stack

Node.js - Event-driven runtime, Termux support

node-cron - Runs your function every 15 minutes without a server

cron.schedule('*/15 * * * *', async () => {
  await runCheck();
});

CoinGecko API - Zero auth, instant price feeds

const response = await fetch(
  `https://api.coingecko.com/api/v3/simple/token_price/ethereum?contract_addresses=${address}&vs_currencies=usd`
);

Supabase - Managed PostgreSQL with instant backups

Why PostgreSQL? SQL means flexible queries later
Why managed? You're paying for not running ops

Telegram Bot API - Push notifications

Simple HTTP calls
Instant delivery
Formatted messages

How It Works (Every 15 Minutes)

1. Scheduler wakes up
2. Load token config (JSON)
3. For each token:
   → Fetch current price from CoinGecko
   → Query last stored price from Supabase
   → Calculate % change
   → Check triggers (% change + targets)
   → If triggered → Send Telegram alert
   → Log to database
4. Wait 15 minutes
5. Repeat

Trigger Logic

Type 1: Percentage Changes

"percentageChanges": [5, 10, 25]

Price moved 5%+ → Alert
Useful for: Catching momentum, volatility spikes

Type 2: Price Targets

"priceTargets": [
  { "price": 5.0, "type": "sell" },
  { "price": 8.0, "type": "buy" }
]

Price crossed $5 selling level → Alert
Useful for: Range trading, DCA strategies, support/resistance

Example:

Previous price: $4.50
Current price: $5.10
Buy target: $5.00
Result: ✅ Alert "Crossed $5.00 buy level"

The Errors I Hit

Error 1: RLS Permissions

permission denied for table price_history

Fix: Grant anonymous API key permissions

GRANT SELECT, INSERT, UPDATE ON public.price_history TO anon;
GRANT USAGE, SELECT ON SEQUENCE public.price_history_id_seq TO anon;

Lesson: Security-first defaults are good, but require understanding.

Error 2: Telegram Connection Timeout

Problem: Telegram API wasn't responding during startup

Fix: Made Telegram optional

if (TELEGRAM_BOT_TOKEN && TELEGRAM_CHAT_ID) {
  await sendPriceAlert(message);
} else {
  console.log('📝 [Mock Alert]', message);
}

Lesson: External dependencies should fail gracefully.

Error 3: CoinGecko Rate Limiting

Error: HTTP 429 Too Many Requests

Fix: Respect rate limits. Added delays between calls.

Lesson: Test with real APIs under real constraints.

Performance After 24 Hours

✅ Price checks: 96 (every 15 min)
✅ Alerts triggered: 3
✅ Price snapshots logged: 96
✅ Errors: 0
✅ Memory used: 5-10 MB
✅ CPU during check: <5%
✅ CPU idle: 0%
✅ Termux stability: Perfect

This tells me: System is reliable, minimal resource usage, scales to many more tokens.

What I'd Do Differently

1. Start with E2E tests
I built everything before testing end-to-end. Caught permission errors late.

2. Mock external APIs during development
Calling CoinGecko 50 times during dev = wasted API calls

3. Use TypeScript
JavaScript is fast, but TypeScript catches type errors before runtime

4. Add logging levels
Current code logs everything equally. Need filtering (debug/info/error)

5. Document while building
Docs after = forgotten context. Docs while = fresh thinking

What's Next

Phase 2: Liquidation Detector

Monitor collateral prices on Aave, Compound
Alert when liquidation price approaches
Rank by urgency

Phase 3: Arbitrage Spotter

Compare prices across DEXs
Detect profitable spreads
Calculate slippage

Key Takeaways

1. Architecture Matters

30 mins of architecture decisions saved hours of rework.

2. Pick Managed Services

Supabase, Alchemy, CoinGecko, Telegram = all managed. I don't run anything.

3. Fail Gracefully

One error shouldn't break the whole system.

4. Data is Everything

Storing every price check means I can analyze later.

5. Deploy Early

Deploy to production ASAP. Production teaches you fast.

Code Structure

All modular and focused:

bot.js          (100 lines) - Scheduler + orchestration
db.js           (80 lines)  - Database I/O
triggers.js     (60 lines)  - Price evaluation logic
notifications.js (50 lines) - Telegram sending
config.json     (20 lines)  - Token watchlist
schema.sql      (40 lines)  - Database setup

Total: ~350 lines of code. You can understand the entire system in 30 mins.

Is This Production-Ready?

For solo/small trading: Yes.

Runs 24/7 on phone
Zero downtime
Costs $0/month
Scales to ~50 tokens

For institutional: Not yet.

No redundancy
No disaster recovery
No audit logs

For learning: Absolutely. This is the foundation.

Final Thought

The hardest part of building isn't coding. It's deciding what to build and why.

I spent 20% of time on architecture. That decision paid for itself 5x over.

Next time you build, do the same:

Define the problem
Lock architecture
Build the skeleton
Deploy early
Iterate based on reality

Don't overthink. Build. Learn. Repeat.

Built by: Wavvy

Timeline: Sept 1, 2026 (1 day start-to-production)

Status: Live and monitoring UNI + AAVE