-
Notifications
You must be signed in to change notification settings - Fork 37
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
"Sign In With Solana" feature #12
Conversation
🦋 Changeset detectedLatest commit: dd13db5 The changes in this PR will be included in the next version bump. This PR includes no changesetsWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Would be sick if we could make this work for Smart Contract Wallets too. EIP-4361 actually takes this concern into account here: The problem is that it relies upon ERC-1271: Standard Signature Validation Method for Contracts which doesn't have an analog on Solana yet. So implementing one would be a prerequisite for the Smart Contract Wallets support. That said, it looks like we could add it later, maybe by introducing a new field to /** The `WalletAccount` that signs the message on behalf of the `account`. */
readonly signer?: WalletAccount; But again, we could probably add it later. |
Super great to see this on the Solana side and getting pushed forward! We're also down to share any experiences we've had on the wallet integration side in the Ethereum ecosystem as well (considerations like domain binding to protect users). |
@vovacodes @obstropolos do you have some ideas about how ERC-1271 would port over to Solana wallets? I'm not sure I understand the trust model here -- what is generating the signature, and how is the wallet guaranteeing that the smart contract verifies it? |
A feature that I've been wanting for months! Awesome proposal and something that will surely put a smile to faces of dApp developers. My question is (and this might be the wrong place to ask it), how does this work with the mobile wallet adapter? |
@vovacodes this seems like it would require the calling app to be aware that the wallet is a program wallet, and have a way of obtaining the Also, any solution that requires dapps to know they are calling a program wallet and do something different for it will be difficult to drive adoption for, and sort of violates the contract the Wallet Standard presents to an app (it's not actually an optional param for a program wallet, even though the API describes it as optional). |
@josip-volarevic it's a good question, and I reached out to someone on the Solana Mobile team for comment. It's not an immediate concern for the Wallet Standard, but we are aiming for maximum compatibility between this and the MWA protocol, so I don't want to design something that won't work there. |
Not exactly, how I see it is that |
Frankly, I'm not totally sure how Below is my initial thoughts of how that can be implemented. Note: this is probably skewed towards our use-case - a multisig program.
and the following instruction data:
The program can then verify if Other notes
Anyways, this a literally a brain-dump, just to start a discussion, so please share your ideas. |
Thanks for kicking this off! Looks great. This is pretty similar to how Phantom currently supports "Sign In With". Bundling If the optional This may be a question for a separate thread, but will cc @jozanza |
The WalletAccount object provided as |
We won't add those params to that method, since some of the fields are required, which would make it a breaking change and an incompatible API with regular message signing. But the |
I think it would be nice to do something like how we do this in Glow and just have a simple constructed string the wallet signs: https://github.com/glow-xyz/glow-js/blob/master/packages/glow-client/src/utils.ts#L9 We've been supporting the |
This PR has been targeted against a new |
This PR adds a "Sign In With Solana" (
solana:signIn
) feature to the Solana Wallet Standard. This feature is expected to be approximately compatible with "Sign In With Ethereum" (EIP-4361).Some notable aspects of the design:
account
is an optional Wallet StandardWalletAccount
in the request, and required in the signed message and method output. This means an application can sign in and connect to the wallet in a single step. It doesn't need to asynchronously connect to get an account, prepare a message to sign in, then prompt the user to sign it. It can sign in without knowing what account to sign in with, and when the message is signed, the account will be connected as well.chain
is a Wallet Standard chainIdentifierString
. This would typically besolana:mainnet
, but others are defined here, and this is arbitrary.solana:signIn
feature supports multiple arguments, allowing signing in with multiple accounts in a single prompt.solana:signMessage
feature, thesolana:signIn
feature returns both the signature and the bytes that were signed. This is necessary because the final message bytes (including the account address) will be prepared by the wallet, not the application. These message bytes may also be prefixed or formatted (for example, for signing with the Solana Ledger app). The application must parse the signed message bytes and verify them against the signature.See also: