Skip to main content

Pay Protocol Merchant Sub-Contract Guide

· 5 min read
Pay Protocol Dev
Pay Protocol Dev
Pay Protocol Development Team

In traditional Web2 internet, when large merchants integrate with payment platforms, they often need to allocate independent payment sub-accounts for different business lines, stores, or even individual users (such as Alipay's PID or bank virtual accounts) to achieve fund allocation management and reconciliation.

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 Wallets?​

Having all users transfer to the same cold wallet 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 aggregation 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-wallet address for specific users and bind them together, achieving clear fund attribution.
  • For payment business: The payment system allocates sub-wallet 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-wallet addresses are initially just regular EOA addresses. Only when they receive funds and trigger the aggregation 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 aggregated to the designated cold contract through the unique aggregation 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-wallet 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 aggregation) 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-wallet address generated for their order or account.
  2. Sub-contract Aggregation → Merchants trigger operations to aggregate 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-wallet 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-wallet address receives payment) → Periodically aggregate 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 aggregated 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-wallet 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 aggregated to the bound cold contract through aggregation operations, meeting complex business requirements while architecturally ensuring asset security.