Claude × krypto — 5 frameworków do rozbioru whitepaperów (200K context)

1. Dlaczego do whitepaperów wybieram Claude #

Przy pracy z whitepaperem liczy się to, żeby cały dokument zmieścił się w context bez cięcia na kawałki — wtedy tabelę tokenomics z początku da się zestawić ze szczegółami vestingu z końca. Rozmiary okna context poszczególnych modeli sprawdzaj w oficjalnej dokumentacji dostawców. A który model lepiej trzyma detale na twoim materiale? Puść ten sam whitepaper z tymi samymi pytaniami przez każdy z nich i porównaj wyniki sam.

2. Framework #1: rozbiór whitepapera w 6 wymiarach #

Framework bazowy — od niego zaczynam każdy projekt. Wrzuć PDF bezpośrednio do Claude (Sonnet 4.5 wystarczy).

Szablon prompt:

W załączniku jest whitepaper PDF projektu [nazwa]. Rozbierz go po sześciu wymiarach.
Dla każdego wymiaru stosuj format: „cytat z whitepapera → twoja interpretacja”.
Cokolwiek nie jest wprost w dokumencie — oznacz jako „brak w whitepaperze”. Nie uzupełniaj.

1. Postawienie problemu: jaki problem projekt deklaruje, że rozwiązuje? Przepisz w 1 zdaniu.
2. Ścieżka techniczna: jaką technologią rozwiązuje, czym różni się od już istniejących projektów.
3. Tokenomics: do czego służy token, total supply, alokacja początkowa.
4. Krzywa odblokowań: vesting schedule dla zespołu / inwestorów / community.
5. Roadmapa: kluczowe kamienie milowe na najbliższe 12 miesięcy + co zostało dostarczone.
6. Sekcja ryzyka: jakie ryzyka projekt sam wymienia.

Na końcu wypisz 5 pytań, które whitepaper „powinien był poruszyć, a nie poruszył”.

Ostatnia linijka — „powinien był, a nie poruszył” — to clou wartości dodanej. Luki, które warto sprawdzić:

• wymagania sprzętowe i próg ekonomiczny dla walidatorów (wpływ na realny stopień decentralizacji);
• model bezpieczeństwa środków w bridge cross-chain (zwykle zbyte mglistym „audytowane”);
• deklaracje dotyczące ujawniania sprzedaży tokenów zespołu po odblokowaniu;
• ścieżka governance w razie nieudanej aktualizacji mainnetu.

3. Framework #2: modelowanie presji odblokowań w tokenomics #

Krzywa odblokowań w whitepaperze zwykle istnieje jako opis tekstowy — okiem ciężko ocenić, które miesiące będą największą presją podażową. Claude z Artifacts narysuje to wprost.

Szablon prompt:

Na podstawie vesting schedule z załączonego whitepapera (strony X-Y):

Zbuduj tabelę emisji tokena na 36 miesięcy z kolumnami:
- miesiąc (1-36),
- odblokowanie zespołu (% total supply),
- odblokowanie inwestorów,
- odblokowanie funduszu ekosystemowego,
- emisja nagród community,
- miesięczny przyrost circulating supply,
- skumulowany udział circulating supply.

Następnie na podstawie tej tabeli odpowiedz:
1. Które 3 miesiące mają największą presję odblokowań? Z jakiej puli pochodzi główna część.
2. Zakładając niezmienną cenę tokena — równowartość USDT odblokowywana co miesiąc (przy FDV X).
3. W których miesiącach odblokowanie przekracza 5× średni dzienny wolumen (czyli realna presja sprzedażowa).

Na końcu wypisz tabelę markdown + wykres słupkowy na 36 miesięcy (przez Artifacts).

Cały sens jest w wykresie. Klasyczny cliff — 12 miesięcy pełnej blokady, a w 13. miesiącu jednorazowe uwolnienie tokenów zespołu — potrafi zmieścić się w whitepaperze w jednym zdaniu, ale narysowany jako słupek nie da się go przeoczyć.

4. Framework #3: raport audytowy + porównanie z kontraktem #

Tu 200K context naprawdę pokazuje, do czego służy: jednocześnie podajesz whitepaper + raport audytowy + kod kontraktu z Etherscan (pliki .sol możesz wrzucić bezpośrednio do Claude).

