Step-by-step guide covering wallet registration, sub-contract creation, auto-sweep, and auto-withdrawal configuration

This document is designed for non-API merchants. It walks you through generating recharge addresses, setting up prepaid deposits, enabling KYT detection, configuring auto-sweep and auto-withdrawal strategies, and handling blacklisted fund sweeps — all from the admin console without any code integration.

Tutorial Objectives​

This tutorial guides you through the complete workflow: wallet preparation, admin console login, batch sub-contract creation, prepaid account setup, pollution blocking (KYT) activation, auto-sweep and auto-withdrawal strategy configuration, blacklisted fund sweep setup and withdrawal, a live payment test, and verifying the automated execution results.

Prerequisites​

• A Web3 decentralized wallet, such as TronLink
• 3 merchant admin wallet addresses
• 1 merchant finance wallet address
• Corresponding chain assets, e.g. TRC20 USDT
• Platform invitation code
• Admin approval required before logging in to the admin console

Overall Workflow​

1. Register or prepare wallets
2. Log in to the admin console
3. Batch-create sub-contract addresses
4. Enable the prepaid account and deposit funds
5. Enable pollution blocking / KYT detection
6. Configure auto-sweep and auto-withdrawal strategies
7. Configure blacklisted fund sweep settings
8. Sweep and withdraw blacklisted funds
9. Complete a test payment using a sub-contract address
10. Verify auto-sweep and auto-withdrawal results

Part 1: Basic Configuration​

1. Register or Prepare Wallets​

Before using the system, you need a Web3 decentralized wallet and must submit your organization information via the registration page. This tutorial uses a TRC20 standard merchant as an example.

You can use an existing Web3 wallet or create a new one by following the official guide: Create a Web3 Wallet

Instructions​

On the registration page, select the organization type and blockchain network. Fill in the organization name, email, admin wallet address, finance wallet address, and invitation code. Check the agreement box and click Sign Up to submit.

2. Log In to the Admin Console​

Once approved, you can log in to the admin console using an admin wallet.

Instructions​

Open the login page, select the blockchain network used during registration (e.g. Tron(TRC20)), click Connect TronLink Wallet, and once connected, click Login to enter the admin console.

3. Batch-Create Sub-Contract Addresses​

No code integration is required. You can batch-generate recharge sub-contract addresses directly from the admin console for user deposits and fund collection.

Instructions​

Navigate to Funds → Sub-Contracts, click Create, enter the number of sub-contracts to create (e.g. 10), select Recharge as the sub-contract type, and click Submit.

Sweep Methods​

After a sub-contract address receives user deposits, merchants can handle fund sweeping in two ways:

1. Auto-sweep: Configure auto-sweep rules on the strategy settings page. The system automatically sweeps funds when thresholds are met.
2. Manual sweep: Merchants can also manually initiate sweeping from the admin console based on actual fund processing needs.

After sweeping, funds move into the cold contract. Merchants can later use auto-withdrawal strategies or manually withdraw to transfer cold contract funds to the finance wallet.

Manual Sweep​

Navigate to Funds → Sweep and view the list of sub-contracts with pending sweep balances under the Pending Sweep tab.

Select the sub-contracts you want to sweep and click Bulk Sweep. The system will prompt a wallet signature request. Once you click Sign in your wallet, the sweep transaction is submitted on-chain. Successful sweep records can be found under the Sweep Records tab.

Manual Withdrawal​

After a successful sweep, funds enter the cold contract. To withdraw cold contract funds to the finance wallet, navigate to Asset Details and click One-Click Rebalance, or check the result under Rebalancing Records.

This action transfers cold contract funds to the merchant's finance wallet, which is useful when you need to move swept funds for subsequent operations.

4. Enable the Prepaid Account and Deposit Funds​

The prepaid account must be enabled before you can use auto-sweep, auto-withdrawal, and KYT detection features.

Instructions​

Navigate to System Configuration → Strategy Settings → Prepaid Account. Toggle the prepaid switch on, click Deposit, select the deposit network (e.g. Tron(TRC20)), and copy the deposit address or scan the QR code to send USDT. After the deposit is confirmed, refresh the prepaid balance.

5. Enable Pollution Blocking / KYT Detection​

Pollution blocking detects whether deposited funds carry risk. When enabled, the KYT detection service is activated. If risky funds are detected, the corresponding recharge sub-contract will be blacklisted for separate handling.

Instructions​

Navigate to System Configuration → Strategy Settings → Sweep Strategy, set the Pollution Blocking switch to Enabled, and click Save Sweeping Strategy.

6. Configure Auto-Sweep and Auto-Withdrawal Strategies​

Auto-sweep collects funds from sub-contracts into the cold contract. Auto-withdrawal transfers funds from the cold contract to the merchant's finance wallet.

Instructions​

Navigate to System Configuration → Strategy Settings. On the Sweeping Strategy tab, set the sweep trigger conditions — for example, sweep when the cumulative balance of all sub-contracts reaches 1,000 USDT, or when a single sub-contract balance exceeds 100 USDT. Switch to the Rebalancing Strategy tab and set the cold contract balance trigger — for example, auto-withdraw when the cold contract balance reaches 100 USDT. Save each strategy after configuration.

7. Configure Blacklisted Fund Sweep Settings​

When the system detects risky funds via KYT, a sub-contract may be blacklisted. Blacklisted sub-contracts are excluded from the normal sweep process. Merchants must configure emergency sweep and emergency rebalancing addresses via multisig to handle these funds separately.

Instructions​

On the Edit Configuration Proposal page, click Update to create a multisig parameter change proposal.

Select Modify Emergency Rebalancing Address as the multisig type, choose New for the address, and click Submit. The system will prompt a wallet signature. After the admin completes the signature, the proposal enters a pending approval state.

Multisig Approval​

After the proposal is submitted, you need to switch to another admin wallet for approval.

Log in with another admin wallet and navigate to: System Configuration → Multi-Signature Management → Edit Configuration Proposal. Find the pending proposal, click Approve, and complete the signature in your wallet. Once signed, the system continues the on-chain submission and waits for blockchain confirmation.

8. Sweep and Withdraw Blacklisted Funds​

When a sub-contract is blacklisted due to KYT detection, its funds are excluded from the normal sweep process. Merchants can manually sweep these funds to the emergency sweep address for separate handling.

Instructions​

Navigate to: Funds → Sweep → Blacklist

Select the sub-contracts you want to process in the blacklist and click Bulk Sweep. The system will prompt a wallet signature. After the admin completes the signature, the sweep transaction is submitted on-chain.

Withdraw Blacklisted Funds​

After blacklisted sub-contract funds have been swept to the emergency sweep address, merchants can withdraw them to the emergency rebalancing address for further freezing, auditing, or refund processing.

Navigate to: Asset Details → Emergency Rebalancing

View the emergency sweep address balance and click One-Click Rebalance. The system will prompt a wallet signature. After the admin completes the signature, the rebalancing transaction is submitted on-chain.

Part 2: Live Demo​

After completing the configuration above, you can run a live payment test to verify that auto-sweep and auto-withdrawal execute correctly.

9. Complete a Test Payment Using a Sub-Contract Address​

Select a created recharge sub-contract address and provide it to a user for payment.

Instructions​

Navigate to Funds → Sub-Contracts and copy a recharge sub-contract address. The user can send USDT to this address from a Web3 wallet or exchange. After the transfer, navigate to Reconciliation → Recharge Report to view the corresponding deposit order.

10. Verify Auto-Sweep and Auto-Withdrawal Results​

After a successful user payment, if the strategy conditions are met, the system will automatically execute sweep and rebalancing.

Instructions​

To check sweep results: navigate to Funds → Sweep → Sweep Records. To check rebalance results: navigate to Asset Details → Rebalancing Records.

Part 3: Key Reminders​

• The prepaid account must be enabled and funded before using any auto-strategy.
• Admin wallets must be Web3 decentralized wallets.
• Recharge sub-contract addresses can be provided directly to users for deposits.
• Collection addresses are mainly for address pool expansion and should not be given to users for deposits.
• When pollution blocking is enabled, risky sub-contracts are blacklisted and excluded from the normal sweep process.
• Auto-sweep and auto-withdrawal only execute when trigger thresholds are met.
• Always click Save after configuring strategies.
• On-chain transactions require block confirmation; the admin console may not update immediately.
• Test payment amounts must meet the configured trigger thresholds.
• Auto-distribution and auto-refund require contact with the technical team for setup.

Part 4: Completion Checklist​

• Merchant registered and approved
• Admin wallet can successfully log in to the admin console
• Recharge sub-contract addresses batch-created
• Prepaid account enabled and funded
• Pollution blocking / KYT detection enabled
• Auto-sweep strategy saved
• Auto-withdrawal strategy saved
• User payment to sub-contract address successful
• Deposit order visible in admin console
• System auto-sweep executed successfully
• System auto-withdrawal executed successfully

1. Access the Strategy Settings Page​

