DEV Community: Solstack

Selling tokens from wallets with no gas, using EIP-7702

Solstack — Sat, 07 Nov 2026 07:28:59 +0000

We built a page that empties old EVM wallets. You paste their seed phrases or private keys, and it finds the tokens with a market price on 15 chains, sells them, bridges the proceeds and delivers SOL to a Solana address.

The wallets people bring to it hold a few dollars of some token and almost never any native coin. That's the hard part. A sale has to go through from a wallet that can't pay for anything.

It works on 14 of the 15 chains. Why the fifteenth refused is the second half of this post.

Who pays the gas

Selling an ERC-20 takes an approve and a swap, and both cost gas. Funding fifteen chains with native coin just to sell $3 of dust on each is the chore the page is supposed to remove. So the gas had to come from somewhere else, and we saw two ways to do it:

The app fronts gas from its own hot wallets on every chain and hopes to earn it back.
A relayer submits the transaction and takes the gas out of what the sale returns.

We went with the second. There's no treasury sitting on fifteen chains waiting to be drained, and the user sees the gas cost in the quote before anything happens.

EIP-7702 and Calibur

A plain EOA can't batch calls, and it can't let someone else pay its gas. EIP-7702 lets the wallet delegate to a contract while keeping its address and key. Uniswap publishes Calibur, an audited delegate contract that does what we needed: it runs a batch of calls authorized by one EIP-712 signature from the wallet's own key.

Keys get parsed in the browser into viem local accounts. There's one input box with one secret per line. A line that's all hex and too long to be a seed word is treated as a private key, and anything else is tried as a BIP-39 phrase:

/** A line that is meant as a private key: one hex word, long enough not to be a seed word. */
const looksLikeKey = (line) => /^(0x)?[0-9a-f]{20,}$/i.test(line);

From there, a sale goes like this:

The browser signs a 7702 authorization that delegates the wallet to Calibur, once per wallet per chain.
The browser signs one Calibur batch (EIP-712, with a deadline) holding the approve and Relay's deposit call.
Our Cloudflare Worker sends it to Relay's /execute with subsidizeFees: false. Relay's relayer pays the gas and takes it back out of the sale.

The wallet only needs the token. Relay's fee plus gas is about $0.02 to $0.03 a sale on most chains and closer to $1.50 on Ethereum mainnet, so the page ticks every holding worth $1 or more and leaves anything smaller up to you.

Only forward an authorization the chain will apply

This is the failure that costs money, and it makes no noise. If the chain skips your authorization, the wallet has no code, the relayed call does nothing, and the relayer has paid gas for a no-op. A skipped authorization is easy to produce by accident, so the Worker refuses anything the chain wouldn't apply:

const code = await rpcRead(chain, "eth_getCode", [user, "latest"]);
if (!delegatesToCalibur(code)) {
  // Delegated to some other smart account by another app: leave the wallet alone.
  if (code && code !== "0x") return json(400, { error: "This wallet is set up as a smart account already." });
  if (
    lower(a.address) !== lower(CALIBUR) ||
    Number(a.chainId) !== chainId ||
    BigInt(a.s) > SECP256K1_HALF_N ||                 // high-s signatures are rejected on chain
    (Number(a.yParity) !== 0 && Number(a.yParity) !== 1)
  ) {
    return json(400, { error: "The delegation must be to Calibur on this chain." });
  }
  const nonce = parseInt(await rpcRead(chain, "eth_getTransactionCount", [user, "pending"]), 16);
  if (Number(a.nonce) !== nonce) return json(409, { error: "The wallet's nonce moved. Sign the delegation again.", code: "nonce" });
  const by = await recoverAuthorizationAddress({ authorization: auth });
  if (!by || lower(by) !== lower(user)) return json(403, { error: "The delegation isn't signed by this wallet." });
  authorizationList = [auth];
}

Some of this we learned the hard way. The authorization nonce comes from the pending transaction count, and it moves if anything else touches the wallet between signing and submitting.

