JPYC EC Agents

Demo

About

JPYC EC Agents lets people delegate shopping to AI through familiar chat apps, using their own funds and their own rules. Users keep their assets in their own wallet and retain control of its private key. They set allowed merchants, a per-purchase limit, a budget for a defined period, and an expiry date, then delegate purchasing authority to the AI. The AI handles orders within those conditions automatically and pauses when an order requires the owner's decision. The existing JPYC EC platform already supported x402 payments and purchases by AI. An earlier prototype required funding an AI-controlled wallet and managing its key and balance. For this hackathon, I added a way for users to set the scope of delegation on screen while keeping their assets in their own wallet, without transferring funds to a dedicated AI account or managing a separate AI key themselves. For example, a regular item may be out of stock, and a substitute found by the AI may exceed the remaining budget for the period. The AI cannot expand its own authority. It presents the order and the reason for exceeding the budget, asks the owner for explicit consent to that order, and requests fresh authentication through World ID for Agents. The server verifies a match with the registered owner, fresh authentication, and consent to the specific order before allowing that single purchase. If the owner declines or cancels, or the authentication expires, the exception order is not executed. Verifying the owner when their decision is needed makes everyday shopping easier to delegate while keeping decisions about exceptions with the owner. EIP-7702 enables delegated execution from the owner's wallet, and ERC-7715 is used to request permissions. A custom PurchaseGate checks normal purchase conditions and approval tied to a specific order; payment is executed through ERC-7710 and x402. The implementation also includes conversion from USDC to the JPYC needed for payment through Uniswap, plus risk screening with Intercepta before payment. Orders involving a merchant outside the approved list, a swap-price deviation, or a risk warning eligible for owner approval are referred back to the owner. If screening results cannot be obtained, the purchase stops. LINE has 100 million monthly active accounts in Japan, whose population is approximately 123 million. By starting with a familiar chat app, we bring delegated shopping closer to an everyday interaction. LINE is the primary experience, with a Telegram demo for judges. Sources: [Statistics Bureau of Japan population estimates](https://www.stat.go.jp/data/jinsui/) and [LINE's official service data](https://www.lycbiz.com/jp/service/line-official-account/). JPYC EC is a live e-commerce platform that accepts JPYC, a yen-denominated stablecoin. It has been publicly available for about six months since its March 2026 launch. As of September 26, cumulative activity, including usage before the public launch, totals 210 paid transactions worth 948,140 JPYC from 141 unique wallets. These figures describe the existing EC platform. Merchants already use it to sell products, receive payments, and manage orders. Connecting the new functionality to their products, inventory, and order management brings AI payments under the owner's control into real shopping workflows.

How it's made

I built the commerce platform with Next.js, TypeScript, and PostgreSQL, the purchase-control contracts in Solidity, and the signing and settlement services in Node.js. LINE provides an interface familiar to users in Japan, while Telegram lets judges try the experience on their own phones. The owner retains the private key that controls their assets. The AI's execution key is generated and stored encrypted in a separate signing service. Users do not have to manage a dedicated AI key themselves; the AI uses its delegated authority to sign authorizations for individual orders. One of the hardest parts was enforcing a normal budget while allowing only explicitly approved orders to exceed it. Permission redemption is restricted to PurchaseGate, which checks normal purchase conditions and exception approvals. The parent permission uses MaxUint256 as its amount limit, can only be redeemed by the Gate, and has an expiry. A separate owner signature registers a finite normal budget with the Gate. The initial setup screen explains that budget and exception enforcement depends on the Gate and the approval server. World ID for Agents verifies the owner immediately before a pending order is allowed to proceed. After recording explicit consent to the order, the system requests fresh authentication. The server checks the signature, issuer, audience, nonce, authentication freshness, and a match with the registered owner. It also rechecks the order, purchase policy, and risk assessment for changes before issuing an H signature bound to that order. World verification happens on the backend; the Gate validates the resulting backend signature, its match to the order, its expiry, and its single use. Declining, cancellation, expired authentication, or a different identity prevents the exception purchase. Revoked permissions and reused approvals are rejected. Uniswap v3 uses an exact-output swap to obtain the amount of JPYC required for the purchase. The implementation checks the maximum USDC input and swap-price deviation, and returns any unused USDC. Intercepta screening runs on the EC backend before payment. The original warning remains in the record even if the owner approves the purchase. Another challenge was that an onchain transfer and saving an EC order do not always succeed together. A transfer may succeed while its response is lost, or a database write may fail after payment. To handle these cases, the system persists the transaction before broadcasting it, follows that same transaction, and recovers the order. Retries avoid duplicate payments, and the merchant receives a single order. Regular purchases, owner-approved exceptions to the budget for a period, swaps, recovery from lost responses, and finalizing merchant orders have been tested on a local fork. Responses from World, risk screening, and other external services in those integration tests are fixtures. The World integration uses the event's development environment; its fake identities do not establish production identity assurance. The public chat demo is a simulation with no transfers or live World authentication. End-to-end verification on public Polygon Amoy testnet (chain ID 80002), including ERC-7715 on a physical device and an interactive World login through to a completed purchase, is still pending. I defined the requirements and chose the design. I used Codex for implementation, testing, research, and documentation.