Log in to the admin console and navigate to:

Configuration → Strategy Settings

On this page, you can configure prepaid accounts and strategy settings (sweeping strategy, rebalancing strategy, withdrawal/distribution strategy).

2. Enable the Prepaid Account​

By default, you will land on the Prepaid Account tab.

If the status shows Disabled, toggle the switch on the right to enable it.

Once enabled, the status will change to Enabled and a Deposit button will appear.

3. Deposit to the Prepaid Balance​

Click the Deposit button to open the deposit dialog.

Steps:

1. Select a deposit network, e.g. BSC(BEP20);
2. The system will generate a deposit address and QR code for the selected network;
3. Click Copy to copy the deposit address;
4. Send USDT to this address from your wallet or exchange;
5. After the deposit is confirmed, refresh the page to check your balance.

4. Configure the Sweeping Strategy​

Navigate to Strategy Settings and select the Sweeping Strategy tab.

The sweeping strategy automatically collects funds from sub-contracts when their balances reach the configured thresholds.

Configurable items:

After configuration, click Save Sweeping Strategy.

5. Configure the Rebalancing Strategy​

Select the Rebalancing Strategy tab.

The rebalancing strategy automatically triggers withdrawals when cold or hot wallet balances reach the configured thresholds.

Configurable items:

After configuration, click Save Rebalancing Strategy.

6. Configure the Withdrawal (Distribution) Strategy​

Select the Withdrawal (Distribution) Strategy tab.

The withdrawal/distribution strategy limits the number of wallets and maximum amount processed per task to prevent excessive processing in a single run.

Configurable items:

After configuration, click Save Withdrawal (Distribution) Strategy.

7. Create Sub-Contract Addresses​

Navigate to:

Funds → Sub-Contracts

On this page, you can view existing sub-contract addresses, types, statuses, balances, and last update times.

8. Batch Create Sub-Contracts​

Click the Create button to open the sub-contract creation dialog.

Fill in the following:

After filling in, click Submit.

9. Sub-Contract Types​

1. Recharge Sub-Contract​

Recharge sub-contract addresses can be provided directly to users for deposits.

Use cases:

1. Assign a fixed deposit address to users;
2. Users transfer USDT directly to this address;
3. The system monitors incoming funds and sweeps them according to the strategy.

2. Payment Sub-Contract​

Payment sub-contracts are used for payment pool scaling. Merchants generally do not need to create them manually.

When a merchant creates a payment link, the system automatically generates a payment sub-contract address.

10. Complete Operation Workflow​

1. Log in to the admin console with a super admin account;
2. Navigate to System Configuration → Strategy Configuration;
3. Toggle on the Prepaid Account switch;
4. Click Top Up, select the network and copy the deposit address;
5. Send USDT to the deposit address via the corresponding network;
6. Refresh the page after deposit to confirm the prepaid balance has increased;
7. Navigate to Strategy Settings;
8. Configure the Sweeping Strategy;
9. Configure the Rebalancing Strategy;
10. Configure the Withdrawal (Distribution) Strategy;
11. Click the corresponding save button after configuring each strategy;
12. Navigate to Funds → Sub-Contracts;
13. Click Create;
14. Select the sub-contract type and enter the quantity;
15. Click Submit to generate sub-contract addresses;
16. Provide the recharge sub-contract addresses to users for deposits.

11. Important Notes​

This guide explains how to use the sub-wallet features of TronLink / MetaMask to manage multiple merchant accounts with 4 mnemonic groups (3 multisig admin groups + 1 treasurer group), each corresponding to 4 master wallets, and complete the following tasks:

• Create sub-wallets for each merchant's multisig admins and treasurer address
• Register a new merchant and configure the multisig admin and treasurer wallets
• Obtain the API Key for integration by the development team

Supplemental Note: What Is an HD Wallet?​

An HD wallet (Hierarchical Deterministic Wallet) is a wallet model that derives addresses from a mnemonic phrase according to a fixed hierarchical rule.

• One mnemonic group can restore all accounts and addresses under that group.
• The same mnemonic group can continuously derive and manage multiple addresses, without generating a new mnemonic for each new address.
• A master wallet and its sub-wallets are essentially accounts on different derivation paths under the same mnemonic group.
• As long as the derivation path is the same, the same address can be restored on a different device.

In the context of this guide, it can be understood as follows:

• You maintain 4 mnemonic groups, corresponding to 4 master wallets (3 multisig admin wallets + 1 treasurer wallet).
• Each merchant derives 1 sub-wallet from each of these 4 master wallets.
• Since every address has a deterministic derivation source, multi-merchant management is clearer and permission separation is more explicit.

1. Use Cases​

If you need to repeat the merchant registration flow for multiple merchants while keeping mnemonic management simple, this approach is a better fit:

• Use 4 master wallets as the fixed base accounts (3 multisig admin master wallets + 1 treasurer master wallet)
• For each new merchant, derive 1 sub-wallet from each of the 4 master wallets
• Use 3 of the sub-wallets as that merchant's multisig admins, and 1 sub-wallet as the treasurer wallet

2. Wallet Structure and Prerequisites​

Before registering a new merchant, confirm the wallet hierarchy and the required parameters.

Wallet Hierarchy​

• First layer: 4 mnemonic groups (3 multisig admin groups + 1 treasurer group) Description: each mnemonic group is kept separately and corresponds to 1 master wallet
• Second layer: 3 multisig admin master wallets + 1 treasurer master wallet Description: each is derived from its own mnemonic group and can be used on both TRON and EVM chains
• Third layer: sub-wallets Description: each master wallet derives 1 sub-wallet; 3 sub-wallets serve as multisig admins and 1 sub-wallet serves as the treasurer wallet

Process diagram:

What to Prepare Before Registration​

• Multisig admin master wallets: 3, each derived from one multisig admin mnemonic group
• Treasurer master wallet: 1, derived from the treasurer mnemonic group
• Sub-wallets per merchant: 4, one from each of the 4 master wallets above
• Registration code: obtain from the business team
• Supported chains: the flow is the same for TRON and EVM chains

3. Create the Admin and Treasurer Sub-Wallet Addresses​

Option 1: Create Sub-Wallets with TronLink (TRON)​

Reference: TronLink Wallet Setup Tutorial

The basic flow is as follows:

1. Switch to multisig admin master wallet 1 and confirm that the current account is master wallet 1.

   

2. In TronLink, open the wallet-add flow.

   

   

3. Choose "Create sub-account", select the TRON chain, and enter a sub-wallet name such as "Merchant A Multisig Admin 1".

   

   

   

4. After creation, copy the sub-wallet address for later use.

   

   

5. Switch to multisig admin master wallets 2 and 3, and then to the treasurer master wallet, and derive 1 sub-wallet from each. Name them "Merchant A Multisig Admin 2/3" and "Merchant A Treasurer Wallet".

6. Once you have the 4 sub-wallet addresses, use them to register Merchant A. See the registration steps below.

   

7. After the merchant is successfully registered, switch to the corresponding sub-account and log in to the backend.

   

Option 2: Create Sub-Wallets with MetaMask (EVM)​

Reference: MetaMask Getting Started

The basic flow is as follows:

1. Open MetaMask and switch to multisig admin master wallet 1.

   

2. Click "Add account" or "Create new account" to derive one sub-account under master wallet 1.

   

   

3. Rename the sub-account, for example "Merchant A Multisig Admin 1", and copy the address for later use.

   

   

   

   

   

4. Switch to multisig admin master wallets 2 and 3, and then to the treasurer master wallet, and derive 1 sub-account from each.

5. You will end up with 4 sub-account addresses, which are used to register the same merchant.

4. Register the Pay Protocol Admin Console​

Use the 3 multisig admin sub-wallets and 1 treasurer sub-wallet created above to complete merchant registration at the sign-up page.

Sign-up page (sandbox): https://adm-sandbox.payprotocol.network/signUp

Registration Steps​

1. Open the sign-up link.

   

2. Choose "Standard" as the organization type.

3. Select the blockchain, such as TRON or ETH.

4. Enter the registration code. Obtain it from the business team.

5. Fill in the 3 multisig admin addresses and 1 treasurer wallet address, which are the 4 sub-wallet addresses prepared above.

6. Review the information and click "Submit".

7. Wait for Pay Protocol to complete the approval.

5. Log in to the Admin Console and Get the API Key​

1. Log in to the Chain Admin Console​

Use the admin wallet for the corresponding chain to log in.

• If this is a TRON admin account, choose Tron as the blockchain type
• If this is an EVM admin account, choose the corresponding EVM network

2. Get the API Key​

1. After logging in, go to the "Organization Info" page.

2. Click "Reset API Key".

   

3. Copy the API Key and API Secret.

   

4. Provide the API Key / API Secret to the development team for subsequent system integration.

6. Enable Additional Chains and Currencies​

After the merchant is registered successfully, you can continue to enable more chains and currencies. See the following guides:

