Is yield discovery on Stacks a real pain point, or are we imagining one?

Hi everyone,

I’m Achim from 1delta.io. We’ve spent two years building yield and lending aggregation APIs on EVM chains - unified rates, positions, and execution across Aave, Compound, Morpho, and others. Originally backed by Aave and Compound grants. Used by dApps, AI protocols, funds, and builders who don’t want to integrate ten lending protocols one-by-one.

The Q1 2026 Stacks numbers pulled us in close enough to ask whether there’s a real product gap here. This post is us trying to figure out whether the gap we think we see is one the ecosystem actually feels - or whether we’re projecting EVM patterns onto a chain with different dynamics. Honest pushback is more useful than polite encouragement.

What we observe

At least five protocols offer something that looks like “yield on your assets”: Zest, Granite, StackingDAO, LISA, Hermetica. Bitflow sits underneath as the DEX layer. Each does something specific well, and the design philosophies vary meaningfully - Granite’s no-rehypothecation isolation is genuinely different from Zest’s Aave-lineage pools, and stSTXbtc’s BTC-streamed rewards don’t exist on any EVM chain.

From outside, what looks fragmented is the discovery and management layer on top, not the protocols themselves. A user with sBTC reads the Foundation’s yield guide, then opens four browser tabs. A user with positions on Zest and Granite checks two apps for total exposure. A wallet team integrating yield does five separate integrations.

On EVM, that gap gets filled by aggregators - Yearn, DeFiLlama Yields, Morpho Vaults, routing APIs like ours. On Stacks, that layer doesn’t really exist yet.

Our working hypothesis: a unified read API (rates, positions, health factors across all five protocols) plus a simple write API (deposit, withdraw, basic BTC-collateralized borrow) would be useful.

What we are not sure about

1. Is fragmentation actually felt by users, or are we overweighting it? TVL is whale-concentrated. Maybe current users are sophisticated enough that five tabs isn’t pain. Or maybe the next wave will hit it hard.

2. Wallet teams - would this change your roadmap? Today users leave your wallet to use Zest/Granite. Would a unified API change how you think about in-wallet earn UX, or is the per-protocol model working fine?

3. Protocol teams - competitive or complementary? Would an aggregation layer reach users you don’t reach today, or does it commoditize you in a way that hurts? We’ve seen both reactions on EVM.

4. What Stacks-unique primitives need first-class API treatment? stSTXbtc reward streaming, Dual Stacking BTC APYs, soft liquidations, sBTC peg dynamics - these don’t map onto EVM yield abstractions. Surface them distinctly, or abstract into generic “APY + risk”?

What this post is, and isn’t

Not an announcement. No engineering allocated, no launch date. If the community thinks this is a solution looking for a problem, we’d rather hear it now than after a quarter of Clarity work.

If signal is strong, we’ll come back with a concrete scoping post. If it’s weak, that’s a real outcome too - we’ll publish what we learned for whoever comes next.

Reply here, DM me, or reach me at [email protected].

- Achim, 1delta

This thread landed at exactly the right moment. I’ve spent the past few weeks running user conversations with active sBTC and STX holders specifically around this problem — asking how people currently decide where to deploy.

What I’m hearing confirms your framing: most people either follow a protocol’s own Twitter, check the Stacks Foundation’s yield overview, or just pick one protocol and stick with it out of inertia. Nobody has a systematic way to compare outcomes across Zest, Hermetica, Bitflow, and the rest simultaneously.

One thing that keeps coming up that your post didn’t mention: the confusion isn’t just “where is the highest APY?” It’s the risk layer — people genuinely can’t tell whether 12% from Hermetica is better or worse than 3.5% from Zest once you factor in strategy complexity and smart contract exposure. The protocols all publish APYs; nobody publishes a simple risk-adjusted ranking.

I’m building something in this space — user-facing rather than an API layer (which sounds like your lane). The approach is a simple ranking UI where users toggle which risk dimensions they care about and get a clear signal. Happy to share what I’ve been hearing from users if it helps the signal-gathering goal of this thread — and curious whether you’re seeing the same fragmentation pain from the builder/integration side.

1 Like

There is also https://www.bitcoinyield.com for discovery

1 Like

Indeed, there are quite a few sites that list the yield options.

They all share that same problem - they are just aggregating links to the providers and do not provide execution details.

We envision that we’d have an API that

  • provides the yield and protocol data - that is the easy part, they already do this
  • execution-relevant data - here we need to see whether there are time-locks for redemption, additional fees, validator addresses required for inputs etc.
  • execution data - we will produce the transaction data so that anyone can just execute deposits and redemptions with the API - allowing integrators to create a unified BTC yield farming experience - where users see their current net APR, all their deposit balances and more in one place

This way, projects can have a full e2e integration of BTC yield and can keep the users in their app rather than sending them to third party websites