This may be desired behavior, as metamorphic contracts are extremely weird, but the onlyNonProxyOwner modifier prevents a proxy being deployed for a user more than once, since it checks that _proxy[user] != address(0), and _deploy sets _proxy[user] = <create2'd address>.
If this is intended behavior, I suggest making explicit in the documentation that once a proxy is selfdestructed, it cannot be re-deployed. This can be considered a safety feature akin to @0age's ImmutableCreate2Factory.
If this is unintended behavior, i.e., a user should be able to re-deploy a proxy, it could be mitigated by checking the codesize of the proxy address is nonzero (this would not work within the same transaction as the selfdestruct, but this is broadly an issue with the selfdestruct opcode). Alternatively, you could optimistically deploy the proxy and check the address is non-zero, though this will incur significant gas overhead in the failure case.
This may be desired behavior, as metamorphic contracts are extremely weird, but the
onlyNonProxyOwner
modifier prevents a proxy being deployed for a user more than once, since it checks that_proxy[user] != address(0)
, and_deploy
sets_proxy[user] = <create2'd address>
.If this is intended behavior, I suggest making explicit in the documentation that once a proxy is selfdestructed, it cannot be re-deployed. This can be considered a safety feature akin to @0age's ImmutableCreate2Factory.
If this is unintended behavior, i.e., a user should be able to re-deploy a proxy, it could be mitigated by checking the codesize of the proxy address is nonzero (this would not work within the same transaction as the selfdestruct, but this is broadly an issue with the selfdestruct opcode). Alternatively, you could optimistically deploy the proxy and check the address is non-zero, though this will incur significant gas overhead in the failure case.