Lambda is one of the latest teams building with SQD, with the partnership already covering live use of SQD Cloud Portal, SQD Pipes and participation in our new Revenue Pool model.
In this first article, we're looking at why Lambda chose SQD, what they needed from their data stack, and how the partnership is helping support the next phase of their product.
Who Lambda is
Lambda provides portfolio tracking infrastructure and APIs for customers who need accurate balance calculations across chains. Its product is built around helping users optimise Web3 portfolios with DeFi yield and PnL data, serving customers including wallets, funds, data providers, and internal teams.
A core part of that work is balance calculation using event logs from SQD Portal.
The problem, and why Lambda chose SQD
As Lambda began discussions with SQD, two priorities became clear.
The first was cost. They needed predictable costs as usage scaled.
The second was control. Lambda wanted more direct control over infrastructure and data ingestion so they could manage costs more deliberately and shape the system around their own requirements.
With real-time freshness, cost predictability, and chain coverage all important requirements, SQD stood out as a strong fit.
Integration
Lambda migrated to SQD Pipes to build a setup that gives them more flexibility and control over how blockchain data moves through their system.
Using the SQD Pipes SDK inside its custom SQD exporter component, the team can build source filters, transform data, and choose different targets, with ClickHouse used by default.
As Lambda described it, SQD Pipes offers:
"A convenient SDK for working with the portal product, particularly for real-time data" along with "good architecture and a convenient DSL-like approach for describing the data pipeline."
For Lambda, this matters because their core workflow depends on taking an initial state at a given timestamp, selecting relevant event logs across chains, and using that data to calculate balances and related metrics for clients. With real-time access to data named as one of their top requirements, having a setup built around that workflow was important from the start.
What's next for Lambda
One of the next areas Lambda is designing for is new pool detection. Lambda wants to automate how quickly it can scale metrics coverage using event-driven signals from SQD, reducing manual setup as new pools appear.
Longer term, Lambda's goal is to become an industry standard for NAV calculations. As that vision develops, broader chain coverage and more automation across the data layer will matter even more.
In the nearer term, Lambda wants to expand to more chains, simplify the backfill procedure, and see further progress around SQD Pipes GA and supporting examples. That makes this early phase with SQD important not just as an integration, but as the foundation for what Lambda wants to build next.
Why this is Part 1
This article is about the foundation.
It covers why Lambda chose SQD, how the setup fits their workflow, and what this partnership is making possible at an early stage.
Part 2 will look at performance benchmarks, workflow improvements, and broader impact once the system has had more time in production.
Follow @Lambda_DeFi on X to stay up to date on the latest developments.