feat: Filter gainer/upcoming assets

[JohnnyWyles]

What is the purpose of the change:

Hide upcoming assets section when only vague launch dates exist.
Filter the top gainers to:

• Only show assets with significant liquidity (>1k)
• Hide stablecoins as they are dominant during red days
• Hide asset variants as BTC, for example, fills the entire table.

Linear Task

https://linear.app/osmosis/issue/FE-1283/filter-top-gainers
https://linear.app/osmosis/issue/FE-1466/hide-upcoming-assets-when-no-assets-have-a-date

Testing and Verifying

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
osmosis-frontend	Ready	Preview	Comment	Dec 8, 2025 0:06am

4 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
osmosis-frontend-datadog	Ignored			Dec 8, 2025 0:06am
osmosis-frontend-dev	Ignored			Dec 8, 2025 0:06am
osmosis-frontend-edgenet	Ignored			Dec 8, 2025 0:06am
osmosis-testnet	Ignored			Dec 8, 2025 0:06am

[JohnnyWyles]

Should be ok, but before marking as ready, testing during:

• Red day
• When an alloy is a top gainer

[JohnnyWyles]

DYM is a top gainer and DYM.dym is filtered from the overall display.
Need to also filter this from the assetlist once the category is clicked.

Also concerns about speed of loading.

[coderabbitai]

Walkthrough

New optional filters—excludeVariants, excludeStablecoins, and minLiquidity—are added to market asset queries. The backend mapGetMarketAssets function implements variant and stablecoin filtering logic and updates liquidity thresholds. The tRPC assets endpoint extends its input schema and propagates these filters. The frontend applies specific filter combinations (all three enabled with minLiquidity=1000) for the topGainers category and adds conditional rendering for upcoming assets with specific launch dates.

Changes

Cohort / File(s)	Summary
Backend market asset filtering packages/server/src/queries/complex/assets/market.ts	Adds three optional filter parameters to mapGetMarketAssets: excludeVariants, excludeStablecoins, and minLiquidity. Implements variant filtering by excluding assets without variantGroupKey or with variantGroupKey matching coinMinimalDenom. Constructs category map from assetLists to filter out stablecoin assets. Updates liquidity filtering logic to enforce minLiquidity threshold when provided, otherwise require positive liquidity.
tRPC assets endpoint packages/trpc/src/assets.ts	Extends getMarketAssets input schema with excludeVariants, excludeStablecoins, and minLiquidity boolean/number fields. Propagates new filters into mapGetMarketAssets calls and updates cache key generation. Enhances getTopGainerAssets to attach liquidity data from market activity, filter assets by stablecoin status and alloy variants, exclude assets lacking priceChange data or with liquidity below 1,000, and sort by priceChange24h.
Frontend top gainers filtering packages/web/components/table/asset-info.tsx	Applies filters to topGainers category: sets onlyVerified to true, enables excludeVariants and excludeStablecoins, and sets minLiquidity to 1000. Other categories preserve existing onlyVerified behavior controlled by showUnverifiedAssets and searchQuery.
Frontend upcoming assets filtering packages/web/components/assets/highlights-categories.tsx	Adds hasSpecificLaunchDate helper to distinguish between specific (month/quarter) and vague launch dates. Filters topUpcomingAssets by launch date specificity, introduces hasQualifyingUpcomingAssets flag, adapts grid layout classes based on presence of qualifying assets, and conditionally renders Upcoming highlights section only when qualifying assets exist.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

• Review backend filtering logic for variants (variantGroupKey comparisons), stablecoins (category-based filtering), and liquidity threshold implementation
• Verify tRPC schema updates and cache key generation correctly incorporate new filter parameters
• Confirm filter propagation through mapGetMarketAssets calls in both getMarketAssets and getTopGainerAssets paths
• Validate topGainers filter combination (excludeVariants, excludeStablecoins, minLiquidity=1000) aligns with product requirements
• Check frontend conditional rendering logic for upcoming assets and layout adaptation based on hasQualifyingUpcomingAssets

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	The PR description covers the main purpose and includes two relevant Linear task links, but the Testing and Verifying section is incomplete—it lacks the verification statement.	Complete the Testing and Verifying section by confirming whether the changes were tested locally and verified as expected, or explain why testing was not performed.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main changes: filtering top gainer assets and managing the upcoming assets section display.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch jw/newassetshide

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

packages/trpc/src/assets.ts (1)

604-660: Consider reusing mapGetMarketAssets to reduce code duplication.

The filtering logic in getTopGainerAssets (stablecoin exclusion, variant exclusion, liquidity threshold) duplicates what's now available in mapGetMarketAssets. Consider refactoring to:

const marketAssets = await mapGetMarketAssets({
  ...ctx,
  onlyVerified: true,
  excludeVariants: true,
  excludeStablecoins: true,
  minLiquidity: 1000,
});

const qualifyingAssets = marketAssets.filter(
  (asset) => asset.priceChange24h !== undefined
);

return sort(qualifyingAssets, "priceChange24h").slice(0, topN);

This would:

1. Reduce code duplication
2. Benefit from getMarketAsset's caching
3. Ensure consistent filtering behavior

However, I understand there may be performance considerations (fetching all assets vs. a subset). If the current approach is intentional for optimization, a comment explaining the trade-off would be helpful.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b672a77 and 9fd379e.

📒 Files selected for processing (4)

• packages/server/src/queries/complex/assets/market.ts (1 hunks)
• packages/trpc/src/assets.ts (6 hunks)
• packages/web/components/assets/highlights-categories.tsx (3 hunks)
• packages/web/components/table/asset-info.tsx (1 hunks)

🧰 Additional context used

🧠 Learnings (4)

📓 Common learnings

Learnt from: JohnnyWyles
Repo: osmosis-labs/osmosis-frontend PR: 4171
File: packages/web/components/pages/asset-info-page/pools.tsx:21-0
Timestamp: 2025-10-08T14:01:51.343Z
Learning: In packages/web/components/pages/asset-info-page/pools.tsx, the poolTypesFilter intentionally excludes only "cosmwasm-transmuter" by default, not all CosmWasm pool types, because alloyed pools should remain visible to users.

📚 Learning: 2025-10-08T14:01:51.343Z

Learnt from: JohnnyWyles
Repo: osmosis-labs/osmosis-frontend PR: 4171
File: packages/web/components/pages/asset-info-page/pools.tsx:21-0
Timestamp: 2025-10-08T14:01:51.343Z
Learning: In packages/web/components/pages/asset-info-page/pools.tsx, the poolTypesFilter intentionally excludes only "cosmwasm-transmuter" by default, not all CosmWasm pool types, because alloyed pools should remain visible to users.

Applied to files:

• packages/server/src/queries/complex/assets/market.ts
• packages/trpc/src/assets.ts
• packages/web/components/table/asset-info.tsx

📚 Learning: 2024-11-05T08:46:24.743Z

Learnt from: greg-nagy
Repo: osmosis-labs/osmosis-frontend PR: 3913
File: packages/trpc/src/assets.ts:444-446
Timestamp: 2024-11-05T08:46:24.743Z
Learning: In `packages/trpc/src/assets.ts`, within the `getUserDustAssets` procedure, a prior filter ensures that `usdValue` is defined and valid, so additional error handling for `usdValue` may not be necessary in subsequent operations.

Applied to files:

• packages/trpc/src/assets.ts

📚 Learning: 2024-11-05T08:46:24.743Z

Learnt from: greg-nagy
Repo: osmosis-labs/osmosis-frontend PR: 3913
File: packages/trpc/src/assets.ts:444-446
Timestamp: 2024-11-05T08:46:24.743Z
Learning: In the codebase, it's acceptable for errors to propagate to the client from the `getUserDustAssets` procedure in `packages/trpc/src/assets.ts`, so adding try-catch blocks for handling potential price fetching errors is not required.

Applied to files:

• packages/trpc/src/assets.ts

🧬 Code graph analysis (1)

packages/server/src/queries/complex/assets/market.ts (2)

packages/types/src/asset-types.ts (1)

• AssetList (6-10)

packages/server/src/queries/complex/assets/index.ts (2)

• AssetFilter (21-21)
• getAssets (81-90)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)

• GitHub Check: preview-swap-usdc-tests
• GitHub Check: preview-pools-and-select-pair-tests
• GitHub Check: preview-portfolio-trx-tests
• GitHub Check: Summary

🔇 Additional comments (12)

packages/web/components/assets/highlights-categories.tsx (4)

41-79: Well-structured date validation with good coverage.

The helper function cleanly handles the different date format cases. A few observations:

1. Line 68: may appears twice in the regex pattern - once in april|may|june and it would naturally be captured, but this is fine.

