Testnet tAX Prepaid Payment and Settlement

Why is a Payment Module Needed?

In a decentralized computing network, resource usage must be accompanied by a reasonable cost mechanism to prevent abuse and provide incentives for maintainers. The Payment Module is the economic hub designed by HyMatrix to solve the following core issues:

• Fair Resource Allocation: By charging for computing, storage, and network resources, it prevents malicious users from occupying node resources through idle or invalid processes.
• Balanced Multi-party Incentives: The system automatically distributes collected fees between node operators (providing computing power) and VM developers (providing application logic), building a sustainable ecosystem.
• Low Barrier to Entry: It introduces a "daily free limit" and "third-party payment" (sponsorship) mechanisms, lowering the threshold for new users to experience DApps.

Core Principles

The Payment Module follows the HIP-3 standard, and its operational logic can be summarized as: "Prepaid Deposit, Real-time Billing, Pause on Demand, and Periodic Settlement."

1. Prepaid Balance System (Prepaid System)

HyMatrix does not deduct funds directly from wallets; instead, it uses a prepaid ledger model. Users can deposit tAX tokens for a specific Beneficiary.

• Self-deposit: Users deposit funds for their own Account ID.
• Third-party Deposit (Sponsorship): Project owners or friends can deposit funds for a specific user, enabling them to use services for free.

2. Billing Items

1. VM Creation Fee (Spawn Fee): A one-time fee charged for each new virtual machine process created.
2. Transaction Fee: Incurred when a user sends a message to or initiates a call with a virtual machine.
3. VM Residency Fee: This is the key fee for maintaining VM survival. As long as a virtual machine is running on a node, it generates rent on a daily basis.

3. Automatic Shutdown and Recovery

• Shutdown: If a beneficiary's balance is insufficient to pay for the "VM Residency Fee" of the next cycle, the node will automatically switch the VM to a Paused state.
• Recovery: Once the beneficiary replenishes enough prepaid balance, the VM can be reactivated and its state restored.

---

Node Configuration

As a node operator, you need to configure payment parameters in config.yaml.

Configuration Example

enablePayment: true # Must be set to true to enable billing

payment:
  prvKey: "0x..." # Settlement private key, used to send settlement transactions
  settlementAddress: "0x0b1A4805..." # Revenue receiving address (Cold wallet recommended)
  axToken: "fHQbzw6acg2nqmCqzdr2GFaeoGzcRd0paVTD2kMGyU4" # Payment token ID
  
  # --- Fee Rates (Unit: 10^-12 tAX) ---
  txFee: 10000000000         # Per transaction fee (Default 0.01 tAX)
  spawnFee: 100000000000     # VM creation fee (Default 0.1 tAX)
  residencyFee: 10000000000  # VM residency fee (Daily 0.01 tAX)
  
  # --- Operational Strategy ---
  dailyLimit: 5              # Daily free calls per user
  developerShareRatio: 5000  # Developer share ratio (5000 = 50%)

---

User and Developer Operation Guide

1. How to Deposit

Users need to send a Transfer message to the node's deposit address. The message Tags must include the Beneficiary field.

Pseudo-code for depositing via SDK:

// Deposit 50 tAX for User A
tags := []Tag{
    {Name: "Action", Value: "Transfer"},
    {Name: "Recipient", Value: "Node's collection address"},
    {Name: "Quantity", Value: "50000000000000"}, // 50 tAX
    {Name: "Beneficiary", Value: "User A's AccountID"},
}

Note: If the Beneficiary field is missing, the deposit will be credited to the address that initiated the transfer.

2. How to Check Balance and Fees

You can query the system status via the API endpoints provided by the node:

Function	API Path	Description
Check Balance	GET /pay/beneficiaryTotal/:id	View the current available balance for a beneficiary
Balance Source	GET /pay/beneficiaryBreakdown/:id	View which sponsors provided funds for this beneficiary
Total Sponsored	GET /pay/sponsorTotal/:sponsor	View the total amount a specific sponsor has deposited
Sponsorship Details	GET /pay/sponsorBreakdown/:sponsor	List beneficiaries and amounts supported by a specific sponsor
Node Rates	GET /pay/info	Check the residency and transaction fee configuration of the node
Pending Fees	GET /pay/totalPending/:id	View fees that have been incurred but not yet settled in the cycle

3. Feedback for Insufficient Funds (HTTP 402)

If a user's balance is insufficient, the node will return an HTTP 402 Payment Required error. Developers can capture this error on the frontend and guide users to complete a deposit using the payTo (deposit address) and amount (required amount) provided in the error message.