使用加密钱包支付域名：无需账户

所有宣称“AI 智能体可以替你购买域名”的说法，最终都会撞上同一堵墙：智能体究竟怎样付款？信用卡默认会有真人在场：在表单中输入卡号、通过反欺诈检查，并确认发送到手机的一次性验证码。AI 智能体做不到这些。Namefi 的答案是一条无需信用卡、无需已保存付款方式、也完全不需要 Namefi 账户的结账路径——只需一个当场签署付款的加密钱包。本文深入说明该流程实际如何运作、签名机制允许及不允许智能体做什么，以及何时应改用 API 密钥计费。

为什么付款是智能体商业中最难的一环

让智能体购买东西时，搜索和比价从来都不是难点。它们都是只读调用——不需要授权，即使智能体出错也没有实际损失。付款不同：这是唯一出错就会损失真金白银的一步，而目前所有广泛使用的支付系统都假定由人来授权扣款。

保存的信用卡是最清楚的例子。已存卡计费的工作方式，是将一个今后可再次扣款的令牌交给支付处理商；商户只要自行决定，就可以在之后扣款，无须持卡人在扣款时重新证明任何事。对于你信任其每月扣款的订阅服务，这没有问题；但它不适合自主流程：任何持有已存卡令牌的人都能扣款，唯一真正的防线是相信软件不会滥用它，或在之后从账单上发现滥用。你无法交给一个智能体一张只能支付不超过 $50 的域名注册费用的已存卡——信用卡并不知道自己是为此而设的。

什么是智能体原生域名注册商？更广泛地阐明：付款是能否被智能体使用的承重组成部分之一，而不只是“有没有 API”。Namefi 的加密钱包结账正是对这一要求的具体回答：它不提供让服务可随时扣款的已存凭据，而是让每笔付款都成为钱包仅为那一笔交易、那个价格生成的签名，除此之外别无授权。

Namefi 的答案：钱包签名结账，无需创建账户

通常，在 Namefi 注册域名要使用一个 API 密钥，其费用从已充值的 NFSC（Namefi Service Credit）余额中扣除；如何在 Namefi 上通过 AI 智能体注册域名对此已有说明。这条路径需要账户：有人从钱包生成密钥、为余额充值，然后每次注册时由该密钥从余额中扣款。

钱包签名路径会跳过所有这些步骤。根据 Namefi 已发布的钱包付款机器可读文档，智能体的钱包可直接以稳定币 USDC 付款，无须任何地方持有 Namefi 账户或 API 密钥——买方的钱包签署付款授权，签名送达后即结算注册。无需预先创建任何东西，也没有任何可在日后被滥用的持续授权：钱包只会在它签名的那一刻行动。

Namefi 记录了钱包生成该签名的三种方式，下面会逐步介绍：x402 协议（主要路径，也是本指南关注的路径）、Machine Payable Protocol（MPP）的质询—响应变体，以及供不使用前两种快捷方式的钱包采用的手动 EIP-712 签名路径。

x402 流程：逐步说明

x402 是一项开放标准，获得 Cloudflare、AWS 和 Stripe 等公司的支持。它重新启用了长期闲置的 HTTP 402 Payment Required 状态码，将其作为在普通请求中内联请求链上付款的结构化方式，而不是重定向到独立的结账页面。Namefi 在其域名注册端点上实现了这一机制：

不附付款地发起请求。 智能体向 Namefi 发起普通 GET 请求，请求目标是 /x402/domain/{domainName} 端点——不附带付款，因为它尚不知道价格。
包含价格的 HTTP 402。 Namefi 响应 402 Payment Required，并在响应体中列出付款选项：网络、接受的资产（USDC）和金额。这正是 x402 与普通错误的不同之处——402 状态携带客户端构造有效付款所需的一切信息，而不只是说“不行”。
钱包签署 EIP-3009 transferWithAuthorization。 钱包不会发送一笔独立的区块链交易再等待确认，而是根据 EIP-3009 生成签名；这是专为经签名授权的代币转移设计的以太坊标准。EIP-3009 的 transferWithAuthorization 函数允许代币持有人签署一条消息，授权将指定金额转给指定接收方，并且仅在指定时间窗口内有效（validAfter / validBefore）；随后第三方可将其提交到链上。Namefi 的文档明确说明，此步骤不需要 Namefi 账户，也不需要事先进行 EIP-712 签名——钱包只需签署独立的 USDC 转移授权，仅此而已。
带付款请求头重放请求。 智能体重新发送原始请求，这次带上承载已签授权的 X-PAYMENT 请求头。
验证、结算、注册。 Namefi 验证签名，启动域名注册工作流并结算付款——USDC 从买方钱包中转出，注册过程则与 API 密钥路径相同；其中包括默认将域名以 NFT——即代币化域名——注册到同一个付款钱包。

