$REPLY Token & ReplyPool

Table of Contents

1. Overview

2. $REPLY Token

3. ReplyPool System

4. Contract Addresses

5. Staking Mechanics

6. Fee Distribution

7. Attribution & Multipliers

8. Alpha Pool Whitelist

9. Frontend Monitoring Interface

10. Technical Architecture

11. User Guide

12. Security Considerations

13. Automation & Bots

14. Contract Interfaces

15. Additional Resources

16. Changelog

17. Quick Reference

Overview

The $REPLY token ecosystem consists of a dual-pool staking system that distributes trading fees to stakers on a daily basis. The system features two pools (Alpha and Public) with attribution-based multipliers that reward active community members.

Key Features

• Dual Pool System: Alpha (Presale) and Public pools

• Daily Fee Distribution: Automatic distribution at 00:00 UTC

• Attribution Multipliers: Performance-based rewards (0.9x - 1.1x)

• Gas Optimized: Batch processing for efficient distributions

• No Claims Required: Fees are automatically distributed to user wallets

$REPLY Token

Token Specifications

• Token Standard: ERC20 with EIP-2612 permit functionality

• Total Supply: 1,000,000,000 REPLY tokens (1 billion)

• Decimals: 18

• Token Type: Fixed supply with no inflation mechanism

Token Addresses

Base Mainnet (Chain ID: 8453):

• REPLY_TOKEN: 0x05B1266DDCeE093cE060DBF697e230EA9B453633

ReplyPool System

Overview

ReplyPools is the core staking contract that manages two separate pools for staking $REPLY tokens and distributing trading fees.

Pool Types

1. Alpha Pool (Presale Pool)

• Purpose: For presale participants and airdrop recipients

• Access: Restricted to authorized deposits (whitelist, airdrops, owner)

• Withdrawal: Users can withdraw any amount at any time

• Re-deposits: Not allowed via standard deposit (only via batch airdrops)

2. Public Pool

• Purpose: Open staking for all users

• Access: Anyone can stake via stakePublic()

• Withdrawal: Users can withdraw any amount at any time

• Re-deposits: Allowed at any time

Contract Addresses

Base Mainnet (Chain ID: 8453):

• REPLY_POOLS: 0x85ED5FdfaCaC0386932AB0b189610a896be59c0E

• ALPHA_POOL_WHITELIST: 0x8066644bF0eFAe1bD7a746bb45EEF2980B1e3034

Contract Addresses

Base Mainnet (Chain ID: 8453)

Deployment Details:

• Chain ID: 8453 (Base Mainnet)

• Deployment Block: 38085458

• Owner: 0x429c599ec991Ff687DCF018C447d11b5A7513ea6

• Bot: 0xE622e4E758827008a774f4AD3d8578FE0b0Be989

Staking Mechanics

Public Pool Staking

Function: stakePublic(uint256 amount)

Process:

1. User approves REPLY tokens to ReplyPools contract

2. User calls stakePublic(amount)

3. Tokens are transferred from user to contract

4. User's stake is recorded with current multiplier

5. Adjusted stake (stake × multiplier) is added to pool totals

Requirements:

• Amount must be > 0

• User must have sufficient token balance

• User must have approved tokens to contract

• Distribution must not be in progress

Alpha Pool Deposits

Authorized Deposits: depositToAlphaAuthorized(address user, uint256 amount)

Who Can Deposit:

• AlphaPoolWhitelist contract (during whitelist window)

• Owner (for batch airdrops)

• Authorized callers

Batch Airdrops: airdropToAlphaBatch(address[] users, uint256[] amounts)

• Owner-only function

• Allows multiple deposits per user

• Gas-optimized batch processing

Withdrawals

Function: withdraw(PoolId pool, uint256 amount)

Process:

1. User calls withdraw(pool, amount)

2. Contract verifies user has sufficient stake

3. User's stake and adjusted stake are reduced

4. Tokens are transferred to user

5. If stake reaches zero, user is removed from pool

Requirements:

• Amount must be > 0

• User must have sufficient stake

• Distribution must not be in progress

Pool IDs:

• PoolId.Alpha = 0 (Alpha/Presale pool)

• PoolId.Public = 1 (Public pool)

Fee Distribution

Overview

Trading fees from $REPLY swaps are collected and distributed daily to stakers. The distribution is automatic and requires no user action.

Distribution Schedule

• Frequency: Daily

• Time: 00:00 UTC boundary (with short random delay)

• Trigger: Automated via executor bot or manual keeper call

• No Claims Required: Fees are sent directly to user wallets

Fee Collection

1. Trading fees accumulate throughout the day

2. Bot collects fees and swaps ETH → REPLY if needed

