Logo Phantom
Logo PhantomLogo Phantom

Adopting “Sign In With” Standards

Phantom is supporting three “Sign In With” (SIW) standards.

Brian Friel
    Phantom Wallet Adopting "Sign In With" Standards

    Today we’re announcing that Phantom is supporting three “Sign In With” (SIW) standards:

    • Sign In With X (CAIP-122)
    • Sign In With Ethereum (EIP-4361)
    • Sign In With Solana (EIP-4361 extension)

    These open standards protect user privacy and improve the robustness of web3 authentication. By adopting one of these standards, dApps can prevent phishers from intercepting sign-in messages and impersonating users to gain access to personal data like user profile information and email addresses.

    How messages work

    If you’ve ever connected your wallet to a dApp (like OpenSea, Magic Eden, or ExchangeART), you’ve probably been asked to sign a message during login. Signatures require your private key, and are used to:

    • Prove that you own the wallet
    • Allow dApps to store things like a user profile, email address, or loyalty program that’s connected to your address
    • Prevent bad actors from impersonating your account


    One of the vulnerabilities in generic sign-in messages is the ability for one domain to impersonate another, get you to sign a message, and then turn around and use that signature to log in to a site on your behalf.

    For example, let’s say you sign a message at “random-nftmint.com” thinking its pretty safe to do so. The owners of that site could now take your signed message and use this to sign-in to other websites and view your saved personal information.

    The Solution

    SIW takes the guess work out of wondering if you are vulnerable to this type of phishing. If a dApp opts in to an open auth standard like CAIP-122 or EIP-4361, Phantom will validate their required message fields at the time of signing. These fields include information such as the site’s domain, the time at which the message was issued-at, and a nonce that is used to prevent signature replay attacks.

    This extra layer of security prevents phishers from intercepting generic sign-in messages and impersonating users.

    What that means for Phantom users

    Most users won’t see this new feature. Phantom will only validate message fields if a dApp chooses to opt-in to one the SIW formats. Generic message signing remains unchanged.

    If a dApp opts-in to a SIW format and the required fields are valid, Phantom will present a signature request like usual:

    Signature request

    If, however, a site opts-in to a SIW format and one or more of these fields are not valid, Phantom will display a warning. Examples of invalid fields include:

    • A different domain than the app that’s requesting a signature
    • A address that does not match the user’s address
    • A issued-at timestamp that is in the future
    Invalid signature request

    We know that SIW standards are still in the process of being more widely adopted, and we believe users should be free to explore the open world of decentralized applications. If users are sure they are on the correct site, they can choose to ignore this warning and sign the message anyway.

    Looking ahead

    Over time, we believe that the ecosystem will move towards fully adopting SIW standards as a chain-agnostic solution to generic sign-in messages. We also feel these standards are an important stepping stone for custodial alternatives to centralized identity providers.

    Next Steps

    • It’s important to note that this feature is entirely opt-in. If dApps don’t want to use one of the open standards, they can continue to use generic messages like usual.
    • This new feature is part of our suite of security features

    If you’re a developer looking to implement SIWX to your dapp, please visit our docs to get started.