This article introduces the working principle, security design, and operational flow of the Pay Protocol Signer, aiming to help merchants understand how to achieve high-security on-chain asset management through an "offline signing + on-chain broadcasting separation" model.

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 Aggregation: 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.

When you make on-chain payments, wallets like TP (TokenPocket) and imToken may display a warning: "The address you entered is a contract address. Please verify before transferring." This warning often causes concern. Below is a detailed explanation.

To help merchants further reduce energy costs, we have added support for the ITRX platform. Merchants can now choose to automatically purchase energy from ITRX or Neee before on-chain operations, thereby reducing TRX consumption.

This document outlines a comprehensive security validation process, covering transaction operations, signature verification, payment flow, and the enhancement of service security and stability, with the goal of ensuring the security of transactions and the high availability of the system.

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.

This tutorial will guide you on how to repair orders where users have overpaid or underpaid through the backend management system.

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).

In the past decade, decentralized payments typically used EOA (Externally Owned Accounts) wallet solutions, including existing MPC solutions based on EOA wallet sharding. However, achieving fully decentralized payments without any custodial servers requires an all-contract solution for fund custody. The optimization of gas costs in full-contract solutions has been a core challenge for developers.

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.

What is Secure Self-Custody?​

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:

This tutorial will guide you on how to buy energy through the TG mini program to reduce transaction fees when performing functions such as aggregation and rebalancing on the Tron network.

This tutorial will guide you on how to replace the batch transfer contract address and display the balance information of the address in the admin console. After the replacement, any administrator can perform the transfer-in operation, while only the owner of the batch transfer contract has the authority to perform the transfer-out operation.

To help merchants reduce network fees, we have introduced the TRON automatic energy purchase feature. With the help of a third-party platform, merchants can automatically purchase energy before performing on-chain operations, thereby reducing TRX consumption.

If you need to use this feature, please follow the steps below: