Meteora Token $MET

$MET not looking too hot today. Polymarket has odds on them being named in zach XBTs big piece dropping soon

$MET Meteora Discover (2H view): the TVL change column contradicts other columns in the same row.

Checked 6 Oct 2026 (~03:30 UTC) on app.meteora.ag, Discover → Top Performers, 2H, no wallet connected.

STONK-SOL (DLMM, bin step 20):

- TVL $2.58M, +101%; Active TVL $2.51M, +99.13%

- Net Deposit -$214.87K, pool price +4.91%

- Fees -24.55%, while Fees/Active TVL +76.11%

Two things don't add up. TVL can't double in two hours while LPs withdraw $215K and the price moves 5%. And if fees fell 24.55% while Fees/Active TVL rose 76.11%, Active TVL must have fallen about 57%, not risen 99%.

Same pattern on ZCAT-SOL (bin step 80): Net Deposit -$137.9K, price -9.84%, yet TVL +78.92%; Fees -65.88% vs Fees/Active TVL +37.11% implies Active TVL about -75%, shown as +91.96%. ALLINU-SOL shows it too, and most rows on the page show TVL around +80-100% for the window.

LPs use these columns to pick pools, so a wrong TVL trend makes a pool look like it is attracting liquidity while it is losing it.

Suggestion: check the baseline used for the TVL / Active TVL change (it looks like the comparison value is far too low, or the direction is flipped), and add a tooltip saying what each % is compared against.

Question: is the 2H TVL change computed against the value at the start of the window, or against something else, like an average over the previous window?

(Researched with AI assistance; numbers taken from the page on 6 Oct 2026.)

$MET I was checking the Discover page on the 2H filter and noticed an ALLINU–SOL pool showing 2.73% Fees/Active TVL, while the token price had moved around 9.37%.

The fee number looks good, but it doesn’t really tell you if an LP actually made more than they would have by just holding the two assets.

It would be really useful to have an “LP Result vs Holding” estimate showing fees earned, impermanent loss, time in range, and expected exit value.

That would make it much easier to compare pools, especially with new and volatile tokens.

$MET Feedback!

Walked through Meteora’s DLMM (Dynamic Liquidity Market Maker) pool setup flow. Selecting between Spot, Curve, and Bid-Ask volatility strategies uses clean visual bin distribution histograms, which helps visualize concentrated liquidity. The biggest UX hurdle for a newer LP is right after choosing a strategy: the interface shows the bin step and fee tier, but doesn't simulate what happens to your position when price moves completely outside your active bin range (zero fee accrual + 100% single-sided asset conversion). Is there a plan to add a simple interactive "Out-of-Range Preview" slider inside the deposit modal before signing the transaction?

$MET is a gem! I checked MET on-chain before trusting the labels on this page, and two of them I can't interpret or reproduce.

What's verified: both the mint authority and the freeze authority are renounced (None / None), and total supply is 997,732,177.39 MET. So the ~$379M market cap here is total supply x price, i.e. fully diluted. That confirms @alessiosol's suspicion from yesterday: the docs put roughly 480M circulating at TGE, so FDV is doing a lot of work in a number most readers will take as float value.

Two labels I couldn't act on:

1. "Entropy 0.261". The FAQ says the 0-100 score is computed from price performance, holder distribution, trading volume and community activity - but "Entropy" isn't defined anywhere I could find, so the score can't be reproduced. Is it a Gini, a top-10 share, or an entropy over holder buckets? And are AMM pool vaults excluded? On a token whose liquidity sits in DLMM bins, vault balances are not whales, and including them would move the number a lot.

2. "Gem Hunters Sentiment: Gem 52% / Rug 48%". On a token with both mint and freeze authority renounced, a 48% rug reading is surprising enough that I want to know what it measures - how many wallets voted, over what window, and what a "Rug" vote means here (contract risk? price? team?). If it's a handful of votes, presenting it as two large percentages beside a 75/100 score implies far more signal than exists.

