I compared PSOL against native staking in Phantom's docs and wallet UI. Two things stand out: rewards accrue from three sources (staking, MEV tips, and priority fees), and each PSOL grows in SOL value over time instead of your balance increasing. One gap: the fee structure (4% protocol fee on staking rewards, 0.1% exit fee on unstake or swap) lives in the help center, not in the earn panel. Showing the fee breakdown inside the PSOL position page would save new users a doc dive. My question: with liquid staking the pool manages validator choice, unlike native staking where I pick my own. Is there a way to see which validators back $PSOL and how the pool rotates them?

$xSOL is a gem!My take on xSOL by Hylo: TokenGems tags it Liquid Staking, but Hylo's own docs classify xSOL as a Leveraged Token (an xAsset), while Hylo's real LSTs are hyloSOL and hyloSOL+. The live numbers here (price ~$0.0798, ~29.6k holders, ~$13.4M market cap, -95% all time) fit leveraged long exposure, not staking yield. Why it matters: an LST and a leveraged token carry very different risk, yield and liquidation mechanics, so listing xSOL next to classic LSTs misleads anyone comparing staking tokens. Practical suggestion: split Liquid Staking from Leveraged Tokens, or add a sub-tag, so leveraged xAssets are not shown beside real LSTs. Sources: docs.hylo.so (Leveraged Tokens page; Stablecoin and Yield page) and this token page FAQ.

I've been exploring TokenGems and really like having the score, holder distribution and Gem/Rug vote all on one page, it makes comparing projects much faster. $ZEUS is currently #4 on the leaderboard, so I took a closer look, and something caught my attention. The score is 81.8, which sounds pretty solid, but the community vote is basically 50/50, 52% gem and 48% rug. And nobody has posted anything yet, so it's hard to tell why almost half of people think it's a rug.

I looked at how the score is calculated, and it's based on price, holders, volume and activity. That's useful, but to decide whether a project is legit I'd also want to see the tokenomics, who holds the supply and when it unlocks, how the token sale went, how much the team raised and at what stage, and whether anyone actually uses the product.

For ZEUS I found that they raised $8M in a seed round led by Mechanism Capital, the supply is 1B, and 3% went to the airdrop. But I'm still wondering about the team size and the amount of users. Would be great to have all this right on the token page.

Also, maybe ask people to leave a short reason when they vote rug? That would make the 48% much more meaningful.

$ZAUTH it keeps a live registry of x402 endpoints and tests them, so an agent can check whether a service actually works before paying for it. It also has a free public API, which made it easy for me to try without a wallet.

$ZAUTH

I pulled the first 100 results from the free /api/directory endpoint, once with verified=true and once with verified=false, using a few lines of Node.js.

What stood out: 90 of the 91 "WORKING" verified endpoints were last tested over 30 days ago, even though the docs say verified endpoints are continuously tested. The unverified ones looked the same (100 of 100 stale). Also, only 9 of the 100 verified endpoints had a title, versus 88 of 100 unverified.

Caveat: these are just the first 100 per group, not a random sample, and the 30-day cutoff is my own.

Suggestion: show lastTested next to the status, or mark it stale after a while. Quick question: how often are verified endpoints retested, and is lastTested the latest test?

$JUP — cancellation needs a clear recovery state.

A review of Jupiter's Trigger V2 documentation found a useful integration edge case. DCA cancellation first stops future fills and moves the order into `withdrawing`; the remaining funds are returned through a separate signed withdrawal confirmation. If confirmation fails, the order stays in `withdrawing`.

An integration could make “stopped buying” look like “funds returned.” Suggest separate progress labels: “Future buys stopped,” “Withdrawal needs completion,” and “Funds returned,” with a recovery action for an unfinished withdrawal.

There is also a concrete reconciliation trap: the history docs say `inputAmountRemaining` is not reset after cancellation. Wallet or portfolio integrations should use order state and withdrawal events when reporting outstanding funds, so a stale remaining amount does not look like a second available balance.

Question for the team: could the integration guide include a reload/reconnect example for an interrupted withdrawal, showing how to distinguish a pending refund from a completed one?

Scope: public documentation reviewed on 8 October 2026. No authenticated flow or transaction was tested. This is an integration suggestion, not a reproduced bug in Jupiter's app.

Sources:

https://developers.jup.ag/docs/trigger/dca-cancel

https://developers.jup.ag/docs/trigger/dca-history

$JUP UX feedback (read-only desktop review, 8 Oct 2026): Jupiter Swap's token picker lists both USDC and Jupiter Lend USDC (jlUSDC). Jupiter Academy says jlUSDC is a yield-bearing lending-pool receipt, not ordinary USDC; its value/redeem mechanics depend on the lending pool. Suggest a prominent 'Lending receipt (not regular USDC)' badge beside jlUSDC in the picker, plus a short explainer of redemption and smart-contract risk before selection. For someone entering Solana for the first time, this could prevent a basic but costly asset-name mix-up. I examined the public token picker without connecting a wallet or making a trade. Source: https://academy.jup.ag/lessons/jupiter-tokens

