Bug: Raydium Parser Swaps TokenIn and TokenOut for Pump.fun Migrated Tokens

[vexelgray]

I've identified a potential bug in the Raydium transaction parser within this library. It appears that for transactions involving tokens that have migrated from Pump.fun to Raydium, the parser incorrectly swaps the tokenIn and tokenOut fields in the parsed output.

This issue is not observed with tokens that were originally deployed directly on Raydium.

To demonstrate this problem, I've provided two example "buy" transactions (WSOL being exchanged for another token):

Example 1: Transaction with a Pump.fun Migrated Token

Signature: 48Sysuy1xSfiUhuH7Ktj4yri2RCoPuDyCWXbgKZqACTXE5oPVUP1C2MLtEeM2icbQrp9z4Q3gDPXWSEPx6BHRv8w

Parsed Output:

RaydiumParser {
  amountIn: 248526n,
  amountOut: 60166396n,
  baseReserve: 565278097927n,
  quoteReserve: 137193807824049n,
  tokenIn: PublicKey [PublicKey(hTRDn7zE5tDHRnjj6Qms2WG1zEGv9ii6AiwfgbFpump)] {
    _bn: <BN: a5d1a5300134806cc52d503758a539194031cc6b13795f6b4bbc4f628fc17af>
  },
  tokenInDecimal: 6n,
  tokenOut: PublicKey [PublicKey(So11111111111111111111111111111111111111112)] {
    _bn: <BN: 69b8857feab8184fb687f634618c035dac439dc1aeb3b5598a0f00000000001>
  },
  tokenOutDecimal: 9n,
  user: PublicKey [PublicKey(AA95dMp7ZmqV2KM7x4q1hXiaTtwaboNyz2ZhJNd12g42)] {
    _bn: <BN: 88108ba27d19e33d676a3c0e934329d2a8a7332b5bef9b8bfc69be3651b80f93>
  },
  poolId: PublicKey [PublicKey(3eGxLTiyoDwoRc9vnzSERz2yqf66xgBQgHBJu4EDSNWt)] {
    _bn: <BN: 2743e731bb9cec57bab31fd62a15660cc60547c239bfe7ba773feee788143041>
  }
}

Problem: In this case, the expected behavior is that tokenIn should represent WSOL (SOL being spent) and tokenOut should be the migrated Pump.fun token (token being received). However, the parser output incorrectly reverses these. The tokenIn is identified as hTRDn7zE5tDHRnjj6Qms2WG1zEGv9ii6AiwfgbFpump (the migrated token) and tokenOut as So11111111111111111111111111111111111111112 (WSOL).

Example 2: Transaction with a Token Deployed Directly on Raydium

Signature: 5QAijtNpbKBemWzGefaqcwRjRFuSazkCCa4gRxh6DW8E1bqBDoeK2aDtE7QRMV1ddXv61uTagtp7AgkfZihyxoFF

Parsed Output:

RaydiumParser {
  amountIn: 100000000n,
  amountOut: 113305726n,
  baseReserve: 238920252098n,
  quoteReserve: 210236442000n,
  tokenIn: PublicKey [PublicKey(So11111111111111111111111111111111111111112)] {
    _bn: <BN: 69b8857feab8184fb687f634618c035dac439dc1aeb3b5598a0f00000000001>
  },
  tokenInDecimal: 9n,
  tokenOut: PublicKey [PublicKey(EkDsamMWbbEFPu7oV19SGo7ZUETDSGy56MK21MkNN4S5)] {
    _bn: <BN: cc3a75993d7314587dae2ff535621e758956391fa49b7453e7a28e8f97f13092>
  },
  tokenOutDecimal: 6n,
  user: PublicKey [PublicKey(4Ndu2tVrJee7sopWiJ97Pn5nzLC5Gmp3JbmRX7CscyPE)] {
    _bn: <BN: 321dfa3b5b878ad836fd7c44cf5bb9a3eb9a0dbcdc11b6f5bad8e24886e393e1>
  },
  poolId: PublicKey [PublicKey(9wncFDQMp8s68ufMR2VGJXCApGAmxaGScjum7XrE92g)] {
    _bn: <BN: 24a97f51c0574a6e8dec74072ed4a9e136bf2b439e78bf586cae51aef0215d9>
  }
}

Observation: The parsing in this example appears to be correct, with tokenIn being WSOL and tokenOut being the other token (EkDsamMWbbEFPu7oV19SGo7ZUETDSGy56MK21MkNN4S5).

Impact: This incorrect parsing leads to a misrepresentation of the actual tokens being traded in transactions involving Pump.fun migrated tokens, which can affect applications relying on accurate Raydium transaction data.

Could you please investigate this issue? Thank you for your time and attention to this matter.

Sincerely,

[Tee-py]

This has already been fixed in the latest version of the package. Kindly confirm that the version you're currently using is the latest one.

[vexelgray]

