Axiochat-Mnee

AI agent with built-in MNEE wallet enables natural language payments. No hex addresses, no app switching. "Send 5 MNEE" → transaction. Agentic Commerce.

Comment

AxiosChat — Agentic Wallet for MNEE (Pay-with-Agent)

One-line pitch Transforming chat into commerce: a conversation-first agent that holds an MNEE wallet, composes transactions in natural language, and executes micro-payments with user approval.

Inspiration

  • Problem: Crypto interactions are fragmented, slow, and force users to leave a conversation to send money, split bills, or tip. Traditional wallets are not conversational.
  • Idea: Give an LLM-powered chat agent a secure, segregated wallet it can operate on behalf of the user — enabling "text-to-pay" inside the chat flow while preserving user control and security.
  • This project came from the desire to remove friction (copy/paste, address-lookup, app switching) and to demonstrate expressive agentic commerce on the MNEE blockchain.

What it does

  • Natural-language transfers: Turn messages like "Send 5 MNEE to @Alice for coffee" into prepared transactions the user can review and approve.
  • Smart tipping & micro-payments: Tip article authors, stream micropayments, or pay for content directly from chat context (resolves addresses from page metadata).
  • Agent sub-account & UTXO tracking: Derives an Agent sub-account (segregated from your main seed) and continuously monitors balances/UTXOs, alerting when thresholds are hit.
  • Transaction construction & preview: Create raw, unsigned transactions (broadcast: false), decode them for human-readable review, request signature, then broadcast on approval.
  • Multi-party flows: Split-the-bill workflows using the UTXO model and transferMulti orchestration for complex payments.
  • Mobile-first, responsive UI: Works equally well on desktop and mobile, preserving conversation continuity.

Why it’s impressive

  • Moves beyond talking about crypto — the agent actually prepares and executes transactions while keeping the user in complete control.
  • Demonstrates deep integration with MNEE SDK features: HD wallet derivation, transaction construction without immediate broadcast, and multi-party UTXO orchestration.
  • Solves a real UX friction for payments in chat: speed, privacy, and UX cohesion.

How I built it High-level architecture

  • Frontend: React + TypeScript chat UI (chat component supports LLM function-calls), responsive design for mobile and desktop.
  • Backend: Node/TypeScript API endpoints (includes a secure LLM proxy for model calls and the Gemini/OpenAI/GPT proxy layer).
  • Blockchain integration: @mnee/ts-sdk for wallet derivation, getUtxos, balance, transfer, transferMulti, and submitRawTx.
  • LLM integration: LLM responses include structured function calls (e.g., prepare_transfer) that the app converts into prepared transactions.
  • Security: Seed and sensitive secrets are stored only in user-controlled environment or encrypted storage; agent sub-account derivation keeps funds segregated.

Key pieces (example)

  • Agent sub-account derivation (from proposal):
// derive an agent sub-account
const agentWallet = hdWallet.deriveAddress(100, false); // Path m/44'/236'/0'/0/100
  • Typical flow:
    1. User types a payment instruction in chat.
    2. LLM returns a function-call with structured params (recipient, amount, memo).
    3. Backend calls MNEE SDK: mnee.transfer({ to, amount, broadcast: false }) to create rawtx.
    4. Frontend presents decoded transaction to user for confirmation.
    5. On approval, call mnee.submitRawTx to broadcast.
    6. UI updates balance and transaction history.

Tech stack

  • TypeScript, React (chat UI), Node.js backend (TypeScript)
  • @mnee/ts-sdk (wallet + UTXO + tx functions)
  • Axios for API calls
  • LLM provider via a secure proxy (Gemini / model-of-choice)
  • Tooling: pnpm (for scripts), ESLint/Prettier, unit tests for core logic

Challenges we ran into

  • Key management / UX tradeoffs
    • Problem: Letting an agent "hold" funds requires strict UX and security to avoid accidental spends.
    • Solution: Agent sub-account derived from user seed + explicit review/sign steps for any outgoing tx; no auto-broadcast without user confirmation.
  • UTXO complexity & fee estimation
    • Problem: UTXO models require careful coin selection and merging; naive implementations can create large fees or fragmentation.
    • Solution: Implemented controlled coin-selection heuristics and preview tools that show fee/cost tradeoffs before confirmation.
  • LLM-to-action correctness
    • Problem: Ensuring the LLM reliably produces structured function calls and avoids hallucinating addresses or amounts.
    • Solution: Use strict JSON Schema / function-call signatures, validate addresses with validateMneeTx, and require explicit confirmation on ambiguous cases.
  • Network & edge cases
    • Problem: Handling split payments or partial broadcast failures concurrently.
    • Solution: Implement robust error handling and transaction rollbacks/logging; persist prepared transactions until user signs or cancels.

