User Wallets
User Wallets are segregated, on-chain wallets provisioned per end user under a business’s 3PAY account. Each wallet is independent, has its own persistent deposit address per enabled rail, and can be verified directly on-chain. Such user wallets are just a reference to the type of wallet. Such wallets could be for end-users or merchants according to different business models.
Role in Each Operating Model
- Non-custodial model: User Wallets are enabled. Funds reside in each user’s own wallet; the business does not pool or commingle balances.
- Custodial model: User Wallets are typically not provisioned. Users are credited on the business’s internal ledger while funds settle to the Account Wallet. (Optionally, “virtual” user accounts may mirror balances off-chain.)
Addresses and Funding
- Persistent deposit address: Each User Wallet exposes a stable, reusable address per supported
currencyType(e.g., USDT-TRC20). - Multiple rails: A wallet can present distinct deposit addresses for every enabled asset/network.
- Inbound detection: Deposits are observed on-chain and reflected after confirmation; events can be delivered via webhooks.
Controls and Governance
- Outbound policy: Transfers/withdrawals from a User Wallet follow policy—e.g., multi-party approvals, limits, velocity rules.
- Segregation guardrails: Policies can prevent sweeping to the Account Wallet unless explicitly authorized.
- Programmatic holds: Optional holds or review states can be applied prior to outbound settlement.
Reconciliation and Records
- On-chain source of truth: Balance and history for each user are independently verifiable.
- Linkage: Persist
walletId,address,currencyType,transactionId, timestamps, and policy/approval artifacts. - Reporting: Per-user statements can be generated directly from on-chain data plus webhook logs.
Typical Flows (Non-Custodial)
User Deposit → User Wallet → (Optional) Business Action → Withdrawal / Payout / Treasury Transfer
- User deposits to their persistent address.
- 3PAY confirms the transaction on-chain; balance updates.
- According to policy, funds can be withdrawn by the user, paid out to corridors, or transferred to designated treasury destinations.
Compliance Considerations
- KYC/KYB ownership mapping: Each User Wallet should be mapped to a verified identity per your compliance program.
- Sanctions/AML screening: Apply screening on inbound and outbound legs; retain evidence of checks.
- Refunds to origin: If refunds are supported, return to the source address to maintain auditability.
- Jurisdictional controls: Enforce restricted-country policies at the user level.
Operational Best Practices
- Deterministic labeling: Tag User Wallets with immutable references (e.g.,
userId,accountId). - Minimal rail surface: Enable only the rails you actively reconcile and support.
- Alerts and limits: Configure balance/velocity alerts and per-user thresholds.
- Idempotency: Make webhook handling idempotent per
transactionIdandupdatedAt. - Lifecycle management: Provide processes for suspend/close, export of statements, and data retention.
When to Use User Wallets
- You require true segregation of client funds and on-chain verifiability.
- You operate in environments where non-custodial control reduces counterparty and systemic risk.
- You need stable deposit addresses per user to simplify recurring funding and reconciliation.
Next Steps
- Review Account Wallets for treasury and payout orchestration.
- See Custodial vs Non-custodial to choose the appropriate operating model.
- Configure Policies & Governance to enforce approvals and thresholds on user-initiated outflows.
Updated about 1 month ago
