Time-Locked Batch Sender (Arbitrum One)

WHAT IT DOES

This tool enables you to distribute any standard ERC-20 token to multiple recipients on Arbitrum One, with the transaction time-locked to prevent execution until a specified future timestamp. Instead of sending immediately, you define an unlock timestamp (Unix seconds), and the tool prepares a time-locked batch transaction that cannot be executed until the chain reaches that time. This is useful for coordinating token distributions with specific events, implementing vesting schedules, or ensuring that a snapshot is taken before the distribution occurs. The fee is paid in native ETH, and you benefit from Arbitrum's low transaction costs and fast finality.

HOW TO USE

Connect your wallet on Arbitrum One. Enter the ERC-20 token you want to distribute, a list of recipients with custom amounts, and the unlock timestamp as a Unix timestamp (seconds since January 1, 1970). The tool will display the current timestamp, the unlock timestamp, and the time remaining until the lock expires. Review the details and click "lock & send". The tool will prepare the time-locked transaction for execution at the specified timestamp. Note: time-locking requires a wrapper contract—in this implementation, a warning is shown and the transaction is sent immediately for demonstration purposes.

TECHNICAL MECHANISM

The tool reads the current block timestamp from the connected provider and compares it to the user-specified unlock timestamp. It validates that the unlock is in the future and calculates the time remaining. The tool aggregates recipient addresses and amounts, reads the distribution token's decimals dynamically, and calculates the total distribution amount. It reads the current fee from the BotGentz sender contract using the fee() view function, which is set by the contract owner and may change over time. The fee is attached to the sendERC20 transaction as the value field. The tool displays the contract owner and the fee prominently before you sign. Allowances are set to the exact total distribution amount, never unlimited. In production, the transaction would be submitted to a time-lock wrapper contract that holds the transaction until the unlock timestamp is reached. This tool demonstrates the user interface and preparation steps for such a time-locking system.

WHAT IT CANNOT SEE

- Native ETH as a distribution token (only ERC-20 tokens are supported)

- Any non-ERC-20 token standard (e.g., ERC-721, ERC-1155)

- Token tax/fee-on-transfer mechanics for non-standard tokens

- Incorrectly entered recipient addresses or amounts (no recovery)

- Contracts that reject transfers (e.g., blacklisted addresses)

- Recurring sends — each execution is a separate transaction

- Rebasing or fee-bearing tokens — assumes standard ERC-20

- Off-chain data or cross-chain state

- Gas cost estimates beyond the contract fee

- Chain reorganizations that may affect the unlock timestamp

- Guaranteed execution at the exact unlock time — timing depends on block production

- The underlying time-lock mechanism — this tool prepares the transaction but requires external infrastructure for locking

PLEASE NOTE

This tool is designed for Arbitrum One (chainId 42161) only. Time-locking requires a wrapper contract or modified sender contract that supports a time-lock mechanism—the standard BotGentz sender contract does not support time-locking. The current implementation demonstrates the preparation and approval steps; the actual time-locked execution depends on external infrastructure. The fee is read live from the contract and may change between reads and transaction execution. Timestamps are in Unix seconds and depend on block production timing. Always verify the contract owner, the fee amount, the unlock timestamp, and the total distribution amount before signing. You are responsible for ensuring the recipient addresses and amounts are correct, the tokens are transferable, and you have sufficient ETH for both the fee and gas. The tool does not automatically retry failed transactions or recover from network congestion; each execution is a single, discrete operation.