Scavenger search
For mints shaped like mint(uint256 id), you don’t know which id is
available until you try one. Scavenger search is how Zyper finds one.
When it kicks in
Use the literal token {id} as the value of any uint256 argument in the
Build Task dialog. The runner sees the token and
spins up a shared scavenger worker for the (chain, contract, function)
triple.
What the worker does
The worker walks token IDs from a starting point (typically 0 or the
contract’s first known ID) and eth_calls the mint with each candidate:
- Revert → ID is unavailable. Skip.
- Success → ID is mintable. Push to the found-IDs channel.
Every scavenger-enabled task on that (chain, contract, function) triple
subscribes to the same worker’s channel. One worker feeds many tasks.
Refcount shutdown
When the last task subscribed to a worker exits, the worker shuts down. Idle scavenger workers don’t linger.
RPC use
Scavenger runs through the same RPC pool everything else uses. It hits one RPC per probe and fails over on errors. The probe rate is conservative by default; you can raise it via Settings if your RPCs can handle it.
When NOT to use scavenger
- Mints with a known qty arg (
mint(uint256 qty), no per-ID semantics) — hard-code the qty instead. - Contracts where successive IDs are batched into one call — pre-compute the range yourself.
- Contracts where
eth_callalways succeeds (e.g., free mints with no conditional state) — scavenger will hand back the first ID immediately, which may not be what you want.
Combining with Simulate
Scavenger + Simulate is the standard “snipe a paginated mint” combo:
- Simulate handles “is the mint open yet?”
- Scavenger handles “which ID can we mint right now?”
The two work together — Simulate’s eth_call ready-check uses the
scavenger-found ID at the time it runs.