Skip to content

AmirhosseinHonardoust/Rate-Limited-Token-Faucet

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
 
 
 
 
 
 

Repository files navigation

Rate-Limited Token Faucet

A Secure, Configurable, and Educational ERC20 Token Faucet with Per-User Cooldown Logic


Introduction

The Rate-Limited Token Faucet is a small but high-quality Solidity project designed to distribute ERC20 tokens to users while enforcing a cooldown period between claims. This prevents abuse and ensures fairness while keeping the system simple, auditable, and dependency-free.

The faucet is engineered with a strong focus on:

  • clarity of logic
  • security best practices
  • ease of deployment
  • practical usefulness for test environments
  • educational value for new developers

This project is intentionally minimalistic but contains all the fundamentals of:

  • access control
  • rate limiting
  • token transfers
  • event logging
  • administrative configuration

If you're learning Solidity or demonstrating smart contract mechanics, this is one of the best compact examples.


Why This Contract Exists

Faucets are essential in blockchain environments because:

Developers need tokens during testing

To simulate transactions, staking, swapping, or other mechanics.

QA teams rely on automated faucet flows

To run continuous testing of user journeys.

Testnets need safe, abuse-resistant distribution

Rate limiting prevents draining by bots or malicious actors.

Tutorials and bootcamps use faucets

Perfect for giving students controlled access to tokens.

It demonstrates real-world contract architecture

  • access control
  • storage mappings
  • ERC20 interactions
  • safe transfer patterns

This faucet is not a toy. It’s a realistic micro-application illustrating how production contracts should be structured.


Key Features (Deep Explanation)

1. Per-Address Cooldown System

Each user has their own individual timer:

lastClaimAt[user]  → timestamp of last claim
cooldown           → seconds required between claims

If cooldown is 86400 (24 hours), then:

now >= lastClaimAt[user] + 86400

must be true.

This prevents:

  • faucet draining
  • wallet spamming
  • automated abuse
  • repeated claims from bots

It’s a simple but powerful protection mechanism.


2. Zero External Dependencies

The faucet uses a minimal ERC20 interface, not OpenZeppelin.

Why?

  • Works with ANY ERC20
  • Zero import errors
  • 100% transparent
  • Easy to audit
  • Perfect for education

This is intentional: the contract shows the essentials of interacting with tokens, purely, clearly, without wrappers.


3. Secure Administrative Controls

The owner can:

  • update dripAmount
  • update cooldown
  • withdraw tokens
  • transfer ownership

This matches real-world patterns in production contracts:

  • admin role
  • controlled configuration
  • safe withdrawal flows

This reflects how DeFi protocols manage adjustable parameters.


4. Event-Driven Transparency

Every change emits events:

  • Claimed
  • DripAmountUpdated
  • CooldownUpdated
  • OwnershipTransferred
  • TokensWithdrawn

This enables:

  • dApp UI tracking
  • indexer integration
  • historical audits
  • backend automation

Events are crucial in blockchain architecture, and this faucet demonstrates their correct use.


5. Readability & Auditability

The entire contract fits into a single file and follows these best practices:

  • single-responsibility functions
  • well-labeled sections
  • no inline assembly
  • no hidden burn/mint logic
  • no modifiers except onlyOwner
  • clear require statements
  • explicit error messages

This is how professional contracts are structured for clarity.


Full Contract Architecture Explanation

Below is a conceptual breakdown of every component.


1. Storage Layout

Token reference

IERC20 public immutable token; A direct pointer to the ERC20 being distributed.

Immutable → cannot be changed after deployment → safer.


Ownership

address public owner; Only owner can modify faucet settings.


Distribution parameters

  • dripAmount | how many tokens per claim
  • cooldown | how many seconds between claims

Per-user state

mapping(address => uint256) public lastClaimAt; Tracks timestamps for every user.


2. Constructor Logic

Initializes:

  • token
  • drip amount
  • cooldown
  • owner

It also validates critical values:

  • token cannot be zero
  • drip amount must be > 0

This prevents “broken faucet” deployments.


3. Claim Logic (Core Function)

The most important flow:

1. Check cooldown
2. Check faucet has tokens
3. Update user timestamp
4. Transfer tokens
5. Emit event

Each step is independent, safe, and ordered correctly.


4. Admin Logic

Admin functions include:

  • parameter updates
  • withdraw tokens
  • transfer ownership

They are gated by:

modifier onlyOwner()