2. Consider whether dates with just a day number (e.g., "22nd" or "15") without month context should be handled. Currently they'd return false, which seems correct.

3. The half-year regex on line 57 (/^h[12]\s*\d{4}$/i) correctly handles "H1 2024" but won't match "H1/2024" or "H12024" (no space). The \s* makes the space optional, so "H12024" actually would match - this is good.

---

103-108: LGTM - Clean filtering logic.

The filtering correctly derives qualifying assets and the boolean flag. Note that during loading (isTopUpcomingAssetsLoading === true), hasQualifyingUpcomingAssets will be false, so the Upcoming section won't show a skeleton loader if ultimately there are no qualifying assets. This is acceptable UX behavior.

---

113-120: Grid layout adjustments look correct.

The conditional classes properly handle both states - 2-column when Upcoming is hidden and 3-column when shown. The inline comments clarify the intent well.

---

140-148: Conditional rendering is correct.

Since hasQualifyingUpcomingAssets requires !isTopUpcomingAssetsLoading, the isLoading prop passed to AssetHighlights will always be false when this section renders. The skeleton loader logic inside AssetHighlights won't trigger, which is appropriate since we've already confirmed qualifying assets exist.

packages/web/components/table/asset-info.tsx (2)

198-208: Verify the minLiquidity threshold value.

The PR description states "Only show assets with significant liquidity (> 10k)" but the code uses minLiquidity: 1000 (1k). This discrepancy should be clarified:

• If 10k is intended: change to minLiquidity: 10000
• If 1k is correct: update the PR description

Also note that getTopGainerAssets in assets.ts (line 657) uses 1000 for the highlights section, so these should be consistent with the intended threshold.

---

198-201: LGTM - Verified assets logic is correct.

For topGainers, forcing onlyVerified: true ensures the filtered list only contains verified assets, which aligns with the PR's filtering goals.

packages/server/src/queries/complex/assets/market.ts (3)

128-137: LGTM - Liquidity filtering logic is sound.

The dual-path logic correctly handles:

1. When minLiquidity is provided: filters to assets with liquidity >= threshold
2. When minLiquidity is undefined: requires positive liquidity (maintains existing behavior)

Assets without liquidity data (undefined) default to Dec(0) and are correctly filtered out in both cases.

---

98-107: LGTM - Variant filtering logic is correct.

The filter keeps:

• Assets without a variantGroupKey (not part of a variant group)
• Canonical assets where variantGroupKey === coinMinimalDenom

This correctly excludes non-canonical variants like "DYM.dym" while keeping "DYM".

---

109-122: Verify coinMinimalDenom consistency between asset sources to ensure stablecoin filtering works correctly.

The stablecoin category lookup builds a map from params.assetLists using asset.coinMinimalDenom as the key, then filters against assets (from getAssets) using the same coinMinimalDenom. If these two sources use different denom formats or have aliasing issues (e.g., one uses canonical denoms while the other uses IBC denoms), stablecoins from the unmatched denoms will not be filtered as expected. Verify that asset.coinMinimalDenom is consistently formatted across both params.assetLists and the assets array before relying on this lookup.

packages/trpc/src/assets.ts (3)

269-271: LGTM - Schema extensions are correct.

The new optional fields are properly typed and will flow through to the downstream functions.

---

650-660: LGTM - Liquidity filtering is correctly implemented.

The filtering logic properly handles:

• Missing priceChange24h data
• Missing or undefined liquidity
• Threshold comparison using Dec

The slice(0, topN) after sorting ensures only the top N gainers are returned.

---

618-634: No action needed. The fullAssetMap lookup will consistently find matches because both getAssets() and fullAssetMap originate from the same ctx.assetLists source, and coinMinimalDenom values are never transformed during filtering.

Likely an incorrect or invalid review comment.

[jasbanza]

@JohnnyWyles I noticed it removes alloys as well as variants? Is the alloyed asset (non-variant) removal intended too?

Update: nevermind, I think it's due to the liquidity being under 10k

If this is the case, then it looks good to me

[JohnnyWyles]

@jasbanza

Update: nevermind, I think it's due to the liquidity being under 10k

In this case it is that it also removes Unverified assets from the list, something that was the case for the mini-display under the swap tool already. Dropped the liquidity requirement to 1k btw, just wasn't reflected in the PR description. This is because it is not pool liquidity but directional liquidity available.