Tapyra

Tap. Pay. Proven. — Self-custody crypto POS for everyday merchants.

Comment

Tapyra

What it does

Tapyra — Tap. Pay. Proven.

Inspiration

Crypto payments still feel like infrastructure: networks, addresses, confirmations, irreversible mistakes. Merchants do not need another wallet. They need a sale — catalog, cart, tax, receipt, reconciliation — that survives audit and closeout.

I asked a sharper question: Can a self-custody crypto currency transfer become a verifiable point-of-sale event without ever holding a key or customer funds?

That question became Tapyra: a smartphone POS for everyday merchants. The customer signs locally; funds move peer-to-peer to a merchant-controlled wallet; the platform independently proves network, asset, amount, and destination before any order can become paid.

The commercial thesis is U.S.-first: 36M+ small businesses, rising mobile in-person payments, and a clearer stablecoin policy landscape. Self-custody reduces custody risk; it does not remove the need for reconciliable evidence, compliance partners, and product honesty.

What it does

In the hackathon MVP:

  1. Merchant authenticates (email OTP), loads a USD catalog, builds a cart, and creates a server-owned order.
  2. The POS displays a QR with a short-lived opaque token only — no amount, wallet address, session JWT, or on-chain proof is encoded in the code
  3. Customer opens the payer page, reviews the server-resolved summary, and signs a direct USDC MsgSend on Noble Testnet (grand-1, uusdc) with Keplr. We use keplr wallet as the self-custody wallet is not fully ready for the MVP.
  4. A Cloudflare Worker verifies the chain evidence against two independent RPCs (chain ID, message type, destination, denom, exact amount, replay defenses, finality).
  5. On success, PostgreSQL atomically transitions the order and attaches an authenticated receipt. Cache, queues, and client optimism are never payment proof.

Tapyra never holds a private key or customer funds.

How is it built

We built Tapyra as a new product with Codex** and GPT-5.6 sol, terra et luna, under my developpement experience guidance.

invariants (non-negotiable) :

  • Self-custody only — no seeds, keys, or encrypted envelopes in Cloudflare, Supabase, Redis, logs, or client JS
  • Opaque QR capability; all money fields server-derived
  • Dual-RPC fail-closed finality before paid
  • PostgreSQL as authoritative ledger; integer minor units only (no floating point)
  • Deny-by-default authz and tenant isolation (RLS)

Codex / GPT-5.6 accelerated:

  • Architecture, threat model, and execution ledger (plan.md, agent protocol)
  • Edge API: Cloudflare Workers + Hono, Zod validation, JWT checks, idempotency, payment verification
  • Data plane: Supabase Auth, migrations, grants, RLS, pgTAP
  • Mobile POS: Expo SDK 57 (merchant flows + web payer)
  • Shared contracts, Vitest suites, and reproducible demo gates (scripts/demo-gate.mjs)
  • U.S. investor / GTM pack aligned to what is actually shipped — not aspirational NFC marketing

Stack: TypeScript · Expo / React Native · Cloudflare Workers · Hono · Supabase · PostgreSQL · Zod · Noble / Cosmos · Keplr / CosmJS · Vitest · pgTAP

Repo: https://github.com/tomdgImpact/Tapyra

What I learned

  • Scope is a security control. The original vision included native wallet, Face ID, NFC, multi-chain, and a future validator-terminal network. That surface could not prove the essential invariant in one week. We narrowed to one network, one asset, one signer (Keplr), one transport (QR), one POS loop — and deferred NFC/native signing behind explicit gates.
  • A sale is not a deposit. Reconciliation, receipts, and atomic state transitions matter as much as the signature UX.
  • Fail closed beats demo theater. Prefer pending/failed over a simulated paid when external dependencies degrade.
  • Codex multiplied delivery speed. Founders retained the non-delegable decisions: no custody of keys, no fake “paid” states, and no over-claiming compliance
  • Compliance is part of product design. Regulatory and tax design ships with the product, not as a retrofit once GMV arrives.

Challenges I faced

1. Trust without custody
Designing a POS that creates commercial value without ever being able to move funds. Solution: capability-based QR, server-owned payment intents, local Keplr signing, and independent chain verification.

2. Dual-RPC finality on testnet
Payment completion stays fail-closed while the second Noble RPC returns stale data (RPC_STALE). We chose not to fake a finalized payment for the jury. Judges can still see the full merchant loop, Keplr payer flow, receipt path, and forged-proof rejection with no fraudulent paid mutation. That limitation is product discipline, not a missing screen.

3. Time vs. ambition
NFC, Secure Enclave wallet, accounting export, and multi-location ops remain post-hackathon (pilot → native wallet → merchant platform/NFC → terminal/validator network), each with separate security and legal exit gates.

4. Building with agents at Critical/High risk
We used a multi-agent protocol (implementer / tester / security reviewer, file leases) so velocity never rubber-stamped custody or payment finality.

What's next

  • 0–3 months: two fresh RPCs, real pilot payments, accounting export, commercial engine, independent security audit, written U.S. legal scope, 10 design-partner merchants
  • 3–9 months: native self-custody mobile wallet, Face ID, two-device recovery
  • 9–18 months: multi-location POS, integrations, second allowlisted network, NFC only after entitlement + security approval
  • 18–36+ months: hardened terminals and a validator-network thesis under a separate threat model

Ask: design-partner merchants, accounting + regulated stablecoin partners, and capital to fund product/security, U.S. legal work, audits, and early distribution.

Why it matters

Tapyra is a merchant software for a world where stablecoins settle like cash — with receipts that reconcile, verification that fails closed, and a custody model founders and regulators can defend.

Tap. Pay. Proven.

Built With

Share this project:

Updates