Feature release: Batched Claim and Swap

Scaling user transactions for a growing platform

Daniel Park · Lead Engineer

Hi, I'm Daniel, a former Google engineer now at Nook helping build out infrastructure to support Nook's growing user base. In this post, I'll be talking about how we took one of our most beloved features and made it more robust.

What is Claim and Swap?

One of the features that makes Nook stand out from other DeFi earning apps is our claim and swap feature. We claim rewards from all lending pools, swap them into USDC, and redeem them, allowing these earnings to gain interest as well.

A compounding effect leading to more gains for our users.

Doing this for each user takes time. Once we finish doing it for one user, we proceed to do it for the next – a synchronous process. With the number of users we have, we effectively have a long line of users, each waiting their turn to claim their rewards. The duration of the entire process is directly correlated to the number of users. Eventually, the time needed to process all users will be greater than the time between claim and swap runs. This consecutive process is unscalable and unsustainable.

To remediate this, we broke down the entire process into steps and implemented a worker-based system. In this architecture, each step is handled by a specialized worker.

How it works

These are the steps:

Step 1: Look for users that have rewards

Step 2: Filter for rewards with values over a threshold

Step 3: Claim the rewards in the form of reward tokens

Step 4: Swap the rewards from the reward token to USDC

Step 5: Deposit the rewards into the user’s protocol

Each worker specializes in doing its own step and hands off the next task to the next worker, which does its own step. If we were to use an analogy with making a burrito bowl, the old system was one bowl maker making the entire bowl from start to finish before starting the next one; the new system is an assembly line with multiple makers, each responsible for their part of their burrito bowl as the bowl passes through (think of a busy Chipotle).

This worker architecture also grants the advantage of parallelism. As long as we add more workers, we can simultaneously do more of that step; the amount of work we do per step is directly proportional to the number of workers (unfortunately, because of nonce requirements, where transaction x has to be present before transaction x+1, we can not do the claiming step in parallel).

We also implemented batching in the claiming step for the chains that support them and also for the swapping step for users. The gas cost to batch claiming is significantly less than claiming rewards individually, and the same can be said for swapping – swapping all the tokens for each user costs significantly less than making one swap call for each token.

Scaling Nook

In addition to the speed and cost benefits, this system is also more robust. If something went wrong in the old system, we’d have to restart from the beginning. Imagine playing Mario without a save file. If the game crashes or the power cuts off or anything else goes wrong before you finish, you’re back at the beginning (for my millennials, this is the equivalent of downloading a file on dial-up and having it cancelled because someone picked up the telephone).

Terrible if one step from the finish line. With this system, you’re adding save files; the system knows which step the process failed in and resuming it is as simple as handing off a job to the worker for that step. No more going through early stages just to get to the one you need to.

In short, batching claim and swap turns a slow, sequential process into a scalable pipeline. By splitting the flow into specialized workers, adding parallelism, batching expensive operations, and preserving progress between steps, Nook can process users faster, spend less on gas, and recover from failures without starting over.

This makes the claim and swap system more efficient today and more capable of handling the growth that we see today.

As Nook scales, it’s important to make sure the infrastructure behind it can handle the increased workload.