A classic access-control pattern.


5. Safety Patterns Used

Updating storage before external calls

lastClaimAt[msg.sender] = now; (before transfer)

This prevents reentrancy issues.

Minimal ERC20 interface

Reduces attack surface.

Clearing all validation before state changes

Avoids failed-state scenarios.

Explicit error messages

Vital for debugging.


Project Structure (Expanded)

rate-limited-token-faucet/
│
├── contracts/
│   └── RateLimitedFaucet.sol           # main faucet contract
│
├── README.md                           # documentation (this file)
├── .gitignore                          # standard ignores
└── (optional future additions)
    ├── scripts/                        # deployment scripts
    ├── test/                           # Hardhat/Foundry tests
    └── frontend/                       # simple UI

This structure is compatible with ALL major dev tools.


Deployment Guide

Option 1, Remix (Fastest)

  1. Open https://remix.ethereum.org

  2. Drag your folder into Remix

  3. Open RateLimitedFaucet.sol

  4. Compile with 0.8.20

  5. Deploy with parameters:

    • token address
    • drip amount
    • cooldown seconds
  6. Fund the faucet with tokens

  7. Call claim()


Option 2, Hardhat

npx hardhat compile
npx hardhat run scripts/deploy.js --network sepolia

I can generate this script for you if you want.


Option 3, Foundry

forge build
forge create ... RateLimitedFaucet --constructor-args <token> <drip> <cooldown>

Foundry support can be added with one command:

forge init

Example Use Cases

1. dApp Test Token Distribution

Give users tokens to try your contract:

  • staking
  • swapping
  • governance voting

2. Bootcamp / Classroom Faucet

Students always need test tokens for exercises.

3. QA Automation

QA pipelines can call faucet in:

  • local Anvil chains
  • CI testing
  • integration workflows

4. Demo Environments

Perfect for hackathons or prototype demos.

5. Developer Sandbox

If you build DeFi protocols locally, you can use this faucet instead of manually minting tokens.


Advanced Examples & Scenarios

Example 1: Daily Claim Faucet

Drip 5 tokens every 24 hours:

dripAmount = 5e18
cooldown   = 86400

Example 2: Cooldown-Free Faucet

Allow unlimited claims:

setCooldown(0)

Useful in local testing environments.


Example 3: Low-Drip High-Cooldown

Drip 1 token every 7 days:

dripAmount = 1e18
cooldown   = 604800

Prevents draining and spreads token usage across weeks.


Example 4: Faucet Shutdown

Owner can gracefully remove tokens:

withdrawTokens(owner, faucetBalance)

Then set:

setDripAmount(0)

(optional, to disable claiming)


Security Considerations (Deep Analysis)

This faucet is safe for test environments but comes with known constraints:


Risk 1, Multi-Wallet Abuse

Users can create multiple wallets to bypass cooldown.

Mitigation (optional upgrade):

  • address whitelist
  • social login faucet
  • IP-based rate limiting (off-chain)
  • maintain on testnets only

Risk 2, Owner centralization

Owner can:

  • withdraw tokens
  • change drip amount
  • change cooldown

This is desired for faucet management, but not suited for mainnet or financial use.


Risk 3, ERC20 Behavior

Some ERC20 tokens are non-standard (fees, rebasing).

This faucet assumes:

  • transfer() returns true
  • no fees based on transfer

If you need support for fee-on-transfer tokens, I can modify the contract.


Risk 4, Token Supply

Faucet does not mint tokens → must be funded.


Future Upgrades

If you want a V2 or V3 version:

Add max lifetime claims per user

Add a Merkle whitelist

Add multi-token support

Add NFT faucet mode

Add a frontend interface

Add Hardhat + Foundry tests

Add time-based dynamic drip amounts

Add Faucet Analytics Dashboard (usage metrics)

I can build any version you want.


License

This project is released under the MIT License, allowing unrestricted use, modification, distribution, and commercial utilization.


Contributions

Contributions, improvements, and feature requests are welcome.

If you're learning Solidity → fork this repo. If you're teaching → use this as a classroom example. If you're building → integrate this faucet into your test flows.

About

A secure, minimalistic ERC20 token faucet with per-address cooldown enforcement. Designed for testnets, demos, QA automation, and educational Solidity environments. Provides configurable drip amounts, adjustable cooldown timings, owner-controlled management, transparent event logs, and a fully dependency-free implementation.

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors