How Decimal put every lender on its no-code canvas with one integration instead of dozens
Decimal is a no-code automation platform for Web3: drag, drop, and let a workflow run on autopilot. To put lending markets on that canvas, it could have written an adapter per protocol per chain. Instead it integrated the 1delta API, putting 121 lenders and ~3,000 markets behind one node. Their report: an excellent developer experience, with hands-on support from the 1delta team.
At a glance
- Partner: Decimal, a no-code automation platform for Web3 ("drag, drop, and let it run on autopilot"), with 100+ integrations across Ethereum, Arbitrum, Polygon, Base and more.
- Challenge: put lending markets on a drag-and-drop canvas, without building and forever-maintaining a separate adapter for every protocol on every chain.
- Approach: integrate the 1delta API (one normalized REST surface over every major lending protocol) as a single workflow node, instead of hand-rolling per-protocol code.
- Result: cross-protocol lending shipped as one node that exposes every lending market 1delta aggregates across six chains (Ethereum, Base, Arbitrum, Optimism, Avalanche and Gnosis): 121 lenders fanning out to ~3,000 markets, loaded live from the pools API. Built by hand it would have meant 121 protocol adapters to reach the same coverage, each then maintained forever. Their report: an excellent developer experience, backed by hands-on collaboration from 1delta's team through testing, edge cases, and output-shape tweaks.
- Timeframe: ~10-14 days of development, plus a further 2 weeks of testing.
The challenge
Decimal's product is a visual workflow builder: a non-developer wires a trigger to a chain of actions (a price alert, a recurring swap, a treasury rebalance) and lets it run, with no Solidity and no backend of their own. The platform's value is the breadth of blocks on that canvas.
Lending is where that breadth gets expensive. "Move my idle USDC to the best deposit rate" sounds like one workflow step. Underneath it's a fragmentation problem: dozens of lenders, each with its own contracts, its own rate encoding, and its own definition of a position, multiplied by every chain. To put lending on a drag-and-drop canvas, Decimal needed all of that to collapse into one clean building block a non-developer could drop in and trust.
The real obstacle was maintenance, not the first version. Hand-rolling lenders is never done: every protocol becomes a node to document and keep alive as those protocols ship breaking changes, and the moment one does (Aave's V3.2 re-encoding of eModes mid-life is a real example), every workflow built on the old shape silently breaks. For a platform whose promise is "set it and forget it," a data layer that quietly drifts is the worst kind of liability.
The approach
Decimal integrated the 1delta API as that single building block. From the platform's side it's one normalized surface over plain HTTPS with one x-api-key header: no nodes to run, no ABIs to track. Two endpoint families cover almost everything a lending workflow needs:
| Endpoint | What it returns |
|---|---|
/v1/data/lending/pools · /lending/latest | Every market on a chain: depositRate, variableBorrowRate, totalLiquidityUsd, collateral/borrow flags, and a stable marketUid like AAVE_V3:42161:0x… |
/v1/data/lending/user-positions | A wallet's positions across every indexed lender: per-token deposits and debt in USD, plus a per-lender health factor |
The decisive property: every record comes back in the same shape, whichever protocol it came from. Aave, a Compound V3 comet, a Morpho Blue market, a Silo vault: all surface as the same pool object and the same position object. (The unifying-Aave article shows how far that goes: even three generations of one protocol land in one record.) So a workflow node can render a rate or read a health factor without a single line that branches on "which protocol is this."
Two properties of that surface directly answer the challenge:
- The hard parts live behind the API. Encoding
eth_calls across a dozen ABIs, decoding fixed-point rate formats, scaling raw balances by token decimals, fetching oracle prices for USD values: none of it landed in Decimal's codebase. That is why integrating was easy: parse one pool object and you've parsed them all, and a normalized REST response (inputs → request → typed outputs) already is the shape of a no-code block. In Decimal's words, "the documentation got us up and running quickly." - Maintenance is upstream. When a protocol ships a breaking change, the normalization absorbs it on the API side; the node and the workflows on top of it don't move. The standing liability that made the build-it-yourself path expensive simply isn't Decimal's to carry, which is the bulk of the time saved.
The results
Decimal summed up the integration in its own words:
The developer experience with 1delta was excellent. The documentation got us up and running quickly, but what really stood out was the team's willingness to collaborate. They helped us validate our integration during testing, were responsive whenever we ran into edge cases, and even accommodated changes to the output structure to better align with Decimal's automation engine. It's rare to see that level of technical support from an infrastructure team.
— Abhijat, CEO & Founder, Decimal
That shows up in the timeline: Decimal built the integration in roughly 10-14 days, followed by a further two weeks of testing (the phase where 1delta's team helped validate the integration and worked through edge cases). Concretely, the speed comes from the work that didn't have to be built, each row a project a from-scratch integration pays for, and keeps paying for:
| Work the API absorbs | Building it yourself |
|---|---|
| Protocol adapters | A bespoke integration per lender, then again per chain |
| Rate normalization | Converting each protocol's fixed-point rate encoding into one comparable APR |
| Amount scaling | Scaling every raw balance by token decimals, into USD |
| Positions & health | Re-deriving each lender's account data and health-factor definition into one shape |
| Ongoing maintenance | Tracking breaking changes (like Aave V3.2 re-encoding eModes mid-life) so workflows don't silently break |
That last row is the one that compounds. A hand-rolled integration is a standing liability that grows with every protocol and every upgrade; a normalized dependency is kept current upstream, so the next chain or lender on Decimal's canvas costs them nothing.
The scale behind "one node" makes the trade concrete. Across the six chains, the pools API exposes 121 lenders (each one an adapter Decimal would otherwise have written and owned), and those lenders fan out to roughly 3,000 individual markets:
| Chain | Lenders (= adapters avoided) | Markets covered |
|---|---|---|
| Ethereum | 44 | 1,708 |
| Base | 25 | 570 |
| Arbitrum | 25 | 399 |
| Optimism | 14 | 18 |
| Avalanche | 8 | 308 |
| Gnosis | 5 | 4 |
| Total | 121 | ~3,000 |
The leverage is the gap between those two columns. A single adapter can expose one market or hundreds: one Euler deployment on Ethereum surfaces 862 markets, while an Aave V3 pool surfaces one. Building in-house, Decimal would have written and maintained all 121 adapters to reach ~3,000 markets, re-deriving each protocol's rate math, decimals, and health-factor definition along the way. Through the node it's a dropdown.
The user-facing result is that a cross-protocol lending strategy is now a handful of draggable blocks. A "park idle stablecoins at the best rate" workflow reads end to end like this:
The read block is the only one that touches DeFi data, and it speaks to one API. The condition compares APYs that are already in the same unit; the action moves funds to the winning marketUid without caring whether it's an Aave market on Base or a Morpho market on Arbitrum. Months of adapter work show up as one node with a dropdown.
Why it worked
Decimal's value is the canvas: the triggers, conditions, no-code ergonomics, multi-chain execution. Cross-protocol lending data is essential underneath that, but it's not where Decimal wins or loses; it's undifferentiated work every consumer of it needs identically. Handing it to a normalized API let the team spend its time on the canvas instead of on adapters, and not inherit a maintenance burden that grows with every protocol and every upgrade.
It helped that the data layer came with a team, not just an endpoint. 1delta "helped us validate our integration during testing, were responsive whenever we ran into edge cases, and even accommodated changes to the output structure to better align with Decimal's automation engine", the kind of hands-on support that turns a dependency into a partnership. As Decimal put it, "it's rare to see that level of technical support from an infrastructure team."
That's the transferable lesson: if your product needs lending data and isn't in the business of being a lending-data layer, the same trade is on offer. The fast start is the uniform shape and single auth header; the saved time is every adapter, rate conversion, and future breaking change that never reaches your backlog.
Where to go next
- Decimal: the no-code Web3 automation platform this case study is about.
- API reference: the
/v1/data/lending/*endpoints andx-api-keysetup Decimal integrated against. Start with a key and the/lending/poolsendpoint. - Docs site: supported protocols, network coverage, and the rest of this series.