TinyPay: Real-World Crypto Payments, Unplugged

TinyPay enables seamless cryptocurrency payments in real-world scenarios—even without internet access. We bridge the gap between digital assets and everyday commerce.

Our platform transforms crypto into a cash-like experience by eliminating the need for constant connectivity. At its core, TinyPay uses a secure One-Time Password (OTP) system on the U2U blockchain to ensure transactions are fast, reliable, and trustless.

🚀 Live Demo & Links

ResourceLink

🜸 Website Visit Our Website

🎬 Video Demo & SlidesView on Google Slides

🍎 TestFlight (Payer App)Download TinyPay

🛒 TestFlight (Merchant App)Download TinyPayCheckout

🧑‍💻 GitHub (Payer App)TrustPipe/TinyPay

🧑‍💻 GitHub (Merchant App)TrustPipe/TinyPayCheckout

🧑‍💻 GitHub (EVM Contract)TrustPipe/TinyPayContract-ETH

🧑‍💻 GitHub (Backend Server)TrustPipe/TinyPayServer

✨ Key Innovations

• True Offline Payments: A hash-chain OTP system lets users generate secure, single-use payment codes offline, enabling transactions anywhere.

• On-Chain Security with U2U: Funds are secured in a non-custodial smart contract. The contract validates OTPs, processes payments, and supports both Precommit and Paymaster models.

• Multi-Currency Support: Built on the U2U URC standard, TinyPay supports U2U, USDC, and any URC20 token.

• Simple UX: Two lightweight Swift apps—TinyPay (payer) and TinyPayCheckout (merchant)—deliver an intuitive, minimal payment experience.

🏛️ System Architecture

TinyPay is built on a four-part architecture designed for simplicity and security:

1. Payer App (TinyPay): iOS app where users deposit assets into the contract and generate offline OTPs.

2. Merchant App (TinyPayCheckout): iOS app for merchants to input sale amounts and collect OTPs.

3. Backend Server (TinyPayServer): Golang service that validates merchant requests and submits transactions to the U2U contract.

4. U2U Smart Contract (TinyPayContract): Manages funds, validates OTP chains, and executes asset transfers.

⛓️ Deep Dive: The EVM Contract (U2U Network)

TinyPay.sol brings the same trustless, offline-to-on-chain settlement flow to EVM. Users preload balances per token, merchants pre-commit intended payments, and a one-time OTP drives a forward-only hash chain so each code can be used exactly once.

Core mechanics

• UserAccount (per payer):

  Stores the current tail (ASCII-hex of the last valid OTP hash), optional per-payment limit, and tail update counters to cap refresh frequency.

• Multi-asset balances:

  Users hold balances per token (native = address(0) / ERC-20). Deposits credit userBalances[user][token]; withdrawals debit them.

• OTP validation (one-time use):

  A payment is valid iff sha256(otp) (as ASCII-hex) equals the current tail. After success, the tail advances to the raw otp, preventing reuse.

• Merchant pre-commit (front-run hardening):

  Merchant calls merchantPrecommit(...) to store a short-lived hash:

  commitHash = sha256(abi.encode(payer, recipient, amount, otp, token)).

  completePayment must present the matching tuple before expiry (unless called by the paymaster, see below).

• Fee model & paymaster:

  Fees are feeRate in basis points (e.g., 100 = 1%). An optional paymaster can call completePayment without a pre-commit (e.g., for sponsored gas or batch clearing).

• Replay & risk controls:

  Per-payment limit, maxTailUpdates, and expiring pre-commits (default 15 minutes) mitigate abuse and parameter tampering.

Typical payment flow

1. Deposit & bind tail – User deposits a token and (optionally) sets/refreshes tail.

2. Pre-commit – Merchant announces intent (payer, recipient, amount, otp, token) -> commitHash stored with expiry.

3. Offline hand-off – Payer shares the OTP to the merchant (e.g., QR, NFC, voice).

4. On-chain completion – Merchant (or paymaster) calls completePayment(...).

5. Contract checks – Token support, balance, pre-commit, sha256(otp) == tail.

6. Settle & advance – Transfer (minus fee), tail = otp, increment counters, emit events.

Why this is trustless & non-custodial

• No shared secrets on-chain: Only sha256(otp) (as ASCII-hex) is compared; raw OTP is revealed only when consumed.

• Forward-only hash chain: tail = otp after success, so an OTP can’t be replayed.

• Bound intent: Pre-commit binds payer/recipient/amount/token/otp to a single hash with an expiry window, defeating parameter swapping/front-running.

• User-held balances: Funds remain attributed to users; the contract only moves value upon a valid OTP + checks.

🗺️ Future Roadmap

• DeFi Integration: Enable yield generation on deposited funds.

• Merchant Services: Add accounting and data-sync integrations.

• Hardware Suite: Build branded QR scanners and POS terminals.

• Fiat On-Ramp: Connect with fiat exchanges for seamless top-ups.

👨‍💻 The Team

• Harold

• Togo

• Lucian

• Keith