• Enable a New Chain and Currency
• Multisig Withdrawal Limit Configuration Guide

You can execute the process in the following order:

• Replace the cold contract (multisig)
• Set the emergency sweep address (multisig)
• Set the emergency rebalancing address (multisig)
• Sweep and withdraw funds from blacklisted sub-contracts

1. Cold Contract Replacement​

Overview​

The cold contract stores large merchant balances. To avoid contamination from high-risk transactions or other security risks, merchants can replace the cold contract address through multisig. This operation requires two admin wallets (one to create the proposal, one to approve and submit on-chain) to protect fund security.

This section uses the Pro console as an example and explains the full replacement procedure.

Steps​

1. Log in with an admin wallet and go to "System Configuration -> Multi-Signature Management".

   

2. On the Multi-Signature Management page, open the "Edit Parameter Proposal" tab, click "Modify", and choose "Modify Cold Contract Address" from the "Category" dropdown.

   

3. In the "Address" dropdown, choose the target cold contract address:

   • If no replacement address exists, choose "New" and let the system generate a new cold contract address.
   • If historical addresses exist, select one of the previously used cold contract addresses.

   

4. Confirm and sign with the current admin wallet to create the proposal.

5. Sign out, switch to another admin wallet, go to "Multi-Signature Management -> Edit Parameter Proposal", find the pending proposal, and click "Approve".

   

6. Verify the details in the approval dialog, sign with the wallet, then confirm on-chain in the wallet (a small gas fee is required).

   

7. Wait about 1 minute. When the proposal status changes to "Approved", the cold contract address replacement is complete.

   

Additional Note: Hot Contract Address Update​

The hot contract address update follows the same multisig proposal workflow as cold contract replacement:

1. Log in with an admin wallet, choose "Modify Hot Contract Address" in "Edit Parameter Proposal", create the proposal, and sign.

   

2. Switch to another admin wallet, approve the proposal, and confirm on-chain in the wallet.

   

3. Wait about 1 minute. Once status becomes "Approved", the hot contract address update is complete.

   

2. Set Emergency Sweep and Emergency Rebalancing Addresses​

Overview​

The Emergency Sweep Address and Emergency Rebalancing Address are used to handle funds from high-risk sub-contracts. When a merchant's receiving sub-contract is marked as high-risk or blacklisted, funds can be swept to the Emergency Sweep Address first, then moved to a safe external wallet through the Emergency Rebalancing Address. This isolates risk and protects the main contract funds.

This feature is typically used with the blacklist API. See: Blacklist API.

The full process includes three phases:

1. Set the Emergency Sweep Address (multisig)
2. Set the Emergency Rebalancing Address (multisig)
3. Sweep funds from high-risk sub-contracts and withdraw them to an external wallet

Phase 1: Set the Emergency Sweep Address​

1. Log in with an admin wallet and go to "System Configuration -> Multi-Signature Management -> Edit Parameter Proposal".

   

2. Click "Modify", choose "Modify Emergency Sweep Address" in "Category", then choose the address:

   • If no Emergency Sweep Address exists yet, choose "New" to let the system generate one.
   • If historical emergency sweep addresses exist, select one for replacement.

   

3. Connect the wallet and sign to create the proposal.

   

4. Sign out, switch to another admin wallet, go to "Multi-Signature Management -> Edit Parameter Proposal", find the pending proposal, and click "Approve".

   

5. Verify details in the approval dialog, sign with the wallet, and confirm on-chain (a small gas fee is required).

   

6. Wait about 1 minute. When status becomes "Approved", Emergency Sweep Address setup is complete.

Phase 2: Set the Emergency Rebalancing Address​

The setup flow is identical to Emergency Sweep Address setup. In the "Category" dropdown, choose "Modify Emergency Rebalancing Address".

1. Log in with an admin wallet, choose "Modify Emergency Rebalancing Address" in "Edit Parameter Proposal", select "New" or a historical address, click "Submit", and sign.

   

2. Switch to another admin wallet and approve the proposal.

   

3. Confirm on-chain in the wallet (a small gas fee is required), then wait for status to become "Approved".

   

Phase 3: Sweep High-Risk Funds and Withdraw to an External Wallet​

After both addresses are configured, you can sweep and withdraw funds from blacklisted sub-contracts.

1. Sweep Funds from High-Risk Sub-Contracts​

1. Go to "Funds -> Sweep".

   

2. Switch to the "Blacklist" tab, select the sub-contracts to sweep, and click "Batch Sweep".

3. Confirm the transaction in the wallet and wait for sweep to complete.

   

2. One-Click Rebalance from Emergency Sweep Address to Emergency Rebalancing Address​

1. Go to "Asset Details" and click "Emergency Withdraw" in the top-right corner.

   

2. On the Emergency Withdraw page, check "Total Balance of Emergency Sweep Address". After funds are confirmed in place, click "One-Click Rebalance".

   

3. If the page shows "Hot contract max limit is not set for some currencies", configure hot contract limits via multisig first. See: Modify Merchant Configuration with Multisig.

   

4. After configuration, click "One-Click Rebalance" again and confirm on-chain in the wallet. Funds will move from the Emergency Sweep Address to the Emergency Rebalancing Address.

   

3. Transfer from Emergency Rebalancing Address (Pro Merchants)​

1. Go to "Asset Details -> Emergency Withdraw -> Transfer from Emergency Rebalancing Address" and click "Transfer".

   

2. In the transfer dialog, choose the currency (e.g., USDT), fill in destination address and amount, optionally click "Add Row" for batch transfers, then click "Submit".

   

3. Sign the transfer proposal with the finance wallet.

4. Sign out, switch to another finance wallet, approve the transfer proposal via multisig, and confirm on-chain in the wallet.

   

5. Wait for confirmation. Funds in the Emergency Rebalancing Address will be transferred to the specified external wallet.

Use Cases​

• Payment business based on the TRON (TRC20) network
• Merchants need to pre-provision large quantities of payment-collection sub-contract wallets to handle high-concurrency payment demands
• Desire to reduce batch sub-contract creation costs by paying gas fees in TRX

Overall Process Flow​

Detailed Steps​

1. Enable TRX Currency in Admin Console​

Log in to the admin console using an admin wallet, navigate to "System Configuration → Currency List", add the TRX currency, and confirm via wallet signature.

Admin console URL: https://adm.payprotocol.network/login

1.1 Select the currency to enable​

Click the "Manage Currencies" button. In the modal that appears, select TRX (TRX) from the dropdown list.

Figure 1: Select TRX (TRX) from the dropdown in the "Manage Currencies" modal

1.2 Submit the activation request​

After confirming that the selected currencies include Tether(TRC20) (USDT) and TRX (TRX), click the "Submit" button.

Figure 2: Click "Submit" after confirming the selected currencies

1.3 Confirm wallet signature​

The system will trigger your wallet to display a "Trigger Smart Contract" signature request, with an estimated gas fee of approximately 2.4785 TRX. Click the "Sign" button to complete the on-chain operation.

Figure 3: Click "Sign" in the wallet popup to complete TRX currency activation

2. Call API to Create Payment Order​

Create a payment order through the merchant API. Each order will correspond to an independent sub-contract wallet address.

API Documentation: Create Payment Order

Request Example

POST /payment/order/create
Content-Type: application/json

{
  "chainId": 1,
  "description": "A sample order",
  "isLegalTender": 0,
  "notifyUrl": "https://www.payment.com/api/notify",
  "outTradeNo": "P2026010100000001",
  "quoteAmount": "0.01",
  "quoteCurrencySymbol": "TRX",
  "redirectionUrl": "https://www.payment.com/order/redirect",
  "tagId": 1
}

Upon successful API call, the response will include the order's unique identifier orderNo, which you'll need for subsequent steps.

3. Update Payment Information to TRX​

After the order is created, call the "Update Payment Info" API to switch the order's payment currency to TRX. This is a critical step: by setting currencyId to 1 (TRX), the subsequent 0.01 TRX transfer will trigger sub-contract wallet generation with minimal gas cost.

API Documentation: Update Payment Info

Request Example

POST /payment/payInfo/update
Content-Type: application/json

{
  "chainId": 1,
  "currencyId": 1,
  "outTradeNo": "P2026010100000001"
}

Key Parameters

4. Retrieve Sub-Contract Wallet Address from Order​

After updating payment information, use the "Query Payment Order Details" or "Query Payment Page Info" API to retrieve the sub-contract wallet receiving address associated with the order.

5. Transfer 0.01 TRX to the Sub-Contract Address​

Using any exchange or wallet (e.g., TronLink, Binance, OKX, etc.), transfer 0.01 TRX to the payment collection sub-contract address obtained in step 4.

6. Wait for Sub-Contract Wallet Deployment​

After on-chain confirmation (typically within 1 minute), the system will detect the TRX transfer transaction and automatically trigger the sub-contract deployment logic. Once deployment completes, the new sub-contract wallet is ready to use as an independent payment-receiving address.

Ways to Confirm Sub-Contract Deployment Success

