4 posts tagged with "introduction"

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​

Security Mechanism	Description
Intranet Deployment	The signing process runs entirely on the merchant's local machine, preventing external intrusions.
Private Key Isolation	The private key exists only in the Signer, is never uploaded, and is never exposed.
No Plaintext Off-Network	Plaintext transfer data is not transmitted through the platform, so the transaction content cannot be inferred.
Principle of Least Privilege	The platform only acts as a broadcast node and cannot control the merchant's funds.
Separation of Powers Design	Signing and on-chain broadcasting are executed separately to avoid centralized control risks.
Zero-Trust Architecture	The platform does not need to trust the merchant, and the merchant does not need to trust the platform; the system operates on a default untrusted model.

---

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.

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.

---

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: