fix: use funderAddress for POLY_ADDRESS header in Magic wallet flows#339
fix: use funderAddress for POLY_ADDRESS header in Magic wallet flows#339skyc1e wants to merge 1 commit into
Conversation
When using Magic wallet (POLY_PROXY signature type), the API key is associated with the funderAddress, not the signer address. This causes L2 authenticated requests to fail because POLY_ADDRESS is set to the signer's address instead of the funder's. Pass the existing funderAddress constructor parameter through to createL1Headers and createL2Headers so that POLY_ADDRESS uses the correct address for proxy/Magic wallet users, while falling back to the signer address for regular wallets. Closes Polymarket#248
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
| this.creds as ApiKeyCreds, | ||
| headerArgs, | ||
| this.useServerTime ? await this.getServerTime() : undefined, | ||
| this.funderAddress, |
There was a problem hiding this comment.
L1 and L2 address headers diverge
Medium Severity
createApiKey and deriveApiKey still call createL1Headers without this.funderAddress, while L2 calls now send this.funderAddress. In proxy/Magic flows this can create credentials under one address and authenticate requests with another, leading to inconsistent auth behavior across src/client.ts.
Additional Locations (1)
| ts = timestamp; | ||
| } | ||
| const address = await getSignerAddress(signer); | ||
| const address = funderAddress ?? (await getSignerAddress(signer)); |
There was a problem hiding this comment.
Empty funder address overrides signer address
Medium Severity
createL1Headers and createL2Headers treat funderAddress as present when it is an empty string because they use ??. That sets POLY_ADDRESS to "" instead of falling back to getSignerAddress, which can break authentication for integrations that pass blank environment values into funderAddress.


Summary
Fixes #248.
When using Magic wallet (POLY_PROXY signature type), the API key is associated with the
funderAddress, not the signer address. Currently,createL1HeadersandcreateL2Headersalways resolvePOLY_ADDRESSfrom the signer, causing L2 authenticated requests to fail for proxy/Magic wallet users because the server expects the funder address.Changes
funderAddressparameter tocreateL1HeadersandcreateL2Headersinsrc/headers/index.tsfunderAddress ?? (await getSignerAddress(signer)), preserving backward compatibility for non-proxy walletsfunderAddressconstructor param as a class property onClobClientand pass it through to allcreateL2Headerscall sites (29 inclient.ts, 11 inrfq-client.ts)funderAddresstoRfqDepsinterface and wired it through the RFQ clientTest plan
tsc --noEmitpassesvitest run tests/headers/)tsc -p tsconfig.build.json)Note
Medium Risk
Touches request authentication headers used across many L2 endpoints; a wrong
POLY_ADDRESScould break signed requests or affect account attribution, though changes are additive and fallback to signer behavior.Overview
Fixes proxy/Magic-wallet flows by allowing an optional
funderAddressto overridePOLY_ADDRESSincreateL1HeadersandcreateL2Headers, falling back to the signer-derived address when not provided.Threads this
funderAddressthroughClobClientinto RFQ dependencies and passes it to allcreateL2Headerscall sites so L2-authenticated CLOB/RFQ requests use the expected address. Adds unit tests covering override and fallback behavior for both L1 and L2 headers.Written by Cursor Bugbot for commit e3a6762. This will update automatically on new commits. Configure here.