Minimum-Activity-Gated Conditional Batch Sender

WHAT IT DOES

Minimum-Activity-Gated Conditional Batch Sender is a specialized DeFi tool that adds a transaction-activity requirement to batch token distributions. Before executing any batch transfer, the tool counts the number of on-chain transactions the sender has performed within a specified time window. Only if the sender's transaction count meets or exceeds the configured minimum threshold does the batch transaction proceed. This creates a powerful sybil-resistance and engagement-based access-control mechanism for token distributions—you can require that distributors are active participants on the network with a proven on-chain history before they are allowed to send tokens to recipients. The tool is ideal for community reward programs, active-user airdrops, DAO treasury management, and any scenario where you want to restrict batch-sending privileges to wallets with demonstrated on-chain activity. By combining activity gating with batch transfers, you add a layer of sybil resistance and encourage genuine participation in the ecosystem.

HOW TO USE

Connect your Web3 wallet to Ethereum L1. Enter the minimum number of transactions required to pass the activity gate. Enter the time window in seconds (e.g., 2592000 for 30 days) during which the activity is counted—use 0 to count all historical transactions. Enter the token contract address you wish to distribute. Paste or upload your list of recipients in the format "address, amount" with one entry per line—amounts are in human-readable token units. The tool parses the list and calculates the total tokens to be sent. It then queries your transaction history and displays your current transaction count within the specified window, along with whether you meet the minimum threshold. Review the sender contract address, fee, and contract owner for transparency. If the activity condition passes, click the send button, review the transaction in your wallet, and confirm. The tool performs a final on-chain activity check before executing the batch transfer, ensuring the condition is met at the moment of transaction execution. If the condition fails at any point, the batch transfer is blocked.

MECHANISM: ACTIVITY COUNTING WITH CHUNKED BLOCK QUERIES

The tool implements a two-phase activity verification mechanism that avoids RPC limitations. For the time window, it uses binary search across block timestamps to find the starting block, then counts transactions using getTransactionCount at the window boundaries. This approach is efficient and does not require eth_getLogs, avoiding the common RPC limit issue where public providers cap log query ranges and refuse full-range requests. The tool checks the sender's transaction count at the current block and at the window-start block, subtracting to get the activity count within the window. This method is lightweight, accurate, and works reliably across different RPC providers. The initial check is displayed in the UI and used to enable or disable the send button. When the user clicks send, the tool performs a second on-chain activity verification to ensure the condition still holds—this prevents race conditions where the activity count might change between the UI check and transaction submission. If the activity check passes, the tool proceeds with the standard batch transfer flow: it calculates the total tokens to send plus the sender contract fee, checks the sender's balance of the distribution token, approves the sender contract for the exact total, and executes the batchTransferERC20 function on the shared BotGentz sender contract. The batch transfer is atomic—either all recipients receive their tokens, or the entire transaction reverts.

WHAT IT CANNOT SEE

This tool reads transaction counts for activity gating but cannot verify recipient validity, token contract correctness, transfer pausing, blacklisting, or gas fluctuations. It cannot guarantee that all transfers will succeed—if one transfer fails due to a blacklisted address, a contract that rejects the token, or any other reason, the entire batch reverts. It cannot detect activity on other chains or off-chain activity that might indicate genuine engagement. It cannot verify that the activity is legitimate or not spam—a high transaction count does not guarantee meaningful participation. It cannot account for RPC limitations if the provider refuses getTransactionCount requests (though this is rare). It cannot ensure that the activity check is atomic with the transfer if the contract does not support atomic re-verification. It cannot verify that the sender will maintain activity levels after the transaction completes. It cannot account for chain reorganization or indexing delays that might affect activity detection.

PLEASE NOTE

This tool works exclusively on EVM-compatible chains and is designed for Ethereum L1. It requires the user to have sufficient native ETH for gas and sufficient distribution token balance to cover the total amount sent plus the sender contract fee. The user is solely responsible for verifying the distribution token address, recipient addresses, and amounts before signing. Always test with a small batch first to confirm the setup is correct. The activity condition is a prerequisite for sending—if you do not meet the minimum transaction count, the tool will not allow the transaction to proceed. The sender contract addresses are hardcoded per chain and are publicly available for verification; no third-party custody is involved; you remain in full control of your wallet and funds at all times. Activity is measured by the number of transactions sent from your address, not received or interacted with, ensuring that only active senders can execute batch distributions.