• Query the address via the TRON blockchain explorer (e.g., Tronscan) to see contract creation transaction records
• Receive order status change notifications via the merchant callback interface (notifyUrl)
• Call the "Query Payment Order Details" API again to verify the order status has been updated

7. Batch Looping Operations​

Encapsulate steps 2 through 6 in a program loop or batch processing script to batch-generate multiple sub-contract wallets.

8. Disable TRX Currency After Completion​

After batch creation is complete, disable TRX currency from the admin console to prevent accidental use of the TRX payment channel for regular payment collection operations.

Steps

• Log in to the admin console using an admin wallet
• Navigate to "System Configuration → Currency List"
• Click "Manage Currencies", then in the dialog that appears, click the "×" next to TRX (TRX) to remove it
• Click "Submit"
• Confirm via wallet signature (similar to step 1.3)

A cross-chain bridge is a protocol mechanism used to transfer assets between different blockchain networks. Because various public blockchains (such as TRON, Ethereum, BSC, etc.) are independent and use incompatible protocols, assets cannot be transferred directly. Cross-chain bridges enable equivalent circulation of the same asset across different chains through mechanisms like "lock → mint" or "swap → release".

Cross-Chain Capabilities of This Platform​

This admin console already has built-in cross-chain swap functionality, allowing you to complete asset transfers between major blockchains without integrating an external bridge. It works similarly to "currency exchange": select the asset to sell, choose the destination chain for the asset to buy, enter the receiving address on the counterparty chain, and confirm to complete the cross-chain transfer.

2. Operation Steps​

1. Log in to Admin Console​

Log in to the admin console using a "Treasurer" account.

Admin Console URL: https://adm.payprotocol.network/login

2. Ensure Hot Wallet (Treasurer) Has Sufficient Balance​

The fund source for cross-chain swaps is the "Hot Wallet (Treasurer)". If the hot wallet balance is insufficient, you need to first withdraw assets from the cold contract wallet to the hot wallet, or transfer from other external addresses to the hot wallet.

Method A: One-Click Withdrawal from Cold Contract

Go to the "Asset Details" page and click the "One-Click Withdraw" button in the top-right corner. The system will automatically withdraw the available balance from the cold contract wallet to the hot wallet.

Figure 2-1: Click "One-Click Withdraw" on the "Asset Details" page

Method B: Transfer from External Address

If the cold contract also has no available balance, you can transfer directly from other addresses you own (such as exchange withdrawal, wallet transfer) to the hot wallet (Finance) address. You can find the hot wallet address in the "Asset Details → Hot Wallet" tab.

3. Enter Swap Page and Fill in Information​

Click the top navigation "Fund Management → Swap" to enter the cross-chain swap page.

Figure 3-1: Navigate to "Fund Management → Swap"

Fill in the following information on the swap page:

Figure 3-2: Swap form (Sell / Buy / Receiving Address)

4. Confirm and Initiate Swap​

After completing the information, the page will display a real-time quote (e.g., 1 USDT ≈ 1.000000 USDT). This quote is for reference only; the final execution rate will be the rate at the time of swap execution.

After confirming everything is correct, click the "Start Swap" button below to submit. The system will deduct the corresponding amount from the hot wallet and transfer the assets to the receiving address on the target chain via the cross-chain bridge.

5. Check Arrival Status at Target Address​

After initiating the swap, you can confirm arrival using any of the following methods:

• Open the block explorer of the target chain (e.g., Etherscan, BscScan) and check the latest transaction records of the receiving address
• Open your wallet app (e.g., MetaMask, TronLink), switch to the target network and check balance changes
• Return to the admin console and check the swap transaction status in "Asset Details → Withdrawal Records"

3. Important Considerations​

• Cross-chain swaps are irreversible; once submitted, they cannot be cancelled. Please verify the address and amount multiple times before operating
• Swaps between different assets will be settled at real-time market rates, with some slippage
• For large swaps, it is recommended to test with a small amount (e.g., 1 USDT) first, then proceed with larger amounts after confirming arrival
• Certain chain pairs (e.g., obscure small-cap assets) may have insufficient liquidity, resulting in longer settlement times or even failure
• Cross-chain bridge fees are already included in the swap rate; no additional fees apply
• Source chain transactions require on-chain gas (borne by the hot wallet account); ensure the account has a small amount of native currency (e.g., TRX)

4. Reference Materials​

• Etherscan (Ethereum Explorer): https://etherscan.io
• Tronscan (TRON Explorer): https://tronscan.org
• BscScan (BSC Explorer): https://bscscan.com

The steps to use the emergency sweep feature are as follows:

1. Blacklist the Sub-Contract​

When the merchant's KYT (Know Your Transaction) system detects that an incoming payment contains blacklisted USDT, call the Add User Sub-Contract to Blacklist API immediately to blacklist the contaminated sub-contract. Blacklisted sub-contracts will no longer be used for payment and will be excluded from the normal sweep flow.

2. Set the Emergency Sweep Address​

Log in to the merchant console with an admin wallet, go to the Multi-Sig Management page, edit the multi-sig parameter configuration, select Modify Emergency Sweep Address, and enter a safe external address. The change takes effect once the multi-sig approval is complete.

3. Execute the Emergency Sweep​

Go to the Sweep page and select the Blacklist tab to view the previously blacklisted sub-contracts. Select the sub-contracts to sweep and click the Batch Sweep button. The system will sweep the funds from those sub-contracts to the emergency sweep address configured in the previous step.

Tag Address is used to categorize and manage wallet addresses. When creating a payment order, merchants can specify tagId so the system automatically assigns a receiving address from the corresponding tagged address pool.

Address allocation rules:

• If an available address exists under the tag, the system prioritizes reusing it.
• If all addresses under the tag are occupied, the system automatically creates a new address.
• The newly created address is automatically assigned to the same tag.

This mechanism helps merchants achieve:

• Address categorization
• Address reuse
• Automatic address expansion

This mechanism is ideal for merchant scenarios that require managing a large number of receiving addresses.

2. End-to-End Workflow​

The overall process is as follows:

3. Create a Tag​

Documentation: Create Tag API

Before creating payment orders, merchants must create a tag first.

Endpoint:

POST /api/mer/user/tag

Request example:

{
  "tagName": "A1"
}

This example creates tag A1.

After successful creation, the API returns data as the tag ID (for example, 1), which can be referenced in payment orders.

4. Create a Payment Order​

When creating an order, include tagId in the request parameters to specify which tagged address group should be used.

Endpoint:

POST /api/mer/payment/createPaymentOrder

Request example:

{
  "chainId": 136,
  "description": "A sample order",
  "isLegalTender": 0,
  "notifyUrl": "https://www.payment.com/api/notify",
  "outTradeNo": "C3",
  "quoteAmount": "0.01",
  "quoteCurrencySymbol": "USDT",
  "redirectionUrl": "https://www.payment.com/result?order=202312131805041280413",
  "tagId": 1
}

Parameters​

5. Address Allocation Rules​

After an order is successfully created, the system runs the following logic:

1. Read tagId from the order
2. Query the address pool under that tag
3. Check whether any available address exists

Processing logic:

• If an available address exists, reuse an existing address first.
• If all addresses are occupied, create a new address automatically.

Address allocation decision flow:

Example (A1 tag address pool):

Address1
Address2
Address3
Address4
Address5

Address allocation results:

• Order1 -> Address1
• Order2 -> Address2
• Order3 -> Address3

If all addresses are occupied, the system automatically creates a new address (for example, Address6) and adds it to the A1 tag address pool.

6. Reassign Address Tag​

Documentation: Update Wallet Tag API

If you need to change the tag assigned to an address, use the API below.

1. Query Address List​

Endpoint:

GET /api/mer/user/list

The response includes:

• walletId
• tagId
• address

2. Update Address Tag​

Endpoint:

POST /api/mer/user/wallet/tag

Request example:

{
  "walletId": 123456,
  "tagId": 1
}

After a successful update, the address is assigned to the new tag.

7. Complete Process Example​

The complete workflow example is as follows:

This guide helps merchant administrators complete the following configurations:

• Enable new blockchain networks (such as ETH, BSC)
• Add new cryptocurrencies (Tokens) on the blockchain

Enable New Blockchain Network​

Prerequisites​

Before enabling a new chain, you need to prepare 4 administrator wallet addresses. These addresses will be used for:

• Asset management on the new chain
• Multi-signature configuration

Create Administrator Wallet (Using ETH as Example)​

Create Wallet with MetaMask​

1. Install MetaMask browser extension or mobile app
2. Follow the prompts to create a new wallet, be sure to back up your seed phrase
3. The wallet connects to Ethereum Mainnet by default
4. Copy the wallet address (you need to create 4 administrator addresses, repeat this step for each)

Login to System Backend​

Use the Tron chain administrator account to connect your wallet and log in to the backend system.

Configure ETH Chain Administrator​

1. Select ETH Chain from the chain list

