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
  1. User deposits to their persistent address.
  2. 3PAY confirms the transaction on-chain; balance updates.
  3. 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 transactionId and updatedAt.
  • 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.