Szablon prompt:

Daję ci trzy materiały:
- Załącznik 1: whitepaper PDF,
- Załącznik 2: raport audytowy PDF (Certik / OpenZeppelin / Halborn),
- Załącznik 3: źródło .sol kontraktu faktycznie wdrożonego na mainnecie.

Porównaj je w trzech warstwach:

Warstwa 1: uprawnienia kontraktu deklarowane w whitepaperze vs sprawdzone w audycie vs faktyczne modifier w źródle.
- Czy są spójne? Gdzie rozjazd.

Warstwa 2: kwestie z audytu oznaczone „Acknowledged but not fixed”.
- Każdy issue + severity + odpowiedź projektu + czy pozostał w wersji wdrożonej na produkcję.

Warstwa 3: funkcje admin w źródle.
- Wypisz wszystkie onlyOwner / onlyAdmin / awaryjne pauzy.
- Które funkcje są pod timelock, które nie.
- Konfiguracja multi-sig N-z-M (jeśli widoczna w kodzie).

Nie pisz podsumowania „projekt bezpieczny / niebezpieczny”. Chcę listę faktów.

Ostatnia linijka jest krytyczna — wprost zakazujesz podsumowania. Werdykt „projekt jest bezpieczny” z modelu nie ma żadnej wartości. Lista faktów masz w ręku — wnioski wyciągasz sam.

5. Framework #4: odwrotny background check zespołu #

Wklejasz do Claude zrzuty LinkedIn członków zespołu, strony poprzednich projektów, historię Twittera, profile Crunchbase. Żeby wynik dało się sprawdzić, materiały zbierasz wcześniej sam.

Szablon prompt:

Daję ci publicznie dostępne informacje o 5 członkach kluczowego zespołu projektu
(streszczenia LinkedIn + historia Twittera + strony wcześniejszych projektów).

Zwróć:

1. Linia czasu każdej osoby:
   - publicznie deklarowana przeszłość vs faktycznie weryfikowalna (zaznacz rozjazdy).

2. Los wcześniejszych projektów:
   - Działa? Przejęty? Zamknięty? Rugpull?
   - Czas od premiery do zamknięcia / przejęcia.

3. Lista czerwonych flag:
   - Czy wcześniejsze projekty miały pozwy SEC, skargi community, podatności w kontraktach.
   - Czy członkowie zespołu figurują równocześnie w 2+ projektach krypto.
   - Czy są oczywiste sprzeczności między LinkedIn a Twitterem.

4. Po jakich dodatkowych keyword warto pociągnąć weryfikację krzyżową?

Nie pisz konkluzji „zespół wiarygodny / niewiarygodny”.

Mocna strona Claude to porównanie poziome: 5 życiorysów rozłożonych obok siebie wychwytuje rzeczy w stylu „trzy osoby twierdzą, że pracowały w tej samej firmie, ale daty się nie pokrywają”. Ludzkim okiem to bardzo łatwo przegapić.

6. Framework #5: matryca porównawcza konkurencji #

Ostatni — używasz go po analizach pojedynczych projektów, do porównania poziomego. W jednej rozmowie wrzucasz 3-5 whitepaperów.

Szablon prompt (sugerowany Opus):

W załączniku 4 whitepapery projektów z tego samego sektora (A/B/C/D).
Zbuduj matrycę porównawczą z kolumnami:

- mechanizm konsensusu,
- data uruchomienia mainnetu,
- bieżący TVL (uzupełnię danymi z DefiLlama),
- udział tokenów zespołu + data końca odblokowań,
- proporcja tokenów inwestorów vs community,
- aktywność deweloperska z ostatnich 6 miesięcy (częstotliwość commitów na GitHubie, uzupełnię),
- liczba audytów + firmy audytujące,
- liczba stron whitepapera i staranność redakcji (subiektywna ocena),
- pozycjonowanie w jednym zdaniu.

Następnie odpowiedz:

1. Który z 4 projektów ma tokenomics najbardziej „przyjazne małemu inwestorowi”?
2. Który ma największy rozjazd „roadmapa vs faktyczna dostawa”?
3. W którym whitepaperze wyraźnie dominuje narracja marketingowa nad detalem technicznym?

