Privy embedded wallets can be made interoperable across apps, making it easy for you to launch your own global wallet. In this setup, global wallets foster a cross-app ecosystem where users can easily port their wallets from one app to another, including by integrating wallet connector solutions like RainbowKit and wagmi. Using global wallets, users can seamlessly move assets between different apps and can easily prove ownership of, sign messages, or send transactions with their existing wallets. images/Crossapp.png

​
Providers and requesters

Suppose that Alice is logged in to App A and wants to connect with her App B wallet to prove she owns an asset. In this setup:
  • App A is the requester app: it requests access to a third-party wallet.
  • App B is the provider app: it provides access to embedded wallets generated on its app.
The provider and requester nomenclature will be used throughout this documentation and the SDK interfaces.
Privy requires that users explicitly confirm all wallet actions in a cross-app context.
Global wallets are built to safeguard user privacy and security. No app developer can view user assets or learn about their address without both:
  • The provider app opting into cross-app flows.
  • The user explicitly consenting to share their wallet information with the requester app.
By enabling cross-app functionality, the provider’s Privy app (hosted on an isolated subdomain) acts as an OAuth-compliant authentication provider. This means requesting apps can initiate the connection, and if the user approves:
  • Users are granted a custom access token to make future requests to the provider wallet
  • The user’s wallet addresses are then attached to the requester’s user object as a new cross-app linked account
  • If the provider allows for the wallet to be used for signatures and transactions, the requester can request signatures and transactions using the custom access token. Providers can also choose to make their wallets available in read-only mode.
Privy enables the provider to opt into cross-app wallets in read-only mode, enabling the requester app to view the user’s wallet address but not prompt the user to transact. If transactions are enabled, the user will always be redirected to the isolated subdomain to explicitly approve them, in addition to needing to be logged in to the provider site and holding the custom access token. Concretely, this means that when a requester app requests a signature or transaction from a user’s cross-app wallet, Privy will open up a pop-up to the isolated subdomain, where the user must confirm the action explicitly. This means requesters cannot customize wallet prompts when interacting with a provider wallet, and cannot prompt users to export private keys from a provider wallet.