2. Fill in administrator addresses

• Use the 4 ETH wallet addresses created earlier
• Carefully verify the address information before submitting

3. After submission, the system will proceed with the approval process

Configure BSC Chain​

Add New Cryptocurrency (Token)​

Import Wallet to MetaMask (If Needed)​

If your wallet address was previously created using Trust Wallet or another wallet, you can import it to MetaMask by following these steps:

Login to Chain Management Backend​

Use the ETH chain administrator account to connect your wallet and log in to the backend, then select "ETH" in the blockchain options.

Configure Tokens (Using ETH Chain as Example)​

1. Navigate to backend management menu: System Configuration → Token List

2. Click the Manage Tokens button and select the tokens you want to enable from the list

3. After confirming your selection, click the "Submit" button

• This operation requires executing a transaction on the blockchain
• It will consume a small amount of Gas fees
• Once the transaction is confirmed, the token is successfully added

BSC Chain Token Configuration​

In Pay Protocol's blockchain world, the core concept that realizes this functionality is Merchant Sub-Contract. It is not the merchant's sole payment address, but rather smart contract addresses that merchants can generate on-demand in batches, specifically serving particular scenarios (such as one user or one order). Due to its foundation on blockchain and smart contracts, the generation and management methods are more flexible, transparent, and secure.

1. Why Do We Need Sub-Contracts? Why Not Transfer Directly to Cold Contracts?​

Having all users transfer to the same cold contract address would cause several core issues, and sub-contracts are designed to elegantly solve them:

1. Business Matching Requirements: Modern business scenarios are complex, and merchants need to create unique identifiers for massive users or transactions. Sub-contracts can generate unique payment addresses in batches, perfectly matching business models like "one address per user" or "one address per order," facilitating precise tracking of fund flows.
2. Fund Security Isolation: There are risky assets (such as blacklisted USDT) on the blockchain. If using a single address for payments, once problematic funds are received, it may lead to contamination or freezing of the merchant's entire main fund pool. Sub-contracts isolate risks to the smallest unit. If a certain sub-contract address receives abnormal funds, it can be handled separately without affecting the merchant's cold or hot main wallets.
3. Protecting Cold Contract Security: Cold contracts, as the main treasury, are designed to minimize on-chain interactions to maximize security. Sub-contracts serve as "frontline cashier points," handling all high-frequency payment activities, while cold contracts only make secure calls when fund sweeping is needed, forming clear security boundaries.

2. Generation Mechanism: Pre-generated Addresses and On-Demand Deployment​

Sub-contract generation is based on a secure factory template pattern. Each merchant's sub-contract factory template is strongly bound to their cold contract address upon deployment, ensuring that all sub-contracts generated through this template have the same security rules and fund flow directions.

• For deposit business: Merchants can actively call APIs to manually generate a dedicated sub-contract address for specific users and bind them together, achieving clear fund attribution.
• For payment business: The payment system allocates sub-contract addresses from a pre-generated address pool on-demand to different orders based on order volume. To improve efficiency, orders from different time periods can reuse the same sub-contract address.
• Key upgrade point: All pre-generated sub-contract addresses are initially just regular EOA addresses. Only when they receive funds and trigger the sweeping operation for the first time does the system formally deploy smart contract code on the blockchain, "upgrading" them into fully functional sub-contracts.

Importantly, due to the factory template's binding design, all funds in sub-contracts can only be swept to the designated cold contract through the unique sweeping operation path, fundamentally eliminating the risk of funds flowing to other addresses.

This process can be compared to a hotel allocating room cards to guests: The hotel reception has blank room cards (pre-generated sub-contract addresses). When guests check in (order generation/user binding), the reception authorizes a blank room card to a specific room (address allocation). Only when the guest first swipes the card to enter the room (first sweeping) is this check-in relationship formally activated and recorded (sub-contract deployment). After the guest checks out, the room is cleaned, and this room card can be re-authorized to the next guest (address reuse).

3. Complete Fund Flow Process​

Combined with sub-contracts, the fund flow path is clear and secure. Based on the binding relationship between templates and cold contracts, all sub-contract fund flows are strictly restricted:

1. User Payment → Funds enter the dedicated sub-contract address generated for their order or account.
2. Sub-contract Sweeping → Merchants trigger operations to sweep funds from that address to the bound cold contract (main treasury); at this point, the address is formally "upgraded" to a sub-contract on-chain.
3. Cold Contract Allocation → As needed, transfer funds from the cold contract to the hot contract (operational liquidity account).
4. Merchant Withdrawal → Perform withdrawals or external payments through the hot contract.

To better understand the entire system, we can compare it to the financial management of a large chain enterprise:

• Merchant is like a large chain enterprise
• Cold Contract is the enterprise's "headquarters central treasury," secure but not frequently accessed
• Sub-contract Factory Template is the enterprise's "standardized branch establishment guidelines," ensuring all branch funds ultimately flow to headquarters
• Sub-contract Address is a batch of "payment account numbers" pre-applied by the enterprise
• Sub-contract is the state after a "payment account number" is actually used and has established complete accounting records
• Hot Contract is the enterprise's "daily operational cash account"

Specific Process: Customers pay to designated payment account numbers (sub-contract address receives payment) → Periodically sweep money from various account numbers according to established rules to the headquarters treasury, at which point the account number completes formal accounting (upgraded to sub-contract and swept to cold contract) → Headquarters allocates budget to operational accounts (cold contract → hot contract) → Enterprise makes daily expenditures (hot contract payments).

⚡ Summary​

• Sub-contract Factory Template = "Standardized sub-account generator" bound to cold contract
• Sub-contract Address = Pre-generated "payment account number"
• Sub-contract = Activated and formally established "independent payment account"
• Cold Contract = Merchant's "headquarters main treasury"
• Hot Contract = Merchant's "daily operational account"

This mechanism, through template binding, pre-generation, and on-demand activation strategies, not only achieves refined fund management and risk isolation but also ensures absolute controllability of fund flows. All sub-contract funds can only be swept to the bound cold contract through sweeping operations, meeting complex business requirements while architecturally ensuring asset security.

It sounds ideal:

• User operations are submitted through UserOperation (UserOps) instead of regular transactions.
• Bundlers collect users' UserOps, bundle them into a single transaction, and submit to the blockchain.
• Account logic (signature methods, multi-factor authentication, limits, recovery mechanisms) is completely controlled by contracts, providing more flexible wallet experiences.

However, after in-depth research, we found: The real-world effectiveness of ERC-4337 in payment business is not as perfect as imagined.

1. Cost Issue: Gas Is Not Actually Cheaper​

• ERC-4337's Problem

  • Each UserOps requires individual verification of signatures, nonces, and limit logic.
  • These validations are not natively executed by the blockchain main protocol, but simulated by Bundlers in the memory pool.
  • The final calldata submitted on-chain is longer and more complex, resulting in transaction fees often 2-3 times higher than regular transactions.
  • This extra overhead essentially trades "higher costs for more complex wallet logic".

• Pay Protocol's Solution

  • Users don't need to operate themselves; merchants can batch operations, significantly reducing costs.
  • No additional verification logic, more concise on-chain data, Gas consumption cheaper than standard transactions.

👉 In payment scenarios, low cost is far more important than complex features. Merchants want "cheaper per transaction", not "fancier signature methods".

2. Compatibility Issues​

• ERC-4337's Problem

  • While the standard unifies UserOps interfaces, specific implementations vary greatly.
  • Smart contract wallets provided by different service providers (like ZeroDev, Biconomy) have inconsistent structures.
  • Application layer faces extremely high compatibility costs when supporting multiple providers. In practice, developers are often forced to choose one provider and get locked into their ecosystem.

• Pay Protocol's Solution

  • Our keyless accounts are based on contract factories, following standard EVM logic.
  • Works out-of-the-box on any EVM public chain, without depending on specific service providers.

👉 For merchants, the real meaning of openness is not "new standards", but "switch chains anytime, integrate anytime".

3. Upgrade & Maintenance: Proxy Complexity vs Template Simplicity​

• ERC-4337's Problem

  • Once contract wallets are deployed, their logic is hardcoded.

  • To add new features, the Proxy upgrade pattern is typically required:

    1. Write a new logic contract first.
    2. Modify Proxy pointer to point to new logic.
    3. Handle old data migration and security audits.

  • This process is not only cumbersome but also prone to introducing new vulnerabilities, increasing audit costs.

• Pay Protocol's Solution

  • Keyless accounts are batch-generated based on template contracts.
  • When upgrades are needed, simply publish a new template version and batch-generate new accounts.
  • No need to handle Proxy complexity; migration path is simple and direct.

👉 Simplicity is security; the more complex the contract structure, the higher the probability of issues.

4. Security Risks: Greater Flexibility Also Brings Larger Attack Surface​

• ERC-4337's Problem

  • Since account logic is programmable, it can theoretically support any signature or permission control method.
  • But greater flexibility also means more ambiguous security boundaries.
  • Past cases have shown: attackers can create "unauthorized accounts" through vulnerabilities, even bypassing verification.
  • Such risks are unacceptable in payment business.

