-
Notifications
You must be signed in to change notification settings - Fork 75
feat: Deploy Polygon CCTP enabled contracts #493
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
0x08C21b200eD06D2e32cEC91a770C3FcA8aD5F877
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Just one question
| "HubPool": { "address": "0xc186fA914353c44b2E33eBE05f21846F1048bEda", "blockNumber": 14819537 }, | ||
| "LpTokenFactory": { "address": "0x7dB69eb9F52eD773E9b03f5068A1ea0275b2fD9d", "blockNumber": 14704307 }, | ||
| "Optimism_Adapter": { "address": "0xAd1b0a86c98703fd5F4E56fff04F6b2D9b9f246F", "blockNumber": 17944184 }, | ||
| "Optimism_Adapter": { "address": "0xb3a4e39F0CD9aBAc5d866f023C18e73224667Fee", "blockNumber": 19833066 }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since polygon will be upgraded ahead of the others, do we need to merge that one first (and release the package) before the others?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
technically yes
| @@ -1,5 +1,5 @@ | |||
| { | |||
| "address": "0x53dcC21887d54f41B049724b73a2195CE7343873", | |||
| "address": "0x7a4Ba159A34c1C49F712B5079a28121bbA0BFb7f", | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not specifically related to this PR: one thing that would be cool: if we could have a way to verify that a deployed address matches the compiled code from the repo.
Might be tricky because the bytecode depends on constructor args, but would be cool to have an automation to do this because it's essentially impossible to verify manually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there's a way to do this with forge it hink
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OOC will we always need to maintain this spoke & should we update it accordingly on Boba?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm i don't think we need to do anything as long as the pool rebalance routes are disabled for this route and the dataworker doesn't propose bundles with boba
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we might want to brick the contract somehow
fillDeadlineBufferas implemented here.- Note I have not been able to verify the Mainnet with theThis worked after waiting some time and re-trying. I also made sure to clean out all deps and build/cache filesverifytask that uses solc-json files. I've tried cleaning out the dependencies folder, updatingsolcto 0.8.25, updatinghardhat-verify, all to no avail. So currently the adapters are deployed and verified as flattened contracts that I deployed from Remix. This is not as safe as deploying with solc-json since we can't easily verify the code matches what's in the repo. Therefore, this PR contains the flattened contracts for nowNew CCTP-enabledSpokePools:
New CCTP-enabled L1 Adapters
New non-CCTP migrated SpokePools: