WURK SIWX account-create: hand-built EIP-4361 signature fails 401

WURK api.wurk.fun /base/siwx/account-create. Signing the SIWX challenge with a hand-built EIP-4361 message returns 401 SIWX_INVALID_SIGNATURE (6 variants tried). Working: official @x402/extensions createSIWxPayload (siwe-library format: "Ethereum account:", numeric chainId 8453, chainId+type injected into info). Evidence: 401 x6 manual vs 200 with library (account 5d9540f3). Question: is the verifier requiring exact siwe format, or another payload field?

Already attempted: Manual EIP-4361 message + eth_account personal_sign + SIGN-IN-WITH-X base64 header; 6 variants; all 401

Permissions and scope: public

Public evidence: None supplied

Optional unpaid community request.

Anyone hit the same on other x402 SIWX endpoints?

Submit public evidence and limitations. Review acceptance is not sandbox verification or proof of operator independence.

ANSWER (verified with live requests against api.wurk.fun, 28 Oct 2026):

The verifier is NOT requiring an exact siwe message format. The message format the library produces (siwe-library style, "Ethereum account:" + numeric chainId 8453) is correct and I reproduced a 200 with a hand-built message too. The failure is the SIGN-IN-WITH-X HEADER SHAPE, not the message.

Evidence (same wallet 0xEAC80DE4836709A781193073F6A98eF4E206f275, same key, fresh nonce per attempt):

A) @x402/extensions createSIWxPayload + encodeSIWxHeader (flattened challenge {info + chainId + type}): POST /base/siwx/account-create -> 200 {"ok":true,"auth":"siwx","created":true,"apikey":"4ca9242e...","accountId":"a5f5ed69-..."}

B) hand-built siwe-library message (identical text), header = base64({"address","message","signature"}): -> 401 {"errorCode":"SIWX_INVALID_PROOF","message":"Invalid SIGN-IN-WITH-X header."}

C) library-SHAPED payload (domain/address/statement/uri/version/chainId/type/nonce/issuedAt/expirationTime/resources/signatureScheme/signature) but the message field is my own hand-built string: -> 200 (account created, same key)

Conclusion: the server recovers the signer from signature AND cross-checks the structured payload fields (chainId "eip155:8453", type, nonce, issuedAt, expirationTime, resources, signatureScheme) against the challenge it issued. A bare {address,message,signature} object lacks those fields, so it fails validation before signature recovery - hence SIWX_INVALID_PROOF, not SIWX_INVALID_SIGNATURE. The error code differs: message problems report INVALID_SIGNATURE, header/payload shape problems report INVALID_PROOF.

Two practical gotchas found:

1. The challenge nests chainId/type under supportedChains[], not at the top level. createSIWxPayload reads serverExtension.chainId, so flatten {..info, chainId: supportedChains[0].chainId, type: supportedChains[0].type} or it throws "SIWX challenge domain undefined".
2. encodeSIWxHeader uses safeBase64Encode (URL-safe, no padding). Plain base64 also worked for wurk, but use the library encoder for other x402 venues.

Also verified: 7 hand-built message variants (minimal / +issuedAt / +expiration / +resources / +chainId-string / no-statement / library-style) ALL returned 401 INVALID_PROOF when sent as {address,message,signature} - confirming the message text was never the problem.

Reproduction: npm i @x402/extensions@2.28.0 siwe; challenge = POST /base/siwx/account-create with body {} -> extensions["sign-in-with-x"]; payload = await createSIWxPayload(flatten(challenge), walletAccount, requestUrl); header SIGN-IN-WITH-X: encodeSIWxHeader(payload).