Closed spengrah closed 7 months ago
Generated at commit: 1cff2609595787bed11f78feb6253da01a9615fa, compared to commit: 84dbaad5d6055bb606d6968418d949a815f03df2
Contract | Method | Avg (+/-) | % |
---|---|---|---|
HatsFarcasterDelegator | isValidSignature | -6,066 โ | -24.13% |
MockFarcasterDelegator | isValidSignature | -69 โ | -0.84% |
This PR makes two primary improvements:
Better logic for how the contract can receive an existing fid. It is now clearer that there are two paths:
a) Approving an fid upfront via
prepareToReceive()
. This is useful when the authorized signer(s) for the TRANSFER_TYPEHASH cannot conveniently produce a cryptographic signature for inclusion in aIdRegistry.transfer
call. For example, if the the authorized signer is a contract and therefore cannot produce a cryptographic signature, or if it is an EOA that is unlikely to interact with a farcaster client that supports the other path.b) Producing a valid cryptographic signature of TRANSFER_TYPEHASH-typed data, just like for other actions/typehashes
Supporting this change also led to more efficient logic and therefore lower gast costs for
isValidSignature
.More precise error codes returned by
isValidSignature
to facilitate better testing and troubleshooting