WALLET AS A SERVICE DEVELOPMENT
PROPELOO engineers Wallet-as-a-Service platforms — multi-chain wallet creation APIs, custodial and MPC key management, transaction signing infrastructure, webhook event notification, gas management, and the developer SDK that makes embedding wallets a one-week integration instead of a six-month infrastructure project. Every application that touches blockchain needs wallets. WaaS is the infrastructure layer that makes that practical.
Every blockchain application needs to create wallets for users, sign transactions on their behalf or with their approval, manage gas, handle chain reconnection and failed transactions, and notify the application of on-chain events. Building this infrastructure in-house requires deep expertise in key management, cryptography, multi-chain RPC management, and transaction lifecycle handling. For most application teams, this is not a core competency — it is infrastructure that must work reliably without requiring constant engineering attention. Wallet-as-a-Service moves this complexity to a dedicated infrastructure layer: a REST API and SDK that application developers call to create wallets, sign transactions, query balances, and receive transaction event webhooks. PROPELOO builds WaaS platforms for infrastructure operators who want to offer this capability to developer customers, and builds WaaS integrations for applications that need embedded wallet functionality.
Key management, transaction infrastructure, and developer experience are three distinct engineering domains.
HD wallet generation (BIP-44 derivation for multi-chain from a single seed). Custodial: platform holds keys in HSM with encryption at rest. MPC: keys split across parties, no single party has the full key. Access control: API key scoping (sign-only, query-only, full access).
EVM chains (Ethereum, Polygon, BSC, Avalanche, Arbitrum, Base), Bitcoin, Solana, TRON, Cosmos SDK chains. Normalised balance API across chains. Chain-specific transaction construction (UTXO for BTC, account-based for EVM, different fee models).
Transaction construction with gas estimation. Broadcast with monitoring. Stuck transaction replacement (gas bump). Failed transaction retry with exponential backoff. Transaction receipt and confirmation webhooks.
Real-time webhook delivery for: wallet creation, transaction confirmed, transaction failed, balance change, token transfer received. Webhook retry with exponential backoff. Webhook signature verification.
JavaScript/TypeScript SDK (Node.js and browser). Python SDK. REST API for language-agnostic integration. API keys with scoped permissions. Sandbox mode with testnet networks. Comprehensive documentation with code examples.
Automatic gas estimation with priority fee options (fast, standard, slow). Gas price oracle integration. Gas sponsorship (paymaster) for gasless user transactions. Gas top-up notifications for custodial wallets.
WaaS is infrastructure — it must be reliable, observable and operable 24/7 without engineering intervention.
An application that relies on WaaS for user wallet operations cannot afford WaaS downtime. The infrastructure must be designed for 99.9%+ availability: redundant RPC providers, automatic failover, transaction retry on network congestion, and graceful degradation (queue transactions during outage, process on recovery).
Axiom: FIVE-NINES OR NOTHING
WaaS holds signing authority over user wallets. A key management breach exposes every wallet on the platform. HSM storage, MPC key splitting, access logging, and regular key management audits are the minimum security requirements. The key management architecture must be documented and independently auditable.
Axiom: KEY MANAGEMENT IS THE PRODUCT TRUST
A WaaS platform that requires 40 lines of boilerplate to send a transaction will not be adopted. The SDK must make the common operations (create wallet, send transaction, get balance, receive webhook) achievable in under 10 lines. Documentation with working code examples is as important as the API itself.
Axiom: DEVELOPER EXPERIENCE IS ADOPTION
These choices define security model, chain coverage and developer adoption.
Impact: MPC for enterprise WaaS where custody liability is a concern. Custodial HSM for developer-focused WaaS where operational simplicity is more important. User-controlled for consumer-facing embedded wallet use cases.
Impact: Multi-provider with automatic failover for production. Own nodes for chains where latency is critical (high-frequency applications). Single provider is acceptable for development and low-volume production.
Impact: Automatic retry with gas bump and developer notification is the right default. Manual override should be available for applications that need precise gas control.
Impact: At-least-once with idempotency keys is the practical standard. Application developers must handle duplicate events, which is standard practice for webhook consumers.
Full Wallet-as-a-Service platform — multi-chain API, MPC key management, SDK, webhooks, developer portal, billing.
Custodial wallet infrastructure for a crypto exchange — multi-chain deposits, hot/cold management, withdrawal queue, reconciliation.
Embedded wallet layer for a FinTech application — users get a wallet on signup, transactions happen invisibly, no crypto UX required.
Enterprise-grade wallet API for internal blockchain operations — ERP integration, treasury management, supply chain payments.
Security-first, reliability-second, developer-experience-third — in that order.
Stack: AWS CloudHSM / Thales HSM, Fireblocks MPC (option), BIP-32/44 key derivation, Encryption at rest (AES-256), Key access audit logging
Stack: Alchemy / Infura / QuickNode, Multi-provider failover, Custom node operation, Chain-specific libraries, RPC health monitoring
Stack: Gas oracle integration, Nonce management, Transaction queue (Redis), Retry with gas bump, Confirmation monitoring
Stack: Node.js REST API, TypeScript SDK, Python SDK, API key management, Sandbox environment
Platform compromise at the key management layer exposes every wallet.
Keys never leave the HSM in plaintext. MPC keys never reconstructed on a single machine. All signing operations happen inside the secure element or distributed across MPC nodes.
Developer API keys scoped to minimum required permissions: sign-only, query-only, specific wallet IDs. API key compromise limited to the scope granted.
Per-wallet and per-API-key daily transaction limits. Large transaction approval workflow. Anomalous transaction pattern detection and alerting.
Every key operation, every transaction signature, every wallet creation logged with timestamp and requestor identity. Logs immutable and exportable for security audit.
Key management model, chain coverage, transaction lifecycle, webhook design, API interface.
HSM/MPC setup, key derivation, access control, recovery procedures.
Multi-chain RPC setup, failover configuration, transaction construction per chain.
Transaction queue, signing, broadcast, retry, confirmation monitoring.
Event monitoring, webhook delivery, retry, signature verification.
REST API, JavaScript SDK, Python SDK, documentation, sandbox.
Key management audit, penetration testing, SDK security review.
Custodial: the WaaS platform generates and stores the full private key, typically in an HSM. The key exists as a complete entity in the HSM. MPC: the key is split into shares held by multiple parties (e.g., WaaS platform + developer + hardware device). No single party has the complete key. Transactions require a threshold of parties to sign. MPC eliminates single-point-of-key-compromise at higher operational complexity.
Multi-provider setup: we configure 2-3 RPC providers per chain. The primary provider handles all requests. On failure (timeout, error), the request automatically retries against the secondary provider. Failed transactions are queued and rebroadcast when connectivity restores. RPC provider health is monitored continuously with alerts on degradation.
Yes. We build the connectivity layer to be provider-agnostic. You can run your own Ethereum/Polygon/etc. nodes and configure them as the primary RPC endpoint, with commercial providers as fallback. This is the standard setup for high-volume or latency-sensitive applications.
Via REST API (language-agnostic) or language-specific SDK (JavaScript/TypeScript, Python). Core operations: createWallet(), getBalance(), sendTransaction(), getTransactionStatus(), registerWebhook(). Each takes under 10 lines with the SDK. Full documentation with copy-paste code examples.
We integrate OpenID Connect (OIDC) and OAuth 2.0 authentication flows (Google, Apple, Telegram, Twitter). When a user authenticates with their social identity, a dedicated cryptographic key share is derived using zero-knowledge identity proofs, creating a non-custodial wallet instantly without requiring seed phrases.
Yes. Through ERC-4337 account abstraction infrastructure, developers can deposit gas sponsorship funds into an on-chain Paymaster contract. The WaaS SDK transparently signs gasless UserOperations, enabling zero-friction onboarding where users do not need to hold native blockchain tokens to interact.
Our WaaS backend is deployed across active-active multi-region Kubernetes clusters with automated failover. We maintain continuous 99.99% service availability SLAs, backed by automated health checks, geo-distributed database clustering, and sub-100ms API response latency.
Yes. We integrate cross-chain bridge aggregators (Li.Fi, Socket) and turnkey fiat on/off-ramps (Stripe Crypto, MoonPay, Sardine) directly into the client SDK, enabling end users to purchase crypto with credit cards or swap tokens across chains without leaving the parent application.