Overview
The platform uses four types of wallets, each serving a strictly defined role in the payment-processing architecture.
Wallet Architecture & Security
The platform operates as a strictly non-custodial solution:
Key Management: Private keys are generated and stored exclusively in an isolated KMS vault. The platform never accesses raw keys.
Key Export: Merchants can export keys (Master, Transit, Static) only encrypted with their own RSA public key.
Strict Fund Flow: Funds move in a predefined direction: Transit / Static → Master → Cold. Direct transfers from transit or static wallets to cold wallets are strictly forbidden.
Master Wallets (Liquidity Wallets)
A Master Wallet is the core liquidity pool within a network.
Used for:
accumulating funds received from transit/static wallets
sending payouts to cold wallets
covering all network fees
ensuring stable operation of automatic sweep mechanisms
Key Properties
Used only for outgoing transactions.
Must always maintain a sufficient balance of the network’s native token (ETH for Ethereum, TRX for Tron, MATIC for Polygon, SOL for Solana, etc.).
Native tokens are mandatory
A Master Wallet must always hold enough native tokens to:
sign and send payouts
pay gas fees
initiate transfers from transit wallets
maintain the auto-sweep strategy
Without native tokens, even internal fund movements are impossible.
Transit Wallets (Payment Reception Wallets)
Transit wallets are designed to receive funds from end users as part of an order-based payment flow.
Used as:
one-time deposit addresses
intermediate storage before the automatic transfer to the master wallet
Key Properties
Generated by the platform (individually or in bulk).
Linked to a specific master wallet.
Not used for payouts.
Static Wallets (Permanent Deposit Wallets)
A Static Wallet is a permanent, dedicated deposit address assigned to a specific entity — a user, a merchant, a service, or any logical unit within the integrating system.
Unlike transit wallets, which are created per-order and recycled after use, static wallets persist indefinitely and always belong to the same recipient. Every deposit to a static wallet is tracked, confirmed, and reported automatically — without requiring an order to be created.
Key Properties:
Persist indefinitely — the address never changes or expires.
Every incoming transaction is automatically detected by the blockchain scanner.
Support both native coin and token deposits on the assigned chain family.
Cannot be used for payouts — deposits only.
Support force sweep to move accumulated funds to the master wallet.
Notification Modes:
When a deposit arrives on a static wallet, the platform notifies the merchant in one of two ways:
Webhook — if a callback URL was provided when the wallet was created, the platform sends HTTP notifications with deposit details for every status change.
Email — if no callback URL was configured, the platform sends an email notification to the project owner.
Automatic Sweep (auto-sweep)
Automatic Sweep is a built-in mechanism that moves funds from transit/static wallets to the corresponding master wallet according to a predefined strategy.
The platform supports three sweep modes, allowing you to control when and how assets are transferred.
Sweep Modes
turned_off
Automatic sweep is disabled.
Funds remain on transit wallets
Transfers can be executed only manually (force sweep)
Typically used for debugging, audits, or custom fund-flow logic
momentum
Funds are transferred immediately after deposit.
Event-driven sweep
No balance thresholds or delays
Best suited for:
high-frequency payments
real-time settlement scenarios
minimizing exposure on transit wallets
threshold
Funds are transferred only after the accumulated balance reaches a defined USD equivalent threshold.
The platform continuously tracks asset value
Sweep is triggered once the threshold is met
Optimized for:
reducing gas costs
batching multiple deposits
predictable liquidity management
Fee Handling Modes
Each sweep operation may require payment of network fees (gas). The platform supports three fee handling modes, applied consistently across all sweep modes.
client
Network fees are paid by the client
If the transit wallet does not have enough native tokens:
the system temporarily transfers the required amount from the master wallet
Fees are fully charged to the client
service
Network fees are paid by Crypto Chief
Required native tokens are supplied by the platform
The equivalent fee amount is deducted from API Credits
No interaction with the master wallet for gas funding
mix
A hybrid strategy combining both approaches:
The platform first attempts the client flow
If it fails (e.g. insufficient master wallet balance), it falls back to service
This mode provides maximum reliability while preserving cost efficiency.
Native Token Availability
If a transit/static wallet already contains enough native tokens, they are always used to pay network fees — regardless of the selected fee mode.
Only when native tokens are insufficient does the platform apply the configured fee handling logic.
Dynamic Transit Wallet Management
You do not need to pre-generate large numbers of transit wallets.
Transit wallets are created automatically as load increases
Wallet generation is instantaneous and does not block deposits
This architecture allows you to:
avoid storing thousands of unused addresses
evenly distribute incoming payments
process large numbers of deposits in parallel
keep the system horizontally scalable
As order volume grows, new transit wallets are provisioned automatically and without delays.
Cold Wallets (External Client Wallets)
Cold wallets are external customer or merchant addresses used for payouts.
Key Properties
The platform never has access to private keys of cold wallets.
Used only as payout destinations.
Cannot be sources of transactions.
Used for:
client payouts
merchant settlements
refunds
external storage of funds
distribution of received assets
Private Key Logic
Master, Transit and Static wallets store private keys (encrypted).
Cold wallets never store or submit private keys — only addresses.
When exporting, the private key is returned only in RSA-encrypted form.
Funds Flow
1. Transit/Static → Master
All funds are regularly transferred from transit wallets to master wallets:
by auto-sweep rules
or manually via force sweep
2. Master → Cold
Payouts are executed only from master wallets.
The platform validates:
liquidity sufficiency
availability of the requested asset
adequate native token balance for gas
3. Payout in a different asset
If the requested asset differs, you can enable:
The system will:
convert the asset (DEX / internal routing)
send the required token to the cold wallet
Security Restrictions
The platform is non-custodial — no access to raw private keys.
Payouts cannot be made from transit wallets.
Cold wallets can never be transaction sources.
Transit/Static → Cold transfers are forbidden.
Master wallets should not receive external deposits.
Last updated