Skip to content

Conversation

@bmzig
Copy link
Contributor

@bmzig bmzig commented Aug 25, 2025

No description provided.

@fusmanii fusmanii force-pushed the faisal/foundry-migration-deploy-scripts branch from 3c02f42 to 56637f5 Compare August 25, 2025 22:09
@fusmanii fusmanii force-pushed the bz/deployV4Extra branch 2 times, most recently from d19e0d1 to af5979f Compare August 26, 2025 14:08
Base automatically changed from faisal/foundry-migration-deploy-scripts to faisal/foundry-migration-deployment-utils August 26, 2025 14:51
Base automatically changed from faisal/foundry-migration-deployment-utils to faisal/foundry-migration-constants August 26, 2025 14:58
@fusmanii fusmanii force-pushed the bz/deployV4Extra branch 2 times, most recently from 9ff6088 to 676fbb3 Compare August 26, 2025 15:24
@fusmanii fusmanii changed the title feat: deploy scroll, blast, zora, and ink feat: deploy scroll, blast, mode, redstone, zora, ink, lens, and soneium spoke pools Aug 26, 2025
nicholaspai
nicholaspai previously approved these changes Aug 26, 2025
}

content.push("");
// content.push("");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left over comment

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@grasphoper
Copy link
Contributor

Do we want to put these new addresses into deployments.json for backward compatibility for now? AFAIK, bits of relayer code rely on deployments.json being a source of truth.

Otherwise when bumping the contracts version in the relayer, we need to handle these changes in ContractUtils.ts

Base automatically changed from faisal/foundry-migration-constants to master August 26, 2025 16:58
@fusmanii fusmanii dismissed nicholaspai’s stale review August 26, 2025 16:58

The base branch was changed.

@fusmanii
Copy link
Contributor

@grasphoper I was hoping to make the new broadcast/deployed-addresses.json as source of truth since it has all the addresses from deployments.json and all new deploys from broadcast

also its automatically kept up to date by with extract-addresses script

@fusmanii fusmanii requested a review from nicholaspai August 26, 2025 17:42
@fusmanii fusmanii force-pushed the bz/deployV4Extra branch 2 times, most recently from 681c342 to a460888 Compare August 27, 2025 18:59
@pxrl
Copy link
Contributor

pxrl commented Aug 29, 2025

Do we want to put these new addresses into deployments.json for backward compatibility for now? AFAIK, bits of relayer code rely on deployments.json being a source of truth.

Otherwise when bumping the contracts version in the relayer, we need to handle these changes in ContractUtils.ts

These are only implementation contracts so we don't actually want them in deployments.json - if we updated them there then it'd break the bots.

@fusmanii fusmanii force-pushed the bz/deployV4Extra branch 2 times, most recently from 35007a7 to 4e83ba9 Compare August 29, 2025 21:14
fusmanii
fusmanii previously approved these changes Sep 9, 2025
Comment on lines 361 to 366
},
"Lens_SpokePool": {
"address": "0xc7772ce23a3ed7f87fe51b87617c7c7d21f15d39",
"transaction_hash": "0xa4938f34425c997b4686b5bad4f66b04bfbc2270dfe9c00b8f134da6a7b6edf5",
"block_number": 4092265
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to include this deployment?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done 9fe5920

Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
fusmanii and others added 10 commits September 9, 2025 17:13
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
This reverts commit 8ccecb1.

Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
Signed-off-by: bennett <bennett@umaproject.org>
Signed-off-by: bennett <bennett@umaproject.org>
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
Signed-off-by: Faisal Usmani <faisal.of.usmani@gmail.com>
@fusmanii fusmanii changed the title feat: deploy scroll, blast, mode, redstone, zora, ink, lens, and soneium spoke pools feat: deploy scroll, blast, mode, redstone, zora, ink, and soneium spoke pools Sep 29, 2025
@fusmanii fusmanii requested review from grasphoper and pxrl September 29, 2025 14:50
"lib/forge-std": {
"rev": "6bce1540c7a5d1c40eec032a1ae16f0e01f82b92"
}
} No newline at end of file
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fusmanii could you explain why we need this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is just pinning lib/forge-std version, not sure why it hasn't been added to the repo already

echo "✅ Code match"
else
echo "❌ Code mismatch"
fi
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fusmanii For the future, we should probably standardize the way we do this "veryfying of bytecode" action.

We've got this script, and 2 more: tasks/verifyBytecode.ts , tasks/verifySpokePool.ts

The latter script seems unused currently (am I wrong here @pxrl?) I like the idea of it: sanity checking some params for the spoke. It'd be nice to keep that up-to-date and potentially also create a foundry version.

It'd be nice if we consolidated all this functionality into some single foundry script that could work for any deployment: either foundry or hardhat.

These are a little vague thoughts and only tangentially relevant

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added this as a quick way to check bytecode of a deployed contract using foundry but I agree, ideally there would be one script that can verify bytecode/params of a spoke pool regardless if it was deployed using foundry or hardhat

Copy link
Contributor

@pxrl pxrl Oct 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The latter script seems unused currently (am I wrong here @pxrl?) I like the idea of it: sanity checking some params for the spoke. It'd be nice to keep that up-to-date and potentially also create a foundry version.

Yeah; it's only sporadically used, but it's a fairly inexpensive way of checking for any configuration issues in the SpokePool. There's value in checking that the onchain values match what was (intended to be) configured by the deployment script, but there's secondary value in dumping the values so that people can sanity check the results for anything that might be misconfigured in the deployment script. The visual inspection might catch issues that we are prone to overlook if the error is buried in a config file.

Ideally it could use executed post-deployment and the output could form part of the eventual PR to add the SpokePool artefacts.

@fusmanii fusmanii requested a review from grasphoper October 1, 2025 00:10
@fusmanii fusmanii merged commit d8cb921 into master Oct 2, 2025
10 checks passed
@fusmanii fusmanii deleted the bz/deployV4Extra branch October 2, 2025 13:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants