Overview
The platform uses three types of wallets, each serving a strictly defined role in the payment-processing architecture.
Master Wallets (Liquidity Wallets)
A Master Wallet is the core liquidity pool within a network.
Used for:
accumulating funds received from transit wallets
sending payouts to cold wallets
covering all network fees
ensuring stable operation of automatic sweep mechanisms
Key Properties
Private keys are stored (encrypted on the platform side).
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.
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).
Have their own private keys.
Linked to a specific master wallet.
Not used for payouts.
Automatic Sweep (auto-sweep)
Automatic Sweep is a built-in mechanism that moves funds from transit 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 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 settl
refunds
external storage of funds
distribution of received assets
Private Key Logic
Master and Transit 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 → 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
Payouts cannot be made from transit wallets.
Cold wallets can never be transaction sources.
Transit → Cold transfers are forbidden.
Master wallets should not receive external deposits.
Last updated