This PR changes the pragmas in the passkeys contract to be:
More consistent: we use ^0.8.20 everywhere for "non-top-level" contracts. The version was chosen as this it the first version that supports all of the compiler features that we make use of. Notably, we have @custom: NatSpec items which are only officially supported as of v0.8.20 (incidentally, this is the same version used by OpenZeppelin contracts for similar reason: source). The choice to use floating pragmas here is to make using these support contracts easier across other projects (namely, the WebAuthn and P256 libraries are useful outside of this project). Furthermore, we use ^ versions so that breaking changes introduced in a potential Solidity v0.9 would not affect the security and integrity of the contract code.
Use fixed pragmas for "top-level" contracts that we deploy:
SafeWebAuthnProxyFactory
SafeWebAuthnSharedSigner
FCLP256Verifier
I am aware that Solidity v0.8.20 doesn't play nice with chains like BNB by default, however this can be worked around by explicitly by setting the EVM version target (as we do in this project) and do not believe this is an issue.
Fixes #17
This PR changes the pragmas in the passkeys contract to be:
^0.8.20everywhere for "non-top-level" contracts. The version was chosen as this it the first version that supports all of the compiler features that we make use of. Notably, we have@custom:NatSpec items which are only officially supported as of v0.8.20 (incidentally, this is the same version used by OpenZeppelin contracts for similar reason: source). The choice to use floating pragmas here is to make using these support contracts easier across other projects (namely, theWebAuthnandP256libraries are useful outside of this project). Furthermore, we use^versions so that breaking changes introduced in a potential Solidity v0.9 would not affect the security and integrity of the contract code.SafeWebAuthnProxyFactorySafeWebAuthnSharedSignerFCLP256VerifierI am aware that Solidity v0.8.20 doesn't play nice with chains like BNB by default, however this can be worked around by explicitly by setting the EVM version target (as we do in this project) and do not believe this is an issue.