Document the Solana signing flow for marketplace offers

[Pierre-Michard]

Why

A developer spent 9 days blocked signing a SolanaTokenTransferAuthorizationRequest for a SINGLE_SALE_OFFER, and concluded the docs only covered StarkEx. Two support investigations agreed with him. They were wrong — examples/solanaTokenTransfer.js already documented it — but the example is unreachable from the sections a developer actually reads when building offers, and it omitted the one step he could not work out for himself: where the Solana signing key comes from.

What changed

Discoverability. The README now has an "Authorization request types" section stating plainly that prepareBid / prepareOffer / prepareAcceptOffer return different request types depending on the asset and payment rail, with a table mapping each type to its example file and approval field. "Bidding on auction", "Creating offers" and "Accepting offers" each point at it. The StarkEx material is untouched — it is still valid for legacy flows.

The actual gap. Nothing said where the Solana key comes from. It is derived from the exported Sorare (Ethereum) private key via SLIP-0010 on m/44'/501'/0'/0'. New example examples/solanaKeyPair.js does the derivation and links back to the existing private key export screenshot as the starting point. The derived address equals the request's senderAddress, which is documented as the fastest way to confirm a derivation before debugging signatures — solanaTokenTransfer.js now asserts exactly that.

Failure modes. The three things that produce a well-formed but always-rejected signature are called out in both the README and the example: you sign the SHA-256 hash rather than the string; assetId is not in the signed message (the card is merkleTreeAddress + leafIndex); senderAddress is not either, while transferProxyProgramAddress and originator are. Also noted that '0x' is a literal empty data field, not a placeholder.

Bug fix. solanaTokenTransfer.js was building a solanaBankTransferApproval — the wrong approval field for that request type.

@sorare/crypto. Now stated explicitly to be StarkEx-only; the user asked this directly and the docs left it ambiguous.

Verification

• Field names, the approval shape (signature / nonce / expirationTimestamp) and the request fields checked against the GraphQL types.
• All four Solana/Base examples run and produce approvals; node --check passes on every example touched.
• solanaKeyPair.js derives 8ixw6XQW2tuZhc1xgbhh6bq6YvL5K5nXLsN9LjrzMrxq from the Ethereum key already used in baseBankTransfer.js — which is exactly the senderAddress in solanaBankTransfer.js, so the worked example is self-consistent across the repo.
• micro-key-producer added to examples/package.json; @solana/kit stays on the ^5.0.0 already in use.

🤖 Generated with Claude Code