PDA terminology
A PDA can be used as a signer authority while its allocated account is System-owned, owned by another program, or not currently allocated. For that reason, Pumpscan says a PDA is derived for a program rather than owned by that program.
| Concept | Meaning |
|---|---|
| Program-derived address (PDA) | An off-curve Solana public key deterministically derived from a program ID and seed set. No Ed25519 private key exists for the address. |
| Signer authority | During cross-program invocation, the deriving program can authorize its PDA with invoke_signed and the matching seeds. |
| Account owner | The on-chain account field naming the program allowed to modify allocated account data. It is independent of which program derived an address. |
| Trader wallet | An attributed on-curve user address. Pumpscan does not promote a raw off-curve Pump trade user to a trader wallet. |
Discovery proof rule
The rule establishes the deriving/signing program for this observation without recovering the PDA seed values or assigning a semantic role such as vault, authority, or custody account. Known infrastructure can receive that role from catalogue metadata.
| Condition | Required evidence |
|---|---|
| Event | A retained, decoded TradeEvent emitted by the Pump core program. |
| Invocation depth | Exactly depth 2: a direct parent program invoked Pump. |
| Raw user | TradeEvent.user is a valid off-curve Solana public key, is not the parent program address, and therefore cannot be a keypair transaction signer. |
| Signer requirement | Pump requires the trade user account to carry signer privilege. At depth 2, only the direct parent can confer that privilege for an off-curve address through invoke_signed. |
| Result | Record the raw user as a PDA derived for the direct parent program, with its retained last-seen timestamp. |
Why deeper CPIs are excluded
At invocation depth 3 or deeper, more than one earlier program exists in the CPI stack. Any eligible caller higher in that stack may have originated signer privilege, so the Pump logs alone cannot identify the deriving program without ambiguity. Pumpscan therefore skips new depth-3-plus PDA discovery instead of assigning the address to the nearest parent.
The Pump Mayhem program is also excluded from this discovery path because its bot account has dedicated smart-account attribution and analytics semantics.
Trader and route separation
An off-curve raw TradeEvent.user remains program-side routing context. If separate log or sibling-event evidence identifies an actual on-curve user, Pumpscan may attribute the trade to that wallet; otherwise the trader stays unresolved. The PDA itself is not inserted into user-event indexes, account accumulators, entry/exit mapping candidacy, or program trader lists.
This separation prevents shared router authorities from appearing as high-volume wallets while preserving the upstream program relationship and the raw transaction evidence.
Discovered and catalogued rows
The API orders retained discovered rows by last-seen time, then appends catalogue-only rows without observation timestamps. A catalogue-only row is configuration-backed knowledge, not evidence that Pumpscan observed the PDA in the current retention window.
| Tag | Source and fields |
|---|---|
| Discovered | Produced by the retained direct-CPI proof rule. The row carries last_seen_at_ms for the current retained record. |
| Catalogued | Declared in Pumpscan's program catalogue as infrastructure for a specific program. It can supply kind and label without a retained trade observation. |
| Both | A catalogued address also observed by the detector. It keeps its last-seen timestamp and catalogue metadata in one row. |
Program page and API
| Interface | Behavior |
|---|---|
| /program/[address]/pdas | Shows PDA address, Discovered/Catalogued tags, optional catalogue label, and retained last-seen time with a refresh control. All PDAs are listed on one page, and the tab is shown only when the program has at least one PDA. |
| GET /v1/programs/:program/pdas | Returns program and pdas, with every PDA in one unpaginated list. Each row includes address, discovered, catalogued, and optional kind, label, and last_seen_at_ms. |
| Ordering | Discovered rows are ordered newest last-seen first, followed by catalogue-only rows. The endpoint takes no paging or sort parameters. |
Address resolution and route safety
A catalogued or retained PDA resolves to its deriving program when that program has an eligible detail page. It does not receive an independent program analytics entity. Every /v1/programs/:program/* handler rejects a known PDA before performing program reads or writes.
Catalogued PDA resolution does not require Redis. Retained discovery does: while Redis is connected, a failed PDA lookup returns Service Unavailable instead of falling through and presenting a possible PDA as an ordinary account or program. During a complete Redis outage, the generic RPC fallback cannot infer an uncatalogued signer-only PDA's deriving program.
Retention and interpretation limits
- Discovery processes newly retained Pump core events; it is not a historical RPC scan and does not backfill every earlier PDA observation.
- Discovered PDA records and indexes expire on the cache retention schedule and can disappear when no newer observation refreshes them.
- The detector does not enumerate seed recipes or every PDA a program can derive.
- An on-curve address cannot be identified as a PDA by this rule, even if a program uses it as infrastructure.
- A derivation/signing relationship does not prove the PDA account's current owner, data layout, token authority, business purpose, or end user.
- Last seen describes Pumpscan's retained observations, not the address's lifetime on Solana.