[DOKUMENT INICJUJĄCY PROJEKT]

Nazwa robocza: CryptoPay Offline / DecentPay

Rola: Dokument Koncepcyjny i Analiza Wykonalności (Project Charter & Discovery Draft)

1. PRZEZNACZENIE I CELE PROJEKTU

Przeznaczenie

Stworzenie nowoczesnego, ultra-szybkiego systemu płatności zbliżeniowych (NFC / Bluetooth Low Energy / QR) umożliwiającego natychmiastowe transakcje P2P (osoba-osoba) oraz B2C (klient-biznes), ze szczególnym uwzględnieniem pracy w trybie wyłączonego dostępu do sieci (Off-line).

System opiera się na cyfrowym tokenie / walucie kryptograficznej zabezpieczanej przez układ sprzętowy telefonu (Secure Element / eSIM) oraz architekturę DLT (Distributed Ledger Technology), eliminując wysokoprocentowe prowizje tradycyjnych organizacji kartowych (Visa/Mastercard).

Cele Projektu (Mierzalne KPI)

  • Cel Produktowy: Stworzenie bezpiecznej aplikacji mobilnej (iOS/Android) i SDK dla terminali/telefonów sprzedawców, realizującej transakcję offline w czasie poniżej 800 ms.
  • Cel Biznesowy: Obniżenie kosztu akceptacji mikropłatności (np. biletomaty, parkomaty, eventy, handel lokalny) o minimum 70% w stosunku do tradycyjnych prowizji acquiringowych.
  • Szacowany Budżet i Czas (Po aktualizacji rynkowej):
  • Wstępna Faza Discovery i MVP (Proof of Concept): 250k – 400k PLN.
  • Pełne wdrożenie produkcyjne (z audytami bezpieczeństwa i zgodnością prawną): 1.2M – 2.0M PLN.
  • Czas realizacji MVP: 6–9 miesięcy.

2. KONTEKST, MOTYWACJA I STAN RYNKU

Dzisiejszy kontekst rynkowy

  • Sytuacja w Polsce: Rynek mikropłatności jest zdominowany przez BLIK oraz płatności zbliżeniowe (Apple Pay / Google Pay / Tokenizacja kartowa). Wszyscy ci gracze wymagają jednak stałego połączenia z internetem oraz generują koszty pośredników.
  • Nowe wyzwania i nisze:
  1. Brak odporności na awarie (Resilience): W przypadku blackoutu, awarii infrastruktury telekomunikacyjnej lub ataku hybrydowego tradycyjne płatności cyfrowe przestają działać.
  2. Wysokie prowizje mikropłatności: Prowizje rzędu 0,5%–1,5% + opłaty stałe (np. 10-20 groszy od transakcji) sprawiają, że transakcje na kwoty 1-5 PLN są dla małych sprzedawców nieopłacalne.
  3. Regulacje (Unia Europejska): Rozporządzenie MiCA (Markets in Crypto-Assets) uregulowało rynek kryptowalut i stablecoinów w UE. Z kolei projekt Cyfrowego Euro (CBDC) zakłada obowiązek obsługi transakcji offline.

Najważniejsze problemy i ich współczesne rozwiązania

Problem z pierwotnego projektu Współczesne rozwiązanie technologiczne
Utrata pieniędzy przy zniszczeniu telefonu Zastosowanie portfela typu Non-Custodial z Social Recovery lub wygenerowaną kopią zapasową w oparciu o MPC (Multi-Party Computation) / ZK-Proofs.
Brak połączenia z siecią (Offline) Wykorzystanie podzespołów Secure Enclave w telefonach do kryptograficznego podpisywania transakcji offline i rejestrowania ich w lokalnym liczniku.
Anonimowość vs Legalność Wdrożenie technologii Zero-Knowledge Proofs (ZK-SNARKs): system pozwala na anonimowość do progu ustawowego (np. transakcje do 150 EUR), automatycznie wymagając weryfikacji KYC przy wyższych kwotach.

3. ANALIZA KONKURENCJI I ALTERNATYW (Aktualizacja)

