Time-zone consistency across sybil wallets

most people building multi-wallet farms spend hours thinking about IP diversity, wallet funding paths, and on-chain activity spacing. very few spend any time on timezone consistency, which is a mistake. timezone signals exist in at least three distinct layers of a typical airdrop interaction: the browser environment that the dApp frontend reads, the IP geolocation that the protocol’s backend correlates, and the statistical distribution of your on-chain transaction timestamps. protocols that run sybil analysis post-snapshot have increasingly started using timing data as a clustering signal. it is quiet, hard to notice until you’re already flagged, and surprisingly easy to get wrong even with a professional anti-detect setup.

i run somewhere between 20 and 60 wallets on any active campaign depending on the protocol’s risk profile and my confidence in the TGE timeline. i’m based in Singapore, which creates a specific problem: my natural timezone (Asia/Singapore, UTC+8) is actually an unusually strong fingerprint because a disproportionate number of airdrop farmers are in Southeast Asia, and protocols hunting for sybils in Asia-Pacific clusters will catch you faster if all your wallets sing the same timezone chorus. this guide is about understanding why the signal exists, how analysts surface it, and what discipline looks like in practice.

the stakes are real. LayerZero’s 2024 sybil hunt disqualified tens of thousands of addresses using behavioral clustering, and the public methodology included transaction timing patterns as part of the fingerprint. gitcoin passport runs ongoing scoring that includes device and behavior signals. if you’re farming anything with a non-trivial allocation, getting cut by a sybil filter costs more than the time it takes to build proper profiles.

background and prior art

the earliest airdrop sybil filters were almost entirely on-chain: same funder address, same contract deployer, same dust consolidation pattern. these are still used, but they’re table stakes now. the shift toward behavioral analysis, including timing signals, started becoming visible around 2022 and accelerated after Optimism’s first airdrop in mid-2022, which triggered a wave of academic and protocol-side research into how to distinguish real users from farms.

the academic foundation here is older than crypto. the original sybil attack paper by John Douceur at Microsoft Research (2002) framed the problem in terms of identity fabrication in peer-to-peer systems. more directly relevant is the body of work on device fingerprinting that predates Web3 entirely. the EFF’s Cover Your Tracks project has been documenting how reliably browsers leak unique fingerprints since 2010. timezone is one of the more stable components of a browser fingerprint, because it is derived from the operating system, not easily spoofed by the browser’s own sandboxing, and it tends to stay consistent across sessions in ways that user-agent strings or screen resolutions don’t. when anti-detect browsers became a core tool for multi-account operators, they added timezone spoofing as a feature specifically because fingerprinting researchers had already established its value as an identifier.

on the protocol side, the shift is toward what analysts call “behavioral clustering” rather than just address-graph clustering. instead of asking “did these wallets share a funder,” they ask “did these wallets exhibit statistically similar behavior patterns across time.” timing is one of the cleanest signals for this because it is hard to fabricate retroactively, it has a natural ground truth (real users in a given geography transact at human-plausible hours), and because most farm operators don’t think carefully enough about it to make it random.

the core mechanism

there are three distinct layers where timezone signals exist, and you need to think about them separately.

layer 1: browser timezone in the dApp frontend

every modern browser exposes the client’s timezone to JavaScript through at least two APIs. Intl.DateTimeFormat().resolvedOptions().timeZone returns the IANA timezone string (e.g. "Asia/Singapore" or "America/New_York"). new Date().getTimezoneOffset() returns the UTC offset in minutes. dApp frontends don’t typically log these explicitly, but any analytics platform they embed, any session recording tool, or any backend that logs request metadata with timestamp correlation can reconstruct what timezone a given session was operating from. the MDN documentation on Intl.DateTimeFormat describes exactly what these APIs expose, and they are called implicitly by a large number of common date-display libraries.

the anti-detect browser correctly handles this if, and only if, you have set the profile timezone to match the IP you are routing through. this sounds obvious. in practice it fails for three reasons: the timezone was set once at profile creation and the operator rotated the IP to a different region later, the anti-detect browser has a bug in how it spoofs the Intl API versus the legacy Date offset, or the operator set the city correctly but the IANA string resolves to a different offset than the proxy due to daylight saving time. i have seen all three in production.

layer 2: IP geolocation correlation

when your wallet signs a transaction or your browser hits a dApp backend, the server sees an IP address. that IP resolves to a geographic region via a geolocation database (MaxMind’s GeoLite2 and GeoIP2 are the dominant commercial options; most protocol backends use one of these or a derivative). the backend can then compare: does the timezone offset reported by the client match what we would expect from the IP’s geographic region?

a residential proxy in Chicago (UTC-6 in winter, UTC-5 in summer) running a browser profile with timezone Asia/Singapore (UTC+8) creates a 13 or 14 hour mismatch. this mismatch is logged. it is not necessarily an instant disqualification on its own, but it is a feature that goes into any clustering model. if 40 of your wallets all have this same mismatch pattern, that’s the cluster.

layer 3: on-chain transaction timestamp distribution

this is the layer most people completely ignore. Ethereum blocks have timestamps set by the validator, expressed as Unix time (UTC). your transaction’s inclusion time is therefore permanently recorded in UTC. a real human user in New York is more likely to be making transactions between approximately 12:00 UTC and 03:00 UTC (7am to 10pm local time). a real user in Singapore is more likely active between 00:00 UTC and 15:00 UTC. if you are running 50 wallets all from residential US IPs but you personally are in Singapore working during Singapore hours, your transaction activity will cluster in UTC hours that are inconsistent with a US user base.

protocols running post-snapshot analysis can aggregate, for each address: what was the distribution of transaction hours (in UTC) over the farm period. they can then compare that distribution against what they would expect from the claimed geography (as inferred from IPs, if they logged those, or from timezone signals in the frontend). a farmer in Singapore running 50 “US” wallets but working their normal hours will have a transaction hour histogram that peaks around 02:00-10:00 UTC, not 13:00-02:00 UTC like actual US users. clustering 50 addresses with nearly identical UTC hour distributions is straightforward.

worked examples

example 1: the 10-wallet pilot with one bad profile

consider a setup of 10 wallets targeting an EVM chain’s DeFi protocol. the operator is based in Berlin (UTC+1 in winter). they buy 10 residential proxies: 7 US (various states), 2 UK, 1 Germany. they create browser profiles in Dolphin Anty, which correctly sets the timezone for 9 of the profiles based on the proxy geo-detect feature. for the 10th profile, the proxy provider rotated the IP to a different datacenter mid-session, and the timezone was never updated. that profile now has a US residential IP but timezone Europe/Berlin.

individually, one mismatch doesn’t flag anything. but the protocol’s analytics capture all 10 wallet addresses interacting with the same contract within a 4-hour window repeatedly. a graph analysis groups them by funding source (they used a shared CEX withdrawal address with a mixer hop). the timezone mismatch on wallet 10 becomes a corroborating signal that this cluster is operated by a single entity who made a configuration error. the entire cluster of 10 is disqualified. cost: the time spent building 10 profiles plus the gas across the campaign.

example 2: the transaction timing fingerprint at scale

an operator runs 35 wallets targeting a protocol with an 8-month farming window. they are in Ho Chi Minh City (UTC+7). their active hours are roughly 08:00-23:00 local, which is 01:00-16:00 UTC. all 35 wallets use US residential proxies and US-profile anti-detect browsers. the on-chain activity, however, tells a different story: 90% of transactions across all 35 wallets fall between 01:00 and 16:00 UTC. for comparison, a legitimate US user cluster of 35 people would show activity spread across 13:00-05:00 UTC with a reasonable distribution. the protocol’s post-snapshot sybil contractor (there are boutique firms that do this work; Nansen and Chainalysis both have analytical products that can feed these reports) flags the cluster based on the bimodal timing pattern. 35 wallets disqualified. the operator would have needed to automate transaction execution at times that matched US user behavior, not their own local working hours.

the fix would have been to use a task scheduler to execute low-value interactions during US peak hours, even if the operator was asleep. this is a solvable engineering problem but it requires actually thinking about it.

example 3: the daylight saving trap

a more subtle failure. an operator creates 20 profiles in March targeting a protocol with a 6-month farm window. proxy region: US East (New York). timezone set correctly: America/New_York, offset -05:00 (winter, EST). in mid-March, New York enters daylight saving time and moves to -04:00 (EDT). most anti-detect browsers update the offset automatically if they are reading the IANA timezone string correctly and the underlying OS timezone database is up to date. some configurations, particularly older profile exports or browsers with stale timezone data, do not update and continue to report -05:00 through summer.

from April through October, 20 wallets are all reporting a timezone offset of -05:00 for an IP geolocation that any backend would expect to be -04:00. that’s a 1-hour mismatch, which on its own seems minor. but it is consistent across all 20 profiles because they were all created from the same template, and consistency is exactly what clustering algorithms look for. a human using a real computer in New York would have their offset update automatically. twenty computers all frozen at -05:00 in July looks like a provisioned fleet.

check your profiles after every DST transition. the US ones matter especially because North America has two transitions (March and November) and different states handle it differently (Arizona doesn’t observe DST).

edge cases and failure modes

pitfall 1: the IANA string versus the UTC offset

these are not the same thing and some anti-detect browsers spoof them independently. America/Chicago and America/Indiana/Knox can have the same UTC offset at a given moment but are different IANA strings. if your browser spoofs the offset correctly but returns a mismatched IANA string, a sophisticated fingerprinting check will catch the inconsistency. test every profile template by opening a browser fingerprint checker (browserleaks.com is commonly used) and verifying both the IANA string and the offset match the expected proxy region.

pitfall 2: RPC calls leaking real timing metadata

