[onajidavid87-web]

Summary

Adds rate and pool state ingestion for Stellar's lending protocol (Blend):

• Rate Ingestion: Ingests each Blend pool's reserves, derived utilisation, supply APY, and borrow APY on a schedule per enabled network.
• Dedicated Schema & Retention: Stores rates in a new lending_rates table via Prisma migration (rather than forcing into price_points), with a 30-day retention prune job.
• Derived Utilisation: Utilisation is derived from liabilities and supply (calcUtilization), with edge cases ($U \le 0$, $U \ge 1$, BigInt scaling) pinned by unit tests.
• Fault Isolation: Failed pool reads are skipped gracefully with a log and blend_pool_errors_total metric increment, preventing process crashes.
• Dual-Network Isolation: Every row explicitly carries its network (mainnet or testnet) without cross-contamination.
• Contract Addresses: Full 56-character pool and backstop addresses verified against Blend documentation.
• API & OpenAPI: Added GET /rates and GET /rates/:asset endpoints returning venue: 'blend', documented in openapi.yaml and synced to openapi.json.

Related issue

Type of change

• Bug fix
• New feature
• Refactor
• Docs
• Tests
• CI / tooling

Checklist

• I have read CONTRIBUTING.md
• npx tsc --noEmit passes
• npm run build passes
• I added / updated tests where relevant
• I updated docs where relevant

Closes #212

[drips-wave]

@onajidavid87-web Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[Miracle656]

Needs a rebase. I tried to resolve this myself and stopped, because the conflicts are not the mechanical kind and guessing at them in config for a money-adjacent feature is not a trade I want to make.

What conflicts: .env.example (4 hunks), src/config.ts (3), src/index.ts (3), src/app.ts (2), prisma/schema.prisma (1), plus the two generated OpenAPI files.

Why keep-both does not work here. The config.ts hunks cut through object literals rather than between them. main adds a publisher: { block for the SEP-40 publisher; this PR adds a blend: { block. Both open a property inside the same object, and both closing braces fall outside the conflict region — so concatenating the two sides leaves one block unclosed:

src/config.ts(89,1):  error TS1131: Property or signature expected
src/config.ts(593,1): error TS1005: '}' expected
src/index.ts(308,3):  error TS1005: '}' expected

Resolving that correctly means knowing which block each tail brace belongs to, thirteen times. You have that in your head; I would be inferring it.

One thing I did find while trying: keeping both sides of .env.example produces a duplicate MCP_MAX_PAYMENT_PRICE= — there is a terse copy and a documented one. Keep the documented block when you rebase.

The work itself is wanted, and the timing is good. Blend lending rates are what the earn surface quotes, and a rate we compute from pool state rather than take on trust is the difference between a number we can defend and one we repeat. The shape looks right from the file list — a real migration, retention for the rate history, metrics, and tests for the ingester, the utilisation maths, retention and the route.

After rebasing, three things this repo will check and that have caught PRs today:

• console.* is forbidden in non-test source; use createLogger
• src/__tests__/envDrift.test.ts fails if a new process.env read is missing from .env.example — and it now covers scripts/ and examples/ too
• tests/openapi.test.ts fails if a route is documented but not registered, or registered but not documented

Get npx tsc --noEmit and npx vitest run clean locally and I will take it.

[Miracle656]

Merged as 4dc40a3 — this closes #212.

Nearly 2,000 lines on a path that writes to the money database, and it arrived with five test files, a migration, env documentation and the retention job already wired into src/index.ts. Four things I want to name specifically, because they are the ones that usually go wrong:

The schema change came with a migration. 20261023130000_extend_lending_rates_for_blend/migration.sql, not a bare schema.prisma edit. That matters more than it did last week: since migrate deploy replaced db push this morning, a schema edit on its own reaches no live database — the column simply never exists, every write fails, and the feature looks implemented. The migration is additive (every column nullable), leaves the baseline untouched, sorts after 0_init, and its index leads with network. The first PR today to need this workflow got it wrong; yours did not.

Lending rates go in their own table. derive returning [] with the comment "Blend rates are stored in lending_rates, not price_points" is the right call and the right place to say it. A supply APR is not a spot price, and letting it into price_points would quietly contaminate VWAP, the volume totals and the screener.

ingestBlendPools takes an injectable ingestPool, which is why blendIngester.test.ts can drive the sweep without a Soroban RPC.

New env vars are in .env.example and the envDrift allow-list. That test exists because a config change that works on the author's machine and nowhere else is a specific recurring failure here.

Three changes on top.

1. classification was missing

#455 landed about ten minutes before this and made classification a required field on VenueAdapter, so the merge did not compile:

src/ingest/venues/blend.ts(556,14): error TS2741: Property 'classification' is missing

Pure bad luck on ordering, not a defect. Set to 'primary', with a comment recording that it is informational here — Blend emits no price points, so it never reaches the net/gross split — and that 'primary' is still the honest value because Blend holds its own reserves: it is the venue a DeFindex vault allocates into, not one re-reporting another venue's trades.

I also added it to VENUE_CLASSIFICATIONS, which the drift test I added to #455 requires. That guard caught the very next adapter to arrive, which is about as good a demonstration of its worth as I could ask for.

2. The ingester loop had no upper bound

while (true) {
  try {
    await ingestBlendPools(network)

Blend runs outside startVenueAdapterLoop — reasonably, since it writes lending_rates and the generic derive/write cycle does not fit — but that also means it missed the per-cycle deadline #471 added this afternoon. And this is exactly the #351 shape: a slow Soroban RPC stretches one sweep indefinitely, the loop never crashes, so restartIngester never fires, and Blend goes quiet with nothing raised anywhere. It is the failure mode that is hardest to notice because there is no error to notice.

Wrapped in runCycleWithDeadline, the same treatment #471 gave the other bespoke ingester (src/ingesters/snapshot.ts), and ingestBlendPools now takes the signal so an abandoned cycle stops at a pool boundary rather than only at the end of the sweep — one pool is one write unit, so nothing is left half-written:

for (const poolId of netConfig.blend.pools) {
  if (signal?.aborted) break

Worth knowing as a general rule now: a bespoke ingester needs runCycleWithDeadline explicitly, because only startVenueAdapterLoop applies it for you.

3. Generated client

clients/typescript/src/schema.d.ts regenerated for the new /rates response shape — byte-compared in CI.

---

One note rather than a request: blendAdapter is exported but deliberately not in venueAdapters, so Blend will not appear in the README's generated venue table. That is defensible — the table describes price venues and Blend is not one — but if more non-price venues arrive it is worth deciding whether the table should grow a section rather than silently omit them.

134 test files / 1,603 tests pass; tsc --noEmit clean.