docs: Trading-first rewrite of all four Meteora pages

[buddies2705]

What changed

Scope grew from one page to all four Meteora pages. The original commit rewrote the DLMM page; the review question that followed was why every Meteora page led with DEXTrades and DEXTradeByTokens when the Trading cubes are the house default. An audit of all four pages answered it and turned up several data bugs, so this PR now covers the whole set.

Cube mix across the four pages: 33 chain-level query blocks and 6 Trading before, 14 and 26 after. Chain-level cubes are kept only where the Trading cubes cannot answer the question: pool creation, pool reserves, and history older than the roughly 30-day Trading window.

Page	Before	After
DLMM	9 chain / 2 Trading	4 / 6
DAMM v2	7 / 0	3 / 6
DYN, now DAMM v1	7 / 0	2 / 7
DBC	10 / 4	5 / 7

Data bugs found and fixed

1. DBC launch tracking missed every Token-2022 launch. The subscription filtered initialize_virtual_pool_with_spl_token only. Over 24 hours that method fired 783 times and initialize_virtual_pool_with_token2022 fired 425, so a third of new DBC tokens were invisible to anyone who copied the example. Both are matched now.

2. DAMM v2 pool creation used the event, not the instruction. The example filtered EvtInitializePool, whose row carries a single account and an empty AccountNames list, while the prose promised "pool creator, token vaults and token mints". Replaced with the three real instructions (initialize_pool 181/24h, initialize_pool_with_dynamic_config 940, initialize_customizable_pool 113), which do carry the full named account list.

3. The DYN page led with a dead code path. "Track Latest created pools on Meteora DYN" filtered initializePermissionlessConstantProductPoolWithConfig2 on the amm program. Zero initialize* instructions fired on that program in 24 hours; Meteora files DAMM v1 under legacy products and new pools are not created. Replaced with a ranking of the pools that still trade, and the page now says so plainly.

4. dataset: combined undercounts, and USD aggregates break on archive. Same 7-day window, TRUMP/USDC on DLMM:

Source	trades	USD volume
Solana(dataset: combined)	45,418	47.7M
Solana realtime	58,238	59.2M
Trading.Trades	58,670	60.5M

Realtime and the Trading cube agree within 1 percent; combined is 22 percent light. Separately, adding sum(of: Trade_Side_AmountInUSD) to a grouped archive query shatters one row per month into 717 rows, and a query with no dimensions at all into 192. Aggregating native Trade_Amount returns the correct 12 rows. All four pages now take USD from the Trading cubes and aggregate native amounts on archive, with a caution box.

This pattern is site-wide: 23 other docs pages carry Solana(dataset: combined) with Trade_Side_AmountInUSD. Out of scope here, worth its own pass.

5. Dead examples on DBC. Three hardcoded addresses returned nothing (7GMB7Xbt… in the market-cap section, whose query also timed out; GowkHeDk… in the PnL section; 4kJkgxzu… in prose). Bonding-curve mints die in hours, so the page now opens with a query that returns mints trading right now and uses placeholders everywhere else.

6. Top-trader queries split each wallet in two. All three unrefreshed pages selected Side.Type and Side.Account as dimensions, producing "bought 0 / sold N" rows per wallet. Replaced with Trading.Trades grouped by Trader.Address.

7. DLMM swap variants still are not decoded (carried from the earlier audit, re-confirmed 2026-09-09). swapExactOut, swapExactOut2 and swapWithPriceImpact2 produce no rows in the chain-level or Trading cubes: 6 of 6 sample transactions per method returned nothing, against 6 of 6 with rows for swap2. That is about 20 percent of DLMM swap instructions. The DLMM page carries a note; the fix belongs in the indexer.

Naming and metadata

• The DYN page is Meteora's DAMM v1. "DYN" is not a Meteora product name, and the page drew 0 clicks at position 13.2. Retitled to "Meteora DAMM v1 API", URL unchanged, with a note explaining the rename and a sidebar_label to match.
• DAMM v2 had the worst CTR of the set: 5,603 impressions, 2 clicks, position 6.8, under the templated title Solana Meteora Damm V2 API. Real title, description and keywords now.
• FAQ blocks added to DBC (9 questions) and DAMM v1 (7); DAMM v2 grows from 4 to 9. Both DBC and DYN had none.
• Each page gains a program-ID section, the four-program comparison table, a facts-only comparison against Meteora's own APIs, and a pricing section.
• Existing section slugs are pinned with explicit heading ids, so the anchors Google already indexes keep resolving. Verified in the built HTML for all three pages that had them.

Verified facts

Claim	Source	Checked
Program IDs and protocol names for all four programs	docs.meteora.ag developer guides; live Trading.Pairs and Solana.DEXTrades	yes
Method casing differs per program: DLMM and DAMM v1 camelCase, DAMM v2 and DBC snake_case	live Instructions on all four programs	yes
Evt* rows are event logs with no account names	live EvtInitializePool rows on DAMM v2	yes
Meteora Data APIs: DLMM 30 rps, DAMM v2 10 rps, DAMM v1 10 rps at damm-api.meteora.ag; no DBC data API	docs.meteora.ag api-reference overviews and llms.txt index	yes
DBC pool authority, migration keeper and its 10 SOL / 750 USDC / 1500 JUP thresholds	docs.meteora.ag DBC developer guide	yes
MET durable on DAMM v2: 778,669 trades since 2025-10-23	live archive query	yes
JitoSOL/WSOL is the deepest DAMM v1 pool, 2.6M trades since the archive floor	live archive and Trading queries	yes
DAMM v1 still swaps (29,315 in 24h) but creates no pools	live Instructions	yes
Trial, rate limits, retention statements	docs/plans/*, docs/graphql/data-coverage-retention.mdx	yes

Query execution (live token, 2026-09-09)

Every GraphQL block on all four pages was extracted from the final files and executed.

Page	queries returning rows	subscriptions delivering	quiet subscriptions
DLMM	6 / 6	3 / 4	pool creation (~55/day)
DAMM v2	5 / 5	2 / 3	pool creation (~1,262/day)
DAMM v1	7 / 7	2 / 2	none
DBC	6 / 6	4 / 6	launches and graduations (~1/min each)

Every quiet subscription was confirmed alive by running the same filter as a 24-hour query. DBC placeholder examples were run with a mint that was trading at the time.

Baseline (GSC, 28 days to 2026-09-08)

Page	clicks	impressions	position
DLMM	19	7,914	6.2
DAMM v2	2	5,603	6.8
DBC	1	2,527	7.6
DYN	0	232	13.2

Re-measure 28 days after merge.

Checks

• npm run build passes with no broken-link or MDX warnings.
• Built HTML verified on all four: titles, descriptions, FAQPage JSON-LD (9/9/7/9 questions), and every preserved anchor resolving.
• No banned vocabulary or em dashes; prose 9+ letter words between 5.1 and 7.2 percent per page.

Follow-ups

• 23 other docs pages use Solana(dataset: combined) with Trade_Side_AmountInUSD and are understating volume the same way.
• docs/graphql/data-coverage-retention.mdx still says every Solana combined cube returns a 500; it returns rows, just fewer than it should.
• IDE saved queries linked from the DLMM page hold the old bodies and need a human with IDE access.
• The DLMM swap-variant decode gap is an indexer fix.

🤖 Generated with Claude Code