when a wallet signs a transaction, the RPC provider (Infura, Alchemy, your own node) receives the raw signed transaction with a timestamp derived from when your local clock generated it. if you are running 20 wallets on the same machine and submitting transactions in a batch script, the submission timestamps may cluster within milliseconds of each other in UTC. even with diverse IPs and timezone profiles, the RPC submission timing creates a fingerprint at the infrastructure level. mempool analysis firms can in principle identify this. the counter-strategy is to add randomized delays (jitter) between transaction submissions, not just between different activity sessions. jitter of 30 seconds to 5 minutes per wallet per action is reasonable. jitter of 200 milliseconds is not.

pitfall 3: social layer timezone leaks

some protocols require Discord activity, twitter/X engagement, or on-chain attestation as part of eligibility. discord shows timestamps on messages. if your 15 “US” farm accounts are all posting in a discord at 03:00 EST (which is 15:00 Singapore time, a very natural posting hour for someone in Singapore), that’s a visible signal to any moderator or analyst reviewing the server. this is hard to automate around without either posting at genuinely random hours or building a queue system that releases messages during target-timezone daylight hours. the latter is the correct approach for serious operations.

pitfall 4: the travel exception problem

real users travel. an actual user who normally transacts from Singapore might spend two weeks in London and their activity would legitimately shift. protocols generally account for this in their models. the problem for farmers is that a real traveler’s timezone shift is gradual and their activity hours shift with it, whereas a farmer who switches proxy regions typically switches IPs and timezone simultaneously in a way that looks instantaneous in the on-chain record. if you need to rotate the geographic profile of a wallet mid-campaign, do it gradually: move the timezone forward or backward by 1-2 hours per week over several weeks, and adjust your transaction timing distribution to match.

pitfall 5: the shared infrastructure fingerprint

even with per-profile timezone consistency, if all 40 of your wallets are running on the same VPS or the same residential proxy subnet, IP-level analysis will cluster them before timezone data even enters the picture. timezone consistency is one layer of hygiene, not a complete solution. the analysis frameworks that sophisticated protocols use (and that you can read about in Chainalysis’s public-facing research and reports) combine address graph analysis, IP clustering, timing analysis, and behavioral pattern matching. you have to pass all layers, not just one.

what we learned in production

the biggest operational insight i’ve arrived at is that timezone hygiene is fundamentally a configuration management problem, not a per-session problem. if you set up your profiles correctly once and maintain them through DST transitions, you basically solve the browser-layer signal for free. what you cannot automate away without explicit attention is the transaction timing distribution at the aggregate level.

i now run all execution scripts through a wrapper that applies a timezone-aware jitter schedule: transactions are queued to execute during the expected “active hours” of the profile’s claimed geography, with the actual submission times drawn from a distribution that matches typical human usage patterns for that region. this means some wallets aren’t touched for 14+ hours at a stretch, which also has the side effect of making the on-chain activity look more human. you can read more about how anti-detect browser profiles should be configured end-to-end, including timezone, canvas, and webGL settings, at antidetectreview.org’s browser guides, which covers the major platforms (Multilogin, GoLogin, Dolphin Anty, Adspower) in practical depth.

the second thing i learned is that you need to audit your profiles periodically, not just at creation. i do a quarterly sweep: spin up each profile, hit a fingerprint checker, verify the IANA timezone string matches the proxy geo, verify the offset matches the current DST status for that region, and verify that recent on-chain activity for that wallet’s address has a timestamp distribution consistent with the claimed geography. this takes about 10 minutes per profile if you have a systematic checklist. it’s boring. it matters. for more on multi-account operational hygiene at the infrastructure level, multiaccountops.com’s blog has good coverage of the proxy and browser stack considerations that the timezone layer sits on top of.

the last production note: for campaigns longer than 3 months, consider whether it is worth diversifying the claimed geographies of your wallet fleet across 3-4 distinct timezone regions rather than clustering them all in one place. a portfolio of 40 wallets with 15 in US/Eastern, 10 in UK, 8 in Germany, and 7 in Japan will have a much harder-to-detect aggregate timing fingerprint than 40 wallets all in one timezone, and the on-chain hour distribution will be genuinely flattened across the UTC clock in a way that looks like a real diverse user base rather than a managed fleet. the cost is more complex profile management. the benefit is resilience against the cluster-detection approaches that are becoming standard in post-snapshot analysis.

references and further reading

1. Ethereum block and timestamp documentation - official Ethereum Foundation developer documentation explaining how block timestamps work, relevant to understanding what timing data is permanently recorded on-chain.

2. EFF Cover Your Tracks - the Electronic Frontier Foundation’s browser fingerprinting research tool, which demonstrates how reliably timezone and related browser signals can uniquely identify a client.

3. MDN: Intl.DateTimeFormat.prototype.resolvedOptions() - technical reference for the JavaScript API that exposes client timezone information to dApp frontends, directly relevant to understanding what signals are available to protocol analytics.

4. Chainalysis research blog - Chainalysis publishes ongoing research on blockchain clustering and behavioral analysis techniques; their public writing is the closest thing to a published methodology for the kind of post-snapshot sybil analysis that major protocols commission.

5. Proxyscraping.org blog - practical operator coverage of proxy selection and IP geolocation behavior, relevant to understanding how the IP layer interacts with the timezone signals described in this article.

Written by Xavier Fok

disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-05-19.