We seem to be ignoring the paging parameters (offset, limit etc) while the response does have the full result (count, next). Is this deliberate?

Was not on purpose 😅 added the missing params now

I would move the !input outside of the function or rename it since empty hex implies a hex.

Renamed the function

It might be a good idea to avoid name colision even if this is scoped. People often use ctrl+shift+f to look for definitions.

So... I dont understand the use case for this particular function but here is some food for thought. Right now, there is no internal coupling between this and the Safe4337 module which is better then if we were importing the type from there. There is, however, an implicit one. For someone to use this endpoint, they would have to either: use Safe4337Pack#createTransaction or implementing an interface themselves that accomplishes the same thing (which is a bit awkward). Are there situation where all these things could be supplied by an external library or people should ALWAYS use both modules together? Should we really use such complex object just for an api proxy and should the api-kit itself sign in this case? Perhaps the interface here is just really an UserOperation (which is clearly defined by the ERC) and the fields associated with packing signature (validUntil, validAfter and the authorizer's signature). That data field also almost look like something to represent the internal state of the object.

I refactored the function in 56315ef to not expect a SafeOperation anymore, but a UserOperation object.

I was looking at the server-side code and this field seems to be validated like this:

safe_owners = self._get_owners(safe_address)
parsed_signatures = SafeSignature.parse_signature(
    signature, safe_operation_hash, safe_operation_hash_preimage
)
owners_processed = set()
safe_signatures = []
for safe_signature in parsed_signatures:
    # do stuff

Please just check if those are not every owner's concatenated signature. I think the SafeOperation#encodedSignatures() or something.