What is LOOMON
LOOMON is an agent-powered custom souvenir marketplace for Vietnamese ceramic craft. The demo connects a familiar shopping flow with wallet sign-in, AI-assisted customization, Arc escrow, seller operations, order chat, and non-transferable delivery proof.
Why it matters
The data bottleneck in custom craft commerce
Custom souvenir orders usually live across product cards, DMs, payment links, vague reference images, and manual status updates. That is fragile for both sides: the buyer is not sure what the seller saw, and the seller has to reconstruct the brief from scattered messages.
LOOMON turns the custom order into structured data: product, quantity, needed-by date, buyer note, uploaded artwork, selected render, escrow state, timeline, and conversation history. The agent can help explain and draft, while final payment, message, and production actions remain user-controlled.
Contributor guide
Demo path
https://loomon.vercel.app/app- Open the app and browse the catalog.
- Customize a product with text or uploaded artwork.
- Place an Arc testnet order.
- Open the seller workspace and accept only the selected incoming order.
- Use the green dock chat button for buyer-seller messages.
- Complete delivery and mint the proof NFT.
Checkpoint scope
What is implemented in this build
Public catalog with Vietnamese ceramic demo products and one controlled seller workspace.
Product customization brief with text, quantity, due date, uploaded artwork, and generated/selected preview assets.
Arc Testnet prepaid order flow, onchain seller acceptance, delivery marking, buyer completion, refund paths, and server projection.
Buyer and seller order centers with scoped row actions, private brief assets, status history, and proof surfaces.
Dock-based buyer/seller chat and Personal Agent chat kept as separate conversation types.
Product
Buyer flow
Browse Vietnamese ceramic products in a visual feed.
Open a product and start a custom brief.
Add quantity, notes, artwork, text, and optional needed-by date.
Generate AI previews or send a standard reference-only brief.
Pay through the Arc escrow flow and track the order in Buying.
Confirm completion and receive the proof NFT after delivery.
Operations
Seller flow
Review incoming paid orders with notes and uploaded/selected images.
Accept one order at a time or reject with refund.
Use the dock chat for buyer questions while the detail page stays focused on production.
Mark delivered, then claim after the completion and hold flow allows it.
Order chat
Messages live in the dock, not inside the production brief
The order detail page is for facts: notes, uploaded artwork, selected render, quantity, due date, escrow state, and timeline. The Chat button opens the green dock conversation for the buyer and seller. Messages and image attachments are persisted in Supabase and scoped to the order participants.
Agent
The green button is the control room
The agent reads page context, drafts messages, explains order status, guides wallet actions, and helps with product discovery. It is deliberately bounded: it does not silently sign, pay, accept orders, refund, deliver, or send buyer-seller messages without the user taking the final action.
Technology
Arc escrow lifecycle
Arc is the trust layer for the paid custom order. LOOMON verifies transaction receipts and contract events before projecting order state into Supabase. The database is the application read model; the payment milestone is accepted only after the expected Arc event is observed.
Arc Testnet chainId: 5042002Technology
Contract registry
These are public testnet addresses or configuration keys used by the demo. Private keys, service-role keys, and minter keys are never committed and must stay in Vercel or local environment variables.
Active Arc Testnet escrow pool
0x95d242919da239859ca7ab8eddc77ae5b4f450dbNative Arc USDC payment, seller acceptance, delivery, buyer completion, refund, dispute, and delayed seller claim.
Seller request decision registry
0x0af0d368ed7a742f623103FDf9e43a193f330380Records the single demo seller's accept/reject decision before server projection updates the request/order state.
Non-transferable order proof
Configured by LOOMON_ORDER_PROOF_ADDRESSMints one proof per completed order hash. It is a demo receipt and does not certify physical authenticity or investment value.
Payment asset
0x3600000000000000000000000000000000000000Used on Arc Testnet. App amounts are tracked as 6-decimal USDC atomic units and converted for native transfer semantics.
Technology
Server API surface
Public browser clients do not receive service-role access. Sensitive endpoints validate wallet session, order ownership, expected participant role, transaction sender, target contract, event name, and onchain order id before returning private data or changing state.
- POST /api/auth/wallet/challenge
- POST /api/checkout/confirm
- POST /api/orders/{orderId}/escrow/confirm
- GET/POST /api/orders/{orderId}/messages
- GET /api/orders/{orderId}/messages/stream
- GET /api/orders/{orderId}/brief-assets
- POST /api/orders/{orderId}/proof
Technology
Supabase data foundation
Supabase stores the app's read model and collaboration state: catalog, profiles, quote requests, order briefs, escrow projections, proof records, messaging, and signed asset references. Contract state is never inferred from client input alone; server routes verify Arc receipts before writing lifecycle projections.
Products, custom briefs, orders, inventory state, status history, and proof records.
Buyer-seller order chats and personal agent conversations are stored separately.
Arc transaction hashes, escrow instances, lifecycle projections, and proof mint attempts.
Server-only keys stay off the client; private order assets use signed access.
Security
Trust boundaries
Wallet sign-in maps an address to a Supabase identity. Server routes verify wallet/order access, private assets are signed per request, service-role keys stay server-side, and contract projections verify onchain events before changing order status. Buyer and seller access can also be derived from escrow participant addresses so older wallet-native orders remain visible even when the Supabase auth identity changes.