Skip to content
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

Provide a way to calculate the salted address of a contract #8798

Closed
chriseth opened this issue Apr 29, 2020 · 4 comments
Closed

Provide a way to calculate the salted address of a contract #8798

chriseth opened this issue Apr 29, 2020 · 4 comments
Labels
closed due inactivity The issue/PR was automatically closed due to inactivity. language design :rage4: Any changes to the language, e.g. new features low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. needs design The proposal is too vague to be implemented right away should have We like the idea but it’s not important enough to be a part of the roadmap. stale The issue/PR was marked as stale because it has been open for too long.

Comments

@chriseth
Copy link
Contributor

chriseth commented Apr 29, 2020

See #2136 (comment):

Since we have type(Holder).creationCode, how about adding type(Holder).calculateSaltedAddress(salt) ?

@axic axic added the language design :rage4: Any changes to the language, e.g. new features label Aug 28, 2020
@dmihal
Copy link

dmihal commented Sep 2, 2020

How about this:

type(Holder).calculateAddress{salt: bytes32(0), deployer: address(this)}(param1, param2);

@cameel cameel added low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. should have We like the idea but it’s not important enough to be a part of the roadmap. needs design The proposal is too vague to be implemented right away good first issue candidate Could be a "good first issue" but something is blocking it or it has open questions. labels Sep 26, 2022
@ekpyron ekpyron removed the good first issue candidate Could be a "good first issue" but something is blocking it or it has open questions. label Jan 5, 2023
@drortirosh
Copy link

How about this:

type(Holder).calculateAddress{salt: bytes32(0), deployer: address(this)}(param1, param2);

This would be great to have.
An alternate format (which requires deployer to be specified):

type(Holder).calculateAddress(bytes32(0), address(this),(param1, param2));

This syntax more resembles the "encodeCall" syntax.

But either implementation is FAR better to the current WORKAROUND implementation:

import "@openzeppelin/contracts/utils/Create2.sol";

return Create2.computeAddress(bytes32(salt), keccak256(abi.encodePacked(
                type(Holder).creationCode,
                abi.encode(param1, param2)
            )), address(this));

@github-actions
Copy link

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

@github-actions github-actions bot added the stale The issue/PR was marked as stale because it has been open for too long. label May 16, 2023
@github-actions
Copy link

Hi everyone! This issue has been automatically closed due to inactivity.
If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen.
However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.

@github-actions github-actions bot added the closed due inactivity The issue/PR was automatically closed due to inactivity. label May 24, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed due inactivity The issue/PR was automatically closed due to inactivity. language design :rage4: Any changes to the language, e.g. new features low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. needs design The proposal is too vague to be implemented right away should have We like the idea but it’s not important enough to be a part of the roadmap. stale The issue/PR was marked as stale because it has been open for too long.
Projects
None yet
Development

No branches or pull requests

6 participants