3. Bot calls addPendingREPLY(amount) to add fees to pending balance

4. Fees accumulate in pendingREPLYBalance until distribution

Distribution Process

Function: distribute() or distribute(uint256 overrideBatchSize)

Process:

1. Contract checks if distribution is due (dayIndex advanced)

2. Pending fees are split between Alpha and Public pools based on weights

3. Fees are distributed proportionally based on adjusted stakes

4. Distribution happens in batches (default: 200 users per batch)

5. Multi-transaction support for large pools

Fee Split:

• Default: 50% Alpha Pool, 50% Public Pool

• Configurable via setPoolWeights(alphaWeightBps, publicWeightBps)

• Weights must sum to 10,000 (100%)

Distribution Formula

For each user in a pool:

userFeeShare = (poolAllocation × userAdjustedStake) / poolAdjustedTotalStake

where:

• userAdjustedStake = userStake × multiplier

• poolAdjustedTotalStake = Σ(userStake_i × multiplier_i)

Deferred Fees

If a fee transfer fails (e.g., contract reverts, fee-on-transfer token), the amount is stored in deferredFeeClaims[user]. Users can claim these later via claimDeferredFees().

Attribution & Multipliers

Overview

The attribution system rewards active community members with multipliers that affect their share of fee distributions. Multipliers are weight-based, meaning they affect proportional shares rather than absolute amounts.

Multiplier Range

• Minimum: 0.9x (90% of base share)

• Maximum: 1.1x (110% of base share)

• Default: 1.0x (100% of base share)

• Precision: Fixed-point with 1e9 scale (FP_SCALE)

How Multipliers Work

Multipliers are applied to user stakes to calculate "adjusted stakes":

adjustedStake = stake × multiplier

userFeeShare = (poolAllocation × adjustedStake) / Σ(allAdjustedStakes)

Key Points:

• Multipliers affect proportional share, not absolute amounts

• Total distributed = exactly fees collected (zero-sum)

• Higher multiplier = larger share of pool allocation

• Lower multiplier = smaller share of pool allocation

Multiplier Updates

Function: updateUserMultipliers(PoolId pool, address[] users, uint256[] multipliersFP)

Process:

1. Attribution system calculates multipliers off-chain

2. Authorized caller (bot) pushes updates to contract

3. Contract updates cached multipliers

4. Adjusted totals are recalculated

5. Updates take effect on next distribution

Requirements:

• Only authorized callers can update multipliers

• Cannot update during active distribution

• Multipliers are cached per epoch (distribution cycle)

Attribution System

Multipliers are managed directly by ReplyPools through a push model. The contract maintains its own cache for gas efficiency.

Alpha Pool Whitelist

Overview

The AlphaPoolWhitelist contract manages time-limited deposits to the Alpha pool using Merkle tree verification.

Whitelist Window

• Duration: 72 hours (259,200 seconds)

• Start Time: Set by owner when activating whitelist

• One Deposit Per User: Users can only deposit once via whitelist

• Merkle Proof: Required to verify eligibility

Contract Address

Base Mainnet:

• ALPHA_POOL_WHITELIST: 0x8066644bF0eFAe1bD7a746bb45EEF2980B1e3034

Whitelist Process

1. Owner Activates Whitelist:

   • activateWhitelist(bytes32 merkleRoot, uint256 startTime)

2. User Deposits:

   • depositToAlpha(uint256 amount, uint256 maxAmount, bytes32[] proof)

   • User provides Merkle proof

   • Amount cannot exceed maxAmount from Merkle tree

   • Tokens are transferred and deposited to Alpha pool

3. Whitelist Expires: After 72 hours, whitelist is inactive

Merkle Tree Structure

The Merkle tree contains leaves of:

keccak256(abi.encodePacked(userAddress, maxAmount))

Each user has a maximum allocation amount stored in the tree.

Checking Whitelist Status

• Function: isWhitelisted(address user, uint256 maxAmount, bytes32[] proof)

  • Returns true if the user is whitelisted with the given max amount.

• Function: isWhitelistActive()

  • Returns true if whitelist is currently active and within time window.

• Function: getTimeRemaining()

  • Returns seconds remaining in whitelist window (0 if expired or inactive).

Frontend Monitoring Interface

Overview

The ReplyPools Contract Monitor is a real-time web interface available at https://lifeguard.replycorp.io that provides comprehensive monitoring and management capabilities for the ReplyPools system.

Features

Real-Time Contract Monitoring

The interface displays live contract state and automatically refreshes every 10 seconds to show:

• Pending REPLY Balance: The amount of REPLY tokens waiting to be distributed

• Distribution Status: Whether today's distribution has been completed

• Current Day Index: The current UTC day index

