Layered request controls
Limits combine destination history, session evidence, network signals and time windows rather than trusting one identifier. Decisions carry reason codes so operators can analyse rejection and bypass patterns.
Web3 & Blockchain
A developer faucet designed on the assumption it will be attacked
We build bounded distribution services for testnets and developer onboarding, treating every request as untrusted and every payout as hot-wallet exposure.
Capabilities
What this service delivers
Proof and challenge flows
Captcha or adjustable proof-of-work challenges increase the cost of automated requests where the audience permits them. Challenges are accessible alternatives within a broader policy, not evidence of unique human identity.
Sybil-aware distribution
Address rotation, shared networks and disposable identities are expected in the request model. Budgets and velocity controls cap loss because no available signal proves that two requests belong to different people.
Hot-wallet and float controls
The signer holds only the distribution float required for a defined operating window. Replenishment is separated from request processing and can require operator approval above a threshold.
Fee-aware payout batching
Eligible requests can be collected into bounded batches to reduce per-output network cost. The queue records reservation, construction, broadcast and confirmation states so retries do not create duplicate payments.
Drain monitoring and administration
Dashboards expose wallet balance, request velocity, rejection reasons, payout backlog and destination patterns. Operators can pause distribution, adjust limits and review actions through authenticated, authorised and logged controls.
Technology stack
Tools used for the work
TypeScriptNode.jsPostgreSQLRedisBitcoin Core RPCCloudflare TurnstileOpenTelemetryPrometheusDocker
Process
How the engagement runs
01
Define the developer use case
We identify network, intended users, distribution amount, expected fee conditions and acceptable friction. The policy fixes daily loss bounds and explicitly excludes promotional reward mechanics.
02
Model abuse and custody
Likely automation, address rotation, proxy use, wallet compromise and fee spikes are modelled. Float, replenishment and emergency pause controls are selected from that exposure.
03
Build request and payout state
Eligibility evidence, reservations, batches and chain transactions are stored as auditable state transitions. Idempotency tests cover repeated requests, worker restart and uncertain broadcast results.
04
Tune controls under staged load
Synthetic abuse and a restricted developer cohort exercise limits, challenges and queue capacity. False rejections and drain rate are reviewed together rather than optimising only request completion.
05
Operate with bounded float
Alerts and pause procedures are rehearsed before the wallet is funded. Operators receive documented replenishment, key rotation, fee change and incident review procedures.
01
A faucet is an intentionally exposed hot wallet
A faucet accepts untrusted requests and sends assets without reciprocal settlement. Even on a testnet, automated drain attempts, malformed destinations and fee amplification should be expected. The online signer therefore holds a small, measured float rather than the client’s reserve.
We cannot make an exposed wallet risk-free. Withdrawal ceilings, isolated signing, replenishment separation and an automatic pause bound loss, while monitoring makes rapid depletion visible before routine top-up conceals it.
02
No single limit establishes one user
IP limits alone fail because offices and carrier networks share addresses while attackers rotate proxies. Address limits fail when wallets generate destinations freely. Cookies, accounts and captcha each add evidence or cost, but none proves a unique person.
We combine weak signals, destination history, velocity budgets and optional challenges according to the developer audience. No faucet is fully Sybil-resistant, so the loss budget remains the final control rather than an assumed identity system.
- Destination and velocity history
- Network signals with shared-IP tolerance
- Adjustable proof or captcha
- Fixed distribution loss budgets
03
Payout state must survive uncertainty
A request moves through eligibility, reservation, batching, broadcast and confirmation states. Idempotency keys prevent browser retries or worker restarts from allocating the same claim twice. When broadcast outcome is unclear, the service checks node and wallet state before constructing a replacement.
Batching can reduce transaction fees but delays individual requests and concentrates more outputs in one transaction. Maximum batch age, size and fee policy make that trade-off visible, while low-fee conditions may justify direct settlement.
04
Developer access is the product boundary
A faucet can remove initial friction when developers need test assets to exercise wallets, contracts or node integrations. An admin view provides pause state, float, queue depth, abuse patterns and a record of policy changes without exposing signing credentials.
We will not build a faucet designed as a promotional giveaway, yield mechanism or inducement to acquire a coin. Token promotion, classification and distribution obligations require qualified advisers; this service implements a developer utility only.
FAQ
Common questions
How do you stop bots draining a crypto faucet?
Bots cannot be eliminated, but their cost and maximum extraction can be bounded. Layered limits, destination history, proof challenges, wallet ceilings and drain alerts reduce exposure without claiming unique-user identification.
Why are IP limits not enough for a testnet faucet?
IP addresses do not map reliably to people. Legitimate users share corporate, mobile and educational networks, while automated clients can rotate proxies.
Should a faucet use captcha or proof of work?
Either can add useful friction when matched to the audience and threat model. Captcha depends on an external service and affects accessibility, while proof of work consumes client resources and may disadvantage mobile devices.
How much coin should a faucet hot wallet hold?
Only the float needed for a defined operating period and loss budget should remain online. Reserve funds and replenishment authority should be separated from the request-processing service.
Can faucet payouts be batched to reduce fees?
Yes, when the chain supports multi-output or aggregated transfers and users can tolerate a short queue. The system must reserve each claim, cap batch age and reconcile uncertain broadcasts before retrying.
Can you build a promotional crypto giveaway faucet?
No. We build faucets for testnets and genuine developer onboarding, not promotional giveaway or investment-acquisition schemes; qualified advisers must determine any distribution obligations.
Related services
Connected engineering capabilities
Plan a crypto faucet development engagement.
Share the problem, current system and constraints. We will respond with the questions needed to define a credible next step.