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

1. Dlaczego do whitepaperów wybieram Claude #

Przez ostatnie 6 miesięcy przepuściłem ten sam whitepaper projektu L2 (68 stron) przez 4 modele, z identycznym zestawem zadań. Wynik:

Gemini ma większy context, ale słabiej rozumie krypto-kontekst. GPT-4o trzeba ciąć na kawałki, a tokenomics między segmentami często się rozjeżdża. Przewaga Claude to nie „największy context” — tylko to, że w dużym context wciąż trzyma detale. To jest decydujące.

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. Z moich rozbiorów najczęściej powtarzają się braki:

• 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).

W zeszłym roku puściłem ten prompt na projekt z sektora AI i Claude wyciągnął, że „w 13. miesiącu jednorazowo odblokowuje się 6,2% tokenów zespołu”. To klasyczny cliff (12 miesięcy zamrożone, w 13. cały blok leci na rynek) — w whitepaperze opisany jednym zdaniem, ale dopiero w formie tabeli widać skalę. Projekt rzeczywiście spadł w 13. miesiącu o 38%.

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. Claude nie ma dostępu do sieci, więc 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 #

Garść wpadek z ostatniego półrocza pracy z Claude przy due diligence krypto — wypisuję, żebyś ich uniknął:

Ograniczenie 1: brak dostępu do internetu. Każdy „bieżący TVL”, „cena z ostatnich 7 dni” czy „aktualne saldo kontraktu”, który ci poda — jest zmyślony albo pochodzi ze starych danych treningowych. Claude nie ma Browse jak ChatGPT, wszystkie dane na żywo wciągasz ręcznie.

Ograniczenie 2: w długich dokumentach czasem „nie schodzą mu liczby”. Klasyk z mojej pracy: whitepaper na stronie 23 mówi, że zespół trzyma 22%, na stronie 47 w detalach vestingu — 18%. Claude wypluł 22%, wybrał wersję, która pojawiła się wcześniej, i nie sygnalizował konfliktu. 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 mocno przycięty context. Faktycznie dostępne context na koncie darmowym jest znacznie mniejsze niż 200K (ok. 100K, dzielone na historię konwersacji). Cały whitepaper przepuścisz wyłącznie na Pro. Inaczej w 5-6 turze rozmowy model zaczyna „zapominać” wcześniejsze fragmenty.

Sprawdź dane projektów na Binance → 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. Minus: brak dostępu do sieci, dane na żywo wklejasz sam. W codziennej rozmowie różnice są niewielkie.

Q2: Sonnet czy Opus do whitepaperów?

Do 80% codziennych zadań Sonnet 4.5 wystarcza i kosztuje 1/5 tego co Opus. 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