x402 Singularity Layer

核心功能

x402-layer 是一个面向代理经济的 Web3 支付基础设施，实现了 HTTP 402 Payment Required 协议标准。该技能支持三大核心场景：

1. 消费者端：代理可使用 USDC 支付 API 调用费用，支持按请求付费（pay-per-request）和积分消费（credit-based）两种模式，兼容 Base、Ethereum、Polygon、BSC、Monad 和 Solana 六大网络。

2. 提供者端：开发者可部署变现端点（$1 一次性创建费含 4000 积分），配置 Webhook 接收支付通知，并在市场中上架服务。积分经济模型为 500 积分/$1，每请求消耗 1 积分。

3. 代理注册与声誉：支持 ERC-8004（EVM）和 Solana-8004 标准代理注册、元数据管理、端点绑定及链上声誉反馈提交，构建可验证的代理身份体系。

显著优点

• 多链多钱包灵活架构：支持原生私钥、Coinbase AWAL、OpenWallet/OWS 三种钱包模式，可按任务按需切换，无需全量配置凭证
• 安全优先设计：明确区分无密钥发现、API 密钥管理、PAT 控制面板、委托钱包、直接签名五级权限路径，遵循最小权限原则
• World AgentKit 集成：自动识别并享受人类托管代理钱包的支付优惠，降低代理运营成本
• 完善的支付验证：提供 PyJWT/JWKS 标准的 Webhook 签名验证脚本，防范支付欺诈
• MCP 控制平面：支持 Singularity MCP 服务端，通过 PAT 实现仪表板级的端点/产品/集成管理
• XMTP 支持通道：内置买家/卖家加密通信能力，支持服务纠纷协商

潜在局限

• Solana 支付复杂度：需精确处理 feePayer 和计算单元限制，生产环境建议优先使用 Base
• OWS 功能边界：OpenWallet 目前仅支持支付、发现、消息签名和钱包认证列表，深度链上注册和更新仍需私钥
• 凭证管理责任：虽然文档强调最小权限，但多凭证类型并存仍要求用户清晰理解每种路径的适用范围
• 早期生态依赖：x402 协议仍为新兴标准，端点可用性和市场流动性取决于网络效应积累

适合人群

• 希望为 API/服务添加加密货币支付能力的开发者
• 构建自主代理经济的基础设施团队
• 需要多链支付 SDK 的 DeFi/AI 应用开发者
• 探索 ERC-8004 代理身份标准的协议工程师

常规风险

• 私钥泄露：直接导出私钥至环境变量存在持久化泄露风险，建议生产环境使用 AWAL/OWS 委托模式
• Webhook 伪造：服务端必须验证 X-X402-Signature HMAC-SHA256 签名，仅依赖传统 header 检查存在被绕过风险
• 积分耗尽中断：端点积分归零后自动停止服务，需监控并设置充值告警
• 网络选择错误：跨链支付需确认端点支持的目标网络，错误选择导致交易失败或资金损失
• AgentKit 资格误判：--agentkit auto 模式下若资格检查失败会静默回退，关键场景应使用 required 模式显式报错

核心用法

x402-layer 是一个面向 AI 代理的 Web3 支付基础设施 Skill，实现 HTTP 402 Payment Required 协议标准。核心能力分为四大模块：

1. 消费端能力 — 代理可使用 USDC 支付调用付费 API（pay_base.py/pay_solana.py），支持按请求付费或信用额度模式（consume_credits.py）。集成 Coinbase AWAL 和 OpenWallet/OWS 委托钱包模式，无需暴露私钥即可完成支付。

2. 供应端能力 — 开发者可部署货币化端点（create_endpoint.py，$1 一次性费用含 4000 信用额度），配置 Webhook 接收支付通知（manage_webhook.py），并在交易市场挂牌（list_on_marketplace.py）。

3. 代理注册与声誉 — 支持 ERC-8004（EVM 链）和 Solana-8004 标准的代理注册、元数据更新、端点绑定，以及链上声誉反馈提交。

4. MCP 控制平面 — 通过 Singularity PAT 令牌，代理可执行所有者级别的仪表板操作，如端点管理、产品更新、Webhook 配置等。

显著优点

• 多链覆盖：Base、Ethereum、Polygon、BSC、Monad、Solana 六链统一支付体验
• 安全设计：最小权限原则明确，区分只读发现、API 密钥、PAT、委托钱包、直接私钥五级凭证模式
• 灵活钱包模式：优先推荐 AWAL/OWS 委托模式，私钥仅用于必要场景
• 完整生命周期：从支付、部署、注册到声誉管理的端到端支持
• 标准合规：实现 EIP-712 和 Solana 支付标准，Webhook 使用 HMAC-SHA256 时序安全验证

潜在缺点与局限性

• 凭证复杂度：支持 5 种凭证类型（私钥、AWAL、OWS、API 密钥、PAT），新手易混淆
• 外部二进制依赖：OWS/AWAL 模式需本地安装 Node.js 二进制，存在供应链风险
• Solana 限制：精确支付流需处理 feePayer 和计算单元限制，生产环境建议使用 Base
• T3 来源可信度：个人开发者/社区项目，非企业级维护
• MCP 与脚本路径并存：部分功能（如端点管理）存在 MCP 和直接脚本两种方式，文档需仔细阅读选择

适合人群

• 构建 AI 代理服务并希望通过加密货币实现自动计费的开发者
• 需要为 API 添加 USDC 支付能力的 Web3 项目
• 探索 ERC-8004 代理注册和去中心化声誉系统的代理开发者
• 希望集成 World AgentKit 人类背书代理钱包优惠的开发者

常规风险

| 风险类型 | 级别 | 说明 |

|---------|------|------|

| 私钥泄露 | 中 | 支持直接私钥模式，文档虽建议 AWAL/OWS，但用户可能误用长期高价值钱包 |

| 供应链攻击 | 中 | OWS/AWAL 二进制需从官方渠道安装，OWS_BIN 指向不可信路径可导致恶意执行 |

| API 劫持 | 低 | 仅 HTTPS 连接官方域名，建议增加证书固定 |

| 交易误操作 | 低 | 代码已验证 ownerAddress 匹配，但用户仍需仔细核对交易参数 |

使用建议：严格遵循文档"Credential safety"章节，优先使用只读发现 → API 密钥/PAT → AWAL/OWS → 临时私钥的安全层级，避免将长期高价值钱包用于测试场景。