• Pay Protocol's Solution

  • The logic of keyless accounts is extremely simple: just a factory contract responsible for generating standard accounts.
  • No complex multi-factor verification or external dependencies, thus no additional attack surface.

👉 For the payment industry, security comes first.

5. Target Customer Base: toC vs toB Fundamental Differences​

• ERC-4337's Positioning

  • Primarily targets C-end individual users, providing them with smarter wallet experiences.
  • Focuses on solving individual user pain points: forgetting private keys, complex signature operations, lack of social recovery, etc.
  • Users are willing to pay extra costs for better experiences, with relatively low sensitivity to Gas fees.
  • Pursues wallet functionality differentiation and personalization.

• Pay Protocol's Positioning

  • Focuses on serving B-end merchants and payment platforms, helping them quickly integrate blockchain payments.
  • Emphasizes enterprise-level needs: batch processing, cost control, compliance requirements, system integration.
  • Merchants are extremely cost-sensitive; even a 1% reduction in transaction fees brings significant benefits.
  • Pursues stability, predictability, and large-scale operations.

👉 Different customer groups have completely different core demands. ERC-4337 solves "making personal wallets more user-friendly", while Pay Protocol solves "making merchant payments more cost-effective".

Comparison Summary​

Our Conclusion​

ERC-4337 represents the future direction of wallet development: more flexible, more personalized, more intelligent. But it's still in early stages with an immature ecosystem:

• Bundler operation relies on a few service providers → De facto centralization.
• High costs → Not suitable for high-frequency payments.
• Upgrade and compatibility not friendly enough → Increases maintenance costs.

For payment business, saving money, peace of mind, and security are the core values.

Therefore, Pay Protocol will not adopt ERC-4337 for now, but chooses a more direct, controllable, and stable keyless account solution to provide merchants and users with a payment experience that's usable today and secure enough.

Summary in one sentence: ERC-4337 focuses on enhancing personal wallet experiences, while Pay Protocol focuses on solving enterprise payment cost issues.

I. Usage-Based Classification​

From user experience and key management perspectives, wallets can be divided into:

1. By Connectivity: Hot Wallet vs Cold Wallet​

2. By Custody: Custodial vs Non-Custodial​

3. By Physical Form​

• Software Wallets: Mobile apps, desktop clients, browser extensions (e.g., MetaMask, Trust Wallet)
• Hardware Wallets: Offline devices (e.g., Ledger, Trezor, OneKey)
• Paper Wallets: Printed/handwritten private keys and addresses
• Multi-Sig Wallets: Require multiple signatures for transactions (e.g., Gnosis Safe)

II. Protocol/Account Model Classification​

Different blockchain account designs at the protocol layer:

Pay Protocol: Web3 Payment Infrastructure​

Pay Protocol is a non-custodial, smart contract-driven decentralized payment and wallet infrastructure designed for B2C enterprises (e.g., retailers, fintech companies). It enables merchants to maintain full on-chain control while avoiding traditional centralized key management risks.

• Protocol Model: Contract Account (CA) type, managing funds through pure contract logic without server-side key storage.
• Technical Advantages:
  • Funds remain recoverable even if merchant servers are compromised
  • Lower costs vs MPC solutions with no server maintenance
  • Flexible multi-sig and administrative policy configurations
• Use Cases: Merchants/financial institutions integrating crypto payments while maintaining on-chain asset control. Classified as CA-type wallet with smart contract management features.

III. Security Risks and Prevention​

Common Risks​

1. Private Key/Seed Phrase Leak → Asset theft
2. Phishing Sites/Fake Apps → Unauthorized approvals
3. Malicious Contract Approvals → Asset draining
4. Counterfeit Hardware Wallets → Pre-installed backdoors
5. Device Infections → Remote control of hot wallets

Prevention Recommendations​

• 🔒 Separate cold/hot wallets: Small amounts in hot, large amounts in cold
• 🛒 Buy hardware wallets from official channels
• 🔄 Regularly revoke unused contract approvals (e.g., Revoke.cash)
• 🌐 Never enter seed phrases on public networks
• 🔑 Enhance security with multi-sig or MPC

IV. Wallet Comparison Table​

Conclusion​

• Usage-based classification determines wallet security and convenience
• Protocol model classification defines functional capabilities and security policies
• Businesses/institutions should consider CA-type wallets (e.g., Pay Protocol) for on-chain asset control with flexible contract configurations for multi-sig, payments, and permissions

1. Signing Principles and Security Design​

What is on-chain signing?

In the blockchain, "signing" refers to the process of using an account's private key to cryptographically confirm transaction data, ensuring that the transaction originates from a legitimate account and its content has not been tampered with. It follows the principles of asymmetric cryptography—signing with a private key and verifying with a public key—making it non-forgeable and tamper-proof.

Why must signatures be protected?

Traditional systems often host the signing process on servers, which poses the following risks:

• Private key leakage risk: If the server is compromised, assets face enormous losses.
• Plaintext data exposure: Transaction content may be monitored or intercepted during transmission over the public network.
• Non-auditable operations: If multiple people can access the server, signing activities lack transparency and a secure boundary.

Secure Signing Design Philosophy

To address these issues, Pay Protocol has designed a security architecture of "localized signing + minimized data + separation of permissions":

• Signing is completed on the merchant's local server, and the private key never goes online.
• The platform only processes the signature hash and never sees the plaintext data.
• Signing and transaction broadcasting are performed by different entities, creating a separation of permissions.

This architecture significantly reduces the risk of single-point-of-failure leaks and enhances the compliance and security of on-chain asset operations.

2. Secure Signing Flow Overview (Five Steps)​

The entire signing process is divided into the following five steps:

For specific deployment, please refer to the document: Signer Installation and Deployment

1. Signer Installation

   Merchants deploy the Signer as a Docker container on their own intranet server:

   • The server does not expose a public network interface.
   • Only the merchant has access rights.
   • It can be deployed on a physical machine, local IDC, or private cloud environment.

   This step ensures the privacy of the signing service, creating physical isolation.

2. Batch Transfer Submission

   Merchants prepare a list of transfers (e.g., multiple addresses and amount combinations) and submit it to the Signer via an intranet interface. This process:

   • Does not go through the platform or any third party.
   • Transaction data remains within the merchant's network.
   • Ensures the privacy of transaction information.

3. Generate Transfer Signatures

   The Signer uses the local hot wallet's private key to sign each transfer data one by one. The signing action does not depend on the platform's API and is completed locally:

   • The private key never leaves the merchant's server.
   • The result of the signature is a hash + digital signature.

   Once completed, the merchant can batch export the signature data in preparation for broadcasting.

4. Submit Signatures

   The merchant submits the signed transaction hashes to the platform. The platform only receives the following information:

   • Signature hash.
   • Blockchain network type.
   • Does not include plaintext of the transfer.

   The platform cannot restore the transfer content, nor can it replay the transaction, ensuring "data invisibility."

5. Confirm Transfer & Callback Notification

   The platform broadcasts the received signature hashes to the blockchain network and verifies the legality of the signatures on-chain. After the transaction is successful, the platform will notify the merchant via a callback:

   • The callback information includes the transaction hash, status, and block height.
   • If it fails, the failure status will also be synchronized for easy tracking.

3. Security Advantage Analysis​

4. Typical Application Scenarios​

• Batch Transfers: Such as payroll, project rewards, batch airdrops, etc.
• Payment Sweeping: Batch consolidation operations after multiple small-amount collections.
• On-chain Broadcasting After Off-chain Risk Control: The internal audit system confirms off-chain and then hands it over to the Signer for signing.

5. Summary​

The secure signing solution from Pay Protocol, through the Signer, builds a secure model of "offline signing + separate on-chain broadcasting," featuring:

• Zero private key exposure risk.
• Strong privacy protection capabilities.
• Flexible distributed deployment.

It is particularly suitable for Web3 merchants or project parties with high-security requirements and batch operation needs, providing a highly reliable, auditable, and low-trust-dependent infrastructure for on-chain asset operations.

1. Is a Contract Address Safe?​

A contract address is an on-chain account used to execute smart contracts. The contract addresses used by our platform are payment contracts deployed and audited by us, with specific purposes and solely for receiving user payments. These contracts cannot initiate fund transfers or maliciously operate your wallet assets, making them secure.

✅ Contract addresses are publicly verifiable on-chain. You can check their code and transaction records in a blockchain explorer to ensure security.

2. Why Do Wallets Display "Contract Address Risk"?​

This is the wallet's default risk warning mechanism, designed to remind users to proceed with caution and avoid sending assets to unknown or malicious contract addresses.

Rest assured, our contract addresses have been tested and verified and have been running stably for a long time.

⚠️ Wallets do not judge whether a contract is "good or bad"—they simply recognize it as a "contract" rather than a regular wallet address, thus triggering the warning automatically.

