Possible Bug in ATA Derivation (Ed25519 Curve Checker & Seed Hashing)

[cienhub]

Hello!
I’ve been working with this library for some time, so first of all thank you for making it available.

I believe I may have found a bug related to #7 , specifically the generation of invalid ATAs due to differences between how this library validates Ed25519 public keys versus how the Associated Token Program performs the same checks on-chain.

After debugging, I identified two methods that may be causing the discrepancy:

1. SolanaRuby::TransactionHelpers::TokenAccount#hash_seeds.

This method flattens and joins the seeds before hashing.
Because Ruby treats binary data as strings, flattening and concatenation can subtly corrupt the byte data, causing mismatched inputs when deriving PDAs.

2. SolanaRuby::Ed25519CurveChecker#on_curve?

This appears to be the primary issue.

• The Y coordinate on the Ed25519 curve is 254 bits long where the 255th bit is the X sign bit that should be cleread out.
  public_key.unpack1("H*").to_i(16) % Q doesn't clear the sign bit.

• Moreover, Y bytes are little-endian, so the bytes must be interpreted as least significant byte first before plugging them into the curve equation.
  The current implementation appears to assume big-endian ordering.

These issues cause the curve checker to incorrectly classify some valid program-derived addresses as invalid.

I have a local implementation with these fixes, and testing against real Solana transactions has so far confirmed their correctness. Previously, certain addresses produced ATAs from the library that differed from those derived by the on-chain ATA Program, consistently resulting in errors such as:
Program Error: "Instruction #1 Failed - Provided seeds do not result in a valid address"

If you think this could be helpful, I'd be happy to open a PR so you can review the changes and discuss further.
Let me know, glad to contribute :)

[AmarildoGrembi]

Hello! I’ve been working with this library for some time, so first of all thank you for making it available.

I believe I may have found a bug related to #7 , specifically the generation of invalid ATAs due to differences between how this library validates Ed25519 public keys versus how the Associated Token Program performs the same checks on-chain.

After debugging, I identified two methods that may be causing the discrepancy:

1. SolanaRuby::TransactionHelpers::TokenAccount#hash_seeds.

This method flattens and joins the seeds before hashing. Because Ruby treats binary data as strings, flattening and concatenation can subtly corrupt the byte data, causing mismatched inputs when deriving PDAs.

2. SolanaRuby::Ed25519CurveChecker#on_curve?

This appears to be the primary issue.

• The Y coordinate on the Ed25519 curve is 254 bits long where the 255th bit is the X sign bit that should be cleread out.
  public_key.unpack1("H*").to_i(16) % Q doesn't clear the sign bit.
• Moreover, Y bytes are little-endian, so the bytes must be interpreted as least significant byte first before plugging them into the curve equation.
  The current implementation appears to assume big-endian ordering.

These issues cause the curve checker to incorrectly classify some valid program-derived addresses as invalid.

I have a local implementation with these fixes, and testing against real Solana transactions has so far confirmed their correctness. Previously, certain addresses produced ATAs from the library that differed from those derived by the on-chain ATA Program, consistently resulting in errors such as: Program Error: "Instruction #1 Failed - Provided seeds do not result in a valid address"

If you think this could be helpful, I'd be happy to open a PR so you can review the changes and discuss further. Let me know, glad to contribute :)

Hey @cienhub, thanks a lot for your feedback. I am happy to hear that the SDK has been useful to you. Unfortunetely, we are not able to work on it now due to financial constraints, but please feel free to open a PR - contributions are very much welcome!

[cienhub]

Hello @AmarildoGrembi

thanks for the reply! Of course, happy to contribute.
I'll open a PR soon

Thanks!