• Last Distributed Day: The most recent day that received a distribution

• Distribution Epoch: Monotonic counter tracking distribution cycles

• Days Behind: How many days behind the current day index (if any)

Distribution Management

The interface includes an "Execute Distribution" button that allows anyone to trigger the distribution transaction:

How the Distribute Button Works:

1. The button checks if distribution is ready:

   • Current day index must be ahead of last distributed day

   • There must be pending REPLY balance to distribute

   • Distribution must not already be in progress

   • Must be outside the bot distribution window (00:00-00:15 UTC)

2. When clicked, the interface:

   • Calls the distribute() function on the ReplyPools contract

   • Shows transaction status and hash

   • Automatically refreshes to show updated state

3. Public Execution: Anyone can execute the distribution transaction through the interface if:

   • The executor bot fails to run

   • Manual intervention is needed

   • The distribution is overdue

Distribution Window:

• Bot Window: 00:00-00:15 UTC (bot has priority)

• Manual Window: After 00:15 UTC, anyone can execute via the interface

• The interface enforces this cooldown period to prevent conflicts

Pool Statistics

Displays detailed statistics for both pools:

• Alpha Pool:

  • Weight percentage (default: 50%)

  • Total staked amount

  • Number of users

• Public Pool:

  • Weight percentage (default: 50%)

  • Total staked amount

  • Number of users

Bot Monitoring

Tracks the health and balances of automated bots:

• Executor Bot:

  • ETH balance (for gas)

  • cbBTC balance (auto-swapped for REPLY)

  • REPLY balance

  • Bot address: 0xE622...e989

• Utility Bot:

  • ETH balance (for gas)

  • Bot address: 0xf69c...20f7

  • Handles airdrop claims, multiplier updates, and other authorized operations

Distribution Progress Tracking

When a distribution is in progress (multi-transaction), the interface shows:

• Current batch being processed

• Total batches required

• Progress percentage

• Estimated completion time

Contract Information

Displays key contract details:

• Contract address: 0x85ED...9c0E

• Batch size (default: 200 users per transaction)

• Total pending balance

• Network: Base Mainnet (Chain ID: 8453)

Access

• URL: https://lifeguard.replycorp.io

• Network: Base Mainnet

• No Authentication Required: Public interface, read-only monitoring

• Transaction Execution: No Web3 wallet connection required, tx is executed on backend

Use Cases

1. Monitoring: Track pool health, pending balances, and distribution status

2. Verification: Verify that distributions are running on schedule

3. Manual Execution: Execute distributions if the bot fails

4. Transparency: Public visibility into contract operations

5. Debugging: Identify issues with distributions or bot operations

Technical Architecture

Key Design Features

1. Multi-Transaction Distribution

Large pools are distributed across multiple transactions to avoid gas limits:

• Default batch size: 200 users per transaction

• Configurable via setBatchSize(uint256 newBatchSize)

• Progress tracked in contract state

• Can resume interrupted distributions

2. Gas Optimizations

• Batch Processing: Process multiple users per transaction

• Cached Multipliers: Read multipliers from cache, not external contract

• Efficient Array Management: O(1) user removal from pools

• Single Transfer Per Batch: Batch airdrops transfer tokens once

3. Reentrancy Protection

• All external functions use nonReentrant modifier

• Distribution state prevents concurrent distributions

• SafeERC20 for token transfers

4. Precision & Math

• All proportional calculations use OpenZeppelin Math.mulDiv

• Fixed-point arithmetic for multipliers (1e9 scale)

• Basis points for weights (10,000 = 100%)

State Variables

Core State:

• pendingREPLYBalance: Accumulated fees awaiting distribution

• dayIndex: Current UTC day index (increments daily)

• distributionEpoch: Monotonic counter for distributions

• distributionActive: Flag for multi-transaction distribution

Pool State:

• totalStakes[pool]: Total raw stakes per pool

• adjustedTotalStakes[pool]: Total adjusted stakes (with multipliers)

• poolUsers[pool]: Array of user addresses in each pool

• userStakes[user][pool]: User's stake amount

Multiplier State:

• cachedMultiplierFP[pool][user]: Cached multiplier (1e9 fixed-point)

• multiplierSyncEpoch[pool][user]: Epoch when multiplier was last synced

Events

Staking Events:

• Staked(address indexed user, PoolId indexed pool, uint256 amount)

• Withdrawn(address indexed user, PoolId indexed pool, uint256 amount)

Distribution Events:

• Distributed(uint256 dayIndex, uint256 alphaAmount, uint256 publicAmount)

• FeeDistributed(address indexed user, PoolId indexed pool, uint256 amount)

• DistributionBatchProcessed(...): Batch processing progress

Multiplier Events:

• UserMultiplierUpdated(address indexed user, PoolId indexed pool, uint256 multiplierFP, uint256 epoch)

• MultiplierSynced(...)

Configuration Events:

• PoolWeightsSet(uint256 alphaWeightBps, uint256 publicWeightBps)

• BatchSizeUpdated(uint256 indexed newBatchSize)

User Guide

How to Stake in Public Pool

1. Approve Tokens:

   IERC20(REPLY_TOKEN).approve(REPLY_POOLS, amount)

2. Stake:

   ReplyPools(REPLY_POOLS).stakePublic(amount)

3. Verify: Check your stake via userStakes(yourAddress, PoolId.Public)

How to Withdraw

1. Withdraw:

   ReplyPools(REPLY_POOLS).withdraw(PoolId.Public, amount)

   or

   ReplyPools(REPLY_POOLS).withdraw(PoolId.Alpha, amount)

2. Verify: Tokens are sent directly to your wallet

How to Check Your Rewards

View Functions:

• userStakes(address user, PoolId pool): Your current stake

• cachedMultiplierFP(PoolId pool, address user): Your multiplier (1e9 = 1.0x)

• deferredFeeClaims(address user): Any deferred fees to claim

Calculate Projected Fees:

projectedFee = (pendingREPLYBalance × poolWeight × yourAdjustedStake) / poolAdjustedTotal

How to Claim Deferred Fees

If a fee distribution failed for your address:

ReplyPools(REPLY_POOLS).claimDeferredFees()

This will transfer any deferred fees to your wallet.

Alpha Pool Whitelist Deposit

1. Get Your Merkle Proof: From the whitelist system

2. Approve Tokens:

   IERC20(REPLY_TOKEN).approve(ALPHA_POOL_WHITELIST, amount)

3. Deposit:

   AlphaPoolWhitelist(ALPHA_POOL_WHITELIST).depositToAlpha(
       amount,
       maxAmount,
       proof
   )

Viewing Pool Statistics

Public View Functions:

• totalStake(PoolId pool): Total staked in pool

• adjustedTotalStake(PoolId pool): Total adjusted stake

• getUserCount(PoolId pool): Number of stakers

• getDistributionStatus(PoolId pool): Distribution stats

• getDistributionProgress(): Multi-transaction distribution progress

Security Considerations

Access Control

• Owner: Can configure weights, batch size, authorized callers

• Authorized Callers: Can add pending fees and update multipliers

• Users: Can stake, withdraw, claim deferred fees

Reentrancy Protection

• All external functions protected with nonReentrant

• Distribution state prevents concurrent operations

• SafeERC20 for token transfers

Fail-Safe Mechanisms

• Deferred Fees: Failed transfers are stored for later claim

• Batch Processing: Large distributions split across transactions

• Multi-Transaction Support: Can resume interrupted distributions

Automation & Bots

Executor Bot

The executor bot handles:

• Daily fee distribution at 00:00 UTC

• ETH → REPLY swapping

• Multiplier updates

• Health monitoring

Required Bot Permissions

• setAuthorizedCaller(botAddress, true) in ReplyPools

• Bot must have REPLY token approval to call addPendingREPLY()

Contract Interfaces

IReplyPools Interface

interface IReplyPools {
    enum PoolId { Alpha, Public }
    
    function token() external view returns (address);
    function dayIndex() external view returns (uint256);
    function totalStake(PoolId pool) external view returns (uint256);
    function adjustedTotalStake(PoolId pool) external view returns (uint256);
    function stakePublic(uint256 amount) external;
    function withdraw(PoolId pool, uint256 amount) external;
    function distribute() external;
    function distribute(uint256 overrideBatchSize) external;
    function claimDeferredFees() external;
    function setPoolWeights(uint256 alphaWeightBps, uint256 publicWeightBps) external;
    function addPendingREPLY(uint256 amount) external;
}

Additional Resources

• Website: https://replycorp.io

• Frontend Monitor: https://lifeguard.replycorp.io

Changelog

Base Mainnet Deployment (Chain ID: 8453)

• Deployment block: 38085458

• ReplyPools and AlphaPoolWhitelist deployed

• Contract addresses documented above

Last Updated: December 2025

Quick Reference

Main Contracts (Base Mainnet)

• REPLY Token: 0x05B1266DDCeE093cE060DBF697e230EA9B453633

• ReplyPools: 0x85ED5FdfaCaC0386932AB0b189610a896be59c0E

• AlphaPoolWhitelist: 0x8066644bF0eFAe1bD7a746bb45EEF2980B1e3034

Frontend Monitoring

• URL: https://lifeguard.replycorp.io

• Network: Base Mainnet (Chain ID: 8453)