Setting Up Alerts for Fundraising Milestones

In the dynamic world of Web3, fundraising events like token sales, private rounds, and public launches are pivotal moments. Manually monitoring these across multiple blockchains is inefficient and error-prone. Automated milestone alerts solve this by providing real-time, programmatic notifications for specific on-chain conditions. This guide explains how to set up these alerts using Chainscore's monitoring tools to track metrics like total funds raised, individual contribution sizes, and wallet activity for any ERC-20, ERC-721, or native token event.

The core mechanism involves defining a trigger condition based on on-chain data. For fundraising, common triggers include: a specific wallet (like a project's treasury) receiving a transaction exceeding a set value, the cumulative balance of a contract surpassing a milestone (e.g., $1M raised), or a particular event log (like a TokensPurchased event) being emitted. Chainscore's alerting system continuously scans the blockchain for these conditions. When a match is found, it executes a notification action, such as sending an email, a Slack message, a webhook to your backend, or a Telegram alert.

Setting up an alert requires a few key pieces of information. First, you need the target address—this could be the smart contract for your sale or the wallet receiving funds. Next, you define the condition type. For a funding milestone, you would typically use a balance condition to monitor the total ETH/USDC held, or a transaction condition to watch for large incoming transfers. You then set the threshold value (e.g., >= 100 ETH) and choose the blockchain network (Ethereum, Polygon, Arbitrum, etc.). Finally, you configure the notification channels where alerts will be delivered.

Here is a conceptual example of the logic for an alert that triggers when a treasury wallet's balance exceeds 500 ETH, indicating a fundraising milestone has been hit:

javascriptCopy
// Pseudo-code for a milestone alert condition
if (walletBalance >= 500 * 10**18) { // 500 ETH in wei
  sendAlert("Fundraising Milestone Reached", 
            `Treasury balance is now ${balance} ETH`);
}

In practice, you configure this through Chainscore's dashboard or API without writing this code, but understanding the underlying condition is crucial for precise monitoring.

Effective alert strategies go beyond single thresholds. For comprehensive oversight, set up a series of alerts for different stages: a small alert for the first contribution, incremental alerts at 25%, 50%, and 75% of the goal, and a final alert when the hard cap is reached. You should also create alerts for anomalous activity, like a single transaction that is abnormally large, which could indicate a whale investment or a potential exploit. Integrating these alerts with tools like Google Sheets via webhooks allows for automatic logging and analysis, creating a live dashboard of your fundraising progress.

By implementing a structured alert system, project teams can respond instantly to successful funding rounds, community managers can announce milestones transparently, and investors can track their portfolio projects' progress without constant manual checks. This transforms fundraising from a black box into a transparent, data-driven process with actionable intelligence delivered directly to your team's communication platforms.

To monitor fundraising milestones, you first need access to reliable on-chain data. This typically involves connecting to a blockchain node provider like Alchemy, Infura, or QuickNode. For real-time event monitoring, you'll also require a WebSocket connection to listen for new blocks and transaction confirmations. Setting up a local archive node is an alternative but requires significant storage and maintenance. Most developers opt for a managed RPC provider with WebSocket support to ensure high availability and historical data access for analyzing past funding rounds.

Your application will need to interact with smart contracts. You must identify the specific contract addresses for the fundraising protocols you wish to monitor, such as a Uniswap v3 Pool for liquidity events or a Juicebox treasury for project funding. Obtain the contract's Application Binary Interface (ABI) to decode transaction logs and call functions. For standardized token sales, you can use the ERC-20 ABI to track token transfers into and out of fundraising wallets. Tools like Etherscan or Sourcify are essential for verifying and fetching these ABIs.

You need a method to store and process the stream of blockchain data. A common architecture involves using a service like The Graph to index specific events into a queryable subgraph, or running your own indexer with a framework like TrueBlocks. For simpler setups, you can write a script that listens for events using ethers.js or web3.py and logs them to a database. The choice depends on the complexity of your queries and the volume of data. Ensure your database (e.g., PostgreSQL, TimescaleDB) can handle time-series data for tracking milestone progress over time.

Finally, establish your alerting pipeline. This requires integrating with a notification service. You can use transactional email APIs like SendGrid or Resend, SMS services like Twilio, or push notification services. For team collaboration, connecting to Slack or Discord webhooks is highly effective. Your application logic must define the specific conditions that trigger an alert, such as a wallet balance exceeding a threshold or a smart contract event signaling a new funding round. Testing this pipeline on a testnet like Sepolia or Goerli is crucial before deploying to mainnet.

A robust alert system for fundraising milestones requires a hybrid on-chain and off-chain architecture. The core logic for milestone definitions—such as a fundingGoal or a deadline—is encoded within a smart contract, typically a Safe or a custom vault. This contract emits standardized events like MilestoneReached(uint256 milestoneId, uint256 amount) when conditions are met. Off-chain indexers, such as The Graph or Covalent, listen for these events, parse the data, and store them in a queryable database. This separation ensures the immutable and verifiable logic resides on-chain while enabling complex, scalable notification logic off-chain.

The notification pipeline begins with an off-chain listener service, often a serverless function or a dedicated microservice. This service subscribes to the indexed events via a WebSocket connection from the indexer or by polling an RPC node. Upon detecting a relevant event, it triggers an alert workflow. Common notification channels include: - Email via services like SendGrid or Resend - Discord/Telegram webhooks for community alerts - Push notifications to a mobile app - Internal dashboards via API calls. The service formats the event data (e.g., milestone ID, amount raised, contract address) into a human-readable message for each channel.

For developers, implementing this starts with the smart contract. A basic milestone tracker in Solidity might include a mapping to store goals and a function to check them. When integrating with an indexer, you must define a subgraph schema and mapping handlers to process the events. The listener service can be built using Node.js with ethers.js or Python with web3.py, connecting to an Alchemy or Infura node. For reliability, implement retry logic and dead-letter queues for failed notifications. Always verify on-chain data in your alerts to prevent spoofing from forked chains or malicious events.

On-chain fundraising events are public, verifiable signals broadcast by smart contracts. Protocols like Liquidity Bootstrapping Pools (LBPs), token sales, and IDO platforms emit standardized events such as TokensPurchased, PoolCreated, or FundsDeposited. By listening to these events on networks like Ethereum, Solana, or Arbitrum, you can capture critical data points in real-time: the investor's address, the amount of capital committed, the token price, and the exact block timestamp. This forms the foundational data layer for any fundraising analytics dashboard.

To implement an event listener, you need to connect to a node provider. Using Ethers.js v6 for an EVM chain, you first define the contract's Application Binary Interface (ABI), focusing on the specific event signatures you want to monitor. You then create a provider using a service like Alchemy or Infura and instantiate a contract object. Finally, you use the contract.on method to log events as they occur. This setup provides a live feed of all transactions interacting with the target contract.

For a practical example, to monitor a hypothetical FairLaunch contract's purchase events, your listener code would filter for the TokensBought event. The listener would output the buyer's address, amount of ETH paid, and number of tokens received each time a purchase is made. This raw data stream is essential but requires further processing to calculate metrics like total funds raised, unique investor count, and funding velocity, which we will cover in subsequent steps.

Beyond simple logging, robust monitoring requires handling chain reorganizations and missed blocks. Services like The Graph or Chainstack offer more resilient solutions by indexing events into queryable subgraphs or providing enhanced WebSocket connections. For multi-chain monitoring, you must deploy separate listeners for each blockchain, as event structures and RPC providers differ between EVM, Solana, and Cosmos-based chains.

The key output of this step is a real-time data pipeline. You should be able to track every capital inflow event from the moment a fundraising round begins. This enables immediate alerts for milestone achievements, such as the pool reaching 50% of its hard cap or a notable wallet making a large investment, allowing for timely analysis and decision-making based on live on-chain activity.

The core of any monitoring system is its alert logic. In Chainscore, you define this logic using rules, which are composed of a condition and an action. For fundraising milestones, the condition typically monitors a specific on-chain metric—like a smart contract's token balance or a wallet's cumulative inflow—and triggers when it crosses a predefined threshold. The action determines what happens next, such as sending a notification to a webhook, email, or Discord channel. This decoupled design allows you to monitor complex, multi-step fundraising goals with precision.

Let's build a rule for a common milestone: a project raising its first 50 ETH. You would create a condition that watches the project's fundraising wallet address. Using Chainscore's Balance Increase condition type, you can set the threshold to 50 ETH and the time_window to monitor increases over the lifetime of the address ("lifetime"). The condition will evaluate to true only when the net balance increase since the wallet's creation reaches or exceeds 50 ETH, accurately reflecting total funds raised.

For the action, you'll likely want an instant notification. Chainscore supports Webhook, Email, and Discord actions out of the box. Configuring a Discord webhook action is straightforward: you provide the webhook URL from your Discord server and craft a message template. You can use dynamic variables like {{condition_value}} (the current balance increase, e.g., 52.5 ETH) and {{contract_address}} to create informative alerts: "🚀 Fundraising Milestone Reached! The vault at {{contract_address}} has raised {{condition_value}} ETH."

For more sophisticated logic, such as alerting on a 10% increase in funds over a 24-hour period, you would use the Balance Increase condition with a time_window of "24h" and a threshold_type of "percentage" set to 10. This is useful for tracking momentum during an active fundraising round. You can also create compound rules using logical operators (AND, OR) to combine conditions, like triggering an alert only if funds exceed 100 ETH and come from at least 50 unique sender addresses, helping to gauge community support depth.

All rules are managed via Chainscore's REST API. Below is an example cURL command to create the 50 ETH milestone rule, specifying the condition parameters and the Discord action configuration. The alert_frequency is set to "once" to prevent spam, ensuring the notification fires only the first time the condition is met.

bashCopy
curl -X POST 'https://api.chainscore.dev/v1/rules' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "50 ETH Fundraising Milestone",
    "alert_frequency": "once",
    "condition": {
      "type": "balance_increase",
      "parameters": {
        "address": "0xYourFundraisingWalletAddress",
        "threshold": "50000000000000000000",
        "threshold_type": "absolute",
        "time_window": "lifetime"
      }
    },
    "actions": [{
      "type": "discord",
      "parameters": {
        "webhook_url": "https://discord.com/api/webhooks/...",
        "message": "🚀 Milestone Alert! Raised {{condition_value}} ETH."
      }
    }]
  }'

