Auth/verify fails: signatures[0] must be ≤ 500 characters (account abstraction)

Embedded Wallets / Web3Auth was working fine for us, but starting today every login hits the wallet auth/verify call and returns validation errors like:

"signatures[0]" length must be less than or equal to 500 characters long

We’re on account_abstraction (AA) with the usual id-token flow. We didn’t change our app or dashboard settings; to rule out our code we also tried a minimal single-page app with only sign-in, same error, separate node_modules / lockfile.

Versions in package.json

  • @web3auth/modal: 10.15.0

  • @web3auth/auth: 10.8.0

  • @web3auth/ws-embed: **5.6.0

    On Sapphire mainnet and using Vite 6**

After OAuth / modal sign-in, the flow hits POST https://api-wallet.web3auth.io/auth/verify and returns 400 with validation on signatures: each signatures[n] string must be ≤ 500 characters. With account_type: account_abstraction (and AA / wallet services enabled), the client sends large signatures entries and the call fails, so the user cannot complete login.

accountAbstractionConfig + social login → auth/verify payload includes signatures[] strings > 500 chars → API rejects.

Exact error message
{
“message”: ““signatures[0]” length must be less than or equal to 500 characters long”
}

Is auth/verify supposed to accept MPC signatures on the same request as account_abstraction + id_token, or if this is a known regression / version mismatch?

Thanks in advance

Thanks — I’m on the MetaMask / Embedded Wallets (Web3Auth) team. I reviewed your report.

Short summary & assessment

  • Likely an API-side validation regression: auth/verify is rejecting MPC/AA signatures >500 chars when using account_abstraction + id_token. This matches your error: “signatures[0] length must be less than or equal to 500 characters long.”
  • I checked docs/KB and found no published change imposing a 500-char limit for AA/MPC signatures — this appears unexpected and needs escalation.

What I already have to start escalation

  • SDK: MetaMask Embedded Wallets (Web3Auth)
  • Packages/versions: @web3auth/modal 10.15.0, @web3auth/auth 10.8.0, @web3auth/ws-embed 5.6.0
  • Platform: Web (Vite), Sapphire mainnet
  • Repro: minimal SPA → POST https://api-wallet.web3auth.io/auth/verify → 400 validation error for signatures[*] > 500 chars
  • Exact API error: { “message”: “"signatures[0]" length must be less than or equal to 500 characters long” }

What I need from you (please attach to your Builder Hub topic)

  • The failing auth/verify request body (JSON). Redact private keys/JWTs, but keep id_token, account_type, and either an example signature string OR its length + encoding (base64/hex).
  • Full HTTP response body + status and any response headers; include request-id / x-request-id if present.
  • HAR or curl of the failing POST, and a timestamp (UTC) when you saw it.
  • Confirm whether disabling account_abstraction (if you can test) allows the flow to succeed.

Immediate guidance

  • If you can safely test with account_abstraction disabled or a non-AA social login, that will confirm if this is AA-specific. If you can’t change production, don’t alter settings — just share the request/response above.
  • There’s no safe client-side workaround to recommend right now; this appears to be an API validation rule.

Next steps from our side

  • I’m escalating this to the Embedded Wallets backend team now with the details you provided. A human engineer will follow up on the Builder Hub thread after they review the request/response you attach.

Thanks — attach the auth/verify payload + response and I’ll push this directly to the backend team for priority review.

Note: This response was generated by an AI bot and may require further verification. The MetaMask Community Team has tracked this issue and will be responding as soon as possible.

Additionally, we would recommend you to join our monthly Office Hours to discuss this with our engineering team. MetaMask Developer Office Hours

1. Failing POST …/auth/verify request body (JSON, redacted)

URL: https://api-wallet.web3auth.io/auth/verify
Method: POST
Content-Type: application/json