这个序列的任何部分都不要求智能体已创建 Namefi 账户、存储一项 Namefi 可在无需再次询问时复用的凭据，或在准确付款时刻到来前放弃资金的控制权。该签名只证明钱包在受限的时间窗口内授权了这一笔指定金额的 USDC 转账。

MPP 质询—响应变体

x402 是主要路径，但对于采用不同付款模式的钱包或智能体框架，Namefi 还记录了第二条路径：Machine Payable Protocol（MPP）。从结构上说，它是 x402 的镜像——用质询—响应取代直接返回 402：

对受保护端点的第一次请求同样返回 402 Payment Required，但这一次携带的是已签名的质询，而非普通价格报价。
客户端（通常通过专为处理签名步骤而构建的 Namefi 命令行工具 mppx）使用付款钱包签署该质询。
客户端将原始请求重放，并在 Authorization 请求头中附上生成的签名。

最终效果与 x402 相同——按请求、由钱包签名的付款，没有已存凭据——但它采用的是已签名质询握手，而不是在 402 中直接返回价格。智能体选择哪一种，取决于它现有的付款工具支持什么；Namefi 的端点两者都支持。

手动 EIP-712 路径

对于既不使用前两种快捷方式的钱包或脚本，Namefi 提供了一条基于 EIP-712 类型化数据签名的、更底层且完全手动的签名路径；EIP-3009 本身也建立在同一标准之上。以此方式签署的请求带有三个请求头：x-namefi-signer（签名钱包地址）、x-namefi-signature（十六进制编码的签名）和 x-namefi-eip712-type（签名依据的类型化数据模式）；其载荷则封装在一个包含 payloadType、payload 本身、timestamp 和 nonce 的信封中。

在这条手动路径中，有两个安全细节至关重要：签名会在 300 秒后过期，且 nonce 只能使用一次。 一旦 300 秒过去，或使用该 nonce 的请求已被接受，截获的签名便无法再次成功重放。Namefi 的文档还规定，线上 EIP-712 类型定义必须在请求时从其 /v-next/eip712/ 端点获取，而非由集成方硬编码，因为签名必须匹配的确切模式可能会变化。

Namefi 还记录了以这种方式为智能合约钱包签名的做法：获批准的外部拥有账户（EOA）可以依据 ERC-1271 或较新的 EIP-7702，代表合约钱包签名，前提是该合约实现了 API 能够验证的 approvedSigners(address) 检查。

安全模型：智能体能做什么，不能做什么

值得精确说明该签名机制实际限制了什么，而不是将它描述成比机制本身更强的保障。

它确实限制的内容。 每条路径都要求钱包针对当前请求签名，而不是向 Namefi 交出持续有效的凭据。各协议的防重放机制不同：手动 EIP-712 路径的签名在 300 秒后过期，并消耗一个一次性 nonce；x402 使用 EIP-3009 授权，该授权绑定特定金额与收款方，由 validAfter/validBefore 限定有效时间，并受 nonce 保护；MPP 客户端签署服务器发出的质询，因此其过期和防重放条件以该质询中的规定为准。钱包从不会授予 Namefi 自行发起未来扣款的持续授权。与已存卡相比：一旦商户拥有你的卡令牌，令牌本身并不限制它下个月可扣多少，或受损系统会否重复使用它。在这些流程中，钱包的私钥都不会离开钱包——智能体要求钱包为一个特定请求生成签名，这就是全部发生的授权范围。

它自身并不限制的内容。 Namefi 的文档并未说明协议本身会强制执行内置的单笔美元支出上限——各协议特定的过期和防重放机制限制的是授权可在何时、以何种方式被重复使用，而不是单个已签请求能够授权多少金额。实际上，智能体的支出纪律来自该机制之外：你为钱包注入多少 USDC，以及你放在智能体与钱包私钥之间的任何策略层——例如需要第二次批准的多重签名钱包，或允许智能体签名之前的人类确认步骤。什么是智能体原生域名注册商？和如何在 Namefi 上通过 AI 智能体注册域名也从护栏的角度说明了这一点：只为钱包注入你可以接受由无人看管流程花掉的金额，并预先决定何处需要人工批准。

这种组合——没有持续凭据、每笔交易均有边界的授权，以及以资金规模作为实际支出上限——形成的风险形态与已存卡确实不同，而不只是同一种机制的“加密版本”。泄露的卡号或受损的计费令牌可以被反复扣款，直至有人发现并取消。截获的付款授权会在触发其所属协议的过期或防重放条件时被拒绝：手动 EIP-712 路径会在 300 秒后或 nonce 已被消耗后拒绝它；x402 的 EIP-3009 授权会在 validAfter/validBefore 时间窗口之外或 nonce 已被使用后被拒绝；MPP 凭据则遵循其已签名质询中规定的过期和防重放条件。

