spectra_get_pool_activity

Get recent trade and liquidity activity for a specific Spectra pool. Returns individual transactions: buys, sells, and liquidity adds/removes with USD values, timestamps, and tx hashes.

Pool activity shows only the Curve pool's perspective (IBT ↔ PT swaps and LP events). The Spectra Router batches operations atomically, so any single pool event may be one step of a multi-step strategy. There is no BUY_YT or SELL_YT event type — the pool never touches YT directly. Use mv_get_protocol_context for the full mechanics of how Router batching maps to pool activity types.

Protocol mechanics that affect how activity appears:

• BUY_PT and SELL_PT are Curve pool swaps between IBT and PT.

• There is NO "BUY_YT" or "SELL_YT" type. The pool never touches YT directly.

• YT selling via the Router's flash-redeem internally buys PT from the pool to pair with YT for redemption — so YT sells show up as BUY_PT in the activity log.

• A standalone mint (deposit IBT → PT+YT) does NOT appear in pool activity. However, the Router can batch a mint + LP add in one atomic execute() call. The minted PT + remaining IBT enter the pool as AMM_ADD_LIQUIDITY while the minted YT goes directly to the user's wallet. So AMM_ADD_LIQUIDITY events may ALSO represent YT acquisition — the YT minting is invisible in pool data.

• The Router can also flash-mint atomically: flash-borrow IBT → mint PT+YT → sell PT on the pool → user tops up the shortfall → user receives YT. This shows up as SELL_PT but the user's net action is acquiring YT, not selling PT.

• AMM_REMOVE_LIQUIDITY returns IBT + PT from the pool. Users often follow up by selling the PT (SELL_PT) to recover capital, completing a mint→LP→remove→sell loop that nets them YT at the cost of the PT discount (~1 - ptPrice).

Key principle: any pool event type can be one step of a multi-step Router operation. Do not assume SELL_PT means "user is bearish on PT" or AMM_ADD_LIQUIDITY means "user is providing liquidity for yield." Always cross-reference with spectra_get_portfolio to see what the address actually holds (PT, YT, LP balances) — the holdings reveal the true strategy better than the activity log alone.

Analysis tips — IMPORTANT: each observation below has multiple valid interpretations. The tool output now presents these as competing branches. Do not collapse to one interpretation without cross-referencing spectra_get_portfolio and other data sources.

• High SELL_PT count: could be flash-mint YT accumulation (check YT balance >> PT) OR simple PT liquidation OR one leg of cross-protocol arb. Portfolio resolves this.

• BUY_PT events: could be fixed-rate accumulation OR flash-redeem YT selling (check if YT balance dropped). These predict opposite future behavior.

• Paired ADD/REMOVE liquidity: could be LP cycling in a mint loop OR fee harvesting OR rebalancing. The intent is not observable from pool activity alone.

• Large volume vs small holdings: could be capital recycling (looping) OR completed round-trip (entered and exited) OR funds moved to another venue.

Output includes an Address Concentration section with full addresses and per-address type breakdowns. Use spectra_get_portfolio on those addresses to see their PT, YT, and LP balances. Most analysis can be done without a block explorer — use spectra_get_portfolio on addresses from Address Concentration, and spectra_compare_yield or spectra_get_pt_details for rate context.

Address isolation mode: When you provide an 'address' parameter, the tool filters to that address only, sorts chronologically (oldest first), and adds:

• Sequence Analysis: detects repeating action cycles (e.g., ADD→REMOVE→SELL repeated 8×). Presents COMPETING INTERPRETATION BRANCHES (A/B/C) that predict different future behavior. Small repetition counts (≤5) are flagged as statistically insufficient for extrapolation. CRITICAL: do NOT collapse these branches into a single narrative without external evidence from spectra_get_portfolio or other tools. The branches exist as friction against premature pattern-matching — the tension between them IS the information.

• Flow Accounting: cross-references portfolio data to show PT/YT flow reconciliation. When position shape is observable (e.g., YT-only, PT-only, fully exited), presents competing hypotheses for WHY the position looks that way. Each hypothesis predicts different future behavior. Do not select one without additional evidence.

• Capital Efficiency: compares total activity volume against the address's throughput, flagging high ratios that indicate capital recycling (looping) vs accumulation.

• If the address shows high-frequency activity (>10 txns), consider checking whether it is a contract (programmatic execution via Router execute()) vs an EOA (manual/scripted). Contracts execute atomically; EOAs submit separate transactions. This distinction affects whether apparent "sequences" are truly sequential or batched.

• Contract Detection: checks whether the address is a contract or EOA via on-chain eth_getCode. Contracts execute atomically; EOAs submit sequential transactions.

• Pool Impact: flags when SELL_PT or BUY_PT volume is significant relative to pool liquidity, indicating potential market impact on implied APY.

• Gas Estimates: estimates total gas cost from transaction count using chain-specific gas heuristics. Shows gas as percentage of activity volume and position value.

• Pool Context: fetches pool liquidity and implied APY for baseline context.

• Observation Coverage: quantifies the blind spots of this analysis. Shows: (1) Value coverage — what % of the position is explained by observable activity. (2) Temporal coverage — active days vs dark periods with no observable events. (3) Data source coverage — which of the available data sources were consulted. CRITICAL: coverage metrics bound the domain of validity for ALL interpretations above. If value coverage is low (<50%), the competing interpretation branches are based on a minority of the address's actual behavior. Position sizing should reflect the coverage level, not the confidence of the best-fitting interpretation.

For multi-pool activity scanning, use spectra_get_address_activity to find all pools an address has interacted with in a single call.