docs: the open-salt address fixes the implementation's address, not its code - #191
Merged
thedavidmeister merged 3 commits intoSep 21, 2026
Merged
Conversation
The derivation commits the implementation's ADDRESS, not its code, so the "no per-implementation audit to get wrong" sentence was false for any implementation that delegates onward to a mutable target. State what the signature does commit, and add the implementation MUST to the list of what the address does not fix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reachedNext included review available in 11 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (2)
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 |
The "Why hashing `data` into the salt is the whole point" section argued the position as well as stating it. The Zoltu analogy teaches how an argument-less deterministic deploy behaves; "the front-runner has deployed their own contract at their own address, at their own expense" and "has done nothing but pay the gas" narrate consequences of the two bullets' own first sentences; clone-and-initialize being atomic and `initialize` running once is the spec stated above, and a `CREATE2` address not being redeployable is the EVM. The MUST list drops the registry-authority bullet, whose `data MAY be empty` is the `@param`'s and whose remainder restates the chain-state bullet, and the new bullet drops the clone delegating forever and the cross-file note on what `checkImplementationCode` screens - that limit is stated on `DelegatedImplementation`, next to the check. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…implementation-code-not-fixed # Conflicts: # src/interface/ICloneableFactoryV4.sol
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
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.
Closes #107
The open-salt front-running argument closed with "It is a property of this
signature, not a condition on the implementation being cloned, so there is no
per-implementation audit of 'could a squatter pass something worse' to get
wrong." The derivation hashes
keccak256(cloneCreationCode(implementation)),and the EIP-1167 creation code embeds the implementation's ADDRESS — so the
address commits to where the clone delegates, never to what runs there. An
implementation that delegates onward to a target it can reach from its own code
(a beacon proxy, whose beacon is an immutable and so survives the clone's
delegatecallcontext) leaves the clone's behaviour with whoever retargets thebeacon: a front-runner picks WHICH logic gets pinned, and the clone's behaviour
stays third-party-controlled forever after.
checkImplementationCodescreensonly zero code size and the
0xefEIP-7702 designator and cannot see this, andthe "What the address does NOT fix, which implementations MUST respect" list
enumerated only
tx.origin, forwarded gas and chain-state resolution.Per owner ruling, fixed by scoping the claim, not by adding a guard.
ICloneableFactoryV4.cloneDeterministicOpenSalt: the closing claim now sayswhat the signature does commit (what a squatter can PASS) and that it commits
neither the implementation's code nor anything else
initializereads.datais the onlything the derivation takes off the table.
target anyone can change.
LibICloneableFactoryV4.DelegatedImplementation: notes that the0xefformis the only mutable-code shape detectable there.
A second commit cuts the section's padding: the Zoltu analogy, the narration of
what each front-running case costs, and the
data MAY be emptybullet the@paramalready carries.Comment-only. No src behaviour changes.
QA
tests never assert comment text.
mutation-probehasnothing to mutate in a comment.
LibICloneableFactoryV4.cloneCreationCode(
EIP1167_CREATION_CODE_PREFIX ++ implementation ++ SUFFIX) andpredictCloneAddress(keccak256(0xff ++ factory ++ derivedSalt ++ keccak256(creationCode))) fix the implementation address in the derivation;checkImplementationCoderejects only zero code size and a leading0xef.grep -rniE "immutab|proxy|beacon|upgrad" src/finds no other statement of animplementation-immutability requirement.
derivation does not actually fix". The other live instance,
predictDeterministicAddressOpenSalt's "what occupies it is the clone thatwas asked for", stays as written: it is true — an EIP-1167 proxy to the
requested implementation, initialized with the requested
data, is whatoccupies the address. What is not fixed is what that implementation runs,
which the new MUST states once, in the same NatSpec block.
🤖 Generated with Claude Code