Scan depth

Every lookup in the app asks one question before it starts: how hard should this try. There are two answers, and the difference is speed against coverage. Throughout this page, the index means our own database of 4.86 million wallet identities, not a third party’s. Deep is the default. It is the one that produces attested X handles, which is the difference the product is built on.

​

What each one reads

A fast scan reads two things: the walletlink index, and the short-term cache in front of it. That is the whole pipeline. Nothing is resolved live, nothing is written back, and the wall clock is dominated by the round trip rather than by how many addresses you sent. A deep scan reads those first, then resolves whatever is left against every live source your account can reach, including onchain ENS text records. It writes what it learns back, so the next lookup over the same addresses is faster for everyone.

​

Which to choose

Pick fast when you are re-running a list you have looked up before, when you want a rough size before committing, or when you are working interactively and would rather have 80% of the answer now than all of it in five minutes. Pick deep when the output is going to drive a campaign. The handles that only a deep scan finds are the owner-attested ones, and those are the ones worth contacting.

​

What it costs you in time

The app estimates before you start, and the estimate follows the choice. The deep figure is deliberately conservative: ten seconds of live sources and eight of onchain reads. Real lists usually run faster, because the more of your list is already indexed, the less there is left to resolve.

​

How a long list is worked

Every lookup works its list 3,000 addresses at a time, and one pass keeps taking the next 3,000 for up to four minutes. It stops early rather than start a batch it expects to run past that, judging by how long the last batch took, and whatever is left is picked up by the next pass, a minute later at most. A fast scan’s batches read only the index, so each takes seconds and a fast scan of 10,000 addresses finishes in its first pass. A deep scan waits on live sources in every batch, so a long one can take several passes, and its time follows the deep figure above. If a pass runs out of time part-way through a batch, the addresses not yet asked about are carried into the next batch rather than counted as done, so every address in a deep scan is asked.

​

Fast scans never write

A fast scan does not write to the index, and this is deliberate rather than an optimization. Writing back would stamp records as freshly checked when nothing checked them, and a later deep scan would trust that stamp and skip the very sources meant to confirm them. One fast scan would suppress the next real one. So a fast scan is free of side effects in both directions: it takes what is there, and it leaves the index exactly as it found it.

​

Through the API

The API has no depth setting; the depth follows the endpoint. The synchronous lookups behave like a fast scan: they answer from the index, which is why they return in milliseconds. An async job runs the standard pipeline, resolving whatever the index cannot answer against live sources, though without the onchain ENS text-record pass the app’s deep scan adds. What either costs depends on how much it resolves: a call that matches nothing is free.