Architecture

Paygrid’s architecture consists of two main layers: the clearing layer and the settlements layer. It leverages programmatic payment intents and integrates interconnected off-chain and on-chain components to securely orchestrate payment workflows across multiple blockchain networks.

Key Components

Paygrid is an infrastructure designed for payment operators, essentially decoupling the payment operators from the payer or payee. Much like how Account Abstraction decouples signer from executor, or how intents decouple user desires from execution details, we believe this separation is key to enabling next-generation DFAs to take over the internet. This separation allows for more sophisticated, efficient, and flexible payment processes.

Payer, Payee, and Payment Operator

Payer: The entity initiating the payment and providing the funds.
Payee: The recipient of the payment.
Payment Operator: The intermediary using Paygrid to manage and optimize the entire payment process.

Payment Operators

Payment operators (likely you) are entities facilitating payments or financial operations on behalf of payers and payees. They are responsible for providing integration APIs and applications for both parties. Operators can configure operational parameters, such as network fee sponsors, authorized delegates, treasury addresses, and fee structures, allowing for flexible fee distribution and payment workflow logic.

Capabilities:

Integration Tools: SDKs and APIs for seamless integration with existing systems.
Operational Control: Set parameters for transactions, including fees and network fees bearer.
Workflow Automations: Schedule payments, set up recurring payments, and implement custom automations.
Delegation and Authorization: Manage authorized signers and control transaction approvals flows to enable complex workflows without giving up self-custody.

Application layer

This represents any kind of interface, system or application that is hosted by a Payment Operator and represents the Decentralized Financial Application (DFA). As an operator you have full freedom to control this, the only thing Paygrid needs at the end is a signed payment intent.

Paygrid require a multi-level authorization scheme (optionally). The chain starts with the payer signature and then the operator signature containing the full workflow intent to construct the CAPI. Both EIP-712 and EIP-1271 are supported.
Paygrid is wallet-agnostic, supporting Externally Owned Accounts (EOA), Smart Contract Accounts (SCA), and embedded wallets (EW).
Operator sends the CAPI to a Paygrid Gateway Node, not to any specific blockchain RPC.

This reduces the work to execute chain abstracted payments down to the bare minimum, 2 authorization signatures the payer and the operator.

Chain Abstracted Payment Intent (CAPI)

A Payment Intent is an abstract representation of a user's intention to make a payment, encapsulating all necessary details for the transaction without requiring immediate execution. It acts as a promise or authorization that can be fulfilled under predefined conditions. This concept decouples the initiation of a payment from its actual execution, allowing for flexibility in handling complexities like authorizations, retries, and asynchronous events across various wallet types.

Payment Intents are primitives based on a declarative model that describe self-contained instructions for executing a payment workflow. Each Payment Intent defines parameters such as the source and destination domains, amount, recipient(s), and any conditions or constraints required for execution.

Features:

Programmability: Support for complex transaction types, including batch payments and conditional transfers.
Security: Incorporate a multi-level authorization scheme supporting both EIP-712 and EIP-1271 signatures.
Flexibility: Allow operators to define custom workflows and business logic.
Transparency: Provide an auditable trail for compliance and reconciliation.

A payment intent essentially transforms a generic transaction into full context-aware payment instructions.

Payment Gateway Nodes

Payment Gateway Nodes are the core off-chain clearing infrastructure of the network, serving as orchestrators and routers to optimize execution paths and ensure preference guarantees for payment intents. These nodes form a payment delivery network that can increase efficiency by reducing costs and latency while providing scalability through workload distribution.

Functions:

Intent Orchestration: Manage and process Payment Intents received from operators.
Execution Optimization: Determine the best execution strategies, including cross-chain transactions and token swaps.
Security Measures: Protect against MEV attacks and ensure transaction integrity.
Scalability: Handle high transaction volumes through distributed processing forming a payment delivery network.

We provide a node by default when using our SDKs or APIs, and we’re looking to open this up to run your own node on request for even more advanced reliability and control.