Smaller one: the token list shows $2.82M of 24h volume for MET, while across the 30 MET pairs on DexScreener I measure about $19.2M - including $8.7M in a single MET/JUP pool holding only ~$200k of liquidity. If that row is scoped to DAMM v2 pools only, it doesn't say so, and someone screening by volume would read MET as roughly 7x less traded than it is.

(On-chain figures read from the Solana RPC, DEX figures from DexScreener, with AI assistance on the data collection.)

$MET T — Detailed UX & UI Audit: DLMM Pool View, Limit Orders & Global Settings

I spent time testing Meteora's web app (app.meteora.ag) across liquidity management, order placement, settings, and campaigns. Here are the core issues causing real UX friction, along with direct fixes.

Priority Issues:

1. High Default Priority Fees

Under Settings > Transaction Broadcasting, 'Ultra' defaults to a 0.008 SOL cap (~$0.93 USD). The app doesn't show standard live fee estimates per tier, so smaller LPs and casual traders end up unknowingly paying massive tip fees on small transactions.

• Fix: Show estimated SOL fee ranges right under Fast / Turbo / Ultra options.

2. Inconsistent Default Slippage

Slippage settings don't sync across tools. Swaps default to 0.5%, DLMM uses Dynamic Slippage, and Zap Out defaults to 0.4%. Moving between swaps and LP actions without noticing these differences leads to failed transactions during fast market moves.

• Fix: Show an active slippage status on order cards and allow a global sync toggle.

Usability & Visual Improvements:

3. Cluttered Price Axes, Range Risk & Missing Chart Keys

On volatile meme pools like CLAUDIA-SOL, tiny token decimal notation (like 0.0s448) stacks right on top of High, Low, and Bin markers, making the price axis unreadable. The Liquidity Distribution graph doesn't clearly label token colors, and the UI lacks a clear indicator for how close a position is to leaving the active bin range or an estimated "Fees Earned vs. Holding Raw Assets" breakdown.

• Fix: Add a visual color key (e.g., SOL = Blue, Token = Turquoise), auto-collapse stacked price labels, and display a prominent active-range proximity indicator alongside net PnL estimates.

4. Full Screen Chart Disconnect

When expanding the price chart to Full Screen, all order and LP controls vanish. LPs analyzing live chart levels have to exit full screen completely just to adjust a range or drop a limit order.

• Fix: Add a minimal overlay card for quick order execution inside the expanded view.

5. Native Swap vs. Jupiter Routing

The Swap tab displays a warning banner stating single-pool routing might deliver worse pricing than Jupiter, which forces users to drop what they're doing and head to Jupiter manually.

• Fix: Place a 'Route via Jupiter' trigger directly inside the swap panel.

6. Campaign Tab Navigation

Campaign cards (like LP Stimulus Season 2) highlight dates and rewards, but don't link straight to the pools that qualify.

• Fix: Add a direct 'View Qualifying Pools' link on each campaign card that filters the pool table automatically.

Reviewed links:

https://app.meteora.ag/dlmm/DfHEafDf9vk6tJzo7UEUQKsHmWnikzFvwW55WsxDyJuU

https://app.meteora.ag/campaigns

https://docs.meteora.ag/core-products/dlmm

I’ve used Meteora LPs, and one thing I’d like to see surfaced more clearly around $MET T is range risk.

For concentrated liquidity pools, showing how close price is to leaving the active range — plus a simple in-range / out-of-range indicator — would make pool selection much easier.

APR looks attractive, but for LPs, knowing how likely the position is to stay active matters just as

$MET Read through docs.meteora.ag/protocol/met/tokenomics and found some inconsistencies:
1. The allocation table says Mercurial Reserve (5%) is 100% unlocked at TGE, but the unlock schedule right below has it unlocking from Nov 2025 to Oct 2031.
2. Meteora Reserve (34%, 72-month vest) is missing from that schedule.
3. The Ecosystem wallet row says it holds "the Mercurial Reserve (45% of supply)", which doesn't match 5% or 34%.
4. The Solscan link for the DcHvzKHD… Mercurial Reserve row points to the 6HHtjZMR… Ecosystem wallet instead.
Also, the market cap shown here (~$379M) looks like FDV, since the docs say only 480M MET circulated at TGE. Is there an official live circulating supply figure?

