Contact us
/// Wallets · WaaS

Wallets are a feature, not a company

Your users need wallets; you do not need to become a wallet company. One API call creates the wallet, the SDK renders it inside your app, and the keys never leave the device.

Contact usAll products
1 call
POST /v1/wallets
4
SDKs — iOS · Android · RN · Web
On-device
Key material
Multi-chain
All major blockchains
/// 01

The API does the heavy lifting

POST /v1/wallets returns a wallet. Balances, transfers, and history are endpoints, not infrastructure you stand up. The developer console shows the whole surface — small enough to read in a sitting.

/// 02

The SDK disappears into your app

The wallet sheet embeds in the host app on iOS, Android, React Native, and Web — your navigation, your brand, our sheet. Key generation and signing happen on the device, so custody stays with the user where it belongs.

  • [ 01 ]One sheet, four platforms
  • [ 02 ]On-device keys — users hold their own
  • [ 03 ]Host app owns the experience around it
/// Features
The whole API on one screen — quickstart, keys, webhooks, uptime.
/// 01

The developer console

The console shows the whole surface: a quickstart that creates a wallet in one curl — HTTP 201 in 84 ms — live and test API keys, webhook delivery status, and the production numbers. The demo program runs 84,120 wallets at 99.99% uptime.

  • [ 01 ]Quickstart in curl, Node, Python, and Go
  • [ 02 ]Live and test keys, revealed and copied in place
  • [ 03 ]wallet.created webhooks with per-delivery status
One sheet inside the host app — balance, pay, receive, and the keys.
/// 02

The embedded sheet

In the demo, a ticketing app sells a €49.00 admission and the Protocore sheet slides up over it: a 124.00 USDC balance on Base, pay and receive, back up, export keys. The host app stays the product; the wallet is one sheet inside it.

Created — one call earlier, the wallet is ready to fund.
/// 03

Wallet ready

The end of onboarding is one screen: your wallet is ready. Funds and activity sync automatically from there — the user renames it, funds it, or just keeps going with the host app. The API call happened earlier; the user never saw it.

One user, three wallets — multi-chain, single-chain, watch-only.
/// 04

Many wallets, one user

The switcher in the demo holds three kinds at once: a multi-chain main wallet at €1,148.20, a single-chain Solana wallet still flagged to back up, and a watch-only cold-storage address along for visibility. Users organize funds the way they think about them.

  • [ 01 ]Multi-chain and single-chain wallets side by side
  • [ 02 ]Watch-only entries for addresses you track, not hold
  • [ 03 ]Unbacked wallets flagged until the seed is written down
Receive on Base — QR, address, and a warning that stops wrong-chain sends.
/// 05

Receive, with guardrails

A receive screen that assumes mistakes: the banner says Base assets only or funds could be lost, the QR and copyable address sit below, and the sheet lists exactly which assets this address supports. Set an amount to turn it into a request, or share the address as is.

Twelve words, once — written down offline, never asked for again.
/// 06

The recovery phrase

Twelve numbered words, shown once, written down offline. The screen carries its own security posture: screenshots are disabled, and Protocore states in plain text that it will never ask for these words. Custody stays with the user because the backup does.

Support-side lookup — 2,418 wallets, read-only, never custody.
/// 07

The wallet registry

The operator console keeps a read-side registry of every wallet in the tenant — 2,418 in the demo — with exact-match address lookup and a per-user view. The drawer says what the architecture enforces: the console never holds keys or moves funds. Addresses are surfaced for support and tracing, never swept.

  • [ 01 ]Exact-match address lookup across the tenant
  • [ 02 ]Owner, chain, label, and registration age per wallet
  • [ 03 ]One click from a wallet to its owner's User 360
142 assets on the record — contracts, decimals, and flags per token.
/// 08

The asset registry

142 assets on the record — symbol, name, chain, contract, decimals, and listing flags in one read-only table. USDC and ETH carry the Core flag; USDT sits flagged Unsafe. Your app surfaces exactly the tokens the registry vouches for, and nothing it does not.

Kill switches per action — off in the console, off in apps ~30s later.
/// 09

Kill switches per action

Send, receive, swap, and buy each have their own switch, their own off-mode — disable with a message, or hide entirely — and a master flag above them all. A change persists server-side and reaches apps in about 30 seconds. When a rail misbehaves, you turn off exactly that rail.

/// And more

POST /v1/wallets

One authenticated call returns a wallet — id, address, chains — in 84 ms in the demo. There is no infrastructure step before the first wallet; the endpoint is the infrastructure.

Four SDKs

iOS, Android, React Native, and Web ship as versioned SDKs — 1.4.2, 1.4.0, 0.9.1, and 2.1.0 in the demo console. One integration pattern, four platforms, the same sheet everywhere.

On-device keys

Key material is generated and held on the user's device — you get wallets without becoming a custodian. The sheet says it plainly at the bottom: secured by Protocore, keys on device.

Multi-chain by default