3. Warning Examples in TP (TokenPocket) and imToken Wallets​

As shown below, when TP and imToken detect a contract address, they display:

"The address you entered is a contract address. Please verify before transferring!"

4. We Recommend the Following Actions:​

1. Confirm the address source is reliable: Ensure the receiving address is provided by our platform. Do not change it yourself.
2. Proceed with the transfer: Even if the wallet shows a warning, you can safely transfer as long as the address is correct.
3. Contact customer support for questions: We will promptly verify the contract address and provide technical support.

I. ITRX Account Application and Login​

1. Submit your email to Pay Protocol business or team members. After administrator review, they will activate your ITRX account.

2. Log in to ITRX using your email and the initial password we sent. Please change your password promptly after logging in.

II. API Key Creation and Deposit Address Retrieval​

1. After logging into ITRX, open "User Center-API", create an API and copy the API Key and API Secret.

   

2. Go to the Deposit & Withdrawal page, copy the deposit address, and deposit TRX to this address using your wallet (ensure the deposit amount is sufficient for purchasing energy).

   

III. Configure ITRX Automatic Energy Purchase​

1. Log in to Pay Protocol admin console with an administrator account, click "Organization Info"-"Edit".

   

2. Select ITRX as the preferred platform for automatic energy purchase, then fill in the ITRX API Key, API Secret, and deposit address. Click "Submit" to save after confirming everything is correct.

   

IV. Automatic Energy Purchase Demo (Using Consolidation as Example)​

1. In the Pay Protocol admin console, click "Fund Management"-"Sweep", select any wallets pending sweeping for batch processing.

   

2. If the current administrator wallet has insufficient energy, the system will prompt "Do you want to purchase energy". Select "Buy for me" and click "Buy on ITRX", the system will automatically complete the energy purchase on the selected platform.

   

3. After the energy purchase is successful, follow the prompts to complete the signature operation in the wallet popup.

   

The above steps cover the complete configuration process for ITRX Automatic Energy Purchase, helping you simplify operations and save on Gas fees.

1. What is the Guardian?​

The Guardian (also known as a "Guardian") is a security service component deployed in the backend or on an independent server. It is used to perform secondary validation and permission review for on-chain transfer requests or other critical multi-signature operations originating from the merchant system.

Its core mechanism is:

After the merchant system completes the initial signature, the Guardian independently generates a signature using the same parameters and compares it with the original signature. Only when the content matches and the permissions are valid is the on-chain execution allowed.

This mechanism effectively prevents data tampering, forged signatures, and unauthorized operations.

2. Why Use a Guardian?​

In blockchain systems, a signature represents control. Any tampered or misused signature could result in severe asset loss. Introducing a security validation mechanism can:

• Data Consistency Validation: Detect man-in-the-middle attacks and forged requests.

• Permission Control Mechanism: Prevent unauthorized or overstepped signatures.

• Audit and Traceability: Record all signature activities for easy backtracking and evidence collection.

3. Merchant System and Backend System Transfer Operation Flow​

1. Encrypt Transfer Request Information

   When the merchant system sends a transfer request to the backend system, encryption algorithms are used to protect transfer data (such as address, amount, currency, etc.), ensuring the security of the information.

2. Request Wallet Signature

   The backend system forwards the transfer request to the Web3 wallet plugin, which performs a multi-signature operation and returns the signature.

3. Signature Verification

   Upon receiving the signature, the backend system submits it to the Guardian web interface. The Guardian generates a signature via the server and verifies that the backend system's signature matches the server's signature.

4. Execute Transfer via Wallet

   Once the signature is verified successfully by the Guardian web interface, it instructs the Web3 wallet plugin to execute the transfer and place it on the blockchain.

5. Obtain Transaction Hash

   After the Web3 wallet completes the transaction, it returns the transaction hash, which the Guardian web interface then retrieves and saves.

6. Callback Transaction Status

   The Guardian web interface updates the transaction hash record by calling the backend system in one of two ways:

   • Direct callback via the web interface to update the status.
   • The Guardian server makes the callback on behalf of the backend system, updating the transaction status based on the hash.

7. Transaction Status Check

   The backend system checks the status of the transaction hash and updates the transaction status record.

4. Guardian Signature Process​

1. Merchant Data Initialization

   When the backend system approves a merchant, it records merchant information (merchant ID, cold/hot contract addresses, etc.) and provides query and delete interfaces to the Guardian.

2. Guardian Data Storage

   The Guardian requests the backend's query interface to obtain merchant data, storing it as a JSON file, and requests the deletion of old data.

3. Scheduled Task for Data Synchronization

   A cron job is used to regularly request the Guardian interface, automatically updating the merchant's initialization data.

5. End-to-End Security​

1. Server Security

   Intrusion detection systems and firewalls are employed to protect the server from external attacks.

2. Encrypted Communication

   HTTPS and encryption algorithms are used to ensure the security of all data during transmission.

3. Prevention of Replay Attacks

   Blockchain mechanisms are utilized to prevent replay attacks by incorporating timestamps, nonces, or unique identifiers on the blockchain, ensuring that each transaction request is unique and non-repetitive.

4. Service Monitoring and Alerts

   The system's health status is periodically checked, and alerts are issued for any anomalies, followed by prompt repairs.

6. Payment Flow​

1. Encrypt Payment Link

   When the merchant system generates a payment link, it uses a signed encryption parameter to ensure the legitimacy and security of the payment link.

2. Payment Information Verification

   When the user submits payment, the payment information's signature and parameters are verified to ensure the request comes from a legitimate merchant.

3. Payment Callback Verification

   After payment completion, the merchant system verifies the callback payment data to ensure the accuracy of the payment status.

4. Payment Interface Control

   IP restrictions and access frequency limits are set to prevent misuse of the interface.

7. Docker Deployment and Web Deployment​

1. Simplify Docker Deployment

   Docker images and configuration files are provided, enabling merchants to easily deploy services using Docker Compose or Kubernetes.

2. Java Web Support

   Web applications are supported to run on common Java web servers like Tomcat, ensuring compatibility.

3. Automatic Service Scaling

   Load balancing and automatic scaling are configured to ensure the service can scale and remain stable during peak traffic periods.

8. API Security​

1. Signature Verification

   All API requests require the use of a signature mechanism to ensure the legitimacy of the request.

2. Encrypted Data Transmission

   All API data transmission is encrypted using HTTPS protocol, ensuring the data is not tampered with.

3. Access Control

   IP address access is restricted and request frequency limits are set to prevent malicious misuse of the interface.

4. Log Recording and Auditing

   All API calls are logged and audited regularly to ensure operations are traceable.

9. Real Case: $1.5 Billion Stolen from an Exchange​

In February 2025, a leading international exchange suffered a $1.5 billion asset theft due to a lack of isolation and validation mechanisms in its signature process.

Attackers hijacked the signature process using a "masked transaction" technique, separating the displayed address on the frontend from the actual signature data. The cold contract and multi-signature mechanism failed to detect the forged transaction.

If a Guardian had been deployed, it could have identified parameter tampering and spoofing behaviors before signing, preventing asset loss at the source.

Conclusion​

The Guardian is a core component of the Web3 security system, especially suitable for scenarios with the following requirements:

• Multi-party management and control of digital assets
• Merchant platforms requiring on-chain transfers
• Institutions needing to isolate business systems from private keys used for signing

Through signature comparison, permission validation, and auditing mechanisms, the Guardian effectively prevents forgery, unauthorized access, and tampering attacks, making it an essential safeguard for building highly secure digital asset systems.

Prerequisites​

Before starting to repair orders, please ensure you have the following information:

1. Order Number: The order number or payment number that needs to be repaired.
2. Transaction Hash: The transaction hash of the user's payment (can be obtained through a blockchain explorer or payment platform).

Step 1: Add New Staff Wallet Address (Optional)​

If you need new staff to assist with order repairs, you can add their wallet address:

1. Administrator Login to Backend

Log in to the backend system using the administrator account.

2. Navigate to Organization Information

• Click Organization > Members.
• On the page, select Add.

3. Fill in Staff Information

• On the "Add" modal, enter the staff's wallet address, e.g., TEYrHyvsssn2Kw6McY9vA1hF2taiZaEjyQ.
• Submit and wait for approval. Once approved, the new staff address will be added to the system.

4. Complete Addition

After the staff wallet address is successfully added, it can be used to log in to the backend and perform order repair operations.

Step 2: Log in to Backend and Perform Order Repair​

1. Log in to Backend System

Use the administrator address or the newly added staff address to log in to the backend.

2. Go to Reconciliation - Payment Report - Order Repair Page

Click Payment Report > Order Repair.

3. Query Order

• On the order repair page, enter the user's Transaction Hash and Order Number.
• Click Search.

4. Verify Order Information

The system will automatically check the following information:

• Order Number Check: Confirm whether the order number matches.
• Transaction Hash Check: Confirm the validity of the transaction record.
• Sub-contract Check: Confirm whether the transaction's wallet is correct.
• Currency and Amount Check: Confirm whether the transaction amount and currency match the order.
• Transaction Time Check: Confirm whether the payment time meets the order requirements.

5. Repair Order

• After confirming all information is correct, click Repair.
• The system will automatically repair the order and send a callback notification.

While full-contract solutions offer high security, optimizing their gas costs remains a core challenge for developers. This article will explore how to significantly reduce gas costs and promote the application of sub-contracts in real scenarios through contract factory template design and tight packing inline assembly solutions.

1. Contract Factory Template Design: Dynamic Generation and Cost Optimization​

Traditional Problems

Traditional contract deployment requires deploying complete code for each sub-contract separately, resulting in high gas consumption and redundant on-chain code storage. To address this issue, we designed and implemented the contract factory template pattern.

Core Concepts

Contract factory templates are mechanisms that dynamically generate sub-contracts through predefined template contracts. By mapping template contract addresses to generated sub-contracts, code reuse can be achieved. This design has several key features:

• Dynamic Generation: Factory contracts dynamically create sub-contracts based on needs, avoiding repeated template logic deployment.
• Reduced Redundancy: All sub-contracts share the same template code, significantly reducing on-chain storage costs.
• Gas Savings: Sub-contract generation only requires passing minimal parameters, avoiding full code deployment and reducing gas consumption.

Practical Application Scenarios

For example, in multi-signature wallet scenarios, users can dynamically generate sub-contracts to execute tasks based on transaction requirements. Compared to traditional sub-contract solutions, this approach is more flexible and efficient, making it possible for sub-contracts to replace traditional sub-contract solutions.

2. Tight Packing Inline Assembly: Ultimate Optimization for Batch Transfers​

Transfer operations are among the most common and gas-intensive scenarios in blockchain. To further optimize, we adopted a tight packing inline assembly solution that effectively reduces gas costs by minimizing transaction payload size and streamlining code logic.

Solution Details

1. Parameter Tight Packing
   • Use minimum byte representation for parameters (such as addresses, amounts) off-chain.
   • Compress parameter storage size to reduce batch transfer payload volume.
2. Inline Assembly Optimization
   • Extensive use of inline assembly instructions provided by EVM (Ethereum Virtual Machine) in transfer logic, these low-level operations directly manipulate the EVM stack, avoiding overhead from high-level languages.
3. Batch Transfers
   • Combine multiple transfers into a single call, reducing transaction count and further lowering total gas consumption.

3. Practical Results​

Gas Cost Reduction

Through contract factory templates and tight packing solutions, test results show:

• Gas consumption for contract deployment and calls reduced by approximately 70%-81% compared to traditional methods.

Example: Sub-contract Consolidation Gas Comparison Table

Test Date: July 29, 2024

Enhanced User Experience

• Significantly reduced user operation costs and gas fees
• More efficient on-chain logic enables faster transaction confirmation

Support for Complex Scenarios

This optimization solution is particularly suitable for:

• Multi-signature wallets
• Large-scale DApp batch operations
• High-frequency smart contract interaction scenarios

Through contract factory templates and tight packing inline assembly solutions, we have not only solved the gas cost optimization challenge but also provided more flexible and efficient solutions for practical application scenarios. In the future, this design will play a crucial role in more complex blockchain scenarios.

Secure self-custody is a fully smart contract-based solution for managing crypto assets. This solution allows merchants to have complete control over all crypto assets and permissions within their system without relying on any third-party servers or services. At the same time, it ensures multi-node security, preventing the loss of funds or data due to the compromise of a single point of authority.

When evaluating whether a solution meets the standard of secure self-custody, two key considerations must be addressed:

1. Are all services and nodes fully owned by the merchant with ultimate authority?​

Traditional solutions and those based on Multi-Party Computation (MPC), while supporting source code-level private deployments, still heavily rely on the security of conventional servers. However, most merchants lack the capability to deploy high-security servers. Attempting to implement MPC deployments independently may introduce additional security risks.

2. Can the loss of any single node or server authority result in no financial loss for the merchant?​

In a secure self-custody solution, the service module and asset custody module are independent of each other:

• Service Module: If the service module relies on Web2 servers and the loss of server authority could lead to asset loss, such a solution cannot be considered secure self-custody. A secure self-custody solution ensures that the service module and asset custody module are fully separated.

• Asset Custody Module: This module is implemented through a fully smart contract-based solution, sharing the same security level as the public blockchain and managed via a multi-signature system. Even if all server authorities are compromised, assets can still be recovered through the multi-signature permissions of senior administrators.

Benefits of a Self-Custody Solution​

1. Elimination of External Attack Risks​

With secure self-custody, merchants have complete control over their funds and permissions without relying on third-party services. Even if servers are compromised by hackers, merchants can continue operating independently without worrying about risks caused by third-party vulnerabilities or malicious actions.

2. Elimination of Internal Malicious Risks​

In traditional crypto asset custody solutions, it can be challenging to trace the root cause of incidents—whether it’s external attacks or internal malicious acts—due to risks in server maintenance, financial management configurations, and executive-level permissions. The PayProtocol secure self-custody solution records all sensitive asset operations on-chain, completely eliminating the possibility of internal malicious behavior.

3. Scalability and Customization​

Many industries require system functionality to be integrated with development needs. Through self-custody, project teams can customize the system according to specific requirements and flexibly meet the unique demands of business development. The self-custody solution is designed with a no-maintenance approach, allowing enterprises to fully control the system's operational state and avoid the aforementioned risks.

Key Elements for Achieving Secure Self-Custody​

1. Fully Smart Contract-Based Solution​

All crypto asset operations are managed by smart contracts, with permissions solely held by the project team, ensuring operational security.

2. Multi-Signature System-Level Configuration​

A multi-signature system is implemented at the system level to reduce the risks and inconveniences of frequent cold contract operations by avoiding direct interaction with the cold contract.

3. Strict Permission Management and Isolation​

• Funds in sub-contracts can only be transferred to cold contracts.
• Crypto assets in cold contracts can only be accessed through multi-signature operations by super administrators.

4. Continuous Monitoring and Updates​

Although this is a self-custody solution, project teams must still design or integrate automated security updates and monitoring mechanisms. We provide various detection scripts and alert modules to ensure the system is always prepared to address emerging threats.

This secure self-custody solution empowers merchants to maintain complete control over their crypto assets while ensuring maximum security and operational efficiency.

Step 1: Calculate the energy required for the sweeping operation​

Example scenario:

1. Log in to the admin console using the admin wallet and initiate the sweeping operation.

   • Select the wallet to initiate the sweeping and enter the signature interface.
   • No need to click the signature operation, just check the total energy required for the transaction.
   • Example: The system shows the total energy consumption as 132,233 energy.

   

Step 2: Detailed steps to buy energy​

Add and use the TG energy purchase Bot

1. Open the Telegram app

   • Enter @nengliangvipBot in the search box and click on the found energy purchase bot.

   

2. Click the "RESTART" button of the Bot

   • Start the Bot function and enter the self-service menu page.

   

3. Select "Rent Energy" in the menu

   • Rent energy as needed.

   

4. Select the number of transactions and perform the conversion

   • 1 transaction = 65,500 energy.
   • For example: Sweeping one transaction requires 132,233 energy, calculated as: Required transactions = 132,233 / 65500 = 2.01
   • Approximately 2 transactions of energy are needed.

5. The Bot provides two payment methods

   1. Method 1: Direct transfer payment

      • According to the Bot's price list, select the required number of transactions and get the TRX payment amount.
      • Example: The total amount to pay for 2 transactions of energy is 6 TRX (equivalent to a unit price of 49sun/transaction).

      

      • Copy the payment address provided by the Bot (e.g., TV5JYxy8GUjtjtg58aLnk7mxo8ZZZZZZZZ).
      • Use the wallet to transfer to this address, complete the payment, and check the energy in the wallet.

      

   2. Method 2: Complete the payment by selecting the number of transactions

      • Select "2 transactions" in the menu.
      • Enter the wallet address to receive the energy as prompted by the Bot.

      

      • Use the TRX wallet to pay and complete the payment according to the order generated by the Bot.

      

6. Wait for the transfer to be credited

   • After the payment is completed, wait for about 6 seconds.
   • Refresh the wallet to check if the energy has been credited.

   

Step 3: Complete the operation using the admin wallet​

Perform backend operations

1. Log in to the backend using the admin wallet.

2. Select the sweeping or other functions that require energy support.

3. Confirm that the energy has been credited and complete the corresponding operation as needed.

   

Precautions​

1. Ensure payment security: Carefully check the payment address to avoid transfer errors.
2. Reserve transaction fees: Leave enough TRX as network fees in addition to the payment amount.
3. Energy demand conversion: Choose the number of transactions reasonably according to the actual transaction needs to avoid insufficient purchase or waste.

By following the above steps, you can successfully complete the energy purchase and reduce transaction fees!