$MET is a gem!

My Meteora DLMM experience on Solana

Tested Meteora DLMM pools this week what I liked about it is dynamic fees really help during volatility, and bin liquidity feels more capital efficient than standard AMM. IL management is better.

What can improve: The curve visualization for beginners is confusing. Adding a simple simulation of what if the price move 20% before adding liquidity on solflare lags a bit.

Overall solid product, using it for my small LP strategy in Nigeria. Would love better educational tooltips inside the pool page.

$MET

Explored Meteora's Dynamic Bonding Curve (DBC) launch architecture and Alpha Vault migration mechanics on Solana.

Specific Observation: When a token completes its bonding curve and initiates liquidity migration into a DLMM pool, the initial liquidity is concentrated heavily into narrow active price bins. During high-velocity launches, retail buyers entering immediately post-migration experience severe price impact because the dynamic fee decay schedule (scaling down from the launch peak) doesn't adapt to block-level priority fee surges. High-frequency MEV searchers using Jito bundles can drain the lowest-priced bin in slot 0, forcing retail market orders into higher price bins with elevated dynamic fees.

Constructive Suggestions:

Introduce a "Migration Impact Simulator" on the DBC creation interface that visualizes estimated price impact across the first 10 DLMM bins under different bin step configurations (e.g. 20bps vs 80bps) before liquidity is committed.

Implement a configurable post-migration fee floor hold (e.g. locking dynamic fees at the max tier for the first 50 slots post-migration) to penalize single-slot sniper dump bundles and protect early retail participants.

Question for the Team: Is Meteora exploring an in-protocol batch auction or TWAP smoothing mechanism during the exact DBC-to-DLMM migration slot to prevent atomic sandwich attacks on migrating liquidity?

$MET is a gem!

Building on @Solano's on-chain check of the MET token mint, I looked at a different layer: the DLMM program account itself (LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo), queried directly via Solana RPC and cross-checked on Solana Explorer against the DLMM Changelog in the docs.

What's good: the program's upgrade authority (JADaUV8kvDpDbJr55wxXJHVaBS3VCj8thZZHjfeuCVLd) looks like a Squads v3 multisig — 8 of its last 15 transactions route through the Squads program. That's much safer than a single upgrade key, and worth surfacing as a positive signal. The program ID also matches the one published in the changelog.

What I couldn't verify, and think the team should close:

1. Deploy vs changelog mismatch. On-chain, the program was last upgraded on June 3, 2026 (slot 423,977,638). The newest changelog entry is lb_clmm 0.12.0, "planned for May 21, 2026 (Wednesday)" — but May 21, 2026 is a Thursday, and June 3 is a Wednesday. So the dates don't line up, and there's no way from the public docs to tell whether the June 3 deploy is 0.12.0 or a later patch.

2. No source link for the running code. In the 0.12.0 release table, the SDK/CLI/commons rows all link to PR #273, but the Program row is just "—". Solana Explorer also shows "Program Not Verified". So there's no verified build tying the ~2.2 MB of deployed bytecode back to a specific commit.

3. Breaking release, no audit reference. 0.12.0 is marked a breaking release (adds limit orders, permissionless claim_fee, and changes swap-quote math), but the changelog entry doesn't reference an audit for it.

4. No security.txt. I scanned the full program data for the security.txt marker and found none, so a researcher looking at the program on-chain has no embedded disclosure contact.

Suggestions: record the actual deploy slot next to each release, link the program source/tag, publish a verified build (solana-verify), note which audit covers each version, and embed a security.txt.

Question for the team: which commit is running at slot 423,977,638, and which audit covers lb_clmm 0.12.0?