Wallets speak BTC, ETH, Base, and Solana from day one. The create call takes a chains array — the quickstart passes base and ethereum and gets one wallet back.

Balances, transfers, history

Everything after creation is an endpoint too: balances, transfers, and history are API calls, not systems you stand up. The console's transactions view reads from the same surface your app does.

Webhooks

Wallet events post to your endpoint with per-delivery status — the demo shows wallet.created at 100% success over 24 hours, last delivery two minutes ago. Your backend learns about wallets the moment they exist.

Live and test keys

Keys come in pairs — sk_live and sk_test — managed in the console. Test mode exercises the full surface before a real wallet exists.

Watch-only wallets

An address can join the switcher without its keys — balances visible, nothing spendable. Users keep an eye on cold storage from the same screen they spend from.

Backup nudges

A wallet without a written-down phrase carries a visible back-up flag until the user fixes it. The nudge lives where the money is, not in an email nobody opens.

Payment requests

Set an amount on the receive screen and share the result — the counterpart gets an address and a number instead of a screenshot and a guess. Plain address sharing stays one tap away.

Wrong-chain protection

Addresses are network-scoped and the UI says so before anyone sends: Base assets only, or they could be lost. The supported-asset list sits on the same screen as the QR.

Key export

Users can export their keys from the sheet — custody stays with the user, not just on the marketing page. The wallet outlives the app relationship if the user wants it to.

Automatic sync

Funds and activity sync without a refresh button — the sheet and the API see the same state. What the chain knows, the wallet shows.

No custody, by architecture

The operator console is read-side only: it can look addresses up, link them to users, and trace flows — it cannot move funds, because it never has the keys. The strongest compliance answer is a capability that does not exist.

User 360 for support

Every registered wallet links to its owner's User 360 in the operator console — balances, devices, KYC tier, and history one click from the address a customer is asking about.

Reason-required operations

Operator actions in the console are reason-required and audited — the production banner says so on every screen. Support can act fast without acting silently.

Whitelabel by design

The sheet renders inside your app — your navigation, your brand, our sheet. Users never leave the flow to find a wallet; it appears where the payment is.

Rename and organize

Wallets take names — Main wallet, Solana savings, Cold storage — from the moment they are created. A wallet a user can name is a wallet a user understands.

Proven at scale

The demo program runs 84,120 wallets at 99.99% uptime, on the same rails every new integration gets. The numbers sit on the console's front page, not in a sales deck.

/// In the product
The developer console — wallets as an API surface.
  • The SDK sheet, embedded — the host app stays the product.
  • Created — one call earlier, the wallet is ready to fund.
  • One user, three wallets — multi-chain, single-chain, watch-only.
  • Receive on Base — QR, address, and a warning that stops wrong-chain sends.
  • Twelve words, once — written down offline, never asked for again.
  • Support-side lookup — 2,418 wallets, read-only, never custody.
  • 142 assets on the record — contracts, decimals, and flags per token.
  • Kill switches per action — off in the console, off in apps ~30s later.
/// FAQ

Wallets by API, answered.

  • No. Key generation and signing happen on the user's device — the keys never reach our servers. You get wallets inside your app without becoming a custodian, and we could not move a user's funds if we tried.

  • One call — POST /v1/wallets — returns a wallet. Balances, transfers, and history are endpoints, not infrastructure you stand up, and the SDK renders the wallet sheet inside your app. The whole surface is small enough to read in a sitting.

  • No. The SDK sheet embeds in the host app — your navigation, your brand, our sheet. The host app stays the product; the wallet is a feature inside it, not a takeover.

  • SDKs for iOS, Android, React Native, and Web, and it is multi-chain from day one across all major blockchains. The receive screen even warns on a wrong-network send before it happens.

  • A twelve-word recovery phrase, shown once at setup to write down offline and never asked for again. Because keys are on-device, recovery is the user's phrase — not a support ticket to us.

  • Support gets a read-only console with exact-match address lookup — enough to help, never custody. Per-action kill switches can pause send, receive, swap, or buy across apps, but no operator can move a user's funds.

/// Evaluate

Create a wallet with one call.

[ 01 ]

Guided demo walkthrough

We run POST /v1/wallets with you and show the SDK sheet embedded in a host app on iOS, Android, React Native, and Web.

[ 02 ]

Developer sandbox

API keys against a test environment, so your team can create wallets, read balances, and move test funds end to end.

[ 03 ]

SDKs, webhooks, and docs

The four platform SDKs, event webhooks, and the integration docs — enough to embed a wallet in your own app.

[ 04 ]

On-device by design

See for yourself that key material is generated and held on the device — you get wallets without becoming a custodian.

Request sandbox access
Availability

Whitelabel by design — wallets ship inside your app, under your brand.

In the ecosystem

Wallets holds what Ramp buys and Chain settles — and Safe is where balances graduate when they stop moving.

Pick a product. Or take the core.

Everything above runs in production demos we can walk you through — standalone, whitelabel, or as one platform. Tell us what you're building and we'll show you the shortest path to it.

Contact us