-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Improve wallet management UX using Keystore #1869
Comments
Counterparts for |
If sticking to the standard keystore json format, you could keep the convention of including the address in the name of the file to easily find it. |
all good points, agreed we'd want them in |
Agree with everything here. Transitioning over from dapptools this has been quite frustrating to deal with. |
Adding my vote in support of this request. |
Just to set expectations, nobody is working on this rn and we're not prioritizing it. Would happily accept a PR that implements something we agree to |
Additional context: #3818 |
I will pay someone to implement this. Import and encrypt a private key to a local keystore file API:
The usage/help command would look like this:
Which prompts you for a private key that it will obfuscate and a password that it will also obfuscate. Then ideally...You could just run:
And it will prompt you for the password to your keystore file. It would be equivalent to:
|
Idk if/how OpenQ works, but YOLO. Funded this issue here. Deliverables (IMO):
The three is probably worth 1000 MATIC right? (...maybe?) |
It works :) merge the PR that is connected to this issue and the contributor can login to OpenQ and claim their money. |
I wanted to implement a Seems like there are two steps then:
For step 2, I would still leverage a lot of the existing methods from the I see that foundry has used So for better ux, I think it would be wrong to use Should I just repeat code here? or is there a way to leverage the interactive / mnemonic options from Hope my question makes sense, let me know if you have any other thoughts |
Closing, this is already done. |
This feature is Awesome. |
Component
Forge, Cast
Describe the feature you would like
I'm currently migrating from
dapp.tools
and it had this nice UX to handle keystore files:ETH_KEYSTORE
: the path to the keystore directoryETH_FROM
: the account from which send the tx from (I believe this was used to find the right keystore file inside the keystore directory).ETH_PASSWORD
: the path to a plain-text password file with the password for the keystore file in the local file system.I'm finding it a bit difficult to work with Foundry for that purpose. Specifically regarding contract deployment. Main differences are:
ETH_KEYSTORE
works, but it expects a keystore file, not a directory.ETH_FROM
is redundant, since the sender wallet is derived fromETH_KEYSTORE
ETH_PASSWORD
doesn't work.Also if I use
CAST_PASSWORD
env var,forge create
does not pick it up, so I need to be explicit when passing it:forge create --password=${CAST_PASSWORD} src/MyContract.sol:MyContract.sol
Also ideally such configs could be in
foundry.toml
as well:Furthermore, users should have the liberty to overwrite any configs with environment variables. For example, it's very useful to be able to define a keystore directory containing multiple accounts and define the
from
address with env vars.Additional context
As a workaround, I have written a small helper script to allow me to use
forge
the same way I could usedapp.tools
. Perhaps this can help guiding the implementation.The text was updated successfully, but these errors were encountered: