docs: clarify Solana SIGN_TRANSACTION parsing and System Program Transfer account handling

[turnkeyintern]

Summary

Adds documentation clarity around two related points that have recently surfaced re: Solana transaction parsing

1. SIGN_TRANSACTION vs SIGN_RAW_PAYLOAD

Customers sometimes encounter parsing errors on SIGN_TRANSACTION and are surprised that SIGN_RAW_PAYLOAD succeeds on the same payload. The new subsection makes the tradeoff explicit:

• SIGN_TRANSACTION → parses the transaction (enables Solana policies, returns an assembled signed tx)
• SIGN_RAW_PAYLOAD → no parsing, no policy evaluation, returns raw signature

2. System Program Transfer instructions with extra accounts

The Solana runtime silently ignores accounts beyond the canonical from/to pair in System Program Transfer instructions. Turnkey's parser now matches this permissive behavior.

This came up when using the Jupiter Limit Order v2 deposit endpoint, which includes a third account in the transfer instruction. Previously, SIGN_TRANSACTION returned a parsing error on these transactions; SIGN_RAW_PAYLOAD was the workaround. We've now included a fix that removes that friction, and the docs now reflect the correct behavior.

Files changed

• networks/solana.mdx — new subsections in "Transaction parsing, policies, and signing"
• networks/solana-transaction-construction.mdx — added a <Note> in the Jupiter/third-party section

[Copilot]

Pull request overview

This PR updates the Solana documentation to clarify the behavioral differences between SIGN_TRANSACTION and SIGN_RAW_PAYLOAD, and to document Turnkey’s permissive handling of System Program Transfer instructions that include extra accounts (matching Solana runtime behavior).

Changes:

• Added a new subsection explaining SIGN_TRANSACTION vs SIGN_RAW_PAYLOAD tradeoffs (parsing/policies vs raw signing).
• Documented acceptance of System Program Transfer instructions that include accounts beyond the canonical from/to.
• Added an additional <Note> in the sponsored-transaction construction doc calling out Jupiter’s extra-account transfer pattern.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
networks/solana.mdx	Adds new subsections under transaction parsing/signing to explain endpoint behavior and extra-account transfers.
networks/solana-transaction-construction.mdx	Adds a Jupiter-related note about extra accounts in System Program Transfer instructions.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

SIGN_RAW_PAYLOAD isn’t necessarily a “blind” byte-for-byte signature and it can still return errors (e.g., invalid encoding / unsupported hashFunction). To avoid implying it can’t fail or that it always signs the raw bytes as-is, consider rephrasing to something like: it does not parse the Solana transaction (so no Solana parsing/policy evaluation), and it signs the provided payload after decoding and applying the selected hash function.

Suggested change

	- **`SIGN_RAW_PAYLOAD`** does not parse the transaction — it blindly signs the bytes provided. This means no parsing errors, but also no policy evaluation against transaction contents. You receive the raw signature as output and must assemble it back into the transaction yourself.
	If you do not need Solana transaction policies and are working with transactions from third-party APIs that may not conform to common instruction patterns, `SIGN_RAW_PAYLOAD` is a viable fallback.
	- **`SIGN_RAW_PAYLOAD`** does not parse the Solana transaction — there is no Solana-aware parsing or policy evaluation of the transaction contents. It signs the provided payload after decoding and applying the selected hash function, and can still return errors (for example, for invalid encoding or an unsupported `hashFunction`). You receive the raw signature as output and must assemble it back into the transaction yourself.
	If you do not need Solana transaction policies and are working with transactions from third-party APIs that may not conform to common instruction patterns, and you are comfortable handling payload encoding and hash function selection yourself, `SIGN_RAW_PAYLOAD` is a viable fallback.