After deploying your rule, you can test it by simulating the condition or by monitoring its status in the Chainscore dashboard. The system will continuously evaluate the condition against new blocks. When triggered, the action executes, and the rule's status logs will provide a timestamp and the exact data that caused the trigger. For ongoing campaigns, you can create a sequence of these rules (e.g., for 50, 100, and 250 ETH milestones) to get a complete, automated alert system for your fundraising progress.

Webhooks are automated HTTP callbacks that send event data from your smart contract to a specified URL. For fundraising, they enable real-time notifications for critical on-chain events like new contributions, milestone completions, or funding goal achievements. Instead of manually polling the blockchain, your backend server receives a structured JSON payload the moment an event is emitted, allowing for immediate action such as sending emails, updating dashboards, or triggering other business logic.

To configure a webhook, you first need an endpoint that can receive POST requests. This is typically a serverless function (e.g., Vercel, AWS Lambda) or a web server route. The endpoint must parse the incoming JSON, which contains the event data. A standard payload includes the eventName (e.g., ContributionReceived), the contract address, the transaction hash, and the event arguments like contributor and amount. Always verify the incoming request's origin and validate the transaction on-chain to prevent spoofing.

Implementing the listener in your code is straightforward. Using a library like ethers.js or viem, you can filter for specific events. The following snippet shows how to set up a provider and listener that triggers a webhook call when the MilestoneReached event is emitted:

