NFT Collection Sales Monitoring System Development

NFT Collection Sales Monitoring System Development

Collection floor dropped 30% in the last 6 hours and you found out on Twitter the next day. Or a whale bought 50 tokens in a row, triggered a pump, and your alerts said nothing. For traders, collection founders, and NFT market analysts you need a system that sees these events within minutes, not hours.

Data Sources

Architectural choice #1: pull data from marketplace APIs or directly from blockchain events. Each approach has trade-offs.

Marketplace APIs (OpenSea, Blur, Reservoir) — easier to implement, but dependency on third-party uptime and aggregation delays. Reservoir is the most convenient option: single API covering Blur, OpenSea, X2Y2, LooksRare and others, returns normalized data.

On-chain events — comprehensive and marketplace-independent, but require parsing each protocol separately. Each marketplace has its own event signature:

For a reliable monitoring system — combination: Reservoir API for fast data + on-chain parsing as backup source and for verification.

System Architecture

Data pipeline

Blockchain events (WebSocket via Alchemy/QuickNode)
          │
          ▼
Event Parser Service  ◄── Reservoir API (polling / webhooks)
          │
          ▼
Message Queue (Redis Streams / BullMQ)
          │
     ┌────┴────┐
     ▼         ▼
Metrics DB    Alert Engine
(TimescaleDB) (rules evaluation)
     │              │
     ▼              ▼
Analytics API   Notification Service
                (Telegram, Discord, Email)

TimescaleDB — PostgreSQL extension for time-series data. Automatic partitioning by time, aggregation functions for time windows (time_bucket), compression of old data. For NFT metrics this is significantly better than plain PostgreSQL.

CREATE TABLE nft_sales (
    time        TIMESTAMPTZ NOT NULL,
    collection  VARCHAR(42) NOT NULL,
    token_id    TEXT,
    price_eth   DECIMAL(20, 8),
    price_usd   DECIMAL(20, 4),
    marketplace VARCHAR(20),
    buyer       VARCHAR(42),
    seller      VARCHAR(42),
    tx_hash     VARCHAR(66)
);

SELECT create_hypertable('nft_sales', 'time');

-- Floor price over last 24 hours by hour
SELECT time_bucket('1 hour', time) AS bucket,
       MIN(price_eth) AS floor,
       COUNT(*) AS volume,
       SUM(price_eth) AS total_volume_eth
FROM nft_sales
WHERE collection = $1
  AND time > NOW() - INTERVAL '24 hours'
GROUP BY bucket
ORDER BY bucket;

Realtime floor price tracking

Floor price is not just the minimum price of the last sale. It's the minimum price of active listings. For correct calculation you need a separate listings tracker:

class FloorPriceTracker {
  private listings = new Map<string, { price: bigint; seller: string }>()

  onListing(tokenId: string, price: bigint, seller: string) {
    this.listings.set(tokenId, { price, seller })
    this.updateFloor()
  }

  onDelisting(tokenId: string) {
    this.listings.delete(tokenId)
    this.updateFloor()
  }

  onSale(tokenId: string) {
    this.listings.delete(tokenId)  // sold = delisted
    this.updateFloor()
  }

  getFloor(): bigint {
    return [...this.listings.values()]
      .reduce((min, l) => l.price < min ? l.price : min, BigInt(Infinity))
  }
}

Listings state initialized at startup from Reservoir API, then maintained via event stream.

Alert System

Alert Types

Floor price alerts: floor change >X% in Y minutes. Important to calculate percentage change relative to rolling baseline, not previous value — otherwise one wash trade at low price generates false alert.

Whale activity: one address bought N+ tokens in M hours. Whale in context of collection — relative concept, threshold depends on supply.

Volume spike: trading volume last hour exceeds N-sigma from average (rolling mean + std deviation over 7 days).

Large single sale: token sold at price exceeding floor by K times.

Wash trading detection: same tokens quickly resold between related addresses at rising prices. Simple heuristic: if sale.buyer == previous sale.seller and interval < 10 minutes — suspicious.

Alert Rules Configuration

Alert rules stored in DB, edited via UI without deploy:

{
  "collection": "0xBC4CA0EdA7647A8aB7C2061c2E118A18a936f13D",
  "alert_type": "floor_change",
  "conditions": {
    "direction": "down",
    "threshold_percent": 15,
    "window_minutes": 30
  },
  "notifications": ["telegram:@bayc_holder", "discord:webhook_url"]
}

Collection Metrics and Dashboard

Key metrics for dashboard:

• Floor price (current, 24h change, 7d change)
• Total volume (24h, 7d, all time)
• Number of sales (24h)
• Unique buyers/sellers (24h)
• Average sale price vs. floor (spread)
• Holder distribution: top 10 holders % of supply, unique holders count
• Listing depth: number of listings in ranges +5%, +10%, +20% from floor

Holder distribution updated less frequently — once per hour is enough. Requires either on-chain Transfer event tracking or request to Alchemy/Moralis NFT API.

Notification Delivery

Telegram Bot: most demanded in NFT community. telegraf or grammy library, group chats for project communities, personal notifications for individual traders.

Discord Webhooks: standard for NFT projects. Formatted embed with collection icon, price, link to token on marketplace.

Email: via SendGrid/Resend for digest summaries — hourly or daily.

Throttling: no more than 1 alert of same type per N minutes per collection, else volatile market spams. Queue with deduplication in Redis.

Development Timeline

Day 1: analyze target marketplaces, obtain API keys, develop storage schema, implement basic HTTP clients with retry/backoff.

Day 2: workers for historical collection, WebSocket integration for realtime, data normalization across marketplace formats, documentation and basic monitoring.

Day 3: alert engine with basic rules, Telegram and Discord notifications integration, basic dashboard.

Total 2-3 working days for system with realtime monitoring, alerts and dashboard. Adding complex detectors (wash trading, multi-collection correlations) — another 1-2 days.