If the wallet already delegates to Calibur, we drop the authorization instead of sending it again, because a stale one in the list can fail the whole transaction. If it delegates to some other contract, we skip the wallet entirely. Overwriting another app's delegation from a dust tool is a good way to break something you don't understand.

Two legs through a hub chain

Relay prices same-chain gasless swaps differently from cross-chain ones. Same-chain needs the app to sponsor the gas and cross-chain doesn't. So every holding makes a cross-chain hop into ETH on Base, inside the same wallet. Tokens that are already on Base hop to Optimism instead.

Then one batch per wallet bridges the collected ETH to SOL, with our fee as a plain ETH transfer at the front of that batch. Compared with quoting each token straight to SOL, the first leg costs about the same relayer fee, so the real extra is the final bridge at about $0.02 per wallet. In return, each wallet pays one fee transfer, and between the two legs the money sits in the user's own wallet.

Relay in production

Relay's docs cover everything in this section. It's still easy to miss, and one of these broke our first parser.

A failure status isn't final. A failed fill usually gets retried or refunded, so the poller only treats success and refund as the end. The exception is a case Relay spells out itself:

if (s.status === "success") return { ...done, requestId };
if (s.status === "refund") return { status: "refunded", requestId, note: "Relay sent it back to the wallet." };
if (s.status === "failure" && s.refundFailReason && s.refundFailReason !== "N/A") {
  return { status: "failed", requestId, note: noRefund(s.refundFailReason) };
}

refundFailReason holds the literal string "N/A" when there's nothing to report. Our first parser expected it to be empty and fell over, which is why that comparison is there.

Set refundTo on every quote. Without it there's no automatic refund path for a deposit Relay can't fill.

Rate limits matter too. /quote allows 50 requests a minute per app, so 429s during a run with lots of tokens are normal, and every call retries with backoff.

The chain that refused: Avalanche

Native AVAX sales failed in testing. Relay's dry run rejected them twice with a generic error, while native ETH and BNB went through on every other chain. The error told us nothing.

Hardhat's default test accounts gave it away. Their keys are public, so bots delegated them long ago on every chain that allows it. eth_getCode on account #0 returns delegation code on all 14 of our other chains, Scroll and Zora included. On Avalanche it returns 0x.

Avalanche C-Chain doesn't have EIP-7702 yet. ACP-209 is still a proposal. Every gasless sale there was never going to work, and we couldn't find an RPC method that tells you so. If you know a cleaner way to ask a chain whether it applies 7702 authorizations than poking known-delegated accounts for code, we'd like to hear it.

So on Avalanche we dropped the gasless path. AVAX itself is still worth selling the ordinary way, with the gas paid out of the AVAX being sold:

const balance = BigInt(await rpc(chainId, "eth_getBalance", [user, "latest"]));
// A quarter over the current price so it confirms; what goes unused stays in the wallet.
const gasPrice = (BigInt(await rpc(chainId, "eth_gasPrice", [])) * 5n) / 4n;
const amount = balance - OWN_GAS_LIMIT * gasPrice;   // OWN_GAS_LIMIT = 1,500,000

const est = BigInt(await rpc(chainId, "eth_estimateGas", [{ from: user, to: c.to, data: c.data, value }, "latest"]));
const gas = (est * 13n) / 10n;
const raw = await account.signTransaction({ type: "legacy", chainId, nonce, to: c.to, value, data: c.data, gas, gasPrice });

A sale through Relay's router used 480k to 740k gas in our tests, so the 1.5M reserve has room to spare, and whatever isn't used stays in the wallet as AVAX. ERC-20s on Avalanche can't be sold for now. The page tells you that up front instead of failing halfway through.

What the server can and can't do

The page asks for seed phrases, so we built it as if our own server were hostile. That's how any sensible user will think about it, and they're right to.