Payment Solver Layer

The solver layer deals with liquidity operations that require solvers to run optimization algorithms, complete, and essentially creates a marketplace between operators and solvers to coordinate on completing a payment via Paygrid. Solvers are specialized entities that optimize intents ordering and execution efficiently and cost-effectively:

Execution Proposals: Solvers analyze payment intents and propose optimal executions.
Competition: They compete based on execution cost, speed, and reliability matching their execution to the payment intent needs.
MEV Protection: By operating in a specialized environment, solvers help protect transactions from MEV attacks, and are experts in navigating the MEV landscape.

Besides doing the core job, solvers essentially allow you to execute certain transactions with highly specialized capabilities and liquidity provisioning strategies that are normally only accessible to large liquidity providers such as CEXs, typically outperforming what you would get from a public pool and a generic RPC in terms of MEV exposure, costs and navigating the continuously shifting landscape of bridges, DEXs, proposer-builder separations and networks. Infrastructure like Paygrid payment solvers are well positioned to handle this complexity, not end-users who just want to pay and get paid.

Security Considerations

Infrastructure security is paramount, we’re baking in best practices and security considerations by design:

Programmable Delegation Authorizations: All payment operations are authenticated and authorized by operators or delegated signers, preventing unauthorized actions. Authorizations can be limited in time and scope, and have constraints of user-defined rules and permissions.
Self-Custody: Users and operators maintain control over their funds and wallets.
Extended Permit2 Mechanism: Signature-based approvals are used to reduce attack surfaces by eliminating the need for infinite and mismanaged allowances. The signatures are valid only for the duration of the transaction and within their intent scope.

Payment Intent Structure

Payment ID: Unique identifier for tracking.
Payment Type: One-time, recurring, etc.
Operator Configuration:
- Operator ID and address.
- Authorized signers.
- Treasury account.
- Fee structures (e.g., percentage rates).
- Network fee sponsorship options.
Transaction Details:
- Amount.
- Source domain (wallet address, network ID, payment token).
- Destination domain (recipient address(es), network ID, payment token).
Scheduling Parameters:
- Processing date.
- Recurring intervals (e.g., daily, weekly).
- Iterations or end dates.
Authorization Parameters:
- Expiration timestamps.
- Nonces.
- Permit2 signature for authorization.
Metadata:
- Payment references for reconciliation.
- Additional data for custom logic.

/* 
* @notice Struct representing the payment intent, 
* the core primitive for processing payments flows 
*/
struct PaymentIntent {
    bytes32 paymentId; // Payment Intent ID, generated or provided off-chain
    PaymentType payment_type; // Specifies the type of payment: one-time, recurring, etc.
    OperatorData operator_data; // Operator processing this payment (operator details, fees, etc.)
    uint256 amount; // The amount to be transferred
    Domain source; // The source chain, specifying the wallet address, network ID, and payment token for the transfer
    Domain destination; // The destination chain 
    uint256 processing_date; // The date the payment is set to be processed, useful for scheduled payments. If not set, defaults to immediate execution
    uint256 expires_at; // Timestamp indicating when this payment intent expires (used for signature-based payments, e.g., permit2)
    Schedule schedule; // Contains scheduling data if the payment is recurring, such as interval details and repetition count
    bytes p2_sig; // The permit2 signature from the payer, authorizing the payment intent
    uint256 nonce; // A nonce to protect against replay attacks, also used for permit2 signature verification
    string payment_reference; // (Optional) An external reference for off-chain reconciliation or tracking of the payment
    bytes metadata; // Arbitrary metadata field for storing additional intent-type specific information
}

struct OperatorData {
    bytes32 operatorId; // Operator facilitating the payment
    address operator; // The address of the operator
    address[] authorized_signers; // List of authorized delegates to sign or initiate the payment on behalf of the operator
    address treasury_account; // The operator's treasury wallet where the operator's fees will be transferred
    uint256 fee; // The fee percentage deducted from the transfer amount and sent to the operator's treasury (e.g., 2% fee = 200 bp)
    string operatorURI; // A well-known public URL that provides a standardized JSON document with operator config data.
}