$JitoSOL — make the delayed-withdrawal clock explicit.

An AI-assisted review of Jito's public documentation found a potential onboarding ambiguity: the comparison table summarizes direct unstaking as taking up to two days, but the detailed flow requires a separate deactivation action, followed by a later withdrawal. A reader who stops after the initial unstake could mistake that step for the start of an automatic countdown.

Suggestion: place a three-step checklist beside the timing estimate: create stake account → deactivate → withdraw after cooldown. Label the estimate ‘up to one epoch after deactivation,’ and show ‘action required’ while the stake remains active. Link directly to the Manage page and wallet-specific guide.

Question for the team: does the current interface automatically request deactivation, or must every user initiate it separately as the docs describe? If that behavior changed, please align the overview and wallet guides.

Scope: documentation review only, assisted by AI. No wallet connection, deposit, unstaking transaction, or authenticated Jito flow was tested.

Sources:

https://www.jito.network/docs/jitosol/get-started/unstaking-jitosol-flow/unstaking-overview/

https://www.jito.network/docs/jitosol/get-started/unstaking-jitosol-flow/unstaking-with-phantom/

$AVAIL is a data availability layer, providing a dedicated chain for ordering and publishing transaction data for modular blockchains. Its purpose is to ensure that rollups can publish their state roots and transaction data, allowing anyone to reconstruct the chain and verify its integrity. The current market capitalization of $AVAIL is approximately $10.6M with reported liquidity around $0.4M. This size indicates a nascent project, and while the underlying mechanism addresses a real need for rollup data publication, the lack of an active fee market or a direct value accrual mechanism to the $AVAIL token for data publishing transactions means its value remains speculative.

A significant recent event for $AVAIL was its mainnet launch, which included the distribution of tokens via an airdrop to eligible users. This event typically increases token circulation, and without a commensurate increase in network utility or direct fee capture, it introduces selling pressure. The core mechanism of $AVAIL as a data availability layer is sound, but its current economic model does not yet route protocol revenue to the $AVAIL token. The call for $AVAIL to fall would be incorrect if the protocol implements a robust fee switch that demonstrably captures value from data publishing directly to the token within the next 90 days, or if a material amount of economic activity on top of $AVAIL generates significant demand for its blockspace and thus its token.

$GRIFFAIN — quick correction for anyone researching it here: the FAQ on this page describes Griffain as a DeFi platform for token swaps and liquidity provision, but that's not really what it is. Griffain is an AI agent coordination layer on Solana: you describe an on-chain action in plain English and specialized agents execute it, routing through integrations like Jupiter and Metaplex. Each agent has a soulbound NFT identity with user-set spending limits and approved protocols, which is the part I find most interesting from a safety point of view. Question for holders: how much of the token's demand comes from premium agent access vs. pure speculation? Would love to see usage metrics (agent tasks executed per day) shown next to the price here.

$AERO is a gem!

The token has seen a strong month, up 31.3%, driven by liquidity flowing into the Base ecosystem. While daily price action shows a slight retracement of 3.7% over the last week, the overall trend reflects continued attention to its locked vote escrow model. This mechanism aims to direct real yield, but rewards from emissions remain significant.

$MKR is a gem!

Mkr has seen a slight decline of 4.9% this past week, though it's up 11.5% over the month. With a market cap of $123.5M, its governance role in MakerDAO's lending and stablecoin ecosystem is crucial. Recent discussions around SparkDAO's DAI strategy and a large deposit of MKR to BlockTower indicate shifting liquidity, warranting caution on its 30-day outlook.

$bSOL — BlazeStake’s withdrawal docs give conflicting fee guidance.

I checked the live app and official docs today. The Fees page lists both Instant Withdrawal and Delayed Withdrawal at 0.1%, and the app also shows 0.1% on both paths.

But the main BlazeStake intro still says instant unstake has a higher fee while delayed unstaking has a much lower fee. That can push users toward delayed unstaking for the wrong reason.

Suggestion: update the intro and show the trade-off clearly:

• Instant: 0.1%, immediate SOL when liquidity is available.

• Delayed: 0.1%, receive a stake account and wait through Solana cooldown.

Sources:

https://stake-docs.solblaze.org/

https://stake-docs.solblaze.org/features/fees

https://stake.solblaze.org/app/

AI-assisted review; no staking transaction was made.

$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

$ORCA

Orca simulator: make the assumptions visible

In an AI-assisted, wallet-free test of the SOL/USDC 0.04% pool, a roughly ±2% range and 7 days of Time In-Range showed approximately 6.13% Estimated Yield Earned. The numbers changed with live pool data.

The tooltip explains the historical 24-hour yield basis. The documentation clarifies that Time In-Range is active time within the range, not total elapsed time, and excludes slippage and priority fees. These conditions are easy to miss.

Could the result panel show “168 hours in range · historical 24H activity · excludes slippage and priority fees”? A 50%-fee-rate stress-test preset would also help users understand uncertainty. Does the estimate assume unchanged competing liquidity and reward rates?

No wallet connection, deposit, or transaction was performed during this review.

$PUMP is a gem!

$PUMP P — Pump has the largest holder base on your top-10 board — 311,239 holders — but the lowest holder-distribution score of the group (0.31). That's a lot of wallets with comparatively concentrated supply. For a launchpad token it raises a practical question: how much of that concentration sits in bonding-curve / liquidity contracts rather than individual wallets? Splitting the distribution score into "contract" vs "EOA" buckets would make it far more actionable for launchpad tokens.

$SNX has seen its price dip over the last week and day, -6.0% and -7.0% respectively, despite a 7.2% gain over the past month. A recent governance proposal, SCCP-2092, aims to enable Perps V3 on Arbitrum, potentially drawing new liquidity and expanding the protocol's reach. The nearly $138M market cap suggests a strong base, but watch closely where this new liquidity flows.

$UNI is down 6.6% in the last day and 9.8% over the week, a notable retraction from its impressive 150.5% three-month surge. While the Uniswap Foundation recently discussed fee switch implementation, progress seems slow. The token needs new, significant liquidity inflows to support its recent gains, or it risks further consolidation as profit-takers exit.

$AERO has seen a minor pullback of 1.0% in the last day, but its one-month performance is a strong 29.2% gain, indicating sustained interest. Aerodrome Finance recently activated a fee switch, directing protocol fees to veAERO holders, which should incentivize long-term staking and deepen liquidity on Base. This move generates real yield for holders.

$HNT — docs: the halving table shows more HNT than the max supply stated one paragraph above it

Page: docs.helium.com/tokens/hnt-token, section "Max Supply".

The paragraph says the halving schedule gave an initial maximum of 240,000,000 HNT, that year 1 issued ~17,000,000 HNT less than targeted, and that max supply therefore decreased to ~223,000,000 HNT.

The table right under it does not apply that shortfall. Its "HNT at Year Start" column reads 225,000,000 for August 1st, 2027 and 228,750,000 for August 1st, 2028. Both are above the ~223,000,000 maximum the page has just stated. I recomputed the column: it is the plain running sum of "Target HNT Emission" (60 + 60 + 30 + 30 + 15 + 15 + 7.5 + 7.5 = 225 million), so it is the pre-shortfall schedule. With the 17 million removed the two rows would be about 208.0 and 211.75 million.

Two smaller things on the same page:

1. The Year column runs 1 to 8 and then repeats 7 and 8 for 2027 and 2028. Those rows should be 9 and 10.

2. The text gives the HIP-20 cap as 34.24 HNT per 30-minute epoch and the current daily cap as 1,643.83561643 HNT. 34.24 x 48 = 1,643.52. The daily figure equals 1% of 60,000,000 / 365, so 34.24 looks like a truncated 34.2466.

What checks out: the Net Emissions example. (400 x 6/7) + (9,500 x 1/7) = 1,700, capped at 1,643.83561643, leaving 7,856.16438357 HNT burned.

Suggestions:

1. Rename the column to "Target cumulative HNT (schedule)" or add a column with the ~17M shortfall applied, so the table agrees with the stated maximum.

2. Fix the Year numbers in the last two rows.

3. Add a link to the live on-chain supply next to the table. Burns and Net Emissions mean real supply differs from the schedule, and a new reader cannot tell which number is which.

Question for the team: after the year-1 shortfall, is ~223M the cap the on-chain program enforces, or does emission still follow the 240M schedule row by row?

Source (reviewed 7 Oct 2026): https://docs.helium.com/tokens/hnt-token

AI-assisted review. The arithmetic was recomputed; nothing was checked on-chain. No affiliation with Helium.

$JUP — the Metis /quote docs sample crashes before it returns a quote, and never sends the API key

Page: developers.jup.ag/docs/swap/v1/get-quote. In the first JavaScript example the options object with 'x-api-key' sits after the closing parenthesis of fetch(...), not inside it. Shortened, the code is: await ( await fetch(url), { headers: {...} } ).json()

That is a comma expression. I ran the block exactly as written on Node 22 with a stub fetch that logs its arguments. Result: fetch is called with 1 argument, so no headers and no key are sent. Then it throws "TypeError: (...).json is not a function", because .json() is called on the plain options object, not on the Response.