Keys only ever exist in the browser tab. The server gets wallet addresses, holdings and signed payloads. The page's CSP lets scripts talk to its own origin and DexScreener's price API and nowhere else, which you can check in the response headers and the network tab.
The Worker re-encodes every batch from its parsed form before forwarding it, so no padding or extra calldata can sneak along.
Each batch has to match a quote the Worker issued itself (an HMAC over the calls, wallet, chain and deadline), recover to the wallet's own signature, and land before a deadline the server picked. The worst the Worker can do is refuse to send a sale. It can't change one or make one up.
On the own-gas path, the broadcast endpoint only accepts a transaction whose call matches an HMAC-quoted call and that's signed by the quoted wallet.

Token discovery doesn't need paid keys either. Alchemy's demo tier lists balances but prices very few tokens, so prices come from DexScreener in the browser. When Alchemy can't answer for a chain at all, a Multicall3 pass reads the balances of every token on CoinGecko's list for that chain straight from the chain.

If you're building something like this

Settle who pays gas first. With subsidizeFees: false the relayer takes it out of the sale and you never hold a float on any chain.

Treat the authorization checks as the core of the whole thing. A skipped authorization costs real money and gives you no error to go on.

And probe every chain for 7702 support before you promise it. Everything else about Avalanche looked standard, and that's what made it hard to spot.

The tool is at https://migration.solstack.xyz if you have an old wallet with some dust in it.

How We Scanned 1 Million Solana Token Accounts Without Timing Out

Solstack — Tue, 20 Oct 2026 04:44:12 +0000

Our Holder Snapshot tool answers a simple question: who holds a token, and how much do they hold?

Projects use it to airdrop tokens to another community, calculate governance voting power, or check whether a token claiming to have 10,000 holders actually has 10,000 distinct owners.

For most tokens, this is straightforward. We fetch the token accounts, discard the empty ones, group balances by owner, and return the results.

Then we tried it with BONK.

With roughly a million token accounts to process, our first implementation fell apart. The scan timed out long before it could finish. We were fetching pages sequentially, and each page was taking longer to retrieve than the previous one.

Fixing pagination turned out to be only part of the problem. We also had to deal with a rate limit shared with other users, requests that could hang indefinitely, token balances larger than JavaScript's safe integer range, and CPU-intensive operations that froze the browser tab.

Here's how we redesigned the scanner and what we learned from testing it against a token of this size.

1. Why Counting Token Holders Is More Complicated Than It Looks

On Solana, a wallet doesn't hold a token balance directly. The balance lives in a token account, which records the mint, owner, and amount.

A wallet usually has an associated token account for each mint, but it can have multiple token accounts for the same token. Empty accounts can also remain on-chain until someone closes them.

That means counting token accounts isn't the same as counting holders.

To calculate the actual holder count, we need to:

Fetch every token account belonging to the mint.
Discard accounts with a zero balance.
Group the remaining accounts by owner.
Sum the balances belonging to each owner.

The grouping itself is easy. Retrieving every account efficiently is the difficult part.

We previously covered another aspect of this problem in Why Solana Holder Counts Differ.

2. Why Ordinary Pagination Didn't Scale

Our first implementation used getProgramAccounts with a memcmp filter on the mint.

This returns matching accounts in a single response. That works well for smaller datasets, but a token with a million accounts can produce an enormous response. Many RPC providers limit or disable this method for large mints.

We needed another way to retrieve the data.

Switching to the DAS API

Helius provides a paginated alternative through its Digital Asset Standard (DAS) API: getTokenAccounts.

It returns up to 1,000 accounts per request, including fields such as the owner, amount, and frozen status. We can also exclude zero-balance accounts.

Our initial implementation simply requested page 1, then page 2, then page 3, continuing until the list was exhausted.

const LIMIT = 1000;

for (let page = 1; ; page++) {
  const accounts = await getTokenAccounts({
    mint,
    page,
    limit: LIMIT,
  });

  addPage(accounts);

  if (accounts.length < LIMIT) {
    break;
  }
}

