Webhook payloads don't identify which authorization key/signer authorized the action

[0xkurious]

None of transaction.*, wallet_action.*, or wallet.funds_deposited/withdrawn webhook payloads include any field identifying which authorization key or signer authorized the underlying action — only wallet_id.

This is a real gap for wallets using additional_signers with per-signer override_policy_ids (a wallet with N independently-scoped signers, each authorized to sign under different rules): the webhook stream lets you observe that a wallet moved funds, but not which signer authorized it. To reconstruct that, an app has to maintain its own out-of-band log correlating each signed request to the authorization_context it used — Privy already has this information at signing time (it verified the signature against a specific registered key), it's just not surfaced downstream.

Notably, intent.* events already track this precisely via IntentAuthorizationKeyMember { public_key, signed_at } — so the platform clearly has the capability internally, it's just scoped to the separate Intents (team-approval) flow rather than the standard authorization_context-signed wallet action path.

Request: add a signer_id (or the signer's public_key) field to transaction.*, wallet_action.*, and wallet.funds_deposited/withdrawn payloads, identifying which authorization key/quorum satisfied the request's owner_id/additional_signers check.

Happy to share a minimal repro (multi-signer wallet + two signers each triggering a transfer) if useful.

[0xkurious]

Concrete scenario that makes this gap especially painful: a single wallet with N additional_signers, each scoped to a different override_policy_ids, acting as N independent agents sharing one on-chain address.

We tested exactly this today:

• One wallet, owner + 2 additional signers.
• Signer A: override_policy_ids allowing only small transfers to address X.
• Signer B: no override -- falls back to the wallet's base policy, allowing transfers to address Y.
• Owner: full-scope base policy.

All three can independently trigger eth_sendTransaction on the same wallet, and each is genuinely sandboxed -- confirmed empirically that a signer's actions are governed only by its own policy (no bleed-through from the base policy or from other signers).

The webhook stream for that wallet today shows only wallet_id for every resulting transaction.* / wallet_action.transfer.* / wallet.funds_withdrawn event -- so from the webhook alone, three completely independently-scoped actors are indistinguishable. Reconstructing "which of the three did this" requires the app to keep its own out-of-band log of which authorization_context was used per call, correlated after the fact by transaction_hash.

This is exactly the shape of a real multi-agent setup (e.g. several autonomous agents, each with their own signer + policy, sharing one treasury address for a unified on-chain identity) -- adding signer_id to these payloads would let the webhook stream itself serve as the attribution ledger, rather than requiring the app to independently maintain that mapping.