Wallets

Wallets are the fundamental addressing and identity mechanism on Web3, akin to email addresses on Web2. The getWallet API assigns users a wallet based on the given user identifier.

📘
Generation 3 API
The Generation 3 Wallet Infrastructure is rebuilt from scratch from Generation 2 to allow for infinite scalability, and transaction signing, offering highest industry leading security till date based on hardware root of trust. It employs zero trust principles to generate user wallet identity in a hardware wallet infrastructure, with fully memory encryption and isolation at rest and during compute, identical to Full Homomorphic Encryption, but without its limitations in speed & generalization to broad cryptography problems. We call this Generalized Homomorphic Encryption.
Simply put, we're giving every user on the planet a hardware wallet on the cloud that cannot be stolen, that's uniquely burned to them, at no cost.

Prerequisites

Have a Developer API Key.
Have the identity(email address or phone number) of your User, for whom you'll be creating a wallet.
- We'll be adding support for social login soon.

Guarantees

On Mainnet, the assigned wallets are guaranteed to be "sticky". This means that for a given user identifier (email address or phone number) MetaKeep on Mainnet guarantees that a given identity always results in the same wallet address.

Stickiness is not necessarily guaranteed on Testnet, as Testnet is designed for Developer abuse and we may occasionally flush out the system to make room for fresh abuse.

❗️
Security Advisory
MetaKeep strongly recommends Developers to not cache the output of this getWallet API.
This is because, caching the response of the getWallet API increases the burden on the developer to ensure that their caching infrastructure is protected against Cache Tampering (CT) attack. In CT, an adversary may modify the users wallet association from the authentic non-custodial one issued by MetaKeep to a wallet address that they control by modifying your database entries. As this is your private infrastructure, MetaKeep is not in a position to safeguard it.
So instead, always call the getWallet API, as and when you need a user's wallet address. This way, you're transferring the burden of security to the MetaKeep's internal infrastructure, which is designed to be tamper evident and resistant.

How to use it

This API does not require user interaction. It's a backend call made from your service to MetaKeep. It sends back wallet addresses assigned to the user. At the moment, getWallet supports Ethereum and EVM-compatible chains such as Polygon, EOS-based chains(e.g. FIO), and Solana. We will add support for every major chain based on the developers' demand.

👍
Truely Non Custodial
The output of this API is a true non-custodial wallet. Due to Gen 3 architecture, it is physically impossible for you as a developer, or MetaKeep employees (even who might be granted temporary root access to production machines to fix a production issue) to acquire access to user's private keys. This is a good thing- It means that even if MetaKeep's infrastructure were to be compromised by a state sponsored adversary, user's private keys will never leak by design.

What's a True Non Custodial wallet?

Not all Non Custodial wallets are built the same. Most "popular" Non Custodial wallet services are riddled with fatal security gotchas that are evident to the trained specialist eyes, that puts your brand reputation at risk when the service providers get compromised. When you build on MetaKeep, you rely on our multi decade collective experience building secure infrastructure that underpins LinkedIn, Facebook, Twitter, and Microsoft, and eliminate reputation risk to your brand.

Note that by definition of non-custodianship, moving crypto assets away from the user's wallet is ONLY possible with user consent, or user pre-authorization.

PS: Consent is only required for taking assets out. You don't require consent to add assets to a wallet on any chain.

Dealing with failures

This API is safe to retry/replay in case you see a failure.

Try it yourself!

You can use the examples provided on the right-hand side of the next page to try out the APIs. Make sure to type in the developer key in the "Header: x-api-key" section field.

© 2025 Passbird Research, Inc. All rights reserved. This documentation and underlying technology are protected by patents, trademarks, and intellectual property rights under U.S. and international law.