🪙

PapaCoin (PPC)

Tokenomika i architektura blockchainowa

🚧

PapaCoin nie jest jeszcze tokenem blockchain

Aktualnie PPC istnieje wyłącznie jako punkt w grze, przechowywany na naszych serwerach. Migracja na sieć blockchain jest planowana — ta strona opisuje projekt techniczny i gwarancje, które uchronią podaż przed rozcieńczeniem po uruchomieniu.

Parametry tokenu

TickerPPC — PapaCoin

StandardERC-20 (Ethereum / L2)lub odpowiednik na docelowej sieci; wybór sieci zostanie ogłoszony przed deploymentem

Total supply≤ suma PPC zdobytych w grzekażdy PPC zarobiony przez gracza odpowiada dokładnie 1 tokenu on-chain — nie więcej

Funkcja mint()brak po deploymenciekontrakt nie będzie zawierał żadnej metody umożliwiającej dodruk po pierwszym i jedynym mint

Decimals18

Dlaczego podaży nie da się rozcieńczyć — 5 gwarancji technicznych

Immutable bytecode — blockchain to rejestr tylko do zapisu

Kontrakt wdrożony na sieci Ethereum (lub kompatybilnym L2) nie może być „zaktualizowany" przez nikogo — nawet przez właściciela projektu. Kod skompilowany do EVM bytecode jest przypisany do adresu kontraktu na zawsze. Jedyna droga do zmiany logiki to wdrożenie nowego kontraktu pod nowym adresem, co byłoby widoczne dla każdego obserwatora on-chain i wymagałoby migracji tokenów — zdarzenie, któremu każdy holder mógłby odmówić.

Brak funkcji mint() po deploymencie

Standardowy token ERC-20 nie zawiera funkcji mint() — dodaje się ją tylko świadomie. Nasz kontrakt wyemituje wszystkie tokeny jednorazowo w konstruktorze (constructor) i nie będzie zawierał żadnej metody mint, inflate ani podobnej. Każdy może to zweryfikować samodzielnie: po wdrożeniu opublikujemy kod źródłowy kontraktu i zweryfikujemy go na Etherscan (funkcja Verify & Publish), dzięki czemu kompilacja kodu źródłowego do bytecode będzie publicznie sprawdzalna.

Jednorazowy, audytowalny mint 1:1 z grą

Przed deploymentem zostanie przeprowadzony publiczny snapshot stanu kont wszystkich graczy. Łączna suma PPC ze snapshotu stanie się totalSupply kontraktu. Każdy gracz będzie mógł porównać swoje saldo w grze z ilością tokenów przypisanych do jego portfela. Proces migracji będzie transparentny i powtarzalny — tak żeby każdy mógł zweryfikować, że nie „dodrukowano" nic ponad to, co gracze zarobili.

Renounced ownership — rezygnacja z uprawnień właściciela

Wiele kontraktów ERC-20 ma wzorzec Ownable, który daje deployer-owi specjalne uprawnienia. W naszym przypadku, jeśliOwnable zostanie użyte, własność zostanie zrezygnowana (wywołanie renounceOwnership()) zaraz po wdrożeniu. Od tej chwili nikt — łącznie z twórcami PapaHunt — nie będzie mógł wywołać żadnej funkcji z ograniczonym dostępem. Transakcja zrzeczenia się będzie widoczna on-chain.

Tokeny mogą być tylko spalane, nie tworzone

Mechanika wydawania PPC w grze (odblokowanie audio, przyszłe funkcje) zostanie odzwierciedlona on-chain jako burn() — trwałe zniszczenie tokenów. totalSupply może więc wyłącznie maleć w czasie. Żaden mechanizm w grze nie będzie wiązał się z emisją nowych tokenów.

Jak to zweryfikować po uruchomieniu

Każda z powyższych gwarancji będzie weryfikowalna publicznie po deploymencie:

1.Wejdź na Etherscan (lub explorer docelowej sieci) i wyszukaj adres kontraktu PPC.
2.Przejdź na zakładkę Contract → Code i sprawdź zweryfikowany kod źródłowy — upewnij się, że nie ma żadnej funkcji mint.
3.Sprawdź Read Contract → totalSupply i porównaj z sumarycznym saldem graczy ze snapshotu (plik opublikujemy razem z deploymentem).
4.Sprawdź historię transakcji kontraktu — poszukaj wywołania renounceOwnership() jako jednej z pierwszych transakcji po wdrożeniu.
5.Porównaj własne saldo w grze z ilością tokenów przypisaną do Twojego portfela podczas migracji — różnica powinna wynosić zero.

Pytania techniczne

Co jeśli właściciele projektu zachowają kopię kodu z funkcją mint?

Nie ma żadnej kopii, którą można by „aktywować" po deploymencie. EVM bytecode skompilowany z danego kodu źródłowego jest deterministyczny — jeśli kod bez mint() jest zweryfikowany na Etherscan, bytecode na sieci jest tym kodem. Nie istnieje mechanizm podmienienia bytecode po fakcie.

Co jeśli projekt wdroży drugi kontrakt?

Nikt nie może zmusić Cię do zaakceptowania nowego kontraktu jako „prawdziwego" PPC. Oryginalne tokeny na oryginalnym adresie kontraktu zawsze pozostają Twoje. Jeśli projekt ogłosi migrację na nowy kontrakt, masz pełne prawo odmówić i zatrzymać stare tokeny — blockchain tego nie zabroni.

Kiedy nastąpi launch na blockchain?

Termin nie jest jeszcze ogłoszony. Priorytetem jest upewnienie się, że mechanika gry jest stabilna i społeczność jest wystarczająco duża, żeby migration event miał sens. Obserwuj kanały PapaHunt, żeby nie przegapić ogłoszenia.

✠

Ta strona to dokument intencji, nie whitepaper ani prospekt emisyjny. PPC nie jest papierem wartościowym, instrumentem finansowym ani produktem inwestycyjnym. Zdobywaj go przez łowy — nie przez spekulację. Totus Tuus.

[DRAFT] Technical Contract Snippets