[ADHOC] budget exhaustion release basesepolia#524
[ADHOC] budget exhaustion release basesepolia#524mmackz merged 7 commits intofeature/timebased-incentivesfrom
Conversation
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Comment Tip CodeRabbit can use TruffleHog to scan for secrets in your code with verification capabilities.Add a TruffleHog config file (e.g. trufflehog-config.yml, trufflehog.yml) to your project to customize detectors and scanning behavior. The tool runs only when a config file is present. |
|
1 similar comment
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/evm/broadcast/UpgradeTimeBased.s.sol/84532/run-latest.json`:
- Around line 42-79: The two-step cutover must be made atomic: replace the empty
calldata in the upgradeToAndCall(address,bytes) invocation (currently passing
"0x") with ABI-encoded calldata that calls setCampaignImplementation(address,
0x402B...) so the proxy upgrade and the campaign-implementation swap occur in
the same transaction; construct the bytes payload for setCampaignImplementation
and supply it as the second argument to upgradeToAndCall on the
TimeBasedIncentiveManager entry that currently uses upgradeToAndCall(..., "0x"),
and make the same change for the other identical pair (the block referenced at
lines ~205-214) so createCampaign/createCampaignDirect cannot clone the old
implementation in between transactions.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 7028646b-3874-498b-99cc-b53b5357418b
📒 Files selected for processing (8)
packages/evm/broadcast/UpgradeTimeBased.s.sol/84532/run-1773769048319.jsonpackages/evm/broadcast/UpgradeTimeBased.s.sol/84532/run-latest.jsonpackages/evm/contracts/archive/TimeBasedIncentives/TimeBasedIncentiveManagerV1.solpackages/evm/contracts/archive/TimeBasedIncentives/TimeBasedIncentiveManagerV2.solpackages/evm/contracts/timebased/TimeBasedIncentiveManager.solpackages/evm/deploys/84532.jsonpackages/evm/script/solidity/ValidateTimeBasedUpgrade.s.solpackages/evm/test/timebased/TimeBasedIncentiveManager.t.sol
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Verify / Verify
- GitHub Check: Use Case Tests / Use Case Tests
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: mmackz
Repo: boostxyz/boost-protocol PR: 479
File: packages/sdk/src/Incentives/ERC20VariableCriteriaIncentiveV2.ts:285-292
Timestamp: 2025-09-22T23:21:17.136Z
Learning: In the boost-protocol repository, security improvements like targetContract filtering should be kept separate from feature-focused PRs and handled in dedicated security improvement PRs.
Learnt from: jonathandiep
Repo: boostxyz/boost-protocol PR: 477
File: packages/evm/script/solidity/UpgradeBoostCore.s.sol:14-23
Timestamp: 2025-09-18T23:41:02.717Z
Learning: In BoostCore upgrade scripts, the deployment pattern uses explicit `vm.broadcast()` calls per on-chain transaction rather than start/stop broadcast. The `_deployImplementation()` method internally calls utility functions that already contain `vm.broadcast()`, so the upgrade script correctly has separate `vm.broadcast()` calls for the deployment and upgrade operations. Private keys are injected via CLI command which makes `msg.sender` accurate.
📚 Learning: 2025-09-18T23:41:02.717Z
Learnt from: jonathandiep
Repo: boostxyz/boost-protocol PR: 477
File: packages/evm/script/solidity/UpgradeBoostCore.s.sol:14-23
Timestamp: 2025-09-18T23:41:02.717Z
Learning: In BoostCore upgrade scripts, the deployment pattern uses explicit `vm.broadcast()` calls per on-chain transaction rather than start/stop broadcast. The `_deployImplementation()` method internally calls utility functions that already contain `vm.broadcast()`, so the upgrade script correctly has separate `vm.broadcast()` calls for the deployment and upgrade operations. Private keys are injected via CLI command which makes `msg.sender` accurate.
Applied to files:
packages/evm/broadcast/UpgradeTimeBased.s.sol/84532/run-1773769048319.jsonpackages/evm/script/solidity/ValidateTimeBasedUpgrade.s.solpackages/evm/broadcast/UpgradeTimeBased.s.sol/84532/run-latest.json
📚 Learning: 2025-09-18T15:42:54.630Z
Learnt from: mmackz
Repo: boostxyz/boost-protocol PR: 477
File: packages/evm/script/solidity/ValidateBoostCoreUpgrade.s.sol:25-33
Timestamp: 2025-09-18T15:42:54.630Z
Learning: In Solidity contracts using OpenZeppelin Foundry Upgrades, the `custom:oz-upgrades-from` annotation specifies the reference contract for storage layout validation. When `Upgrades.validateImplementation()` is called, it automatically uses this annotation to compare storage layouts between versions, ensuring upgrade compatibility without needing to explicitly set a `referenceContract` in the options.
Applied to files:
packages/evm/script/solidity/ValidateTimeBasedUpgrade.s.sol
🔇 Additional comments (6)
packages/evm/contracts/archive/TimeBasedIncentives/TimeBasedIncentiveManagerV2.sol (1)
14-18: Archive baseline metadata looks consistent.The upgrade-from annotation, initializer lock, and pinned
2.0.0version make the intent of this file clear as a historical upgrade baseline.Also applies to: 183-186, 598-602
packages/evm/contracts/timebased/TimeBasedIncentiveManager.sol (1)
17-17: Release metadata is aligned.The new upgrade baseline and
2.1.0version string line up with the release artifacts in this PR.Also applies to: 600-601
packages/evm/deploys/84532.json (1)
28-28: Deployment registry matches the new campaign implementation.This address update stays consistent with the rollout artifacts and keeps the chain manifest in sync.
packages/evm/script/solidity/ValidateTimeBasedUpgrade.s.sol (1)
10-10: Validation is pointed at the archived V2 baseline.The script now checks the manager upgrade against the same V2 baseline introduced elsewhere in this PR.
Also applies to: 28-32
packages/evm/broadcast/UpgradeTimeBased.s.sol/84532/run-1773769048319.json (2)
42-83: Deployment transaction linkage is consistent.Line 48 correctly references the implementation deployed at Line 26, and Line 70 correctly references the campaign deployed at Line 7. Nonce ordering is also coherent for a single broadcaster.
96-110: VerifyblockHashfields against Base Sepolia RPC.The JSON file contains transaction receipts where all
blockHashfields are zeroed (0x0000...) whilestatus,blockNumber, andblockTimestampare populated with valid values. Confirm these are canonical on-chain receipts rather than incomplete or simulated output before using this artifact as release evidence. This pattern applies to all transaction receipts in the file (lines 96, 109, 136, 148, 176, 188, 217, and 229).
2 participants
Deploy new contract upgrade on base sepolia
Summary by CodeRabbit
New Features
Chores