This is a simplified illustration of our original approach, not the complete production implementation.

It worked for smaller tokens. BONK exposed its limitations.

Through our production proxy, a request for page 60 took 12.8 seconds. Requests around page 200 and beyond timed out after 15 seconds because of an upstream database timeout. After we passed 500,000 accounts, the API refused the request and recommended cursor-based pagination.

The underlying problem was offset pagination.

To return page N, a database may have to walk past the rows that precede it. As the page number increases, the work can become more expensive.

With a million accounts, we're looking at more than 1,000 pages. If later pages take increasingly long to retrieve, the entire scan becomes impractical.

We needed a way to move through the dataset without repeatedly paying the cost of skipping records we'd already retrieved.

3. Switching to Keyset Pagination

Helius's getTokenAccounts supports a cursor parameter, along with after and before bounds on account addresses.

These let us use keyset pagination instead of relying on page numbers.

Rather than asking for page 500, we can ask for the next 1,000 accounts after a particular address.

The cost doesn't grow in the same way as offset pagination because we continue from a known position.

However, a cursor alone wouldn't solve everything. Each request would still depend on the previous one, since we need the previous page's final cursor before requesting the next page.

With more than 1,000 pages to process, we wanted to parallelize the scan.

The after and before parameters gave us another option: split the address space into independent ranges and scan them concurrently.

One important detail: address ordering

Solana addresses are represented as Base58 strings, but the API sorts addresses by their underlying 32 bytes.

Sorting the strings lexicographically doesn't necessarily produce the same order as sorting those bytes. If we built our range boundaries using string comparisons, we could introduce gaps or overlapping ranges.

We used PublicKey from @solana/web3.js to convert addresses into bytes and estimate their positions in the address space.

import { PublicKey } from "@solana/web3.js";

// Approximate position in the address space, from 0 to 1.
const position = (address) => {
  const b = new PublicKey(address).toBytes();

  return (
    b[0] / 256 +
    b[1] / 65536 +
    b[2] / 16777216 +
    b[3] / 4294967296
  );
};

// Build an address whose first byte is `byte`.
const edge = (byte) => {
  const b = new Uint8Array(32);
  b[0] = byte;

  return new PublicKey(b).toBase58();
};

The position function gives us an approximate location between zero and one based on the first four bytes.

The edge function constructs an address at a specific byte boundary.

Together, they provide the building blocks for dividing the address space into independently scannable ranges.

4. Estimating the Token's Size Before Scanning Everything

Before starting an expensive scan, we wanted to know whether a token had a few hundred accounts or several million.

The first page gives us a useful estimate without requiring another RPC call.

Associated token accounts are program-derived addresses generated using SHA-256, while many other accounts are random keypairs or addresses derived by other programs. In practice, their addresses are distributed across the address space well enough to make a rough estimate useful.

If the first 1,000 accounts reach a fraction (p) of the way through the address space, we estimate the total number of accounts as:

$$
\text{Estimated accounts} \approx \frac{1000}{p}
$$

Here's how we use the first page:

const LIMIT = 1000;

const first = await call({});
addPage(first);

if (first.length < LIMIT) {
  return;
}

const firstEnd = first.at(-1).address;
const firstPos = position(firstEnd);

const estimate = LIMIT / firstPos;

if (estimate > MAX_SCAN_ACCOUNTS * 1.1) {
  throw tooMany(estimate);
}

This estimate serves three purposes.

First, it lets us finish small scans immediately. Most tokens have fewer than 1,000 accounts, so we can return their results after a single request.

Second, it lets us reject oversized scans early. We set our limit at 1.5 million estimated accounts, roughly what we're willing to process in a browser tab. USDC has around 9.8 million token accounts, so we can identify it as too large after the first request instead of making users wait several minutes.

Third, it improves the progress indicator. We can compare the number of accounts retrieved against the estimated total instead of presenting the number fetched as though it were the final count.