struct GatewayConfig {
    address relayer_address; // Address of the relayer or gateway handling the payment execution
    uint256 fee; // Fee charged by the gateway for processing the payment, distinct from the operator fee
    address treasury; // Treasury address for the gateway where the execution fee is sent
}

struct Domain {
    address account; // The wallet address from which the payment is sourced or to which it is sent
    uint256 network_id; // Network ID of the blockchain where the payment will be executed (e.g., Ethereum mainnet, Polygon, etc.)
    address payment_token; // Address of the token being used for the payment (e.g., ERC20 token or native address)
}

struct Schedule {
    IntervalUnit intervalUnit; // Unit of time for the recurring interval (day, week, month, year)
    uint256 interval_count; // Number of interval units between each occurrence (e.g., 2 for bi-weekly if intervalUnit is week)
    uint256 iterations; // Number of iterations the payment should be repeated; if set, end_date should not be used
    uint256 start_date; // The timestamp of when the recurring payments should start
    uint256 end_date; // The timestamp for when the recurring payments should stop (ignored if iterations are set)
}

PreviousWhy Chain Abstracted Payments?NextBrand assets

Last updated 16 days ago

/* * @notice Struct representing the payment intent, * the core primitive for processing payments flows */ struct PaymentIntent { bytes32 paymentId; // Payment Intent ID, generated or provided off-chain PaymentType payment_type; // Specifies the type of payment: one-time, recurring, etc. OperatorData operator_data; // Operator processing this payment (operator details, fees, etc.) uint256 amount; // The amount to be transferred Domain source; // The source chain, specifying the wallet address, network ID, and payment token for the transfer Domain destination; // The destination chain uint256 processing_date; // The date the payment is set to be processed, useful for scheduled payments. If not set, defaults to immediate execution uint256 expires_at; // Timestamp indicating when this payment intent expires (used for signature-based payments, e.g., permit2) Schedule schedule; // Contains scheduling data if the payment is recurring, such as interval details and repetition count bytes p2_sig; // The permit2 signature from the payer, authorizing the payment intent uint256 nonce; // A nonce to protect against replay attacks, also used for permit2 signature verification string payment_reference; // (Optional) An external reference for off-chain reconciliation or tracking of the payment bytes metadata; // Arbitrary metadata field for storing additional intent-type specific information } struct OperatorData { bytes32 operatorId; // Operator facilitating the payment address operator; // The address of the operator address[] authorized_signers; // List of authorized delegates to sign or initiate the payment on behalf of the operator address treasury_account; // The operator's treasury wallet where the operator's fees will be transferred uint256 fee; // The fee percentage deducted from the transfer amount and sent to the operator's treasury (e.g., 2% fee = 200 bp) string operatorURI; // A well-known public URL that provides a standardized JSON document with operator config data. } struct GatewayConfig { address relayer_address; // Address of the relayer or gateway handling the payment execution uint256 fee; // Fee charged by the gateway for processing the payment, distinct from the operator fee address treasury; // Treasury address for the gateway where the execution fee is sent } struct Domain { address account; // The wallet address from which the payment is sourced or to which it is sent uint256 network_id; // Network ID of the blockchain where the payment will be executed (e.g., Ethereum mainnet, Polygon, etc.) address payment_token; // Address of the token being used for the payment (e.g., ERC20 token or native address) } struct Schedule { IntervalUnit intervalUnit; // Unit of time for the recurring interval (day, week, month, year) uint256 interval_count; // Number of interval units between each occurrence (e.g., 2 for bi-weekly if intervalUnit is week) uint256 iterations; // Number of iterations the payment should be repeated; if set, end_date should not be used uint256 start_date; // The timestamp of when the recurring payments should start uint256 end_date; // The timestamp for when the recurring payments should stop (ignored if iterations are set) }