Feature request
Problem
Safes that use the canonical SafeWebAuthnSharedSigner (0x94a4F6affBd8975951142c3999aEAB7ecee555c2, from safe-modules) as an owner — the standard gas-optimized passkey setup for ERC-4337 — cannot interact with the Transaction Service:
POST /api/v2/delegates/ rejects registrations where the delegator is the shared signer, and- proposing multisig transactions signed by it fails the same way,
because signature validation performs the EIP-1271 isValidSignature eth_call without a from address. The shared signer stores each Safe's P-256 public key in the Safe's storage and reads it back through msg.sender, so in a from-less call there is no configuration to find and validation always fails.
Request
When the delegator (or proposal sender) is an owner of the given Safe and provides a contract signature, perform the isValidSignature eth_call with from set to the Safe address. That makes msg.sender-dependent signers like SafeWebAuthnSharedSigner verifiable without changing anything else about the validation.
Support scoped to just the delegates endpoint would already unblock the main use case: a passkey-only Safe could authorize a delegate once, and all subsequent proposing happens through the delegate key. No Safe{Wallet} UI support for shared-signer passkeys is needed for this.
Current workarounds (both work, but are heavy for what they achieve):
- deploy the credential's
SafeWebAuthnSignerProxy via the factory and add it as an additional owner, solely so the service can verify a signature from the same underlying passkey (an extra owner and an on-chain transaction just for API access), or
- have an EOA owner sign the delegate registration — not possible for passkey-only Safes.
Context: we operate ERC-4337 passkey Safes (shared-signer owner, threshold 1) and want to register a backend delegate so transactions can be queued to the Safe app for co-owners to confirm.
Feature request
Problem
Safes that use the canonical
SafeWebAuthnSharedSigner(0x94a4F6affBd8975951142c3999aEAB7ecee555c2, from safe-modules) as an owner — the standard gas-optimized passkey setup for ERC-4337 — cannot interact with the Transaction Service:POST /api/v2/delegates/rejects registrations where the delegator is the shared signer, andbecause signature validation performs the EIP-1271
isValidSignatureeth_callwithout afromaddress. The shared signer stores each Safe's P-256 public key in the Safe's storage and reads it back throughmsg.sender, so in a from-less call there is no configuration to find and validation always fails.Request
When the delegator (or proposal sender) is an owner of the given Safe and provides a contract signature, perform the
isValidSignatureeth_call withfromset to the Safe address. That makes msg.sender-dependent signers likeSafeWebAuthnSharedSignerverifiable without changing anything else about the validation.Support scoped to just the delegates endpoint would already unblock the main use case: a passkey-only Safe could authorize a delegate once, and all subsequent proposing happens through the delegate key. No Safe{Wallet} UI support for shared-signer passkeys is needed for this.
Current workarounds (both work, but are heavy for what they achieve):
SafeWebAuthnSignerProxyvia the factory and add it as an additional owner, solely so the service can verify a signature from the same underlying passkey (an extra owner and an on-chain transaction just for API access), orContext: we operate ERC-4337 passkey Safes (shared-signer owner, threshold 1) and want to register a backend delegate so transactions can be queued to the Safe app for co-owners to confirm.