Repository navigation
/basket averages prices quoted in different currencies #174
Description
Background
src/routes/basket.ts:4-16's fetchAssetVWAP(asset) runs WHERE (asset_a = $1 OR asset_b = $1) over price_points and volume-weights every matching row into one number. But price in that table is denominated in whatever the other leg was: src/ingesters/sdex.ts:41-43 stores XLM/USDC as USDC-per-XLM and XLM/EURC as EURC-per-XLM. Averaging them produces a figure in no currency at all.
Two more problems in the same six lines: asset_a/asset_b store only the code, so every issuer's "USDC" is conflated — the exact failure src/api/rest.ts:24-37 documents and guards against for /price — and the row's price is inverted for half the pairs depending on which side the asset sits on.
Adding a network predicate (#157) does not touch any of this.
Acceptance criteria
-
/baskettakes an explicit quote asset, or restricts to pairs sharing one, and documents which - Prices are inverted when the requested asset is the counter side, so all components share a unit and a direction
- Asset matching honours a supplied issuer, reusing the
findPairsemantics rather than matching on bare code - An asset with no price in the chosen quote returns 404 naming it, rather than a silently mixed number
- A test with two pairs sharing a base but different quotes asserts they are no longer pooled — fails before
Drips Wave · Complexity: Intermediate · 150 points
The shape of the problem
Lens aggregates SDEX trades and AMM pool prices into VWAP, OHLCV and best-route data. It is in good shape on the surface — 47 test files, 401 passing tests, a clean typecheck, changesets, OpenAPI publishing, Prometheus metrics.
Underneath it is two codebases wearing one coat. Everything written since the dual-network work (#113–#118) is network-aware. Everything written before it silently pools testnet and mainnet: exactly one of roughly twenty data-reading modules filters by network. Several issues below are that seam.
State of main before you start
Verified on 2026-09-24: npx tsc --noEmit exits 0, and npx vitest run gives 400 passed, 1 skipped, green across seven consecutive runs.
So two open issues are stale and should not scare you off:
- Fix broken @stellar/stellar-sdk vitest mock — makes every PR look red #146 ("broken
@stellar/stellar-sdkvitest mock makes every PR look red") does not reproduce onmain. - Flaky test suite: auth.test.ts and pairs.test.ts fail intermittently (~1 in 5 runs) #151 ("flaky suite, fails ~1 in 5") did not reproduce in seven runs. The underlying hazard is real though:
src/config.ts:245-253memoises eachNetworkConfigin a module-levelMapon first access, so whichever test file imports first freezesprocess.envfor every other file.
#113 ("restructure config.ts into a per-network map") is already fully implemented at src/config.ts:97-315.
Ground rules
- Every PR needs a test that fails before the change and passes after, unless the issue says otherwise.
- A price with the wrong units, the wrong network or the wrong timestamp is worse than no price. Prefer refusing to answer over answering confidently.
- Don't widen a Prometheus label to something unbounded. Pairs and networks are fine; issuers and pool ids are not.
- Don't reformat a file you're changing.
Required: Before submitting, join the contributor Telegram so your work can be tracked and counted toward the Stellar Wave: https://t.me/+fxHXq8f1SwlkZDBk
Activity
mubby4 commentedon Sep 24, 2026
@mubby4 has applied to work on this issue as part of the Stellar Wave Program's 9th wave.
ℹ️ Repo Maintainers: To accept this application, review their application or assign @mubby4 to this issue.
drips-wave commentedon Sep 26, 2026
Congratulations, @mubby4! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on September 30, 2026.
🧑💻 @mubby4: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.
Warning
When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.
🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.
🌊 Happy Wave 🌊
Miracle656 commentedon Oct 16, 2026
@mubby4 — a heads up, and an ask. Do not worry: this issue is yours and your PR #181 is safe.
The situation: this issue was assigned to you on GitHub outside the Drips Wave. The Wave will not accept an already-assigned issue, so as things stand, when #181 merges you close a Wave-eligible issue and earn nothing for it. I want to fix that before I merge, not after.
The fix needs a brief handover: I unassign you on GitHub, add the issue to the Wave, you apply on Drips, I approve it, and it comes straight back to you.
The ask: reply here when you are at a keyboard and ready to apply within a few minutes. I will then do the unassign and the add, and you apply immediately.
I am asking rather than just doing it because I tried the other order on #147 an hour ago — unassigned first, then waited — and two other contributors applied inside that window before the original author saw the notice. Nobody lost anything, but only because I caught it. Your work is already written and I am not putting it through that gap.
If you would rather not bother with the Drips side at all, say so and I will simply review and merge #181 as it stands. You would not be paid for it through the Wave, which is why I would rather we did this properly, but it is your call and either is fine.
Miracle656 commentedon Oct 16, 2026
Do not apply for this issue and do not start work on it. Any application will be declined.
This issue is the subject of open PR #181 by @mubby4, which is complete and in my review queue. It appears unassigned only because of a mechanical problem on my side: it was assigned on GitHub outside the Drips Wave, the Wave refuses an already-assigned issue, and that would have meant @mubby4 earning nothing when their PR merged. Unassigning is the only way to add it to the Wave so they can be paid for work they have already done.
@mubby4 — apply on Drips whenever you see this and I will approve it immediately. There is no deadline and no race; this issue is being held for you. If anyone else applies in the meantime they will be declined with an explanation.
If you would rather skip the Drips step entirely, say so and I will just review and merge #181 as it stands.
Looking for something to work on? These are genuinely unclaimed in this repo right now: #286 (impermanent loss, 200), #284 (DeFi TVL endpoint, 150), #84 (liquidity depth & slippage, 200), #81 (staleness-aware median pricing, 200). More are published continuously — watch the
Stellar Wavelabel rather than racing for the last few.Devadakene commentedon Oct 19, 2026
@Devadakene has applied to work on this issue as part of the Stellar Wave Program's 10th wave.
ℹ️ Repo Maintainers: To accept this application, review their application or assign @Devadakene to this issue.