Solana Blockchain Transaction Monitoring Bot
Budget: €750 – €1,500 EUR
We aim to develop a transaction monitoring bot for the Solana blockchain with the following features.
Main Objective
Monitor transactions on the Solana network originating from different wallets (approximately 7 to 10 wallets). When a transaction meets the specified filters and at least one of the conditions mentioned below, the bot should send an alert to a Telegram group with detailed transaction information.
Filters
All filters must be met for the transaction to be sent to Telegram:
• The transaction is an outgoing transfer from one of the “MADRE” wallets (it should be possible to edit this list if needed).
• The transfer involves the Solana (SOL) token (other tokens are irrelevant).
• The transfer amount must be between 2.9 and 25 SOL (this range should be adjustable).
Conditions
In addition to meeting all filters, the transaction must meet at least one of the following conditions:
• Fresh Wallet: The receiving wallet has no previous transactions.
• Only Inflows: The receiving wallet has previous transactions, but they are exclusively inflows (funds received). There must be no:
• Swaps.
• Outflows (funds sent).
• Mints or other types of transactions.
• Inflows from CEX: The inflows to the receiving wallet come exclusively from centralized exchange (CEX) wallets.
• A list of CEX addresses will be provided, and it should be easy to update this list.
• Maximum Balance: If the receiving wallet’s total balance exceeds 40 SOL, it should be discarded, and no alert should be sent.
Alerts to Telegram
When a transaction meets the criteria, the bot should send a message to the Telegram group with the following details:
• Wallet Name: Example: “MOTHER1”.
• Wallet Address: The address of the sending wallet.
• Receiving Wallet Address.
• Amount of SOL sent.
• Link to Solscan to view the transaction.
Note: Examples will be provided during development to guide implementation.
Technical Requirements
1. Libraries and Required APIs
• Solana API: to retrieve outgoing transactions from the “MOTHER” wallets, and analyze the transaction history of receiving wallets since their creation.
• Telegram Bot API: for sending alerts to a Telegram group.
• Real-time Monitoring: Use of Websockets, gRPC, or any other efficient technology for real-time transaction tracking.
2. Data Validation
• Real-time processing and filtering of transactions.
• Verification of balances and prior activity in receiving wallets.
3. Execution
• The bot should run continuously and stably, whether on a local server or in the cloud.
Challenges to Address
• Ensuring the bot can correctly analyze transaction data using the Solana API (or alternative tools like gRPC, if necessary). A private RPC node is available for optimization.
• Implementing robust error handling and exception management:
• Provide detailed debugging logs.
• Notify the Telegram group of critical errors to ensure visibility.
• Provide full access to the source code to allow future modifications if necessary.
Key Notes
• The bot should be efficient, reliable, and modular for future upgrades.
• The implementation should allow flexible configuration of filters, conditions, and wallet lists.
Main Objective
Monitor transactions on the Solana network originating from different wallets (approximately 7 to 10 wallets). When a transaction meets the specified filters and at least one of the conditions mentioned below, the bot should send an alert to a Telegram group with detailed transaction information.
Filters
All filters must be met for the transaction to be sent to Telegram:
• The transaction is an outgoing transfer from one of the “MADRE” wallets (it should be possible to edit this list if needed).
• The transfer involves the Solana (SOL) token (other tokens are irrelevant).
• The transfer amount must be between 2.9 and 25 SOL (this range should be adjustable).
Conditions
In addition to meeting all filters, the transaction must meet at least one of the following conditions:
• Fresh Wallet: The receiving wallet has no previous transactions.
• Only Inflows: The receiving wallet has previous transactions, but they are exclusively inflows (funds received). There must be no:
• Swaps.
• Outflows (funds sent).
• Mints or other types of transactions.
• Inflows from CEX: The inflows to the receiving wallet come exclusively from centralized exchange (CEX) wallets.
• A list of CEX addresses will be provided, and it should be easy to update this list.
• Maximum Balance: If the receiving wallet’s total balance exceeds 40 SOL, it should be discarded, and no alert should be sent.
Alerts to Telegram
When a transaction meets the criteria, the bot should send a message to the Telegram group with the following details:
• Wallet Name: Example: “MOTHER1”.
• Wallet Address: The address of the sending wallet.
• Receiving Wallet Address.
• Amount of SOL sent.
• Link to Solscan to view the transaction.
Note: Examples will be provided during development to guide implementation.
Technical Requirements
1. Libraries and Required APIs
• Solana API: to retrieve outgoing transactions from the “MOTHER” wallets, and analyze the transaction history of receiving wallets since their creation.
• Telegram Bot API: for sending alerts to a Telegram group.
• Real-time Monitoring: Use of Websockets, gRPC, or any other efficient technology for real-time transaction tracking.
2. Data Validation
• Real-time processing and filtering of transactions.
• Verification of balances and prior activity in receiving wallets.
3. Execution
• The bot should run continuously and stably, whether on a local server or in the cloud.
Challenges to Address
• Ensuring the bot can correctly analyze transaction data using the Solana API (or alternative tools like gRPC, if necessary). A private RPC node is available for optimization.
• Implementing robust error handling and exception management:
• Provide detailed debugging logs.
• Notify the Telegram group of critical errors to ensure visibility.
• Provide full access to the source code to allow future modifications if necessary.
Key Notes
• The bot should be efficient, reliable, and modular for future upgrades.
• The implementation should allow flexible configuration of filters, conditions, and wallet lists.