Accomplishments we’re proud of

  • Full “text-to-pay” flow working end-to-end on MNEE: derivation -> prepared raw tx -> user preview -> signed broadcast.
  • Agentic account that’s segregated from the main wallet, enabling safe agent operations with a defined budget.
  • Implemented a decoded transaction preview UI that explains UTXO inputs/outputs in human terms so non-technical users can approve payments confidently.
  • Demonstrated multi-party split-the-bill orchestration leveraging MNEE’s UTXO model.
  • Mobile-first UI and accessible controls for approval and history.

What we learned

  • UTXO-based UX design is different from account models — it's powerful for multi-party transactions but requires transparent coin-selection UX.
  • LLM function-calling is a safe and practical approach when combined with strict validation layers; never let the model be the final authority on payment execution.
  • Security-first product design: segregation, explicit approvals, and minimal exposure of seeds is vital when giving an agent the ability to act financially.
  • Building agentic features benefits from small, auditable steps (prepare -> preview -> sign -> broadcast).

User & developer experience notes

  • For users: payments are conversational, fast, and require one confirmation step.
  • For developers: Chat.tsx and the function-calling flow are designed to be extensible — add new agent actions (e.g., subscribe, stake, swap) by declaring function schemas.

What’s next for AxiosChat–MNEE Short-term

  • Add multisig support for higher-value agent actions (require 2-of-3 signatures for certain thresholds).
  • Build richer on-chain receipts and transaction metadata to link chat context with on-chain evidence.
  • Add fiat-rail integrations for instant on/off ramps (via third-party services).

Mid-term

  • Open-source developer SDK: Example integrations, UI components for decoded tx preview, and coin-selection helpers.
  • Marketplace integrations: Let content creators add tipping buttons or paywalled content that integrate directly with AxiosChat Agent.
  • Advanced policy & budget controls: Per-agent budgets, time-limited allowances, and spend categories.

Long-term vision

  • Agentic commerce where agents can autonomously manage small budgets to perform recurring tasks (like paying subscription renewals), always transparently requesting confirmation for new or large spend categories.

How to run / demo (developer instructions)

  • Clone repo: git clone https://github.com/OkeyAmy/Axioschat-MNEE.git
  • Install: pnpm install
  • Configure env (example):
    • MNEE_SEED or secure keystore
    • LLM_PROXY_KEY (Gemini / OpenAI) — configure proxy in api/gemini-proxy.ts
    • API_URL for backend
  • Start frontend: pnpm dev (or pnpm start) — open on mobile/desktop to test responsive behavior
  • Run backend: pnpm --filter backend dev (if monorepo) or pnpm start in server/

Security & privacy notes

  • Never store raw seed in remote servers; prefer local encrypted keystore or user-managed environment.
  • All transaction broadcasts require explicit user confirmation in the current UI.
  • Audit logs and transaction history are kept for user visibility and troubleshooting.

Metrics & validation

  • Latency: prepared tx construction typically sub-second; broadcast depends on MNEE propagation (very low fees & fast confirmations make UX fluid).
  • Safety: zero funds were broadcast without explicit approval in tests and manual QA.

Team

  • Solo — full-stack dev, MNEE integration, UI/UX, LLM orchestration.

Why this matters now

  • Micro-payments and content monetization are ripe for innovation. A text-first payments UX lowers friction and makes on-chain commerce approachable.
  • MNEE’s speed & low fees are perfect for micro-transactions; this demo shows a real, practical consumer UX for agentic payments.

Appendix / tech highlights (copy into the Devpost extra details)

  • Core MNEE SDK calls used: HDWallet.deriveAddress, mnee.getUtxos, mnee.balance, mnee.transfer({broadcast:false}), mnee.transferMulti, mnee.submitRawTx, validateMneeTx
  • LLM function-calling: chat UI triggers prepare_transfer which maps into MNEE transaction creation
  • Code reference: see MNEE_Feature_Proposal.md for initial design and technical rationale

Call to action for judges

  • Try the flow: send a 1 MNEE tip to an address, watch the agent prepare the transaction, review the readable decoded tx, and approve it — you’ll see how fluid agentic payments can be.
  • Evaluate on innovation: agent-based finances inside chat are a new UX category and directly reduce friction for on-chain payments.

Challenges we ran into

  • Proxy errors & model quota spikes: In production testing we sometimes see proxy/timeouts when calling the MNEE SDK (especially under load) and the AI occasionally exhausts my Gemini quota. The worst cases happen when the agent triggers parallel function-calls (e.g.,balance_checking + address-resolve + transfer preparation) which multiply requests and quickly consume quota. We mitigated this with rate-limiting but still experience occasional spikes. Short-term workarounds include queuing/deduping function calls, batching related calls, applying exponential backoff and circuit-breaker logic, caching resolved addresses, and surfacing a friendly “quota exceeded — please wait a moment” message to users. Long-term fixes are: move heavy validation to lightweight local checks, consolidate RPC calls server-side, and implement strict per-action concurrency limits and quota-aware fallbacks (e.g., offload to a lower-cost model or delayed task queue).

Built With

Share this project:

Updates