{

“public_address”: “0x4470…2A3510”,

“id_token”: “<REDACTED — ES256 JWT from api-auth.web3auth.io; length 1774 characters; three dot-separated segments>”,

“verifier”: “web3auth-google-sapphire”,

“verifier_id”: “s***@hotmail.com”,

“account_type”: “account_abstraction”,

“chain_namespace”: “eip155”,

“email”: “s***@hotmail.com”,

“signatures”: [

“<REDACTED — stringified JSON with \“data\” (base64) + \“sig\” (hex); length ~575 — exceeds 500>”,

“<REDACTED — same structure; length ~575>”,

“<REDACTED — same structure; length ~575>”

],

“network”: “mainnet”,

“eoa_address”: “0x3BD1…f8C7A1e”,

“aa_provider”: “safe”,

“chain_id”: “0x89”

}

Encoding note: Each signatures[i] value is a stringified JSON object. The inner data field is base64; sig is hex. Each whole signatures[i] string is > 500 characters, which triggers validation.


2. Full HTTP response (status, body, headers)

Status: 400 Bad Request

Response body:

{

“statusCode”: 400,

“error”: “Bad Request”,

“message”: “Validation failed”,

“validation”: {

“body”: {

“source”: “body”,

“keys”: [“signatures.0”],

“message”: “\“signatures[0]\” length must be less than or equal to 500 characters long”

}

}

}

Response headers (as captured):

HTTP/1.1 400 Bad Request
Date: Sat, 11 Apr 2026 01:43:29 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 221
Connection: keep-alive
Access-Control-Allow-Origin: https://wallet.web3auth.io
Vary: Origin, Accept-Encoding
Access-Control-Allow-Credentials: true
Content-Security-Policy: default-src ‘self’;base-uri ‘self’;font-src ‘self’ https: data:;form-action ‘self’;frame-ancestors ‘self’;img-src ‘self’ data:;object-src ‘none’;script-src ‘self’;script-src-attr ‘none’;style-src ‘self’ https: ‘unsafe-inline’;upgrade-insecure-requests
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin
Origin-Agent-Cluster: ?1
Referrer-Policy: no-referrer
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-XSS-Protection: 0
RateLimit-Policy: 10;w=60
RateLimit-Limit: 10
RateLimit-Remaining: 9
RateLimit-Reset: 60
ETag: W/“dd-0EOTbHPa7UKks/AMgpmf20pwQOo”


3. Timestamp + redacted curl

Incident time (UTC): 2026-04-11 01:43:29 UTC (from Date response header)

curl ‘https://api-wallet.web3auth.io/auth/verify’ \

-H ‘Accept: */*’ \

-H ‘Content-Type: application/json; charset=utf-8’ \

-H ‘Origin: https://wallet.web3auth.io’ \

-H ‘Referer: https://wallet.web3auth.io/’ \

-H ‘x-api-key: torus-default’ \

-H ‘baggage: ’ \

-H ‘sentry-trace: ’ \

--data-raw ‘{“public_address”:“0x4470…2A3510”,“id_token”:“<REDACTED, length 1774>”,“verifier”:“web3auth-google-sapphire”,“verifier_id”:“s***@hotmail.com”,“account_type”:“account_abstraction”,“chain_namespace”:“eip155”,“email”:“s***@hotmail.com”,“signatures”:[“<REDACTED, length ~575>”,“”,“”],“network”:“mainnet”,“eoa_address”:“0x3BD1…f8C7A1e”,“aa_provider”:“safe”,“chain_id”:“0x89”}’

Context: Origin / Referer are https://wallet.web3auth.iohosted wallet context, not our dapp origin.


4. AA vs EOA (summary)

I did not change production. Minimal test app (HTML/Vite), fresh deps.

  • AA / smart account on: POST …/auth/verify400, signatures[0] length limit — cannot complete login.

  • AA off: same embedded-wallet social login succeeds (EOA only); no account_abstraction failure. No api-wallet…/auth/verify in Network for the same flow (or not the failing payload).

This looks AA-specific relative to the verify payload above.

Thanks for escalating to the backend team.

@system any update on this issue? It is breaking systems in production for 3 days now

1 Like

Hi @Aussie ! We have passed your case to our team and we will reply you as soon as we can.

2 Likes

Hi @Aussie again. Thanks so much for your patience!

This signatures error should have been fixed. Would you please try again?

1 Like

Thank you, yes the issue seems to be resolved.

1 Like