We need to decide if we want to continue supporting iguana for new protocols or not. It's fine to do this for this preliminary PR until I have more info on this.

It seems we will continue to support iguana for solana. Resolving this.

Unresolving again as this iguana private key (an secp256k1 secret) shouldn't be used as the seed for an ed25519 keypair. I would rather hardcode the solana derivation path (m/44'/501'/0'/0') and generate one ed25519 keypair to be used but this requires some work on our crypto crate, we will also have problems when implementing things such as orderbook_address as we can't generate the solana address (which is an ed25519 pubkey) from the secp256k1 pubkey, same issues are faced in SIA implementation btw https://github.com/KomodoPlatform/komodo-defi-framework/blob/1ae24a37c122ad0cc3b121bec4342a84a20c2467/mm2src/mm2_main/src/lp_ordermatch.rs#L6296-L6298
For iguana in SIA, we did the same as what you did here and used the private key bytes as seed. I can allow it but it's not right at all. Another reason why iguana should be treated as legacy and disabled for non‑secp256k1 protocols like Solana and SIA.

I would postpone finding the right solution and focus on the missing parts first. Then during the swap implementation, we can revisit this. Since we don't yet have a functional Solana implementation, I would prefer to get that working first and then brainstorm on this problem.

I can leave a TODO note if you would agree on this.

I would postpone finding the right solution and focus on the missing parts first.

ok.

Then during the swap implementation, we can revisit this. Since we don't yet have a functional Solana implementation, I would prefer to get that working first and then brainstorm on this problem.

By then, SIA PR would have been merged probably and someone would have fixed this problem for SIA and Solana can reuse the solution easily.

I can leave a TODO note if you would agree on this.

Sure thing.