The estimate isn't an exact count, and we never use it as a substitute for scanning the actual accounts. It's an early signal that helps us decide whether to continue and gives users a reasonable idea of how much work remains.

5. Splitting the Address Space Into 16 Lanes

With the range boundaries in place, we divided the address space into 16 lanes based on the first byte:

Lane 0: 0x00–0x0f
Lane 1: 0x10–0x1f
...
Lane 15: 0xf0–0xff

Each lane uses after to continue from the last address it retrieved and before to stay within its upper boundary.

Since the initial request already covered the beginning of the address space, lane 0 starts where that request ended.

Here's the core implementation:

const LANES = 16;

async function lane(i) {
  const lo = i / LANES;
  const hi = (i + 1) / LANES;

  // The first request has already covered this lane.
  if (firstPos >= hi) return;

  let after =
    firstPos > lo
      ? firstEnd
      : edge(i * (256 / LANES));

  const before =
    i === LANES - 1
      ? undefined
      : edge((i + 1) * (256 / LANES));

  for (;;) {
    const page = await call(
      before ? { after, before } : { after }
    );

    addPage(page);

    if (page.length < LIMIT) return;

    after = page.at(-1).address;
  }
}

await Promise.all(
  Array.from({ length: LANES }, (_, i) => lane(i))
);

Each lane processes its own range. The lanes run concurrently through Promise.all, while requests within an individual lane remain sequential because every request needs the previous page's final address.

The underlying RPC call is a thin wrapper around getTokenAccounts:

await rpcCall(endpoint, "getTokenAccounts", {
  mint,
  limit: 1000,
  displayOptions: {
    showZeroBalance: false,
  },
  ...range,
});

Because each lane covers a separate range, accounts shouldn't appear in multiple lanes. In our BONK run, we didn't see any duplicate accounts.

Parallelizing the scan solved the sequential-pagination bottleneck, but it introduced another problem: we could suddenly send many requests at once.

That brings us to rate limiting.

6. Managing a Rate Limit Shared With Other Users

Our 16 lanes could easily generate more requests than our Helius plan allowed.

We started receiving HTTP 429 responses at around 6–8 DAS calls per second. The limit was shared across everyone using the site, including our Telegram bot.

Letting a single large scan consume the entire request budget would affect other users, so we needed a rate limiter shared by all lanes rather than a separate limit for every worker.

An adaptive token bucket

We implemented a token bucket that:

Starts at eight requests per second.
Reduces the rate to 70% whenever a request receives a 429 response.
Increases the rate by 0.1 requests per second after each successful request.

This follows the general principle of additive-increase, multiplicative-decrease (AIMD), which is also used by TCP congestion-control algorithms.

Here's the core of the rate limiter:

function pacer(max) {
  let rate = max;
  let tokens = max;
  let last = Date.now();

  return {
    async take() {
      for (;;) {
        const now = Date.now();

        tokens = Math.min(
          max,
          tokens + ((now - last) / 1000) * rate
        );

        last = now;

        if (tokens >= 1) {
          tokens -= 1;
          return;
        }

        await sleep(((1 - tokens) / rate) * 1000);
      }
    },

    slower() {
      rate = Math.max(1, rate * 0.7);
      tokens = Math.min(tokens, 0);
    },

    faster() {
      rate = Math.min(max, rate + 0.1);
    },
  };
}

You might wonder why we kept 16 lanes when the rate limiter only allows around eight requests per second.

Because concurrency and throughput aren't the same thing.

A request might take a second or longer to return. Having enough work in flight helps ensure the limiter doesn't sit idle while waiting for a lane to become available.

Sixteen lanes kept requests ready without allowing them to bypass the shared rate limit. Adding more lanes would mostly create a longer queue.

Handling non-JSON error responses

We also ran into a smaller but important issue with HTTP 429 responses.

Our original code assumed every response contained JSON and called res.json() directly. The upstream rate-limit response was plain text, so JSON parsing failed before we could inspect the HTTP status.

