Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
TLDR: allows an ENS record to point to a specific projectId on a specific chainId. i.e. @jango points to project 33 on Op.
The ENS records now returns a projectId and the chainId on which the projectId should be resolved.
In order to do this, we remove the Permission check since we cant know who owns a projectId on a different chain, and instead allow anyone to set records for any project on any chain, BUT the record will be set relative to the msg.sender. Clients are advised to request matches only for a project's current project owner if they wish to resolve records set by the project owner.
The new ENS record keys are "juicebox:projectId" and "juicebox:chainId".
To be clear, this contract is only meant to be deployed on the chain where the ENS registry lives -- likely only mainnet to start.
Limitations & risks
Are there any trade-off or new vulnarbility surface based on theses changes?
Check-list
Interactions
These changes will impact the following contracts:
Directly:
Indirectly: