First real EntPay purchase: an AI-generated photograph for 0.001 ENT
This was not an API mock or a prepared demo. On August 6, 2026, I used the local EntPay Agent as an ordinary user to make a real purchase from an independent merchant: I paid 0.00100000 ENT for a photograph generated from my prompt, waited for an on-chain confirmation, and automatically received a verified JPEG file.
The requested image was:
A golden-shaded kitten and a black cat play-fighting with each other.
Here is the complete flow, in the same order in which it appeared during the purchase.
1. The Agent asks for approval before spending
The merchant first returned a signed invoice. After verifying it, the EntPay Agent displayed an approval page with the product, prompt, price, merchant address, expiry time, and required confirmations.
The payment boundary was explicit:
- Price:
0.00100000 ENT - Local per-payment hard limit:
0.01000000 ENT - Merchant:
ent1352aef5949f66d967e10608919869d42ed7ce1cc52417b42 - Required chain confirmation:
1 confirmation - I could still reject the request; payment began only after I clicked Confirm payment
The Agent may discover a service, understand its quote, and prepare a transaction, but it cannot silently bypass the user's local spending policy and approval.
2. Local signing, broadcast, and confirmation
After approval, my local wallet signed and broadcast the transaction to Entcoin mainnet. The UI immediately changed to a pending view and displayed the transaction ID instead of leaving the user with an unexplained JSON response.
Transaction:
f40cf1b36d4d78e586e7bab35c71080ffc6db1352f5a5e4fb65bf0cdf83fee9b
The merchant does not fulfill an order merely because a client claims to have paid. It checks the Entcoin network for the transaction, verifies that the exact output address and amount match the invoice, and waits for the required confirmation. This prevents fabricated transaction IDs, incorrect payment amounts, and reuse of one payment across multiple invoices.
3. Merchant generation and Agent-side delivery verification
Only after payment confirmation did the merchant invoke its image model. The delivery returned a merchant-signed Receipt, delivery metadata, and an artifact hash. The Agent checked these against the original invoice, transaction, and downloaded bytes before saving the file to the user-selected local directory.
Public verification data for this delivery:
- Invoice ID:
061e042f191de602f4ecb0261e251484 - Transaction ID:
f40cf1b36d4d78e586e7bab35c71080ffc6db1352f5a5e4fb65bf0cdf83fee9b - Amount:
0.00100000 ENT - File: JPEG,
1402 x 1122,158493 bytes - File SHA-256:
66150d33df60aaf75230ee590ee1de281c49439cef6412646185717f1877c8d9 - Local destination:
~/Downloads/EntPay/generated-photo-061e042f191de602f4ecb0261e251484.jpg
I also compared the locally received JPEG against the merchant's stored fulfillment artifact. Their dimensions, byte counts, and SHA-256 hashes are identical.
4. The delivered result
From approval to verified delivery, the user did not have to copy a merchant address, manually enter an amount, paste a transaction ID back into a website, or decide whether the downloaded bytes had been replaced. Payment and digital delivery became one verifiable workflow.
Who does what?
User: states the request, reviews the product, amount, and merchant, approves or rejects payment locally, and receives the artifact.
Local EntPay Agent: discovers merchant services, requests and verifies the signed invoice, enforces local spending limits, asks for approval, invokes the local wallet, tracks the state, and verifies the Receipt and artifact hash.
Independent merchant service: publishes its product descriptor and price, signs a single-use invoice, verifies payment on-chain, invokes its own image model, signs the Receipt, and delivers the artifact. Its model API key and merchant signing key remain in the merchant's server environment.
Entcoin network: provides payment facts and confirmation state independently of the merchant's database. The wallet seed and payment private key remain on the user's machine and are never disclosed to the merchant.
Each merchant deploys and owns its own product; it is not a plugin hosted by Entcoin. EntPay provides an open payment and delivery protocol, an Agent client, and a reference implementation. A merchant can run image generation, data retrieval, API access, compute jobs, or another digital service on its own machine or server, publish a price, and make it discoverable and purchasable by Agents.
What this proves, and what it does not
This purchase demonstrates a real end-to-end path: signed quote -> user approval -> local wallet payment -> exact on-chain verification -> merchant fulfillment -> signed receipt -> artifact hash verification.
A Receipt is the merchant's cryptographically signed delivery statement. It does not mean that the entire JPEG is stored on-chain, nor does it guarantee that every person will like the model output. The chain proves payment; the merchant signature and SHA-256 make the delivered content verifiable. Each layer has a clear responsibility.
To run it yourself or integrate a merchant product:
- Entcoin v1.5.1: https://github.com/HONG-LOU/entcoin/releases/tag/v1.5.1
- EntPay overview: https://entcoin.xyz/entpay/
- Merchant deployment and full protocol guide: https://community.entcoin.xyz/t/7
第一次真实使用 EntPay：0.001 ENT 购买一张 AI 生成照片
这不是接口模拟，也不是预先准备好的演示数据。2026 年 8 月 6 日，我以普通用户身份在本机 EntPay Agent 中完成了一次真实购买：向独立商家购买一张按提示词生成的照片，支付 0.00100000 ENT，等待链上确认，然后自动收到并验证 JPEG 文件。
购买内容是：
一只金渐层小猫和一只黑色玄猫在打架闹着玩
下面按我实际看到的页面，完整说明这笔 Agent Payment 是怎么发生的。
1. Agent 先让我确认，不会直接花钱
商家先返回一张签名发票。EntPay Agent 校验发票后展示付款确认页，明确列出商品、提示词、金额、商家地址、发票有效期和所需确认数。
这一步最重要的不是“有一个按钮”，而是付款边界清楚：
- 本次价格：
0.00100000 ENT - 本地单笔硬上限：
0.01000000 ENT - 商家：
ent1352aef5949f66d967e10608919869d42ed7ce1cc52417b42 - 链上确认要求：
1 confirmation - 支付前仍可拒绝；只有点击 Confirm payment 才会继续
也就是说，Agent 可以发现服务、理解报价和准备交易，但不能悄悄越过用户设置的本地限额与人工确认。
2. 本机签名并广播，等待链上确认
我确认后，交易由本机钱包签名并广播到 Entcoin 主网。页面立即进入等待状态，并显示交易 ID，而不是让用户面对一段无法理解的 JSON。
本次交易：
f40cf1b36d4d78e586e7bab35c71080ffc6db1352f5a5e4fb65bf0cdf83fee9b
此时商家不会仅凭“客户端说已经付款”就交付。商家会从 Entcoin 网络核验交易是否存在、付款 output 的地址和金额是否与发票完全一致，并等待发票要求的确认数。这样可以防止伪造 txid、错付金额和把同一笔交易重复用于多张发票。
3. 商家生成照片，Agent 验证收据和文件
确认到账后，商家才调用图片模型生成照片。交付返回给 Agent 时包含商家签名的 Receipt、交付信息和文件哈希。Agent 会验证它们与原始发票、交易和实际下载文件一致，然后把文件保存到用户选择的本地目录。
这次交付的公开核验信息：
- Invoice ID：
061e042f191de602f4ecb0261e251484 - Transaction ID：
f40cf1b36d4d78e586e7bab35c71080ffc6db1352f5a5e4fb65bf0cdf83fee9b - 金额：
0.00100000 ENT - 文件：JPEG，
1402 x 1122，158493 bytes - 文件 SHA-256：
66150d33df60aaf75230ee590ee1de281c49439cef6412646185717f1877c8d9 - 本地保存位置：
~/Downloads/EntPay/generated-photo-061e042f191de602f4ecb0261e251484.jpg
我又把本机收到的 JPEG 与商家服务器保存的履约 artifact 做了独立哈希比对：尺寸、字节数和 SHA-256 全部一致。
4. 实际收到的结果
从点击确认到拿到可验证文件，用户不需要复制商家地址、不需要手填金额、不需要把 txid 粘贴回网站，也不需要自己判断下载内容是否被替换。支付和数字交付被串成了一个可核验流程。
谁在做什么？
用户：提出需求，检查商品、金额与商家，在本地批准或拒绝付款，最后获得文件。
本机 EntPay Agent：发现商家服务、请求并验证签名发票、执行本地限额策略、请求用户确认、调用本机钱包付款、跟踪状态、验证 Receipt 和文件哈希。
独立商家服务：发布产品描述与价格、签发一次性发票、核验链上付款、调用自己的图片模型、签署 Receipt 并交付文件。模型 API key 和商家签名私钥只存在于商家的服务器环境中。
Entcoin 网络：提供无需依赖商家数据库的付款事实和确认状态。钱包 seed 与支付私钥始终留在用户本机，不会交给商家。
商家部署的是自己的产品，不是 Entcoin 官方托管的插件。EntPay 提供的是开放支付与交付协议、Agent 客户端和参考实现；任何商家都可以在自己的本地机器或服务器部署图像生成、数据查询、API 调用、算力任务等服务，定价后让 Agent 发现和购买。
这证明了什么，也没有证明什么？
这次记录证明了一条真实链路可以工作：签名报价 -> 用户确认 -> 本地钱包付款 -> 链上精确核验 -> 商家履约 -> 签名收据 -> 文件哈希验证。
Receipt 是商家对交付的加密签名声明，不等于由区块链保存整个 JPEG，也不代表模型输出一定符合每个人的审美。链上负责证明付款，商家签名和 SHA-256 负责让交付内容可核对；二者各自承担清楚的职责。
想亲自运行或为自己的产品接入：
- Entcoin v1.5.1：https://github.com/HONG-LOU/entcoin/releases/tag/v1.5.1
- EntPay 页面：https://entcoin.xyz/entpay/
- 商家部署与完整协议教程：https://community.entcoin.xyz/t/7