rhinestonewtf / registry Goto Github PK

Background

• registerResolver function has a modifier called onlyResolver
• it checks if the resolver address is not zero address and supports the interface for IExternalResolver

Minor readability Issue

• name onlyResolver may mean if it is checking the address is a resolver address
• sounds similar to onlyOwner

Suggested change

• rename onlyResolver to isSupportedResolver

_{From SyncLinear.com | RHI-18}

Following discussion with @leekt, we should add dynamic msg.value to create2

Following on from feedback by Ankur at Biconomy

Saw that these are not used

https://github.com/rhinestonewtf/registry/blob/main/test/AttestationDelegation.t.sol#L316-L328

_RHI-590

the registry currently uses a boolean flag in attestations to allow for L2 propagations.

It would be better to implement a more complex whitelist, that allows attesters to either:

• generally allow propagations
• generally disallow propagations
• pick chainIDs to propagate

Ongoing security is so critical to the module ecosystem and the Registry that I can't think of any legitimate reason to want to have a Schema or Attestation be un-revocable.

At best, this flag would only waste gas, at worst it could lead to security issues where attestations on compromised modules cannot be revoked.

following to discussion with @shahafn

there are optimization opportunities how the registry is handling revocationTime and revocable in the attestation struct.

Not using the sender/owner to calculate the UID of Resolvers could lead to senders being frontrun and unable to register the Resolver because the UID is already taken - it could also lead to resolvers being owned by someone malicious without noticing and later changed (thanks to Lee Yu for pointing this out)

Requires discussion

_{From SyncLinear.com | RHI-19}

we are currently deriving the schemaUID by calculating a hash on the schema string, the owner (wallet registering the schema) and if its revokable.

I am not sure if this is a good derivation path...

we need schemaIDs to be the same across chains to allow for propagation, and the schema need to be bound to the creator, or else someone could frontrun registration and block the schemaID.

the downside of the current derivation path is that it doesnt allow for wallet rotation for authorities in the future.

we could use the resolver address as a parameter in the hash derivation but that also makes things dangerous if some authorities choose to use create2 for their resolver and can be frontrun

https://github.com/rhinestonewtf/registry/blob/main/src/base/RSSchema.sol#L110-L121

The current ERC1271 checks only allow for r,s,v, signatures.

this breaks compatibility with multisigs or other signature schemas

https://github.com/rhinestonewtf/registry/blob/main/src/eip712/EIP712Verifier.sol#L217

Following on from discussions with @rmeissner on ERC-7484

_RHI-272

Following feedback by @shahafn:

Query.sol checks should reference the expirationTime

Following on from discussions about ERC-7484

_RHI-273