Na końcu otwarcie przyznaj, których pól nie da się wypełnić wyłącznie z whitepapera — wskaż te wymagające danych zewnętrznych.

Ostatnia linijka jest kluczowa. Model domyślnie wypełni każde pole na siłę, nawet bez danych. Dopiero polecenie „przyznaj, których nie da się wypełnić” zmusza go do wpisania „insufficient data”.

7. Czego Claude nie zrobi #

Zanim użyjesz Claude do due diligence krypto, poznaj te ograniczenia:

Ograniczenie 1: nie ufaj liczbom „na żywo” na słowo. Każdy „bieżący TVL”, „cena z ostatnich 7 dni” czy „aktualne saldo kontraktu”, o ile nie pochodzi z materiału, który sam wkleiłeś, albo ze źródła w sieci, które model wprost cytuje, może być starą wartością z danych treningowych — albo po prostu zmyśloną. Dane bieżące pobieraj sam i wklejaj do rozmowy.

Ograniczenie 2: w długich dokumentach czasem „nie schodzą mu liczby”. Na przykład tabela alokacji na początku i szczegóły vestingu dalej podają dwa różne udziały zespołu — model może wypisać jeden z nich i w ogóle nie zasygnalizować sprzeczności. Dlatego liczby krytyczne weryfikuj sam w źródle. Najlepiej dodatkowo każ Claude wypisać wszystkie strony, na których dana liczba się pojawia.

Ograniczenie 3: tematy dźwigni i futures generują kaskady disclaimerów. Pytanie „jak zbudować strukturalną strategię 3× lewar” włącza paragrafy „to nie jest rekomendacja” i obniża gęstość informacji. Przeformułuj: „mam już pozycję X, przeanalizuj ekspozycję tej pozycji przy spadku BTC o 10%” — przesuwasz model z roli doradcy w rolę analityka.

Ograniczenie 4: wersja Free ma ciaśniejsze limity. Wgrasz cały whitepaper, dopytasz kilka razy — i darmowy plan może szybko dobić do limitu użycia; w długich rozmowach model potrafi też „zapominać” wcześniejszy materiał. Due diligence na długich dokumentach lepiej robić na płatnym planie — aktualne limity sprawdź na oficjalnych stronach Anthropic.

Cała biblioteka promptów →

8. FAQ #

Q1: Czy Claude nadaje się do analizy krypto lepiej niż ChatGPT?

W rozbiorze długich dokumentów — wyraźnie tak. 200K context wciąga whitepaper razem z raportem audytowym i tweetami zespołu. Zastrzeżenie: liczbom „na żywo” nie ufaj na słowo — każ mu wyszukać i zacytować źródło albo wklej dane sam. W codziennej rozmowie różnice są niewielkie.

Q2: Sonnet czy Opus do whitepaperów?

Do większości pracy Sonnet 4.5 wystarcza, a według oficjalnego cennika kosztuje mniej niż Opus 4.5 (input $3 vs $5 za milion tokenów). Opus zostaw na ciężkie wielowątkowe rozumowanie — np. porównanie 5 projektów naraz z oceną ryzyka tokenomics. Wtedy bierzesz Opus 4.5.

Q3: Czy Claude odmawia rozmowy o projektach krypto?

Strukturę, tokenomics i szczegóły techniczne omówi bez problemu. Odmówi pytań typu „czy X urośnie” albo „doradź strategię z dźwignią” — i dobrze, bo eliminuje szum.

Q4: Da się puszczać analizy automatycznie przez Claude API?

Tak. API Anthropic rozlicza się po tokenach. Sonnet 4.5 to ok. $3 za milion tokenów input — pełny przebieg na 200K input wychodzi około $0.6. Batchem 50 due diligence w jedną noc zamykasz w mniej niż $50.

Q5: Jak zbudować workflow krypto w Claude Project?

Załóż Project na Claude.ai i wrzuć do Project Instructions trzy bloki: „framework due diligence krypto”, „czarna lista typowych chwytów marketingowych projektów” oraz twój własny profil ryzyka. Dla każdego nowego projektu wystarczy wgrać whitepaper — framework aplikuje się automatycznie.

AI Trade Lab · 2026-05-15