Thanks for the quick response!

I appreciate you letting me know that this should be fixed in the latest version. I'm fairly confident I'm using the most recent version of the package, as I just updated it recently.

To be absolutely sure, could you possibly test the two transaction signatures I provided in the issue description using your latest version?

Signature 1 (Pump.fun migrated token): 48Sysuy1xSfiUhuH7Ktj4yri2RCoPuDyCWXbgKZqACTXE5oPVUP1C2MLtEeM2icbQrp9z4Q3gDPXWSEPx6BHRv8w

Signature 2 (Directly deployed Raydium token): 5QAijtNpbKBemWzGefaqcwRjRFuSazkCCa4gRxh6DW8E1bqBDoeK2aDtE7QRMV1ddXv61uTagtp7AgkfZihyxoFF

If you run these through the parser on your end, it would help confirm whether the issue is indeed resolved in the latest release, or if perhaps there's still something lingering, specifically with these migrated tokens.

Thanks again for your time and help!

[Tee-py]

appreciate you letting me know that this should be fixed in the latest version. I'm fairly confident I'm using the most recent version of the package, as I just updated it recently.

To be absolute

Figured the issue
install the latest version (0.1.5)

[vexelgray]

Great! Thanks for looking into this so quickly.

I've updated to version 0.1.5, and it does indeed seem like the token swap issue is resolved for the migrated Pump.fun tokens. That's excellent news.

(Just a small note: I didn't initially see version 0.1.5 listed in the "Releases" section on GitHub, so it wasn't immediately obvious that a new version was available. Perhaps updating the releases page might be helpful for other users in the future.)

However, while testing with version 0.1.5 and the same transaction signature (48Sysuy1xSfiUhuH7Ktj4yri2RCoPuDyCWXbgKZqACTXE5oPVUP1C2MLtEeM2icbQrp9z4Q3gDPXWSEPx6BHRv8w), I've noticed another discrepancy.

According to Solscan (https://solscan.io/tx/48Sysuy1xSfiUhuH7Ktj4yri2RCoPuDyCWXbgKZqACTXE5oPVUP1C2MLtEeM2icbQrp9z4Q3gDPXWSEPx6BHRv8w), the actual user/signer of this transaction is 2mz4ydwRMeQFRLuPdQapVsDRp4hJri8bbx12de9HJCrG.

However, the parsed output from version 0.1.5 still identifies a different user: AA95dMp7ZmqV2KM7x4q1hXiaTtwaboNyz2ZhJNd12g42.

Here's the parsed output again for reference:

RaydiumParser {
  amountIn: 248526n,
  amountOut: 60166396n,
  baseReserve: 565278097927n,
  quoteReserve: 137193807824049n,
  tokenIn: PublicKey [PublicKey(So11111111111111111111111111111111111111112)] {
    _bn: <BN: 69b8857feab8184fb687f634618c035dac439dc1aeb3b5598a0f00000000001>
  },
  tokenInDecimal: 9n,
  tokenOut: PublicKey [PublicKey(hTRDn7zE5tDHRnjj6Qms2WG1zEGv9ii6AiwfgbFpump)] {
    _bn: <BN: a5d1a5300134806cc52d503758a539194031cc6b13795f6b4bbc4f628fc17af>
  },
  tokenOutDecimal: 6n,
  user: PublicKey [PublicKey(AA95dMp7ZmqV2KM7x4q1hXiaTtwaboNyz2ZhJNd12g42)] {  // <--- Incorrect User
    _bn: <BN: 88108ba27d19e33d676a3c0e934329d2a8a7332b5bef9b8bfc69be3651b80f93>
  },
  poolId: PublicKey [PublicKey(3eGxLTiyoDwoRc9vnzSERz2yqf66xgBQgHBJu4EDSNWt)] {
    _bn: <BN: 2743e731bb9cec57bab31fd62a15660cc60547c239bfe7ba773feee788143041>
  }
}

It seems the user field is still not being parsed correctly for this transaction. The expected user should be 2mz4ydwRMeQFRLuPdQapVsDRp4hJri8bbx12de9HJCrG.

[Tee-py]

p7ZmqV2KM7x4q1hXiaTtwa

Cool 👌

AA95dMp7ZmqV2KM7x4q1hXiaTtwaboNyz2ZhJNd12g42 was the address that sent WSOL into the pool
2mz4ydwRMeQFRLuPdQapVsDRp4hJri8bbx12de9HJCrG was the address that received the token.

The parser's user field is the account that signed the raydium instruction, which is also the source account: AA95dMp7ZmqV2KM7x4q1hXiaTtwaboNyz2ZhJNd12g42.

Also, if you check Solscan, you'd see that there are two signers; 2mz4ydwRMeQFRLuPdQapVsDRp4hJri8bbx12de9HJCrG and AA95dMp7ZmqV2KM7x4q1hXiaTtwaboNyz2ZhJNd12g42.