One Image to Understand Pay Protocol


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.
In the blockchain field, ERC-4337 (Account Abstraction) has been very popular in recent years. It proposes a new account system that allows wallets to move beyond traditional Externally Owned Accounts (EOA) and be completely defined by smart contracts.
It sounds ideal:
However, after in-depth research, we found: The real-world effectiveness of ERC-4337 in payment business is not as perfect as imagined.
Blockchain wallets are the "keychains" of the blockchain world, determining how you access and manage assets while impacting security and functionality. Wallet differences can be categorized by usage patterns or underlying protocol models. This article provides a comprehensive understanding of both classification methods, including security recommendations and a comparison table of common wallets.
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.
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.
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.
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: