Update, October 14: Pump.fun’s developer documentation now describes an additional layer of coin-to-coin pairing, but its public help page still states the earlier limit. This update replaces the article’s treatment of one secondary hop as a universal current boundary. The original October 9 publication date and URL are preserved; the newly reviewed developer announcement is dated October 13, not today.
In its October 13 repository announcement, Pump.fun says a new coin can be paired with a Pump coin that is itself paired with another Pump coin. The documented path can therefore contain three markets, rather than the two in the initial secondary-pair example.
However, the Supported Pair Assets help page, checked October 14 and carrying an October 9 update date, still says “One hop only.” Its example allows B to pair with A when A was launched against SOL, but says C cannot pair with B. The repository now describes that extra layer as enabled. The two texts do not give a reader the same answer.
Dev.Cooking has verified the documentation difference, not resolved it by testing a launch. The reviewed sources do not establish which nested choices appear in every app interface or region. A documented instruction is not enough to promise that a particular creator can use it through the app.
What changed after the first Custom Pairs release
Pump.fun introduced Custom Pairs before these updates. The original feature let a creator choose from supported pair assets instead of launching only against SOL. The October 8 expansion opened that role to eligible Pump-created coins as well, including coins on the bonding curve and coins that graduated to PumpSwap, according to the platform’s accompanying explanation.
The platform says coins that previously graduated to Raydium generally are not eligible unless Pump has separately whitelisted them. It named Fartcoin as an example of a whitelisted exception. That means a ticker, market size or history on Pump is not enough to establish eligibility. The exact mint and its launch path matter.
No new coin is automatically backed by the older community whose token it uses. Pairing establishes a trading relationship between two assets. It does not transfer governance, intellectual-property permission, project endorsement or control of the child token to holders of the parent coin.
This distinction also keeps Pump's marketing claim in proportion. The announcement says the model can produce “less PVP, more PVE,” a shorthand for communities building together instead of rotating attention between rival launches. That is a goal, not a measured result. The sources reviewed by Dev.Cooking do not yet show whether the design improves liquidity retention, reduces abandoned launches or changes trader behavior.
Depth counts dependencies, not token names
The pinned coin-creation instructions define depth 0 for a coin launched against SOL, USDC or another listed quote asset. A coin paired with a Pump coin takes that quote coin’s depth plus one. The document says depth 2 was enabled October 13 and identifies Global.max_curve_depth as the platform-controlled limit. It does not announce unlimited nesting.
Consider a hypothetical sequence: A is paired with SOL, B with A, and C with B. A has depth 0, B depth 1 and C depth 2. Buying C from SOL can involve SOL/A, A/B and B/C. The extra layer is a market dependency, not a new form of backing or a promise by A’s community to support C.
The creation instructions require account information for the quote coin and the coins underneath it. They also describe a refusal when a required upstream curve has finished but its migration pool does not yet exist. Nesting therefore requires attention to the state of the chain below the new launch, not only to the final coin’s metadata.
A single instruction is not a single market
The simpler depth-1 example still applies: CHILD is paired with PARENT, which is paired with SOL. A buyer beginning with SOL crosses two markets. A depth-2 route adds another Pump coin between the buyer’s starting asset and the final token.
PumpSwap’s multi-hop instructions describe one instruction spanning multiple pools or curves, without requiring the intermediate coins to enter the user’s wallet. The minimum-output check applies to the final amount. That can simplify execution, but it does not merge the reserves of the underlying markets or make their prices independent of one another.
Pump's fee documentation says its own interfaces apply the protocol fee once on the first pool in a multi-hop route, then apply creator or holder-reward and liquidity-provider fees once on the final pool. It warns that outside interfaces which have not adopted this routing logic may charge fees at every pool.
For a custom-pair coin still on its bonding curve, Pump currently lists a 1.25% total fee: 0.95% to the protocol and 0.30% to the creator, with no liquidity-provider fee. After graduation to the canonical PumpSwap pool, the listed total is 0.30%: 0.05% to the protocol, 0.05% to the creator and 0.20% to liquidity providers. Holder rewards can replace the creator fee at a creator-selected rate within Pump's published limits.
Those percentages describe platform rules, not the buyer's complete execution cost. Slippage can arise in the PARENT and CHILD markets and, for a nested route, another upstream market. A route that looks liquid on its final pool can still produce a poor fill if an earlier market is shallow.
Every added quote market extends the dependency chain
In a conventional SOL-paired launch, traders already need to examine the new token's supply, permissions, holder concentration and pool depth. A Pump-coin pair adds the PARENT market to that checklist. A nested pair means working through the additional quote relationship too.
Pump's terms say the platform does not review, audit or endorse Secondary Pair Assets. They also warn that liquidity, value and displayed market capitalization can depend on multiple pools. A SOL or USDC valuation derived through that route is an indicative conversion, not proof that the full displayed value can be sold into the underlying asset.
Creator fees or holder rewards may also be paid in the paired Pump coin. A large reward balance can therefore be difficult to realize if that asset has thin liquidity or rapidly falling demand. The denomination matters as much as the displayed quantity.
Readers can extend Dev.Cooking's liquidity versus market-cap guide to the whole route. Instead of asking only how much value sits behind CHILD, ask how much executable depth exists at every conversion needed to reach SOL or USDC. The pool-versus-order-book lesson explains why a displayed price is not an exit quote for an arbitrary trade size.
What to record before trading a custom pair
Start with the full mint chain. Copy the new coin’s address and the addresses of each Pump coin below it. Identify the supported quote asset at the bottom, then distinguish the developer-documented depth from the options actually offered by the interface being used. Do not treat the still-published one-hop help text and the newer depth-2 repository text as interchangeable.
Then inspect every pool or curve in the proposed route at the intended trade size. Record reserves, migration state and estimated slippage rather than relying on a converted market-cap label. Compare the final quoted output and minimum received, not just the apparent liquidity beside the token name.
Finally, identify the reward asset. A creator-fee or holder-reward dashboard can show a meaningful number while denominating it in a market that is difficult to exit. Pump's new arrangement does not make every paired token equivalent to SOL or USDC.
The same evidence discipline applies to holder analysis. A large PARENT balance inside a CHILD pool is not a person, and a routing wallet is not automatically a team wallet. Dev.Cooking's holder-list investigation guide explains how to separate addresses, accounts and inferred controllers before making claims about ownership.
The October 13 repository update expands the documented architecture; the unchanged public help text leaves a narrower description in circulation. Neither source makes a paired token safe. The reader’s immediate problem is to establish which rule and route a particular operation actually uses, before treating a familiar ticker as a familiar exit asset.
Reporting and image notes
Original Dev.Cooking news analysis updated October 14 after reviewing the October 13 developer-repository change and the current public help, fee and terms pages. The original October 8 announcement and Phemex’s contemporary event report remain historical references for the initial expansion. Repository links are pinned to the reviewed commit. Enablement is attributed to Pump.fun’s documentation, not an independent read of mainnet configuration. No token was created, transaction submitted or app-access availability tested. The A/B/C sequence is hypothetical. The conflicting public texts remain unresolved in this report; no endorsement, improved liquidity outcome or token-safety finding is claimed.
The existing cover uses MohsenVaje’s authentic Pump.fun logo, licensed CC BY-SA 4.0, inside a pair-routing composition. The exact file’s license was rechecked October 14. The logo was downscaled, not enlarged; the adaptation remains shared under the same license. Its branching nodes are illustrative, not a screenshot or a measured nested route. No affiliation or endorsement is implied. Corrections: Hello@dev.cooking.