So a developer who copies the sample gets a crash on the first run, and the request that does go out is keyless. The rate-limits page lists Keyless at 0.5 RPS and Free at 1 RPS, so the difference matters.

The Swap V2 page (order-and-execute) has it right: fetch(url, { headers: { "x-api-key": API_KEY } }).

Suggestions:

1. Move the options object inside fetch( ) in the v1 sample. It is a one-line fix.

2. The page says Metis is "no longer actively maintained". Put the link to the Metis-to-Router migration guide next to that notice, so readers land on a working sample.

3. Run doc samples in CI against a stub fetch. This class of error would be caught automatically.

Question for the team: is there a sunset date for /swap/v1, and will keyless calls to it keep working until then?

Sources (reviewed 7 Oct 2026):

https://developers.jup.ag/docs/swap/v1/get-quote

https://developers.jup.ag/docs/swap/order-and-execute

https://developers.jup.ag/docs/portal/rate-limits

AI-assisted review. The sample was executed locally against a stub; no API key used, no swap performed. No affiliation with Jupiter.

$PUMP bounty board (go.pump.fun) this week: 79 live bounties and roughly $14K unclaimed, but most open bounties are attention-buying (hold $5 and callout, follow me to win). Original-artifact bounties sit at only $5-9 with single-digit submissions, while the bigger $100+ content bounties I found had already expired with 34-49 entries and no winner. Has the team considered a higher funding floor for escrow-backed artifact bounties? The current economics select for token purchases over creative work, which likely drives the high expiry rate.

$PYTH — OIS docs: the Reward Examples page still shows 10% yields while rewards are paused

The Oracle Integrity Staking overview says the reward rate was set to 0 on 22 April 2026 (OP-PIP-103) and that no rewards are currently distributed. The Mathematical Representation page repeats it: y = 0, "stake is still at risk of slashing".

The Reward Examples page, one click away, carries no such notice. All six examples assume "Annual Rate of Rewards r = 10%" (Example 4: publisher 10.3% APY, delegators 9.8%), and the built-in calculator returns positive rewards. Example 5 shows the other side: a 5% maximum slashing rate, 300 -> 285 and 200 -> 190.

Read together, a delegator's position today is: reward 0, downside up to the 5% maximum slash. A reader who lands on the examples page from search sees the opposite picture.

Suggestions:

1. Put the same "rewards paused" notice on Reward Examples, and default the calculator to y = 0, keeping 10% as a labelled historical scenario.

2. Add an example for the current state: stake 500, y = 0, one 5% slash = -25. That makes today's risk/reward explicit.

3. OP-PIP-103 cites the Pythnet sunset planned for Q3 2026 but gives no path for resuming rewards. A line on that in the overview would help.

Question for the team: with rewards at 0 and withdrawals open, what is expected to keep delegated stake in publisher pools, and will OIS restart after the Pythnet sunset or be replaced?

Sources (reviewed 7 Oct 2026):

https://docs.pyth.network/oracle-integrity-staking

https://docs.pyth.network/oracle-integrity-staking/mathematical-representation

https://docs.pyth.network/oracle-integrity-staking/reward-examples

https://forum.pyth.network/t/passed-op-pip-103-pausing-ois-rewards/2471

AI-assisted documentation review; no staking transaction performed.

$GEMS
What are Gems actually used for on TokenGems? Are they currently just platform points, or do they have any additional utility?

$MNDE — Marinade Native: explain reward eligibility for small accounts

The Native overview says accounts under 2 SOL are rebalanced as whole blocks; positions comprising small accounts can have their next reward delayed by more than one epoch. It also distinguishes the 1.0046 SOL minimum from the 100 SOL recommendation for broad validator distribution.

Could the team add an epoch-by-epoch example for a 1.5 SOL Native position, showing active/deactivating/activating states and reward-eligible SOL at each step? Label the timeline as illustrative, rather than promising a fixed delay.

Question: what triggers a whole-account rebalance under the current delegation strategy, and how can a user determine the next reward-eligible epoch? The overview says this rebalancing caveat does not apply to Recipe reward-token positions. Explaining that exception in the same example would help users understand the mechanics before staking.

A "currently reward-eligible SOL" metric and status timeline could explain temporary reward gaps alongside headline APY. This is a documentation-based suggestion, not a report of a failed position.

Source (reviewed 7 Oct 2026):

https://docs.marinade.finance/marinade-protocol/protocol-overview/marinade-native

AI-assisted documentation review; no staking transaction performed for this review.

$Moolah is a gem! MOOLAH’s current visibility appears to be driven chiefly by Token2049 exposure and an ambitious treasury/RWA narrative, not yet by independently verified usage or token fundamentals. The read would become materially stronger if circulating supply, market capitalization, treasury holdings, and real platform activity became transparent and verifiable.