How to add a crypto wallet to your app or site (WaaS)
Build key infrastructure or use Wallet as a Service? What changes in responsibility, custody and risk when you embed a wallet in your product.
Your product needs a wallet. You have two options
If your app needs users to receive, send or swap crypto, one component is unavoidable: a wallet. And that brings the decision that shapes everything else: build the key infrastructure, or use Wallet as a Service.
The choice is not about development effort. It is about what kind of responsibility you want to carry — and, above all, what you want to exist in your database.
What building from scratch means
Generating a keypair is trivial: a few lines with a well-known library. The problem starts afterwards.
A real wallet requires solving, in order:
- Secure generation. Weak randomness produces predictable keys. The recovery-phrase standard is BIP-39, and hierarchical address derivation is BIP-32 — not something to improvise.
- Storage. Where does the key live? On your server, and you are a custodian, with every regulatory and risk consequence. On the device, and you need a recovery path that is not "lost it, tough luck".
- Signing. Every network has its format. Structured-data signing follows EIP-712, and showing the user what they are signing is a security requirement, not decoration.
- Multiple networks. Each new network is a new set of formats, access nodes and error cases.
- Recovery. The part that generates the most support and shows up least in demos.
None of these is optional, and none of them is your product.
What changes with WaaS
Wallet as a Service moves that layer out of your scope. VKX WaaS embeds a non-custodial wallet across 8 networks in your app, with hosted infrastructure.
npm install @vkx/waas
The design has two halves:
- On the client, you initialize with the project's public key. The user gets a securely generated wallet and can receive, send and swap inside your product.
- On the server, operations requiring the secret key stay isolated from the app — where a secret credential belongs.
The part that matters most: the user's key does not sit with you. It is not in your database, it does not leak in your incident, and it does not turn you into a custodian. That stops being a risk you manage and becomes a property of the architecture.
Non-custodial does not mean no responsibility
Precision matters here, because this is the most common confusion. Self-custody does not eliminate risk — it transfers responsibility for the key to the user. What changes for you:
- You cannot move a user's funds. That is protection, and also limitation: there is no "chargeback" in the traditional sense.
- You remain responsible for the experience — making clear what the recovery phrase is, what happens if it is lost, and what your application does and does not do.
- You remain responsible for never asking for the user's key under any circumstance. Every fake-support scam exploits exactly that.
When WaaS is the right call
It makes sense when:
- The wallet is a means, not an end. Your product is a game, a marketplace, a fintech, a loyalty program. The wallet enables it, but is not the pitch.
- You do not want to be a custodian. Deciding not to hold someone else's key is strategic before it is technical.
- You need several networks. The cost of multi-network support grows per network, not once.
- Time to market matters. Integrating takes hours; building and maintaining takes quarters.
It does not make sense when the wallet is your product — outsourcing the core does not hold up there — or when a specific regulatory requirement demands a custody design of your own.
What comes ready
- 8 networks supported out of the box.
- Receive, send and swap inside your product, without pushing the user out.
- Hosted infrastructure: access nodes, signature formats and error cases stop being your problem.
If your case also involves users with no native coin to pay fees — common when the wallet is new — gas sponsorship solves the next step.
FAQ
Does the user's key pass through my server? No. The wallet is non-custodial: the key does not sit with you and does not exist in your database.
Does this make me a custodian? No. You have no way to move a user's funds — protection and limitation at the same time.
How many networks are supported? Eight out of the box, with receive, send and swap.
Do I need my own server? Yes, for operations using the project's secret key. Secret credentials do not go in the app.
What if the user loses the recovery phrase? In self-custody, recovery depends on it. Explaining that clearly in your product is part of the responsibility that stays with you.
Can I use only the swap? The operations are independent; the product page has the scope of each.
Next step
If you are deciding between building and integrating, the useful test is asking what your team will still be maintaining in two years. Integration details are on the WaaS page and in the documentation.
Disclaimer: this content is informational and educational and does not constitute investment advice.