javascriptCopy
contract.on("MilestoneReached", (milestoneId, amount, event) => {
  fetch(YOUR_WEBHOOK_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      event: 'MilestoneReached',
      milestoneId: milestoneId.toString(),
      amount: ethers.formatEther(amount),
      txHash: event.log.transactionHash
    })
  });
});

For production reliability, consider using a dedicated service like Chainlink Functions, OpenZeppelin Defender Sentinel, or Tenderly Webhooks. These platforms manage the blockchain connection, event filtering, and delivery retries, reducing infrastructure overhead. They also provide delivery logs and failure alerts. When setting thresholds (e.g., "alert when 80% of goal is met"), calculate this logic off-chain in your webhook handler or use a custom event emitted by a keeper script to keep gas costs low.

Best practices for webhook security are critical. Always verify the sender using IP allowlisting or a shared secret token in the request header. Validate the on-chain data by fetching the transaction receipt and confirming log inclusion. Implement idempotency in your handler to process duplicate deliveries safely. Finally, set up monitoring and alerting for your webhook endpoint itself using tools like Sentry or DataDog to ensure you're notified if the notification system fails.

On-chain fundraising, such as token sales or NFT mints, operates autonomously. Without proactive monitoring, you risk missing critical events like a hardCap being reached or a deadline passing. Setting up automated alerts ensures you can respond in real-time to successes, failures, or potential security incidents. This is a core component of operational reliability, allowing you to manage community expectations and execute post-fundraising steps like token distribution or refunds without delay.

The most reliable method is to use an off-chain service that listens for on-chain events. Services like Tenderly Alerts, OpenZeppelin Defender Sentinel, or Chainlink Functions can monitor your smart contract. For example, you can configure an alert to trigger when the totalContribution state variable in your fundraising contract crosses a predefined threshold. These services typically send notifications via email, Slack, Discord, or webhook, enabling integration into your existing ops workflow.

To implement this, you first need to identify the key events and state variables in your contract. Common milestones include: the fundraisingGoal being met, the endTime being reached, a single-wallet contribution limit being exceeded, or the contract balance hitting a specific ETH/USDC amount. Write a monitoring script that periodically calls the contract's view functions or listens for emitted events like ContributionReceived or CapReached.

Here is a basic Node.js example using ethers.js and a hypothetical webhook service. This script checks if the total funds raised have exceeded a milestone and sends an alert.

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

const provider = new ethers.JsonRpcProvider(process.env.RPC_URL);
const contractAddress = '0x...';
const contractABI = [...]; // ABI containing the totalRaised function
const contract = new ethers.Contract(contractAddress, contractABI, provider);
const MILESTONE = ethers.parseEther('500'); // 500 ETH milestone

async function checkMilestone() {
    const totalRaised = await contract.totalRaised();
    if (totalRaised >= MILESTONE) {
        await axios.post('https://your-webhook-url', {
            message: `Fundraising milestone reached: ${ethers.formatEther(totalRaised)} ETH`
        });
        console.log('Alert sent!');
    }
}
// Run check every 60 seconds
setInterval(checkMilestone, 60000);

For production reliability, avoid relying on a single point of failure. Do not run your monitoring script on the same server as your frontend. Use a dedicated, resilient service. Tenderly Alerts provides a no-code solution where you define a formula (e.g., Contract.Balance > 1000 ETH) and a destination. OpenZeppelin Defender is ideal for more complex logic, allowing you to write automated scripts in a managed environment with built-in security and reliability.

Finally, test your alert system thoroughly on a testnet before mainnet deployment. Simulate milestone events by making contributions to your testnet contract and verify that alerts fire correctly. Document the alert procedures for your team, including escalation paths if a critical alert is missed. This proactive approach transforms fundraising from a passive event into a managed process, significantly improving operational security and stakeholder confidence.

Your alert system is now live, but it requires maintenance. Regularly review the logic in your monitor.js script to ensure it aligns with the latest contract ABIs and RPC endpoints. For production use, consider moving your private key and webhook URL to environment variables using a library like dotenv. Implement a more robust scheduler, such as a cron job on a VPS or a serverless function (e.g., Vercel, AWS Lambda), to replace the simple setInterval loop for 24/7 reliability.

To extend this system, you can add more sophisticated triggers. Monitor for specific wallet addresses (e.g., venture capital funds) interacting with the contract using the transaction's from field. Track the rate of fund inflow by calculating the ETH received per hour. You could also integrate with a notification aggregator like PagerDuty for critical alerts or log all events to a database for historical analysis and reporting.

The principles used here—event listening, state polling, and external integrations—apply to many other Web3 monitoring tasks. You can adapt this codebase to track governance proposal states, NFT collection mint progress, or liquidity pool health. For deeper analysis, explore using The Graph to index and query on-chain data more efficiently than direct RPC calls. Always refer to the official Ethers.js documentation and the target contract's verified source code on Etherscan for the most accurate implementation details.