Architecture
This page explains how the walt.id Wallet SDK is assembled: a shared holder core, a mobile facade, a Swift API, sample apps, and the custodial Wallet API v2.
The Wallet SDK is a headless holder stack. Your app owns screens, branding, and consent UX. The SDK owns protocol sessions, credential matching, keys, and storage.
Product Boundaries
Loading diagram...
| Piece | Role |
|---|---|
| Core library | Framework-agnostic OID4VCI 1.0 and OID4VP 1.0 holder logic, including DCQL matching. |
| Mobile SDK | Android and Kotlin Multiplatform facade: sessions, encrypted persistence, platform keys, proximity, and Digital Credentials API hooks. |
| Swift WalletSDK | Native async/await iOS API over the same mobile module. |
| Wallet API v2 | Custodial HTTP surface that uses the same core. Community and Enterprise share this holder logic. |
| Sample apps | Reference shells that prove the integration. Replace the UI; keep the SDK. |
When to Use Which Surface
- Mobile SDK — You are embedding a non-custodial wallet in an Android or iOS app. Keys stay on the device.
- Wallet API v2 — You are building a custodial or server-held wallet, a web wallet, or a Wallet-as-a-Service backend.
- Sample apps — You want a working wallet to try Portal2, white-label a shell, or copy an integration pattern.
The demo apps own PIN lock, brand colours, QR rendering, and permission prompts. Those are not Wallet SDK APIs. Session state, matching, reader trust, and credential storage stay in the SDK.
Next Steps
- Try a sample app — Try the Demo.
- Create a wallet in your app — Integrate the SDK.
- Use the custodial HTTP wallet — Wallet API v2 Getting Started.
Last updated on September 29, 2026