# TechnicalWhitePaper
## Technical White Paper (Zen7 Payment Agent)
## 1. Abstract and Overview
Zen7 Payment Agent stands as the inaugural practical implementation of the DePA (Decentralized Payment Agent) framework, pioneering the next generation of intelligent payment infrastructure. It not only fully realizes the core functionalities of DePA but has also been successfully deployed with innovative application cases within the field of agent-enabled e-commerce.
As the first practical project within the DePA ecosystem, Zen7 achieves several key characteristics: automated encrypted payments among intelligent agents, an "authorized password-free" mechanism, and intent recognition and interaction powered by large language models.
By supporting multi-chain, multi-wallet, and multi-currency operations, integrating robust security mechanisms, and delivering an exceptional user experience, Zen7 Payment Agent establishes a seamless "intent-to-result" payment journey.
## 2. Technical Architecture
Zen7 Payment Agent employs a multi-agent collaborative architecture designed to deliver a comprehensive payment solution. It provides support for both A2A (Agent-to-Agent) and MCP (Model Context Protocol) protocols, enabling seamless communication and integration within decentralized ecosystems. The architecture natively supports both custodial and non-custodial fund management models, offering flexibility to accommodate diverse application requirements and user preferences for asset control.
This architecture is engineered to provide a multi-chain, multi-currency, and multi-wallet payment solution specifically for AI Agents and native DApps. It is capable of handling high-frequency transactions while incorporating features such as a "authorized password-free" mechanism and solutions for gas fee abstraction, thereby creating a seamless and efficient payment experience from intent to result.
### 2.1 Multi-Agent Collaborative Architecture
Zen7 Payment Agent employs a "1+3" multi-agent collaborative architecture to implement
\
decentralized payment processes. Within this framework, the Host Agent acts as the core
\
coordinator, responsible for intent comprehension, intelligent routing, state management, risk
\
control, and auditing . Three specialized agents operate with distinct responsibilities: the Payer
\
Agent handles payment capability assessment, credit authorization checks, and the generation
\
of signatures based on the EIP-712 standard; the Settlement Agent functions as the on-chain
\
execution engine, completing processes such as risk control, authorization, and fund transfer,
\
while supporting both custodial and non-custodial models ; and the Payee Agent is tasked with
\
payment receipt confirmation, settlement record generation, and fund management.
\
The complete payment flow is as follows: the Host Agent routes the payment request → the
\
Payer Agent performs validation and generates signatures → the Settlement Agent executes the
\
on-chain settlement → the Payee Agent confirms receipt of funds. This sequence forms an end-to-end automated closed loop. Building on this collaboration, the service agent layer exposes user-facing capabilities.
Beyond the core multi-agent architecture, Zen7 Payment Agent provides a comprehensive suite
\
of supporting services designed to ensure compliance, observability, and operational efficiency.
\
These services are fundamental to the platform's security, auditability, and manageability in a
\
production environment.
* Notification & Alerting Service: This service offers event subscription and push notifications
\
for both end-users and various intelligent agents. It supports multi-channel integration,
\
ensuring timely dissemination of critical information related to transaction status, system
\
events, or potential risks.
* Risk Control Engine: The engine performs real-time transaction interception based on a
\
combination of configurable policies, including quota limits, address whitelists, and on-chain
\
risk scoring modules. All enforcement decisions are logged, providing a clear and auditable
\
trail for risk management activities.
* Event Monitor: This component continuously monitors both on-chain events and
\
interactions among the various internal agents. It writes these events to immutable audit
\
logs and the internal ledger. The monitor also supports alert triggering, event replay for
\
debugging, and comprehensive compliance tracing.
* Audit Log & Ledger: This service meticulously records critical data points, including onchain transaction hashes, permission usage, approver signatures, and reconciliation
\
vouchers. This creates a dual-ledger system that synchronizes on-chain records with offchain audit data, ensuring a complete and tamper-evident record of all activities.
* Policy & KYX Service: Providing a unified compliance framework that covers KYC (Know Your
\
Customer), KYS (Know Your Supplier), and KYA (Know Your Agent), this service performs
\
identity verification and risk assessments for customers, merchants, and intelligent agents. It
\
underpins transaction policies, manages whitelists and blacklists, and conducts necessary
\
compliance checks.
### 2.2 Custodial Mode
In Custodial Mode, the Host Agent completes intent validation and triggers the Payer Agent to perform an on-chain balance check and generate an EIP-2612 Permit signature. The Settlement Agent verifies the signature, pays the gas fee, executes permit + transferFrom operations, transfers funds into a designated escrow wallet, and records the transaction in real-time. Funds are protected by risk control policies during the custodial period. Upon reaching settlement conditions, funds are released to the Payee Agent after review. The Event Monitor and Audit Log & Ledger maintain records; contingency procedures (re-authorization, interception, arbitration, refunds) are available for anomalies.
A key feature: the Settlement Agent covers Gas fees uniformly, providing a "Zero-Gas" payment experience for both Payer and Payee across custodial and settlement phases.
The Zen7 Payment Agent operational workflow is a sequence of discrete, automated steps. The following stepper details the flow from intent initiation to final settlement and auditing.
{% stepper %}
{% step %}
### Intent & Validation
Host Agent receives the payment request and performs initial validation of parameters (asset, amount, validity period). On success, it creates a unified Payment Agent Context and routes the request.
{% endstep %}
{% step %}
### Balance Check
Payer Agent queries on-chain balance to verify sufficiency. If sufficient, proceed. If insufficient, workflow terminates with an error and requires re-initiation.
{% endstep %}
{% step %}
### Signature Processing
Payer Agent requests a signature from the connected wallet to generate EIP-712 structured signature data compliant with EIP-2612 Permit. On failure, the workflow terminates with an error.
{% endstep %}
{% step %}
### Authorization Request Submission
Payer Agent submits the authorization and payment request (including signature data) to the Settlement Agent.
{% endstep %}
{% step %}
### Authorization & Transfer (Escrow Funding)
Settlement Agent uses EIP-2612 Permit to execute authorization. Upon token contract verification, Settlement Agent calls transferFrom to transfer funds into escrow wallet. Settlement Agent covers Gas fees. On failure, workflow terminates with an error.
{% endstep %}
{% step %}
### Escrow Confirmation
Settlement Agent confirms escrow transaction success and records escrow details; funds enter a holding period under escrow protection per business rules.
{% endstep %}
{% step %}
### Settlement Processing
When settlement conditions are met, Settlement Agent performs final risk and compliance checks and transfers funds from escrow wallet to Payee. If settlement fails, exception handling is triggered. Settlement Agent covers Gas fees.
{% endstep %}
{% step %}
### Settlement Confirmation & Auditing
Settlement Agent confirms settlement; Payee Agent receives payment confirmation. Event Monitor captures events from escrow and settlement phases; Audit Log & Ledger record the complete transaction link, creating an immutable and auditable trail.
{% endstep %}
{% endstepper %}
If exceptions occur at any stage, the system supports re-authorization, policy-based interception, dispute arbitration, and refunds.
The payment sequence diagram illustrates the message and data flow among the multiple agents across the stages of Intent → Sign → Payment → Settlement.
* Funds Transfer Phase: This phase encompasses the critical steps from intent validation to the successful escrow of funds.
* Settlement Phase: This phase involves the release of funds from escrow to the Payee upon meeting predefined conditions.
All state changes generate on-chain events captured by the Event Monitor and written into the Audit Log & Ledger, forming a replayable evidence chain. Key events include:
| Event Name | Trigger Point | Corresponding Workflow Stage | Purpose |
| ------------------- | ---------------------------- | ---------------------------- | -------------------------------------------------------- |
| IntentCreated | T0 - Payment intent creation | Intent & Validation | Records origin and parameters of the payment request. |
| PermitSigned | T2 - Signature generation | Signature Processing | Records the EIP-2612 Permit signature data. |
| FundsEscrowed | T4 - Funds placed in escrow | Authorization & Transfer | Marks transfer of funds into escrow wallet. |
| FundsReleased | T6 - Funds released | Settlement Processing | Marks transfer of funds from escrow to Payee. |
| SettlementCompleted | T7 - Settlement confirmed | Settlement Confirmation | Confirms Payee has received funds; payment completion. |
| TransactionFailed | Transaction failure | Exception Handling | Records reason for failure. |
| DisputeInitiated | Dispute initiated | Exception Handling | Triggers freezing of escrowed funds pending arbitration. |
### 2.3 Non-Custodial Mode
In the Non-Custodial Mode, the operational workflow is as follows: the Host Agent first completes intent validation and triggers the Payer Agent to perform an on-chain balance check and generate an EIP-2612 Permit signature. The Settlement Agent then verifies the signature, pays the Gas fee required for the transaction, and executes the `permit`+ `transferFrom`operations. This results in the direct transfer of funds from the Payer's wallet to the Payee's wallet. Upon successful transfer, the transaction is recorded in real-time. Throughout this entire process, the Event Monitor and Audit Log & Ledger maintain comprehensive records. Should any anomalies occur, predefined contingency procedures—such as re-authorization, transaction interception, arbitration, or refunds—are automatically triggered.
A defining characteristic of the Non-Custodial Mode is that the Settlement Agent covers the Gas fees specifically for the on-chain `transferFrom`operation during the fund transfer phase. This mechanism ensures that both the Payer and the Payee experience a seamless, "Zero-Gas" transaction from initiation to completion, eliminating the financial and operational burden of blockchain transaction fees for the end-users.The operational workflow for the Non-Custodial Mode, where funds are transferred directly from the Payer to the Payee, consists of the following sequenced stages:
{% stepper %}
{% step %}
### Intent & Validation
Host Agent receives and validates the payment request (asset type, amount, validity period). On success, it creates the Payment Agent Context.
{% endstep %}
{% step %}
### Balance Check
Payer Agent queries on-chain balance for sufficiency. If insufficient, the workflow terminates with an error.
{% endstep %}
{% step %}
### Signature Processing
Payer Agent instructs the connected wallet to generate an EIP-712 structured signature compliant with EIP-2612 Permit. On failure, workflow terminates with an error.
{% endstep %}
{% step %}
### Authorization Request Submission
Payer Agent submits signature data and payment request to Settlement Agent.
{% endstep %}
{% step %}
### Authorization & Transfer (Direct)
Settlement Agent uses EIP-2612 Permit to authorize, then calls transferFrom to transfer funds directly from Payer to Payee. Settlement Agent covers Gas fees. On failure, workflow terminates with an error.
{% endstep %}
{% step %}
### Transfer Confirmation & Auditing
Settlement Agent confirms on-chain transfer; Payee Agent records transaction and receives payment confirmation. Event Monitor captures transfer event; Audit Log & Ledger record the transaction trace for auditing.
{% endstep %}
{% endstepper %}
Diagrams illustrating the sequence and on-chain event capture:
Key events and purposes in Non-Custodial mode:
| Event Name | Trigger Node | Key Information | Purpose |
| ---------------------------------------------------- | --------------------- | ----------------------------------------- | ------------------------------------------------------------------ |
| IntentCreated | Intent Creation | intentId, payment parameters | Marks starting point and solidifies request parameters. |
| PermitSigned | Authorization Signing | signature digest, deadline | Records authorization credential and supports replay verification. |
| TransferCompleted | Fund Transfer | payer/payee, amount, txHash | Confirms funds transferred from payer to payee. |
| PaymentSettled | Payment Settlement | payee, timestamp | Confirms payee received funds; closes business process. |
| AuditRecorded | Audit Logging | blockNumber, auditHash | Aligns on-chain and off-chain data for tracing. |
| PolicyBlocked / TransactionFailed / DisputeInitiated | Exception Handling | blocking rule, error code, dispute reason | Captures risks/failures/disputes and triggers processes. |
## 3. Core Technologies and Innovations
### 3.1 Summary of Technical Advantages
Zen7 Payment Agent, as the first practical DePA project, leads the new generation of intelligent payment infrastructure. It realizes DePA core functionalities and has deployed innovative use cases in agent-driven commerce.
Key characteristics include automated encrypted payments between agents, verifiable authorization safeguarding user sovereignty, and LLM-powered intent recognition and interaction.
By supporting multi-chain, multi-currency, and multi-wallet operations, incorporating robust security mechanisms, and delivering a seamless user experience, Zen7 provides a solution for high-frequency, micropayment scenarios and lays groundwork for AI Agent economy payment infrastructure.
#### 3.1.1 Technical Advantages
Core competitiveness summarized:
* Agent-Native Architecture & Automated Payments: Built for AI Agent collaboration; supports A2A/MCP protocols; enables intent-driven automation of payment processes, autonomous negotiation, transaction execution, and settlement by agents.
* Threefold Technical Breakthrough:
* Authorization without Passwords (EIP-712/EIP-2612): Web2-level UX while maintaining non-custodial security; single authorization supports batch transactions.
* Multi-Chain, Multi-Currency, Multi-Wallet Support: Native multi-EVM chain and stablecoin support and mainstream wallets.
* Gas-Free Experience: Agents cover Gas fees, removing user friction.
* Exceptional User Experience: Shields users from Web3 complexities; provides an "intent-to-result" experience—users specify payment goal only.
* Enhanced Security: Users do not sign each transaction individually, reducing exposure to malicious prompts; agent behaviors confined within authorized scopes; custody choices preserved.
* Intrinsic Composability: Acts as payment-layer infrastructure connecting DeFi, DePIN, GameFi, SocialFi, fostering complex on-chain ecosystems.
### 3.2 Payment Protocol Support: EIP-2612 & X402
Zen7 Payment Agent integrates two complementary payment protocols: EIP-2612 for blockchain-native authorization and X402 for internet-native AI agent payments.
#### 3.2.1 EIP-2612: Gasless Permit-Based Authorization
EIP-2612 extends ERC-20 tokens with a permit function, enabling gasless approvals via off-chain signatures.
Workflow: User signs EIP-712 structured message → Settlement Agent submits to permit() → executes transferFrom() → completes transfer. Settlement Agent pays all Gas fees.
Key Benefits: Single signature authorizes multiple transfers; non-custodial security; atomic authorization + transfer; eliminates approve-then-transfer friction.
#### 3.2.2 X402: Internet-Native AI Payment Protocol
X402 leverages HTTP 402 "Payment Required" status code for AI-first, pay-per-use scenarios without accounts or API keys.
Workflow: AI agent requests resource → receives 402 with payment details → autonomously pays via stablecoin → receives access upon confirmation.
Key Benefits: Zero-barrier integration (single line of code); supports sub-cent micropayments; blockchain-agnostic; native Coinbase AgentKit support.
Integration with Zen7: X402 Protocol Adapter translates HTTP 402 responses into unified payment intents, routing through Payer Agent → Settlement Agent → Payee Agent workflow.
Use Cases: AI-to-API payments (data, compute, LLM inference); M2M commerce; granular content monetization; dynamic service pricing.
#### 3.2.3 Protocol Selection Guidance
EIP-2612: Best for blockchain-native, pre-authorized workflows (subscriptions, escrow, batch payouts).
X402: Best for on-demand API access without pre-authorization (pay-per-call, data queries, compute resources).
### 3.3 Multi-Chain & Multi-Currency Strategy
#### 3.3.1 Multi-Chain Support Strategy
DePA Chain is designed for high-frequency, micro-payment, and password-free payment scenarios of the AI Agent economy. Characteristics:
| Blockchain | Core Advantages | Potential Limitations |
| --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| Ethereum L1 | Native issuance of mainstream stablecoins; High security; Strong compliance recognition | High Gas costs; Long confirmation times |
| Base | Backed by Coinbase ecosystem; Regulatory facilitation; Smooth connectivity with CEX liquidity | Degree of decentralization under development; Relatively fewer assets |
| BNB Chain (BSC) | High throughput; Low fees; Strong liquidity in emerging markets | Relatively lower decentralization; Weaker regulatory reputation |
| Polygon | Low fees; Fast confirmation; Active ecosystem | Security slightly lower than L1; Limited support for some stablecoins |
| Arbitrum | Strong Ethereum ecosystem compatibility; Low Gas fees; Large user base | Relatively concentrated ecosystem; Limited support for some assets |
| Solana | High throughput (65,000+ TPS); Sub-second finality; Extremely low transaction costs; Growing DeFi and payment ecosystem | Non-EVM architecture requires separate integration; Network stability concerns during peak load |
| DePA Chain | Optimized for A2A: Extremely low Gas, millisecond-level confirmation, native support for password-free authorization; deep integration of Agent identity and payment protocols; self-controlled governance | Early-stage ecosystem development; Requires cross-chain bridges |
* Ultimate Performance Optimization: second-level confirmations, near-zero Gas, capable of handling high TPS for inter-Agent payments.
* Native Protocol Integration: EIP-712/2612, Agent identity (KYA), policy engines, audit tracing at blockchain level.
* Dedicated Agent Ecosystem: customized economics, incentives, governance for AI Agents.
* Cross-Chain Interoperability: bridges to major L1s/L2s; L1 as final settlement layer; L2s handle high-frequency transactions.
* Cost Structure Advantage: Agent-covered Gas fees on L2s enable sustainable "Zero-Gas" models.
#### 3.3.2 Multi-Currency Support Strategy
Zen7 employs a layered "Agent collaboration + smart contracts" architecture to support multi-currency payments.
| Currency | Core Advantages | Potential Limitations / Risks | Primary Supported Chains |
| -------- | --------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------------------- |
| USDC | High regulatory recognition, direct fiat redemption, strong liquidity | Confusion between native and bridged versions; issuer allowlists/policies require monitoring | Ethereum, Base, Arbitrum, Polygon |
| USDT | Wide adoption, strong liquidity, abundant trading pairs | Diverse on-chain versions require strict address management | Ethereum, Base, Arbitrum, Polygon, BNB Chain, TRON |
| PYUSD | Strong compliance backing, brand trust, Ethereum integration | Limited on-chain coverage and liquidity | Ethereum |
| EURC | Euro-denominated, clear compliance path | Primarily suited for Eurozone; limited cross-regional use | Ethereum |
| ENA | Yield-bearing mechanism, deep DeFi integration | Reliance on staking yield; smart contract complexity risk | Ethereum, Arbitrum |
| DAI | High decentralization, DeFi-friendly | Peg stability pressure during extremes; governance risks | Ethereum, Arbitrum, Base, Polygon |
| LUSD | Crypto-collateralized, decentralization narrative | Limited liquidity; liquidation volatility risk | Ethereum |
| FRAX | Flexible mechanism, active ecosystem | High mechanism complexity; stability pressure | Ethereum, Arbitrum, Base, Polygon, BNB Chain |
### 3.4 Multi-Wallet Service (Wallet Execution Service)
Current Wallet Adaptation Achievements:
Deep integration for mainstream EVM hot wallets (e.g., MetaMask, Coinbase Wallet, Phantom) via a unified wallet adapter. Core operations—on-chain signing, asset authorization, and balance queries—are standardized across wallets, reducing multi-wallet complexity for developers and ensuring consistent user experience.
Future Wallet Ecosystem Expansion Plan:
* Diversify wallet types: integrate multi-signature wallets (Safe, Fireblocks MPC multi-signature, Cobo) for cross-chain and team asset management.
* Enhance asset security: support MPC wallets and multi-factor authentication for high-net-worth security.
* Priority integrations: Fireblocks, Safeheron, Coinbase WaaS, ZenGo, Web3Auth MPC, Cobo MPC, OKX MPC.
### 3.5 Audit and Ledger
"Ledger + Audit" functions form an event-driven dual-ledger system with a replayable audit trail to enable a full-cycle loop from data collection and reconciliation to exception alerts and compliance evidence.
Ledger Functionality:
* Dual-ledger model: on-chain ledger + off-chain business ledger.
* Event Monitor captures Agent-to-Agent events (intent creation, authorization signing, funds escrowed, funds transferred, settlement completed) to form off-chain ledger.
* Transaction hashes, block heights, agent-paid Gas fees, and deadlines are written to the on-chain ledger for synchronization.
Audit Functionality:
* Audit Service reuses event streams to build a replayable payment process, preserving context for key nodes (transfer completions, failures) and supporting multi-stage evidence collection and dispute arbitration.
### 3.6 Dual Protocol Support: A2A & MCP
Zen7 follows a "thinnest possible adaptation" approach to bridge A2A and MCP protocols. It exposes a consistent semantic interface upstream and maintains a unified internal invocation path and response format for the core Payment Agent. The adaptation is a pass-through with format conversion, avoiding added business logic or persisted state, and ensuring explicit failure returns. Modular protocol adapters enable horizontal scaling.
#### 3.6.1 Protocol Adaptation Layer Positioning
Role: sits between upstream ecosystems (A2A, MCP) and the core Payment Agent; responsible for protocol parsing, authentication validation, invocation orchestration, and response writing. Input: heterogeneous payloads; Output: structured execution results and error messages.
Responsibilities and Components:
* Protocol Adapter: parses upstream requests, verifies signatures/credentials, maps to internal instructions.
* Invocation Orchestrator: forwards requests to core services; handles retries, circuit breaking, rate limiting.
* Response Formatter: transforms core responses into upstream protocol formats and attaches metadata.
* Observability Layer: collects metrics, logs, traces; drives alerts.
#### 3.6.2 Adaptation Processing Flow
Process loop: "Client Initiation → Protocol Adaptation → Protocol Routing → Core Execution → Response Writing."
* MCP scenario: client accesses adapter with session token, tool ID, and payload. Session Manager isolates multi-tenancy (TenantID + Session Token) and injects quotas. Protocol Router schedules core execution; Response Formatter outputs results with status and metadata.
* A2A scenario: access via REST/WebSocket/message queues with chain signatures and context. After identity verification, idempotency checks, session read/write, Protocol Router schedules core execution. Response Formatter generates response with status codes, error codes, trace IDs. Failed requests can be retried using idempotency key or trace ID. Sessions are cleaned up on TTL expiration.
## 4. Risk Control and Security
### 4.1 Design Principles
* Security by Design: multiple signatures, permission isolation, and real-time auditing enforced for critical paths; layered defense to protect core fund boundary.
* Scalability and Observability: Event Monitor and Invocation Orchestrator, supported by policy and risk engines, perform circuit breaking, quotas, and rate limiting; aggregation of on-chain events, metrics, logs, traces into Audit Log & Ledger for alerts and anomaly isolation.
* Dual Assurance of Compliance and Privacy: KYX data encrypted and isolated; Travel Rule executed via independent control plane with minimal visibility access to meet multi-regional regulations while protecting privacy.
### 4.2 Key & Signature Management
#### 4.2.1 Key Isolation Strategy
* Payer / Payee: funding account wallets are self-custodied; private keys belong to users and are used solely for signing authorized (Permit) transactions. No third-party custody; supports offline recovery.
* Settlement Agent: holds private key for signing policy instructions (EIP-712). Key is stored in an HSM; invocation requires short-lived tokens; all operations audited to prevent misuse or lateral privilege escalation.
* Escrow Wallet: intermediate step in fund flow; in custodial mode funds moved into this wallet under policy governance; in non-custodial mode transferFrom moves funds directly to Payee self-custodied wallet.
#### 4.2.2 Replay Attack Protection
Replay attacks are mitigated via multi-layer protections:
* Terms Hash Verification: termsHash = keccak(payer, payee, asset, amount, deadline, disputeKey, policyChecksum). Any tampering changes termsHash and invalidates signatures.
* Time Window Limitation: signatures include a deadline; operations are rejected after expiry.
### 4.3 Compliance
Closed-loop KYC / KYS / KYA operation enabling layered compliance:
* Role definitions:
* KYC: customer identity verification and sanctions screening.
* KYS: merchant/supplier compliance qualification and risk rating.
* KYA: human and AI agent authorization scope and behavior trails.
* Automated controls triggered by risks:
* Incomplete customer info restricts process initiation.
* Higher-risk suppliers get downgraded limits.
* Anomalous agent operations trigger credential suspension.
* Traceable decisions: Event Monitor generates KYXStatusChanged and PolicyEscalated records for KYX events. Audit & Ledger support tracing the compliance decision chain via intentId.
## 5. Typical Agentic-Commerce Application Case Study
### 5.1 System Architecture Diagram
### 5.2 Business Process Flow Diagram
### 5.3 Agentic-Commerce Business Processing Full Workflow
{% stepper %}
{% step %}
### Intent Capture
User interacts with an LLM via prompt/dialogue, which activates the Buyer Agent to drive the Shopping Agent or directly invokes the Shopping Agent, initiating the e-commerce scenario.
{% endstep %}
{% step %}
### Order Preparation
Shopping Agent parses user intent, completes product selection, sets payment amount and validity period, generates core order fields, and synchronizes key order points with Seller Agent.
* Payment-related parameters (amount, asset type, validity period) are sent to Host Agent; detailed order items are not retransmitted.
* Host Agent issues payment instruction to Payer Agent, which checks amount and validity period.
{% endstep %}
{% step %}
### Fund Escrow
Payer Agent transfers digital assets to Settlement Agent per instruction. Settlement Agent escrows assets and returns a Callback URL; Payer Agent notifies payer of status.
{% endstep %}
{% step %}
### Fulfillment Trigger
Settlement Agent synchronizes payment success with Seller Agent (or Shopping Agent) to initiate fulfillment/shipment.
{% endstep %}
{% step %}
### Shipment & Notification
Upon receiving payment success Callback, Seller Agent pushes shipment notification to Buyer Agent and executes fulfillment.
{% endstep %}
{% step %}
### Batch Settlement
Settlement Agent aggregates transactions based on threshold conditions (e.g., 1000 USDC, 20 transactions, 3-day cycle) and initiates a one-time transfer to Payee.
{% endstep %}
{% step %}
### Payout Confirmation
After Payee receives transfer, it sends a Callback URL to Settlement Agent, completing the settlement closed loop.
{% endstep %}
{% endstepper %}
### 5.4 Case Highlights
* D2C Focus: serves high-value vertical industries selling directly to consumers with automated payment and fulfillment.
* Paradigm Shift: moves from manual search-based commerce to automated Agent-driven business models.
* Experience Upgrade: seamless switching between conversational and embedded interfaces.
* Technology Integration: combines LLM cognition, process automation, data insights, and fintech capabilities for trusted payments.
* Ecosystem Co-creation: platform functions as Agent-driven commerce infrastructure and incubator for Agent economy; supports autonomous negotiation between merchant and buyer Agents.
* Agent Assetization: tokenization of AI Agents and splitting revenue rights via smart contracts.
## 6. Glossary and Appendix
| Term | Full Name / Source | Plain Explanation | Role in Zen7 |
| --------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| MCP Protocol | Model Context Protocol (MCP) | A standardized protocol for discovery, negotiation, and secure invocation of tools and context between models/agents. | Settlement/Host exposes payment tools as MCP Servers, enabling low-friction integration for external Agents. |
| Escrow | Escrow Contract | Funds locked in a third-party contract and released when conditions are met. | Security cornerstone guaranteeing "authorize once, release upon conditions". |
| EIP-712 | Ethereum Improvement Proposal 712 | Ethereum signature standard binding off-chain signatures to on-chain data, preventing tampering/replay. | Used for non-repudiation signatures for release/refund requests. |
| Meta-Tx | Meta Transaction | A relayer submits transactions and pays Gas fees on your behalf. | Enables Settlement Agent to trigger on-chain releases without holding tokens. |
| MPC / KMS / HSM | Multi-Party Computation / Key Management Service / Hardware Security Module | Enterprise-grade secure signature solutions. | Helps Payer/Payee manage private keys securely, avoiding centralized risks. |
| KYX | Know Your X (KYC / KYS / KYA) | Unified compliance framework for identity verification and risk assessment of customers, merchants, and agents. | Ensures participants are trustworthy and permissions are controlled; supports regulatory/audit requirements. |
| KYS | Know Your Seller / Supplier | Review of qualifications and compliance risks of upstream merchants/suppliers. | Assesses external executors (liquidity/custody partners) impact on fund flow. |
| KYA | Know Your Agent | Auditing whether an AI Agent has legitimate authorization and remains compliant. | Manages entities triggering payments, preventing unauthorized access or hijacking risks. |
| Travel Rule | FATF Travel Rule | Requires VASPs to share sender and receiver identity info for qualifying transfers. | Compliance control plane interacts with KYX/Policy for AML and reporting. |
| Policy Engine | Policy Control Service | Aggregates risk control rules, quotas, blacklists, and KYX results. | Enables Settlement Agent to decide approvals during intent stage. |
| termsHash | Terms Hash | Unique identifier generated by hashing key payment parameters. | Ensures term integrity and prevents tampering; binds terms for escrow transactions. |
(End of document)
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://zen7.gitbook.io/zen7-docs/technicalwhitepaper.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.