Every trade on a pump.fun bonding curve or PumpSwap pool splits execution SOL into distinct fee components. While developers often treat trading fees as a single scalar deduction from input amounts, modern pump.fun trade instructions decompose fees across several specific recipients and mechanisms behind the scenes.
Understanding where these fees actually move is critical for builders constructing wallet trackers, leaderboard analytics, or automated trading strategies. Inaccurately parsing these fee legs leads to severe accounting errors, including false recipient payouts and incorrect volume calculations.
The Multi-Leg Anatomy of a pump.fun Trade Fee
Trade instructions on pump.fun do not treat fees as a monolithic pool. Instead, fees are segmented across distinct execution legs depending on the contract version, the trade venue, and whether the token is on a bonding curve or a migrated pool:
- Protocol Fee: Directed to designated protocol fee collector accounts to fund ongoing platform infrastructure and development.
- Creator Fee: Distributed to the deployer wallet that created the token, giving creators ongoing yield based on trading volume.
- Buyback Share: Reserved allocations designated for automated token buyback mechanisms or promotional protocol operations.
- Embedded Reserve Retention: Fee portions that remain directly inside the bonding curve or liquidity pool reserve balance rather than executing as an external transfer.
Crucially, not every fee leg results in a separate native SOL transfer instruction to an external wallet during execution. Some legs are accounted for in program state and settled separately or retained to support curve invariant rules.
The All-Zero Recipient Pitfall: Retained Fees vs. Real Transfers
A frequent pitfall in parsing pump.fun trade events occurs when indexers inspect the fee recipient fields emitted in program event logs or instruction data. In newer event schemas, when a specific fee leg is retained in the curve or pool rather than transferred to an external wallet, the contract populates the fee recipient field with the system program ID or default all-zero public key: 11111111111111111111111111111111.
Naive indexers that aggregate total earnings by recipient public key will group all of these unassigned fee allocations under 11111111111111111111111111111111. As a result, the analytics pipeline reports the System Program as the single largest fee earner on the platform, creating a completely phantom top earner on dashboards and reports.
An all-zero recipient key does not represent an actual payment to that address. Instead, it signifies that the fee leg remained inside the bonding curve or pool reserve. Data pipelines must explicitly filter default keys and reclassify those allocations as internal pool reserve retention rather than outbound transfers.
Multi-Hop Fee Capping and Routed Swaps
Beyond single-curve executions, routed swaps across PumpSwap pools add another layer of accounting complexity. Historical DEX models frequently charged an unadjusted base fee at every individual hop in a multi-step swap route, compounding trading friction for users and confusing event parsers.
Following protocol updates (such as those detailed in October 2026 reporting by TokenPost), pump.fun updated multi-hop fee logic so fees no longer accumulate linearly at every step of a routed swap. Instead, multi-hop fee structures are capped or scaled across intermediate hops to prevent multi-pool trades from taking repeated full fee penalties.
Pipelines that calculate fees by multiplying a fixed percentage by the number of routed hops will overestimate total fee costs on routed trades. Instead, pipelines should read the explicit fee fields from parsed instruction events. Developers getting started with real-time event streaming can consult the Tessium quickstart guide to ingest pre-parsed event streams where fee fields are already validated and normalized.
A Practical Checklist for Solana Fee Analytics Pipelines
To maintain accurate financial records and avoid misattribution bugs when building pump.fun analytics, ensure your ingestion system follows this technical checklist:
- Filter All-Zero Keys: Never attribute fee amounts associated with 11111111111111111111111111111111 to an external wallet; flag them as pool-retained liquidity.
- Decompose Fee Legs: Store protocol fees, creator rewards, and buyback shares as distinct database columns rather than a single aggregated sum.
- Account for Multi-Hop Capping: Rely on emitted event data or exact balance changes rather than multiplying flat rates across intermediate swap hops.
- Contextualize Venue Type: Distinguish pre-graduation bonding curve fee rules from post-graduation PumpSwap pool executions in your schema.
- Use Standardized Event Feeds: Eliminate manual transaction decoding by connecting to dedicated WebSocket streams on Tessium streams, receiving clean, structured trade and fee data on every block.