Moneta

The store's agent is paid to make you buy. Moneta is paid to save you money.

Moneta is an AI shopping agent. Point her at a product, tell her what you're willing to pay and by when. She finds every merchant selling it, works out the real cheapest trustworthy offer, watches continuously, and completes the purchase through Prava — on a one-time card locked to the exact merchant and amount, approved with your fingerprint.

Built for the Prava × OpenAI Agentic Commerce Hackathon.

Try it

Live: https://moneta-production-de8b.up.railway.app

email     kenny.m@audria.tech
password  moneta-demo-2026

Live demo: https://www.youtube.com/watch?v=BZnvu0vUFNg

Product demo: https://drive.google.com/file/d/1OcFZ9ggxivzWIWdHpxvfs_au6JGhixHM/view?usp=sharing

Hosted on Railway, so it stays up on its own. If it's briefly unreachable, the demo videos show every flow end to end.

The insight nobody else has

Every price comparison tool on the internet compares the wrong number.

Catalogs expose item price. Shipping only exists once you drive the merchant's real checkout. Those two numbers rank differently — and they routinely invert. Measured live on Prava's catalog, Aug 1 2026, same product, three sellers:

Seller	Item	Shipping	Delivered
glamourbeautycenter.com	$24.00	$6.00	$32.07 ← actually cheapest
forstylists.com	$17.97	$17.95	$35.92
imagebeauty.com	$29.95	$7.49	$37.44

On item price, forstylists.com looks 40% cheaper and wins by $11.98. On what you actually pay, it loses — and the real saving is $5.37. A tool that stops at item price is quoting a number nobody pays.

Moneta can do this because Prava lets her drive a real merchant checkout. So she ranks on delivered total. Keepa can't. Google Shopping can't.

Why this isn't a price alert

• She arbitrates across merchants. Verified live on Prava's catalog: the same Olaplex No.3 Plus listed at $29.95 in search sells for $17.97 at a seller search never surfaces — Moneta finds it by expanding every listing. Spreads of 67–280% on identical products are normal.
• Then she checks what it actually costs delivered, and re-ranks (above).
• She judges. Product matching across messy SEO-stuffed listings, junk- and dropship-seller detection, target-price sanity checks, and a suggested target — all OpenAI-driven, with deterministic fallbacks.
• She finishes the job. Alerts carry one tap into a real checkout: binding total (shipping + tax included), spending-limit guardrails, biometric approval via Prava, order placed. Most tools stop at "here's a link."
• She refuses. If the real total exceeds your limits, she stops and asks. The refusal is a feature, on screen.
• She can be trusted with a budget, not a blank cheque. A standing Prava mandate moves your passkey tap earlier: authorize a capped, merchant-locked amount once, and she completes a qualifying purchase without waking you — and cannot spend a cent outside it. Pause or revoke any time.

Architecture (one repo + one extension)

Chrome extension (MV3)  →  /arm handoff  →  Next.js dashboard + API routes
                                            ├─ MCP client → Prava (OAuth 2.1)
                                            ├─ OpenAI (match/trust/verdict/copy)
                                            ├─ SQLite (node:sqlite, zero setup)
                                            └─ tick loop + rules ladder + Telegram

• Prava MCP (mcp.pay.prava.space): shop_search → shop_product → shop_quote → create_payment_session → passkey → shop_checkout. Shopping is MCP-only, so the backend runs its own authenticated MCP client.
• Purchases are a state machine (quoting → quoted → session_created → approved → ordering → done): every transition is persisted before the next external call — crash-safe, resumable, never double-charges.
• The alert ladder: target hit / stretch band / best-offer-lost / deadline — factual copy with provenance, never manufactured urgency. State-hash dedupe.

Run it

npm install
npm run auth        # one-time Prava OAuth (browser + passkey)
npm run dev         # dashboard on :3000

Optional (.env.example): OPENAI_API_KEY (smarter matching), TELEGRAM_BOT_TOKEN (phone alerts). Extension: chrome://extensions → Developer mode → Load unpacked → extension/.

Useful scripts: scripts/steel-thread.ts (full buy chain, checkout gated behind --buy), scripts/simulate-drop.ts (fire the ladder), scripts/seed-history.ts (labeled demo history).

Honest disclosures

What existed before the hackathon. Groundwork on this repo began Jul 23–28, before the Jul 31 build window: the arm pipeline, watch loop, rules ladder, purchase state machine, Chrome extension and product shell. All of it is in the commit history with its original dates. Devfolio's rules allow this explicitly — "existing work can be the starting point; it cannot be the entire submission."

What was built during the window (Aug 1–2). Each is a separate commit:

• Delivered-total ranking — the headline. lib/delivered.ts quotes the leading candidates through Prava and re-ranks on what you actually pay. This is the feature that found the inversion in the table above.
• Linq channel — alerts over iMessage/RCS/SMS from a real provisioned number, with an inbound webhook so a reply can navigate or mute. Replies deliberately cannot authorize spending (see below).
• Standing mandates — the autonomy layer. New mandates table, lib/mandates.ts, /api/mandates, profile UI, and a coverage check wired into the buy flow so a pre-authorized purchase can complete without a fresh tap. 15 new smoke tests.
• Sandbox mandate lifecycle (lib/prava-sandbox.ts) — Prava's REST surface has a sandbox and a hosted checkout but no shopping endpoints, the exact inverse of MCP. So the mandate lifecycle is proven end to end there with the issued test card: create → approve → charge → balance decrements. It runs on separate rails and can never authorize production spend — enforced by coverageFor() and asserted by smoke tests M12/M13.
• Buy flow repaired against Prava's current MCP schema. create_payment_session had drifted out of sync and could not have succeeded: merchant_country missing, wrong products shape, and — the substantive one — no checkout_session_id, which is what arms automatic order placement. Without it the call produces a bare payment link that takes money and never buys anything.
• AI layer upgraded: strict structured outputs, a matching fix that stops "No.3" and "No.3 PLUS" being armed as one watch, per-listing (not per-merchant) trust scoring, and cost guards.
• Model choice measured, not guessed — scripts/pick-model.ts benchmarks candidates against the live catalog.

Other disclosures:

• ⚠️ No order was completed. The demo deliberately stops at create_payment_session — the last step before any money moves. Everything shown is real: live catalog, real shop_quote totals with real shipping and tax, a real Prava payment session. But no purchase was made and nothing shipped, because Prava's MCP shopping path runs on live rails with no sandbox, and we chose not to spend real money on a demo. We are not claiming a completed checkout.
• ⚠️ The delivery address on file is a placeholder used to obtain realistic US shipping quotes. It is not a real recipient, and no order was ever placed against it.
• The Prava MCP path has no sandbox for shopping and no REST equivalent for the shop_* tools, so a "working sandbox flow" is not achievable for this integration path. Checkout is explicitly gated in every script and flow.
• A Linq reply can never authorize a payment. SMS/iMessage is a low-assurance channel (no passkey, spoofable sender), so inbound replies may navigate and mute only. Spending still requires the dashboard plus a passkey, or a standing mandate the user approved in advance.
• Demo price charts can include seeded history — always labeled in the UI (is_seed column); live observations accumulate from the moment a watch is armed.
• Provenance is the commit history. Judges: git log tells the whole story.