Gap
Commit 66f171e ("feat(probable): unified Web3 auth lifecycle, secrets never exposed over HTTP", #1614) landed a 6-method Probable auth lifecycle: getAuthNonce, loginWithSignature, logout, isSessionActive, getSession, verifyL1, verifyL2. Four of these (getAuthNonce/loginWithSignature/logout/isSessionActive) got entries in core/src/server/method-verbs.json, which is what the SDK client generators consume to produce first-class methods — and both SDKs correctly picked them up. getSession was deliberately added to EXCLUDED_METHODS (core/scripts/generate-openapi.js:1181) since it's a private/security-sensitive accessor. But verifyL1/verifyL2 fall into neither bucket: they are NOT in EXCLUDED_METHODS, yet no entry for them was ever added to method-verbs.json, so they never made it into the OpenAPI spec, and neither SDK generated a named wrapper. This looks like an oversight in the 66f171e diff rather than an intentional exclusion.
Core
core/src/exchanges/probable/auth.ts:150 — export async function verifyL1(walletAddress, signature, callApi)
core/src/exchanges/probable/auth.ts:170 — export async function verifyL2(walletAddress, signature, callApi)
core/src/exchanges/probable/index.ts:130-136:
async verifyL1(walletAddress: string, signature: string): Promise<boolean> {
return verifyL1Fn(walletAddress, signature, this.callApi.bind(this));
}
async verifyL2(walletAddress: string, signature: string): Promise<boolean> {
return verifyL2Fn(walletAddress, signature, this.callApi.bind(this));
}
core/src/server/method-verbs.json — has entries for getAuthNonce (line 2), loginWithSignature (line 12), logout (line 32), isSessionActive (line 42), but no entry for verifyL1 or verifyL2 anywhere in the file.
core/scripts/generate-openapi.js:1181 — EXCLUDED_METHODS = new Set(['callApi', 'defineImplicitApi', 'fetchMatches', 'getSession']) — confirms verifyL1/verifyL2 are not deliberately excluded.
TypeScript SDK
Missing — sdks/typescript/pmxt/client.ts has getAuthNonce (~960), loginWithSignature (~985), logout (~1012), isSessionActive (~1037), but no verifyL1/verifyL2 method anywhere (only unrelated verifySignature occurrences).
Python SDK
Missing — sdks/python/pmxt/client.py has get_auth_nonce (~1309), login_with_signature (~1329), logout (~1351), is_session_active (~1371), but no verify_l1/verify_l2 method anywhere (only unrelated verify_signature occurrence).
Evidence
verifyL1/verifyL2 are implemented in core and mentioned in the 66f171e commit message as part of the "unified auth lifecycle," but grep across method-verbs.json, core/src/server/openapi.yaml, and docs/api-reference/openapi.json returns zero matches for verifyL1/verifyL2/AuthVerifyL. Since both SDKs' clients are generated from method-verbs.json/the OpenAPI spec, these two methods structurally cannot reach either SDK as named methods — they're only reachable via each SDK's generic untyped implicit-API passthrough.
Impact
Users of the "unified" Probable auth flow can get a nonce, log in, log out, and check session state, but cannot call the L1/L2 signature-verification step through a typed SDK method in either language — defeating the stated goal of a complete, unified auth lifecycle. Callers must drop to raw/untyped API calls to reach verifyL1/verifyL2, with no type safety or discoverability.
Found by automated Core-to-SDK surface coverage audit
Gap
Commit 66f171e ("feat(probable): unified Web3 auth lifecycle, secrets never exposed over HTTP", #1614) landed a 6-method Probable auth lifecycle:
getAuthNonce,loginWithSignature,logout,isSessionActive,getSession,verifyL1,verifyL2. Four of these (getAuthNonce/loginWithSignature/logout/isSessionActive) got entries incore/src/server/method-verbs.json, which is what the SDK client generators consume to produce first-class methods — and both SDKs correctly picked them up.getSessionwas deliberately added toEXCLUDED_METHODS(core/scripts/generate-openapi.js:1181) since it's a private/security-sensitive accessor. ButverifyL1/verifyL2fall into neither bucket: they are NOT inEXCLUDED_METHODS, yet no entry for them was ever added tomethod-verbs.json, so they never made it into the OpenAPI spec, and neither SDK generated a named wrapper. This looks like an oversight in the 66f171e diff rather than an intentional exclusion.Core
core/src/exchanges/probable/auth.ts:150—export async function verifyL1(walletAddress, signature, callApi)core/src/exchanges/probable/auth.ts:170—export async function verifyL2(walletAddress, signature, callApi)core/src/exchanges/probable/index.ts:130-136:core/src/server/method-verbs.json— has entries forgetAuthNonce(line 2),loginWithSignature(line 12),logout(line 32),isSessionActive(line 42), but no entry forverifyL1orverifyL2anywhere in the file.core/scripts/generate-openapi.js:1181—EXCLUDED_METHODS = new Set(['callApi', 'defineImplicitApi', 'fetchMatches', 'getSession'])— confirmsverifyL1/verifyL2are not deliberately excluded.TypeScript SDK
Missing —
sdks/typescript/pmxt/client.tshasgetAuthNonce(~960),loginWithSignature(~985),logout(~1012),isSessionActive(~1037), but noverifyL1/verifyL2method anywhere (only unrelatedverifySignatureoccurrences).Python SDK
Missing —
sdks/python/pmxt/client.pyhasget_auth_nonce(~1309),login_with_signature(~1329),logout(~1351),is_session_active(~1371), but noverify_l1/verify_l2method anywhere (only unrelatedverify_signatureoccurrence).Evidence
verifyL1/verifyL2are implemented in core and mentioned in the 66f171e commit message as part of the "unified auth lifecycle," but grep acrossmethod-verbs.json,core/src/server/openapi.yaml, anddocs/api-reference/openapi.jsonreturns zero matches forverifyL1/verifyL2/AuthVerifyL. Since both SDKs' clients are generated frommethod-verbs.json/the OpenAPI spec, these two methods structurally cannot reach either SDK as named methods — they're only reachable via each SDK's generic untyped implicit-API passthrough.Impact
Users of the "unified" Probable auth flow can get a nonce, log in, log out, and check session state, but cannot call the L1/L2 signature-verification step through a typed SDK method in either language — defeating the stated goal of a complete, unified auth lifecycle. Callers must drop to raw/untyped API calls to reach
verifyL1/verifyL2, with no type safety or discoverability.Found by automated Core-to-SDK surface coverage audit