We changed the response handling to read the body as text first and parse it only when possible:

const text = await res.text();

let j = null;

try {
  j = JSON.parse(text);
} catch {
  // Could be a plain-text 429 or an error page.
}

if (res.status === 429 || !j) {
  const e = new Error(
    res.status === 429
      ? "Rate limited"
      : `RPC returned ${res.status}`
  );

  e.code = res.status;
  throw e;
}

This lets the retry logic distinguish rate-limit responses from successful JSON responses and react accordingly.

Without this change, the code could fail while trying to parse the very response it needed to handle.

7. Putting a Timeout on Every Request

Another issue appeared during testing: fetch doesn't time out by default.

We had one request that stayed stuck for 300 seconds, holding its lane while the other 15 lanes finished their work.

Even with parallelism, a single request that never returns can keep the entire scan waiting.

We added an AbortController with a 25-second timeout to every request, along with exponential backoff and a maximum of eight attempts:

for (let attempt = 1; ; attempt += 1) {
  await pace.take();

  const ac = new AbortController();

  const timer = setTimeout(
    () => ac.abort(),
    25_000
  );

  try {
    const r = await rpcCall(
      endpoint,
      "getTokenAccounts",
      params,
      { signal: ac.signal }
    );

    pace.faster();

    return r?.token_accounts || [];
  } catch (e) {
    if (attempt >= 8) throw e;

    if (e.code === 429) {
      pace.slower();
    }

    await sleep(
      Math.min(8000, 400 * 2 ** attempt)
    );
  } finally {
    clearTimeout(timer);
  }
}

If a lane eventually fails after exhausting its retries, we set a shared stopped flag. The other lanes check that flag before making their next request and stop as well.

There's no point finishing a scan if we already know we can't produce a complete result. Cancelling the remaining work also avoids wasting the shared RPC budget.

8. Aggregating Results Without Keeping Every Account in Memory

Once the network side was under control, we looked at how we stored the results.

We didn't need to retain every raw page after processing it. All we needed was the total balance and the number of token accounts belonging to each owner.

So we folded each page directly into a Map keyed by owner.

const byOwner = new Map();

function add(owner, amount /* BigInt */) {
  if (amount <= 0n) return;

  const existing = byOwner.get(owner);

  if (existing) {
    existing.amount += amount;
    existing.accounts += 1;
  } else {
    byOwner.set(owner, {
      amount,
      accounts: 1,
    });
  }
}

This keeps the aggregated results instead of retaining an additional copy of the entire raw account list.

Why we used BigInt for token balances

The BigInt type is important here.

JavaScript numbers can't represent every integer exactly above Number.MAX_SAFE_INTEGER. Token balances can easily exceed that limit when expressed in raw base units.

BONK has five decimals and a supply of roughly 88 trillion tokens. Its raw supply is:

8,799,435,602,096,182,068

That's about 977 times Number.MAX_SAFE_INTEGER.

If we added large balances using ordinary JavaScript numbers, lower digits could silently disappear and produce incorrect totals.

We therefore keep raw amounts as BigInt throughout aggregation and convert them into display-friendly numbers only at the end, when preparing each owner's balance for presentation.

The principle is simple: preserve exact integer arithmetic during the part of the pipeline where accuracy matters most.

9. Classifying Wallets and Program-Owned Addresses

The largest holder of a token isn't necessarily a person.

It might be a liquidity pool, a launch curve, a token lock, or another program.

Many of these accounts are represented by program-derived addresses (PDAs). These addresses are deliberately derived so they don't lie on the Ed25519 curve, meaning they don't have a corresponding private key that someone can use to sign transactions directly.

Solana's PublicKey.isOnCurve method lets us distinguish on-curve addresses from off-curve ones.

The problem is that running this check a million times is expensive.

In our measurements, each check took around 57 microseconds. Multiply that by a million addresses, and you're looking at nearly a minute of CPU time.

Running all of that on the main thread freezes the page, even after the network requests have finished.

