Funding & Coordination

latest_native_in

Last native MON received by a wallet. Primary funding signal: "when was this wallet last funded?"

GET /api/latest_native_in?address=0x...

Returns: latestNativeIn (from, amount, amountWei, txHash, blockNumber, timestamp, source), historicalCoverageStartBlock

The source field indicates how the funding was detected:

• "direct" — a standard wallet-to-wallet MON transfer (high confidence)
• "internal" — MON received via a contract interaction such as delegation, staking, or bridge (fallback when no direct transfer exists)

Use case: Fresh wallet detection, funding recency for sniper bots.

wallet_funding_source

First native MON ever received by a wallet. Answers: "who originally funded this wallet?"

GET /api/wallet_funding_source?address=0x...

Returns: firstFunding (from, amount, txHash, blockNumber, timestamp, source), historicalCoverageStartBlock

Same source field as latest_native_in ("direct" or "internal").

Use case: Origin tracing, launchpad tools, fresh vs exchange-funded detection.

funding_recipients

Wallets this address has funded (parent view). "Who has this wallet sent MON to?"

GET /api/funding_recipients?address=0x...&blocks=10000&limit=100

Use case: Coordination detection, bundler/funder analysis.

recent_token_transfers_out

Token transfers from a wallet. Redistribution signal: "is this wallet moving tokens to others?"

GET /api/recent_token_transfers_out?address=0x...&blocks=10000&limit=50

Use case: Fresh wallet snipe detection (funded + token buy), redistribution tracking.

Typical Polling Workflow

Today, bots poll these endpoints in a loop to detect "fresh wallet bought token":

1. Poll latest_native_in for funding
2. Poll recent_token_transfers_out for token buys
3. Combine logic locally

Real-time signals (coming) will push these events instead of requiring polling.