https://mi-hashport-frontend.vercel.app/
Chat. Build. Pay. On Stellar — the web companion for the WhatsApp-native MiHashport wallet.
MiHashport lets people send, receive, swap, and deploy contracts on Stellar, entirely inside WhatsApp. The project is split across three repositories:
- Frontend (this repo) — the web dashboard companion to the WhatsApp bot
- MiHashport-Backend — the API and WhatsApp integration
- MiHashport-Contract — the Soroban smart contracts
Most people who want to use Stellar have to leave the conversation they're already in — install a wallet app, manage a seed phrase, learn a new UI — before they can send a payment or interact with a contract. MiHashport removes that step: the entire experience (sending funds, swapping assets, deploying and calling Soroban contracts) happens inside WhatsApp, the app billions of people already have open.
WhatsApp is great for conversation, but not for everything — reviewing a long transaction history, inspecting a deployed contract's methods, or linking a wallet for the first time all work better on a screen with more room. This repo is that surface: a Next.js web app that talks to the MiHashport backend to let a linked user view balances and transaction history, review and interact with contracts deployed on their behalf, and give the project a public-facing landing page. See docs/PLAN.md for how these features are being built out phase by phase.
MiHashport is trying to make Stellar usable for people who will never touch a block explorer or manage their own keys. That's a UX problem as much as a technical one, and it benefits from more eyes: more device/browser combinations tested, more accessibility feedback, more scrutiny on how a non-custodial-feeling flow is built on top of a backend-managed wallet. Open development also means the sibling backend and contract repos can be verified against a real, inspectable client instead of a black box.
This repo is a concrete, public example of a non-crypto-native product
built on Soroban — one where users never see "Soroban" or "Stellar" in the
main flow, and the contract layer is exercised through a normal web UI (form
generation from a contract's spec, simulate-vs-invoke distinctions, error
enums mapped to human-readable messages). That's a pattern other builders
targeting mainstream, non-crypto-native users can copy directly. Every
merged phase in docs/PLAN.md also doubles as documentation of what it
actually takes to wire a web frontend to Soroban contracts end-to-end,
which lowers the bar for new Soroban developers coming from a typical web
background.
- Next.js (App Router, TypeScript)
- Tailwind CSS
- ESLint (
eslint-config-next) - Node.js (version pinned in
.nvmrc)
- Node.js version matching
.nvmrc(usenvm use) - npm
npm installcp .env.example .env.localSee .env.example for the variables this app reads
(backend API base URL, target Stellar network, contract ID).
npm run devOpen http://localhost:3000.
npm run buildnpm run lintsrc/
app/ # Next.js App Router routes
components/
ui/ # Reusable, generic UI primitives
features/ # Feature-specific components
lib/ # Shared utilities, API client
hooks/ # Shared React hooks
types/ # Shared TypeScript types
config/ # Typed env/config access
docs/
PLAN.md # 6-phase implementation plan
- docs/PLAN.md — implementation plan and phase breakdown
- docs/RELEASES.md — release status and criteria for first tag
- CONTRIBUTING.md — how to find work and submit changes
- CHANGELOG.md — record of notable changes and releases
- SECURITY.md — security policy and reporting guidelines
- CODE_OF_CONDUCT.md — community standards for this repository
- AGENTS.md — rules for AI coding agents contributing here
If you have questions, run into issues, or want to suggest improvements, please open an issue or start a discussion on our GitHub Issues.
MIT — see LICENSE.