Moving CPU-heavy work into Web Workers

We moved this work into Web Workers once the list exceeds 20,000 owners.

The implementation uses the available hardware concurrency, reserves a core where possible, and caps the worker count at eight:

export async function onCurveFlags(addrs) {
  if (
    addrs.length < 20_000 ||
    typeof Worker === "undefined"
  ) {
    return onMainThread(addrs);
  }

  const n = Math.min(
    8,
    Math.max(1, (navigator.hardwareConcurrency || 4) - 1)
  );

  const size = Math.ceil(addrs.length / n);
  const slices = [];

  for (let i = 0; i < addrs.length; i += size) {
    slices.push(addrs.slice(i, i + size));
  }

  // Fall back to the main thread if a worker fails.
  const parts = await Promise.all(
    slices.map((s) =>
      inWorker(s).catch(() => onMainThread(s))
    )
  );

  const flags = new Uint8Array(addrs.length);

  let at = 0;

  for (const p of parts) {
    flags.set(p, at);
    at += p.length;
  }

  return flags;
}

Each worker decodes Base58 addresses and uses @noble/curves directly, then transfers its Uint8Array back to the main thread.

For smaller lists, or browsers without worker support, we use the main-thread implementation and yield every 2,000 checks so the browser can continue painting and responding to user input.

Once we've identified off-curve owners, we make getMultipleAccounts calls in batches of 100 to identify the programs behind them.

This lets us label accounts such as Raydium pools, pump.fun bonding curves, token locks, and multisigs instead of presenting every address as an ordinary wallet.

10. The Results

We tested the finished implementation against BONK on October 13, 2026, using headless Chromium and our production build.

Here's what the scan returned:

Metric	Result
Token accounts with a balance	Approximately 1.025 million
Distinct owners	1,020,085
Wallet addresses	1,006,273
Program-owned addresses	13,812
`getTokenAccounts` calls	Approximately 1,110
Total scan time	3 minutes, 44 seconds
Worker count for classification	7
Duplicate accounts observed	0
Page errors	0

At a steady rate of eight requests per second, 1,110 calls would take roughly 2 minutes and 19 seconds.

The remaining time came from rate-limit backoffs against the shared request budget and the work required to classify and label the owners.

For RPC providers that don't support the DAS method, the scanner has fallback paths: Helius's paginated getProgramAccountsV2, followed by the standard RPC method getParsedProgramAccounts.

These alternatives have their own limitations, but they let us support providers with different capabilities rather than making the entire tool depend on a single API.

11. What We'd Do Differently Next Time

The biggest lesson is that a solution that works for a few thousand accounts doesn't necessarily scale to a million.

Our original pagination strategy was perfectly reasonable for small lists, but its cost grew with the size of the dataset. If a list can reach hundreds of thousands of records, we'd look for keyset pagination from the start and verify the ordering of the underlying keys before designing parallel ranges.

We'd also estimate the workload before committing to it.

The first page gave us enough information to decide whether a scan was worth attempting, reject oversized tokens early, and display a more useful progress estimate.

On the networking side, we learned to pace requests against the shared API budget rather than setting an independent concurrency limit for every worker. A fixed concurrency limit can either leave capacity unused or overwhelm the provider. An adaptive rate limiter gives us a better way to respond to changing conditions.

Finally, network performance isn't the whole story when the work runs in a browser.

Every fetch needs a timeout. Retries need sensible limits. CPU-heavy operations need to move off the main thread when the dataset gets large enough.

And using BigInt for raw token balances was equally important: a fast scan isn't useful if the numbers it returns aren't exact.

Try It Yourself

The Holder Snapshot tool is part of Solstack, our collection of Solana token tools.

Paste a mint address to start a scan. The scan and first 200 rows are free.

If you've worked on large paginated datasets, RPC rate limiting, or browser-side data processing, we'd be interested to hear how you approached similar problems. Feel free to leave questions or feedback in the comments.