何时应改用 API 密钥或 NFSC 计费

当购买前完全不应存在账户正是你的目的时，钱包签名路径就是合适的工具：完全自主的脚本、代表他人操作但不共享登录凭据的智能体，或希望将加密原生钱包作为唯一身份的人。它并不会自动适合所有情况。

正如如何在 Namefi 上通过 AI 智能体注册域名所详述的，针对已充值 NFSC 余额的 API 密钥计费在以下情况下更合理：智能体会反复注册域名，持续、可核对的余额优于每次都签署新付款；运营者想在一个仪表板中查看支出，而不是从链上转账中重建记录；或客户端已有安全存放请求头值的简洁方式，却不容易持有和使用私钥签名。两条路径在付款结算后都会通向相同的注册和 DNS 操作——选择的差异在于授权如何完成，而不是之后能注册或管理什么。

常见问题

使用加密钱包付款时，我需要 Namefi 账户吗？

不需要。x402 和 MPP 流程均可通过钱包签名付款结算域名注册，无需 Namefi 账户，也不必预先创建 API 密钥。只有采用 NFSC 余额计费路径时才需要 API 密钥。

Namefi 接受哪种加密货币用于钱包结账？

USDC。Namefi 的 x402 端点专门以 USDC 报价和结算付款，避免了像 ETH 这样的波动资产在报价与付款结算之间可能带来的价格波动。

签署钱包付款是否等于把我的私钥交给智能体？

不是——签名由钱包生成，私钥本身从不会暴露。智能体（或它调用的工具）要求钱包为一项特定且受限的授权签名；密钥始终留在钱包内部。

他人能否重复使用我此前生成的付款签名？

截获的签名在被自身的过期或防重放机制拒绝之前，仍可能有效；三条路径并不存在统一规则。手动 EIP-712 路径的签名会在 300 秒后过期，且每个 nonce 只能使用一次。x402 流程的 EIP-3009 授权仅在其 validAfter/validBefore 窗口内有效，其 nonce 也不能使用两次。MPP 使用已签名质询，因此必须查看该质询中的过期和防重放条件，不能假定它与另外两条路径相同。

以这种方式付款时，域名会自动代币化吗？

默认会。已注册的域名会作为 NFT 铸造到付款的同一钱包中；除非指定不同的接收钱包，这与 API 密钥路径采用的代币化行为相同。有关它与完全不提供钱包原生结账或代币化所有权的注册商有何不同，请参阅Cloudflare、Name.com 与 Namefi：智能体原生注册商。

钱包结账是否比使用已存信用卡更安全？

它限制的是另一组风险，并非完全消除风险。不存在可被受损系统无限复用的持续凭据，而且每笔付款都需要针对当前请求生成新签名。各路径的防重放机制不同：手动 EIP-712 使用 300 秒有效期和一次性 nonce；x402 的 EIP-3009 授权使用 validAfter/validBefore 和 nonce；MPP 遵循其已签名质询中的条件。这些机制都不限制单个已签请求可授权的金额，因此智能体实际能花多少，仍取决于你为钱包注入的资金，以及你在其前设置的额外批准策略（例如多重签名）。

在 Namefi 使用钱包购买域名

若使用智能体的目的，就是不让人工账户介入智能体与购买之间，Namefi 的钱包签名结账正是为此而设：真正的 ICANN 认证域名注册，通过一次签署的 USDC 授权付款，并将代币化所有权交付到付款的同一钱包。可在 namefi.io/web3/llms.txt 查看完整机制，或从更广泛的设置指南如何在 Namefi 上通过 AI 智能体注册域名开始。

在 Namefi 搜索并注册域名。

来源与延伸阅读

Namefi — namefi.io/web3/llms.txt（x402 流程、MPP 质询—响应变体、手动 EIP-712 签名路径、签名过期/nonce 规则以及 ERC-1271/EIP-7702 智能合约钱包签名的一手来源）
Namefi — namefi.io/llms.txt（NFSC/API 密钥计费路径，以及指向上述钱包付款参考资料的链接）
x402.org — x402：互联网原生付款标准（Namefi 流程所实现的、基于开放 HTTP 402 的付款协议）
Ethereum — EIP-3009：授权转账（transferWithAuthorization 步骤背后的签名标准；validAfter/validBefore 时间限制与单次使用的随机 nonce）
Ethereum — EIP-721：非同质化代币标准（代币化域名所有权所建立的 NFT 标准）
Namefi — 如何在 Namefi 上通过 AI 智能体注册域名（API 密钥/NFSC 计费路径与更广泛的护栏指南）
Namefi — Cloudflare、Name.com 与 Namefi：智能体原生注册商（钱包原生结账在三家面向智能体的注册商之间的比较）