Aby projekty nie powielały istniejących rozwiązań, zaktualizowaliśmy analizę otoczenia rynkowego:

  1. BLIK i Płatności P2P (BLIK na telefon): Król polskiego rynku. Działa świetnie, ale wymaga internetu po obu stronach i centralnej bazy w PSP.
  2. Apple Pay / Google Pay (Tokenizacja EMV): Wygodne, bezpieczne, ale są tylko "nakładką" na tradycyjne karty płatnicze i pobierają wysokie opłaty interchange.
  3. Cyfrowe Euro (CBDC) & Offline CBDC: Unia Europejska pracuje nad cyfrowym euro, które ma mieć opcję offline. Projekt wpisuje się idealnie w ten trend, mogąc być dostawcą technologii dla tego ekosystemu.
  4. Stablecoiny i L2 Crypto (np. USDC na sieci Solana/Polygon): Przesyłanie wartości trwa sekundy i kosztuje ułamki centa, ale wciąż wymaga dostępu do sieci i bazuje na skomplikowanych dla zwykłego użytkownika adresach kryptograficznych.

Wniosek strategiczny: Szansa na sukces naszej aplikacji leży nie w konkurowaniu z BLIK-iem na rynku masowym, ale w niszach specjalistycznych: płatności offline (festiwale, transport publiczny w trasie, parkingi w podziemiach), mikropłatności walutami lokalnymi/punktami lojalnościowymi oraz rozwiązania odporne na sytuacje kryzysowe (blackout).

4. PREZENTACJA IDEI I ARCHITEKTURA TECHNICZNA

Jak działa nowa archiwum płatności offline?

[Portfel Użytkownika] ──(NFC / BLE)──> [Terminal / Telefon Sprzedawcy]
       │                                         │
 (Podpis cyfrowy w                         (Zapis transakcji
 Secure Element)                             w lokalnej pamięci)
       │                                         │
       └────────────── Wyłapanie sieci ──────────┘
                            │
              (Synchronizacja z Siecią / DLT)

  1. Doładowanie: Użytkownik zasila portfel w aplikacji (ze swojego banku lub kartą). Kredyt kryptograficzny trafia do bezpiecznego obszaru pamięci telefonu (Secure Enclave / StrongBox).
  2. Płatność Offline (Parking / Transport / Sklep):
  • Telefon zbliża się do terminala (NFC) lub łączy przez BLE (Bluetooth Low Energy).
  • Aplikacja generuje kryptograficzny, jednorazowy token transakcyjny (z wykorzystaniem pary kluczy).
  • Terminal weryfikuje podpis sprzętowy telefonu bez pytania serwera. Transakcja trwa < 0.5 sekundy.
  1. Rozliczenie (Clearing): Gdy terminal (lub telefon użytkownika) złapie zasięg internetowy (np. pod koniec dnia), przesyła zebrane paczki transakcyjne do sieci rozliczeniowej.

5. REKOMENDOWANA METODOLOGIA I NARZĘDZIA (Wskazówki PM-a)

Dla tego typu projektu (wysokie ryzyko technologiczne, wysokie wymagania bezpieczeństwa, zmiana regulacyjna) rekomendujemy Podejście Hybrydowe (Hybrid Agile).

       FAZA PLANOWANIA (Waterfall)                   FAZA WYKONANIA (Agile / Scrum)
┌──────────────────────────────────────┐     ┌────────────────────────────────────────┐
│  • Zgodność prawna (MiCA / RODO)     │ ──> │  • Iteracyjne budowanie aplikacji      │
│  • Architektura Bezpieczeństwa       │     │  • Sprinty 2-tygodniowe                │
│  • Specyfikacja API i Hardware       │     │  • Testy z użytkownikami (MVP)        │
└──────────────────────────────────────┘     └────────────────────────────────────────┘

Rekomendowany Stos Narzędziowy dla Projektu:

  • Zarządzanie Projektem i Wymaganiami:

  • Jira / Linear – do zarządzania backlogiem, sprintami i błędami.

  • Confluence / Notion – Centralna dokumentacja biznesowa, architektoniczna i wymogi prawne.

  • Projektowanie UX/UI i Prototypowanie:

  • Figma – makiety aplikacji mobilnej i terminala (wraz z testami "elevator pitch").

  • Bezpieczeństwo i Kodowanie:

  • Kod źródłowy: GitHub / GitLab z automatycznym skanowaniem podatności (SAST).

  • Mobilne SDK: Flutter / Swift & Kotlin (z dostępem do native Secure Element).

Ostatnia modyfikacja: piątek, 24 lipca 2026, 01:57