chore(deps): bump OpenZeppelin 5.6.1 → 5.7.0 — only the wrapped vault's bytecode moves - #300
Open
thedavidmeister wants to merge 1 commit into
Open
chore(deps): bump OpenZeppelin 5.6.1 → 5.7.0 — only the wrapped vault's bytecode moves#300thedavidmeister wants to merge 1 commit into
thedavidmeister wants to merge 1 commit into
Conversation
The only production bytecode this moves is StoxWrappedTokenVault: 5.7.0's ERC4626Upgradeable swaps its private _tryGetAssetDecimals for the shared SafeERC20.tryGetDecimals helper. The candidate pointers regenerate to a fixpoint, cascading through everything that embeds the vault's Zoltu address: its beacon, the beacon-set deployer, the unified deployer and the orchestrator pair. Frozen release-tag snapshots are untouched; nothing deployed changes until a release is cut. Everything else compiles byte-identical under 5.7.0 — in particular the governance timelock: testTimelockPinsMatchCompiledDependency passes unchanged against the 5.7.0 dependency, proving the frozen TIMELOCK_CREATION_CODE / TIMELOCK_RUNTIME_CODEHASH pins (and therefore the three live deployments) are exactly reproduced by the new version. rain-vats 0.1.6 still imports @openzeppelin-contracts-5.6.1/ prefixes internally; two remappings.txt bridge lines point those at the 5.7.0 install so exactly one OZ copy compiles (same class of bridge as the existing @openzeppelin/contracts/ line; re-apply if soldeer regenerates the file) until rain-vats republishes against 5.7.0. Bump-protocol suites all green: LibERC20Storage + LibERC1155Storage (ERC-7201 layout pins), LibStockSplit, LibRebase sequential precision, LibTotalSupply fuzz, LibTimelockInvariants, testCandidateSelfConsistent. StoxReceiptVault runtime 24,058 bytes (518 under EIP-170). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 58 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (9)
📒 Files selected for processing (76)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
What
Bumps
@openzeppelin-contractsand@openzeppelin-contracts-upgradeablesoldeer deps 5.6.1 → 5.7.0, sweeps the versioned import prefixes across src/test/script, regenerates the candidate pointers to a fixpoint, and records the result in the CHANGELOG.The byte-level answer this PR exists to give
testTimelockPinsMatchCompiledDependencypasses unchanged against the 5.7.0 dependency — the frozenTIMELOCK_CREATION_CODE/TIMELOCK_RUNTIME_CODEHASHpins (and therefore the three live deployments) are reproduced exactly. Independently cross-checked by compiling both tags standalone under the repo's exact profile: identical 8,149-byte creation code, identical runtime keccak0xb623…6993.StoxWrappedTokenVault. 5.7.0'sERC4626Upgradeableswaps its private_tryGetAssetDecimalsfor the sharedSafeERC20.tryGetDecimalshelper. The candidate pointer regeneration cascades through everything embedding the vault's Zoltu address: its beacon, the beacon-set deployer, the unified deployer, and the orchestrator pair. Frozen release-tag snapshots are untouched — nothing deployed changes until a release is cut, at which point this is a new-tag event per the versioning rules.Reviewer decision
rain-vats 0.1.6 still imports
@openzeppelin-contracts-5.6.1/prefixes internally, so tworemappings.txtlines bridge those onto the 5.7.0 install (same class of bridge as the existing@openzeppelin/contracts/line, documented in the CHANGELOG; soldeer regenerating the file would need them re-applied). The alternative is waiting for rain-vats to republish against 5.7.0 and bumping in lockstep — this PR takes the bridge; call it out if you'd rather wait.QA
testCandidateSelfConsistent— fails on base source combined with this branch's regenerated pointers, and was observed failing live on this branch before the pointer fixpoint (candidate constants vs 5.7.0 compile mismatch);testTimelockPinsMatchCompiledDependencydeliberately does NOT discriminate — its passing under 5.7.0 IS the byte-identity claim.testCandidateSelfConsistent(observed directly: the pre-fixpoint tree, where the beacon pointer still carried the 5.6.1-era embedded vault address, failed exactly there with the mismatched bytecode in the assertion output). Dep-version line itself: reverting foundry.toml to 5.6.1 alone → build breaks on the swept import prefixes (compile-time kill).[profile.default](solc 0.8.25, optimizer 2000, cancun, no metadata) — pointer expectations come from the compiler over the dependency, never hand-written; for the timelock additionally the three live on-chain deployments the frozen pins describe.🤖 Generated with Claude Code