thirdweb Wallet Security

If you are looking for the previous security documentation around the shamir secret sharing model, please refer to the In-App Wallet Security page.

When a user signs into an application using their email or social logins for the first time, a wallet is generated within a secure enclave on the server after verifying the user's legitimacy. The enclave provides a trusted execution environment, ensuring the wallet creation process is isolated and protected from external interference.

• The wallet and its corresponding private key are generated entirely within the enclave, never leaving its secure confines.
• User authentication data is verified within the enclave, ensuring that only legitimate, authenticated users can initiate wallet creation.

• The enclave's cryptographic properties ensure that even the server operators cannot access the contents or operations within the enclave.
• The enclave provides a verifiable hash of the image of the code that is being run on the device, allowing anyone to verify the contents of the code.
• The wallet's private key never exists in an unencrypted form outside of the enclave.
• All sensitive operations, such as transaction signing, occur within the enclave, ensuring the wallet's security.

• When users interact with their wallet via the the enclave, all communications are encrypted and only the legitimate user can access their wallet.
• All traffic is encrypted with TLS and HSTS. Services are run in private VPCs on AWS and accessible only from a single entry point via our Cloudflare DNS.
• Applications can link multiple authentication methods to the same wallet. Any of these methods can be used to authenticate into the users wallet.

Ecosystem wallets are controlled by the ecosystem owner. Ecosystem owners are able to specify usage policies for their partners and developers which restricts what they can do with the wallet. Unlike the shamir secret sharing model, the enclave wallet model ensures that the private key is never reconstructed on the client. This ensures no-one can extract the private key from the client, including other developers in the ecosystem. Moreover, it also means that partners and developers must submit the request to the enclave which would be able to verify the request and block requests that are out of scope or denied by the ecosystem owner.

In-App Wallets are scoped to applications per Client ID. If users use the same email to sign in to a different application using In-App Wallets, the application will manage an entirely different wallet.

• Each application has limited access only to wallets created through their application. It cannot manage wallets from other applications.
• Users may only view tokens sent or purchased from your application.
• To improve user experience, saved payment methods and KYC verification are only provided to thirdweb; applications cannot view this information.

Ecosystem Wallets are scoped to the ecosystem. If users use the same email to sign in to a different application using the same ecosystem, they will get the same wallet.

• Applications can now share assets across various applications. This is useful if you're a brand powering multiple application and want your partners to take advantage of network effects.
• Application owner has full control over what happens within each application. This is useful if you're a brand that wants to ensure that all applications in your ecosystem are following the same rules.

• Users can export their private key at any time.

• Users may recover their wallet from any device by authenticating or signing into an application to receive access to their wallet.

• Thirdweb wallets support four categories of authentication: socials, custom authentication, external wallets, and email / phone authentication. If a user ever loses access to their authentication method:

  • For socials and email / phone authentication, users can utilize the recovery flow of their providers to regain access to their account.
  • In the case of custom authentication, the developer managing their authentication flow will be able to re-instate the users account upon successful verification.
  • Application providers do not have direct access to user accounts or private keys, as these remain secured within the enclave. The enclave's design ensures that only verified user requests can trigger wallet operations.

• Users are able to link their authentication methods which will provide them multiple ways to access their account if they ever lose access to any one of their authentication method.

To increase security and privacy, private keys or wallet "seed phrases" are never stored or sent over a network. TLS encryption is used in transit for internal and external communications with thirdweb's back-end and databases. TLS encryption is also required for third-party vendors.

Data backups and storage are encrypted with AES-256.

thirdweb complies to GDPR and CCPA compliance frameworks and deletes customer data per request within the required timeframe of each standard (30 days for GDPR and 45 for CCPA).

Halborn has audited our enclave wallet security architecture which we'll be releasing shortly, and there is an ongoing bounty program to ensure vulnerabilities are caught. View the Letter of Attestation.