Kryptowalutowa lista kontrolna DYOR: Oceń projekty kryptowalutowe przed inwestycją

Rynek kryptowalut jest szeroko otwarty dla nowych podmiotów, a każdy może uruchomić projekt kryptowalutowy lub token w ciągu kilku godzin; dlatego też należy wyrobić w sobie nawyk oceny projektów kryptowalutowych przed dokonaniem inwestycji. I tak, nie ogranicza się to do akcji cenowej tokena w czasie rzeczywistym na rynku, ze wszystkimi wzlotami i upadkami jego ceny, a nawet jego tokenomiki jako całości, ale wymaga znacznie szerszej perspektywy. Tutaj dowiesz się, jak przeprowadzić własne badania kryptowalut, na co zwrócić uwagę i dlaczego ma to znaczenie, a także otrzymasz krok po kroku kryptowalutową listę kontrolną DYOR.

Co oznacza DYOR w kryptowalutach?

Zdefiniujmy od razu, że Do Your Own Research, czyli DYOR w kryptowalutach, nie jest częściowym zbiorem rozproszonych faktów, z których niektóre traktujesz priorytetowo, a inne całkowicie wykluczasz. Jest to kompleksowy, powtarzalny proces, w którym traktujemy projekt jako system ludzi, kodu i procesów, a token jako autonomiczny system ekonomiczny z własnymi zachętami i mikrostrukturą rynkową. Rezultatem powinna być skoncentrowana mapa ryzyka z priorytetami, warunki unieważnienia hipotezy o potencjale projektu oraz zrozumienie, które elementy są chronione architektonicznie, które są procesem, a które pozostają otwarte i wymagają limitów ekspozycji.

Czy DYOR jest naprawdę konieczny, jeśli inni podnoszą monetę? OK, możesz zapytać, czy warto oceniać projekty kryptowalutowe przed wyczerpującym zainwestowaniem w nie. W końcu możesz być całkowicie zadowolony z podejścia, w którym widzisz dynamikę aktywów w czasie rzeczywistym, a Twoim zadaniem jest po prostu handlować ich wzlotami i upadkami, które mogą być napędzane głównie przez szum. Tak, może to działać, jeśli dany token nie jest częścią twojego portfela, nie planujesz nim stale handlować lub twoje inwestycje w niego są tak nieznaczne, że nawet nie będziesz o nich pamiętać następnego dnia. Brak DYOR nie jest jednak jednoznacznym podejściem, jeśli zamierzasz regularnie handlować tym tokenem, nawet w niewielkich ilościach, a tym bardziej, jeśli planujesz zainwestować znaczną kwotę lub grać w długą grę.

W związku z tym ogólny pozytywny sentyment może ukrywać nierównowagę strukturalną, która objawia się dokładnie wtedy, gdy powoduje największe szkody. Tak więc szum nie anuluje podstawowej logiki systemów: jeśli uprawnienia administratorów pozwalają na szybką i cichą zmianę krytycznych parametrów, proxy aktualizacji nie mają przejrzystej blokady czasowej, klastry odblokowujące pokrywają się ze słabym profilem płynności lub routing handlu jest powiązany z jedną pulą lub jednym dostawcą - wszystkie te szczegóły pojawiają się w momencie jednostronnego przepływu zleceń. DYOR pomaga dokładniej ocenić potencjał handlowy: co dokładnie wspiera obecną zbywalność, kto zapewnia głębokość w księgach zleceń i pulach oraz z jakimi zachętami, które wydarzenia jako pierwsze zerwą powiązania przyczynowe wzrostu i jak zachowa się system, gdy jedno lub kilka założeń zewnętrznych ulegnie pogorszeniu.

Crypto DYOR krok po kroku

Istnieją różne sposoby podejścia do kryptowalutowego DYOR, a klasyczna 7-etapowa lista kontrolna due diligence może być bardzo skuteczna w przypadku kryptowalut.

Dopasowanie problemu do rozwiązania

Celem tego kroku jest upewnienie się, że projekt nie jest jedynie spekulacją na temat misji oderwanej od rzeczywistości, ale rozwiązuje rzeczywisty problem, którego rozwiązanie jest rzeczywiście poszukiwane i skuteczne. Aby to zweryfikować, przejrzyj oświadczenia projektu, jego opis podróży użytkownika i obietnice uproszczenia, obniżenia kosztów i innych ulepszeń. Następnie spróbuj przejść przez to z niewielkim depozytem i zanotuj czas do wyniku, całkowite opłaty, liczbę wymaganych działań i odsetek prób, które wymagają ponownej próby. Powtórz test o innej porze dnia i w inny dzień - wykluczy to jednorazowe udane uruchomienie i pokaże stabilność.

Następnie porównaj zaobserwowane wartości z tym, co twierdzi projekt; na przykład, jeśli obiecuje się niskie opóźnienia, ale w praktyce wymagane są długie potwierdzenia lub ręczne przełączanie sieci, zapisz rozbieżność jako ryzyko. Osobno sprawdź zachowanie w przypadku błędów: jasne komunikaty, przewidywalne odzyskiwanie i brak zablokowania środków. Wynikiem tego kroku powinna być krótka notatka na temat powtarzalności scenariusza, jego kosztu, stabilności czasowej i obecności zewnętrznych potwierdzeń stosowalności; jeśli ścieżka działa tylko z ręcznym trzymaniem moderatorów na czacie lub odbiega od podanych obietnic, to już na tym etapie hipoteza staje się wątpliwa.

Architektura i projekt protokołu

Tutaj musimy zrozumieć system nie na poziomie użytkowania, ale jako całość. Nie musisz być inżynierem i samodzielnie sprawdzać kodu, ale powinieneś zrozumieć logikę systemu i gdzie znajdują się potencjalne pojedyncze punkty awarii. Opierając się na informacjach publicznych, dopasuj łańcuch kluczowych komponentów: sieć bazową i tryb ostateczności, możliwą nakładkę L2, mosty, kanały cenowe, przechowywanie stanu, wyrocznie i usługi indeksowania; każde łącze powinno mieć jasny profil ryzyka i udokumentowane ograniczenia.

W krytycznych miejscach należy szukać redundancji i trybu degradacji, w którym zachowane są niezmienniki bezpieczeństwa: dwa niezależne źródła cen są lepsze niż jedno, obecność alternatywnej trasy przez mosty zmniejsza ryzyko operacyjne, a udokumentowana strategia wycofywania zwiększa przewidywalność.

Należy również zwrócić szczególną uwagę na obecność planu migracji - w jaki sposób projekt przenosi użytkowników i płynność między wersjami bez utraty środków, w jaki sposób ogłaszane są okna aktualizacji i w jaki sposób zapewniona jest odwracalna zmiana parametrów. Jeśli architektura jest opisana w abstrakcjach, mechanika zewnętrznych zależności jest niejasna, a scenariusze degradacji są zredukowane do nadziei na "stabilne działanie", prawdopodobnie masz do czynienia z dość ryzykownym projektem, więc powinieneś uwzględnić to w wielkości pozycji i ścisłych warunkach unieważnienia hipotezy.

Zarządzanie i operacje

W tym miejscu należy dokładnie przeanalizować, kto jest źródłem zmian w systemie, jakie są prawa do zmian i jak przewidywalne są one w czasie. Zacznij od publicznego modelu zarządzania i zweryfikuj go z rzeczywistymi prawami: czy istnieje blokada czasowa dla krytycznych aktualizacji, jak multisig dla kluczy administracyjnych, jakie kworum i progi propozycji są stosowane w praktyce.

Korzystaj z ogłoszeń o wydaniach i ogłoszeniach technicznych, aby ocenić kadencję dostaw - regularne okna aktualizacji z jasnymi informacjami o wydaniach są lepsze niż rzadkie duże wdrożenia bez kompatybilności wstecznej. Innym bardzo ważnym wyznacznikiem dojrzałości jest obecność raportów z incydentów z jasną analizą przyczyn i działań naprawczych, a także publiczna identyfikowalność tego, w jaki sposób poprawki trafiają do produkcji i jak potwierdzany jest ich efekt. Weryfikacja podanego modelu z zaobserwowanymi transakcjami na kluczowych adresach: jeśli decyzje są rzekomo podejmowane przez społeczność, ale w rzeczywistości parametry są zmieniane natychmiast przez jednego operatora, formalna konstrukcja nie pasuje do rzeczywistości.

Ostatecznie musisz sformułować wniosek, czy możesz liczyć na opóźnienie i przejrzystość przed zmianami, a także listę miejsc kontroli, które wymagają dodatkowych limitów ryzyka.

Weex Banner

Postawa w zakresie bezpieczeństwa

Bezpieczeństwo jest kluczowe i ten aspekt wymaga osobnej weryfikacji. Należy upewnić się, że typowe klasy zagrożeń są objęte nie obietnicami, ale standardami, procesami i raportami. Zacznij od dopasowania wersji umów w raportach z audytów do tego, co jest obecnie wdrażane; raport o starej wersji bez późniejszych ponownych testów nie zmniejsza ryzyka. Dla każdej luki należy sprawdzić status naprawy i potwierdzenie ponownego testowania. Warianty bezpieczeństwa określone w dokumentach powinny być odzwierciedlone w testach i praktykach: izolacja ścieżek krytycznych, sprawdzanie warunków brzegowych, ograniczenie uprawnień ról i rotacja kluczy.

Wiele projektów oferuje również programy bug bounty, w ramach których wszyscy badacze bezpieczeństwa są otwarcie zapraszani do przeglądu kodu projektu w zamian za nagrodę. Musisz upewnić się, że projekt oferuje bug bounty nie jako baner reklamowy, ale jako działający program: terminy odpowiedzi, proces weryfikacji zgłoszeń, przykłady zamkniętych spraw i publiczne potwierdzenia wypłat. Kolejnym bardzo ważnym aspektem, który ostatnio stał się jednym z kluczowych wektorów ataku, są integracje

Oczywiście absolutne bezpieczeństwo jest mitem i zawsze będzie istniało pewne potencjalne ryzyko. Twoim zadaniem nie jest udowodnienie ich braku, ale stworzenie jasnej mapy ryzyka architektonicznego, które jest zamknięte, ryzyka zarządzanego przez procesy o sprawdzonym cyklu kontroli oraz ryzyka szczątkowego, które będzie wymagało limitów ekspozycji i monitorowania zdarzeń.

Produkt i przyjęcie

Należy oddzielić długotrwałe użytkowanie od krótkoterminowych działań motywacyjnych i zrozumieć higienę operacyjną produktu. Skoncentruj się na powtarzalności działań docelowych bez wyzwalaczy promocyjnych: uruchamiaj te same scenariusze w "zwykłe" dni, sprawdzaj dostępność aktualnych przewodników dotyczących wdrażania i rozwiązywania problemów oraz oceniaj szybkość i szczegółowość odpowiedzi w oficjalnych kanałach wsparcia.

Wejdź na strony partnerów i sprawdź, czy deklarowana integracja faktycznie działa, kiedy była ostatnio aktualizowana i jak partner opisuje ograniczenia. Jakość obsługi technicznej ma tutaj kluczowe znaczenie: przewidywalne zmiany, staranny dziennik zmian i brak przerw w kompatybilności bez ścieżek migracji. Jeśli aktywność spada natychmiast po zakończeniu kampanii, instrukcje stają się nieaktualne szybciej niż wydania, a punkty wejścia partnera prowadzą do symboli zastępczych, jest za wcześnie, aby mówić o dojrzałych operacjach.

Ostatecznie należy sformułować wniosek, czy produkt ma wystarczająco trwały rdzeń użytkowania i jak dobrze nawyki operacyjne zespołu pasują do długotrwałej usługi.

Kontekst prawny i zgodność z przepisami

Spójność polityki i zgodność z przepisami nie są rzeczami, które można zaniedbać; możesz sam zobaczyć, jak w ciągu ostatniego roku ich rozwój zasadniczo zmienił całą branżę kryptowalutową

Dyscyplina finansowa i startowa

Sprawdź proporcjonalność określonych celów do dostępnych zasobów i zdolność zespołu do osiągania wyników bez polegania na niekontrolowanych wydarzeniach. Porównaj kilka ostatnich kamieni milowych z rzeczywistymi wydaniami i datami, zwróć uwagę na wyjaśnienia opóźnień i zastosowane korekty procesów. Zidentyfikuj krytyczne zależności od zewnętrznych dostawców infrastruktury i oceń gotowość do ich zastąpienia lub degradacji, od dostawcy indeksowania po operatora mostu. Zadaj sobie pytanie, czy krótkoterminowa wartość dla użytkownika zależy od zdarzeń, których zespół nie kontroluje i czy istnieją alternatywne ścieżki do osiągnięcia tych samych wyników. Regularne dostawy z przejrzystymi korektami, buforami i planami awaryjnymi wskazują na dyscyplinę; przeskakiwanie obietnic związanych z kampaniami, systemowe opóźnienia bez postmortem i poleganie na zewnętrznych wyzwalaczach bez scenariuszy awaryjnych zwiększają ryzyko niedostarczenia. Rezultatem jest zdyscyplinowana ocena tego, jak bardzo można ufać prognozom czasowym projektu i jak wpływa to na horyzont czasowy i limity.

Łączymy siedem kroków w jedną decyzję

Po ukończeniu każdego kroku należy połączyć te ustalenia w mapę ryzyka projektu: gdzie odporność jest potwierdzona przez obserwowalne fakty, ryzyko jest umiarkowane i zarządzane przez wielkość pozycji i okna czasowe, a ekspozycja jest niedopuszczalna niezależnie od potencjalnych zwrotów. Następnie należy nałożyć tę warstwę DYOR projektu na oddzielną analizę tokenów, taką jak mapa podaży, uprawnienia, prawa, płynność i mikrostruktura. Jest to dokładnie połączony obraz, który określa warunki wejścia, wielkość pozycji, punkty przeglądu hipotez i powody wyjścia.

Przewodnik po analizie due diligence kryptowalut

Nie ma jednego podejścia do tego, więc możesz uznać inne za bardzo wygodne; kryptowalutowy DYOR można podzielić na dwa kluczowe poziomy, które sprowadzają się do charakterystyki tokena i wszystkiego, co za nim stoi. Na poziomie należytej staranności całego projektu kryptowalutowego weryfikuje się niezmienniki architektoniczne, zdolność zespołu do dostarczania i utrzymywania produktu pod docelowym obciążeniem, dojrzałość procedur zarządzania i procedur operacyjnych oraz zgodność określonych założeń bezpieczeństwa z rzeczywistymi zachowaniami użytkowników.

Weex Banner

Jak sprawdzić zespół projektu kryptograficznego?

Dlaczego więc zespół stojący za projektem kryptograficznym jest ważny? Zespół w dużej mierze determinuje charakter rozwoju projektu, od rodzaju wiedzy branżowej, jaką może zaoferować, po kulturę inżynieryjną, którą zbuduje.

Po pierwsze, należy zidentyfikować głównych członków zespołu, zbadać ich sposób działania i przekształcić te fakty w prognozę zachowań operacyjnych. Pamiętaj, że sposób działania członka zespołu nie jest zbiorem abstrakcyjnych historii, ale weryfikowalnych przypadków branżowych porównywalnych z bieżącym projektem pod względem zadań, ryzyka i skali. Innymi słowy, zbieraj fakty według domeny, a nie według tytułów. Sprawdź także ich ogólny wkład w domenę poza ostatnimi projektami poprzez publiczne artefakty; na przykład udział w konferencjach, publiczne dyskusje na temat ustaleń, autorstwo notatek projektowych itp. I oczywiście ich konkretny wkład w ostatnie projekty; na przykład publiczne złożone moduły kodu, materiały pośmiertne z działaniami naprawczymi itp.

Zestawienie faktów z obecną rolą w projekcie. Dla każdego kluczowego uczestnika, powiąż przeszłe sprawy z jego obecnym obszarem odpowiedzialności. Poszukaj, gdzie dana osoba pojawia się osobiście w swoim obszarze: w datowanych ogłoszeniach o wydaniu z odpowiedzialnymi nazwiskami, w publicznych zestawieniach złożonych zmian, w materiałach, w których wyjaśniają ryzyko i kompromisy, a nie tylko wiadomości. Główny inżynier - o stabilności i odwracalności zmian, produkt - o priorytetyzacji i kryteriach gotowości, bezpieczeństwo - o znalezionych i usuniętych podatnościach, operacje - o odzyskiwaniu i planowanych oknach konserwacji, społeczność - o dokładnych przewodnikach i rozwiązaniach typowych problemów. Głośny tytuł bez takich śladów nie potwierdza prawdziwej roli i wartości w projekcie.

Czego szukać w whitepaper projektu?

Bardzo ważne jest, aby traktować whitepaper prawidłowo - a mianowicie nie jako obietnicę marketingową, ale jako specyfikację systemu. Zacznij od udokumentowania założeń i granic stosowalności: które warunki zewnętrzne zespół definiuje jako domyślne, dla jakiej klasy zakłada uruchomienie i obsługę projektu oraz jakie ograniczenia przepustowości i opóźnień uznają za akceptowalne. Należy wyraźnie oddzielić to, co jest opisane jako niezmiennik bezpieczeństwa, od tego, co jest określone jako zachowanie docelowe przy normalnym obciążeniu. Wynikiem tej analizy powinna być tabela założeń i niezmienników z każdym elementem powiązanym z metodą walidacji: gdzie go obserwować, jak go potwierdzić i jakie zachowanie traktować jako odchylenie.

Następnie należy ocenić model stanów i przejść. Przejrzysta biała księga zawsze wyjaśnia, jakie obiekty stanu istnieją, gdzie są przechowywane, które zdarzenia je zmieniają i jakie kontrole są wykonywane przed zmianą. Bardzo ważne jest również udokumentowanie warunków przerwania akcji i odwracalności operacji: czy zapewnione są mechanizmy wycofywania, w jaki sposób obsługiwane są nieudane transakcje i jakie istnieją ograniczenia dotyczące ponownego wykonania. Pośrednim, ale istotnym wskaźnikiem jakości jest tutaj obecność w dokumentacji diagramów stanów/sekwencji i wyraźnych warunków wstępnych/końcowych dla krytycznych operacji. Jeśli przejścia są opisane w sposób ogólny, bez predykatów i warunków wstępnych, istnieje ryzyko niezdefiniowanego zachowania pod obciążeniem.

Oddzielnie skompiluj mapę zewnętrznych zależności - może to stać się krytycznym aspektem odporności i bezpieczeństwa, nawet jeśli główny system jest bliski doskonałości. Biała księga powinna wyraźnie wymieniać wyrocznie, mosty, indeksowanie, usługi przesyłania wiadomości międzyłańcuchowych i inne łącza zewnętrzne, a także opisywać tryb degradacji w przypadku ich awarii. Sprawdź, czy określono alternatywne źródła danych lub mechanizmy przełączania awaryjnego, politykę buforowania i okna czasowe, po których system przełącza się w tryb bezpieczny. Brak opisanej strategii degradacji również znacząco zwiększa ryzyko i zwiastuje prawdopodobieństwo niekontrolowanych awarii.

Aktualizacje i migracje powinny być procedurą, a nie deklaracją. Należy zarejestrować, kto i w jaki sposób jest upoważniony do inicjowania zmian, jakie okna powiadomień i opóźnienia mają zastosowanie, w jaki sposób potwierdzane jest powodzenie migracji stanu i czy istnieje plan odwracalności wersji. Jeśli biała księga opiera się na proxy aktualizacji, zweryfikuj opisane role, blokadę czasową i kolejność publikowania nowej logiki oraz scenariusz wycofania w przypadku regresji; jeśli istnieje niezmienne podejście, ważne jest, aby mieć wyraźny, wysokiej jakości opis niezmienności jako modelu i braku ścieżek administracyjnych do modyfikowania logiki.

Na koniec należy zwrócić uwagę na obserwowalność. Dobry dokument definiuje, jakie metryki i zdarzenia powinny być dostępne dla użytkowników i integratorów: identyfikatory krytycznych transakcji, statusy kolejek, kody błędów i sygnały o przełączeniach trybów. Co najmniej udokumentowane zdarzenia w umowach dla kluczowych przejść i statusów usług publicznych (zdrowie/status), które umożliwiają śledzenie przejść trybów. Jeśli obserwowalność jest pozostawiona zewnętrznym narzędziom według ich uznania bez minimalnego niezbędnego zestawu zdarzeń, weryfikacja obiecanych właściwości systemu staje się wyzwaniem.

W rezultacie, minimalne korzyści dla mapy ryzyka:

• Lista niezmienników i założeń, które można zweryfikować za pomocą artefaktów;
• Lista zewnętrznych zależności i odpowiadających im trybów degradacji;
• Procedura aktualizacji i migracji wraz z oczekiwaniami dotyczącymi opóźnień;
• Wymagania dotyczące obserwowalności.

Jak zweryfikować kod projektu lub audyty?

Tutaj musimy dopasować specyfikację i implementację. Oczywiście idealnie byłoby móc odczytać kod, ale nie jest to konieczne, ponieważ kluczowym celem jest weryfikacja dyscypliny bezpieczeństwa jako procesu. Zacznij od ustalenia kanonicznego źródła kodu: oficjalnego repozytorium, domyślnej gałęzi i znaczników wydania. Zapisz, że wydanie jest uważane za aktualne i jakie zmiany zostały uwzględnione w porównaniu z logiką opisaną w białej księdze.

Dopasuj wydania do wdrożonych adresów. Dla każdej kluczowej umowy adres wdrożenia, wersja i metoda aktualizacji powinny być jasne. Sprawdź, czy adresy te są oznaczone w oficjalnych materiałach i czy kod bajtowy/metadane są zgodne ze zweryfikowaną umową w eksploratorze i artefaktami kompilacji w repozytorium; jeśli zespół stosuje proxy aktualizacji, sprawdź, czy adresy proxy i implementacji są zgodne z dokumentacją oraz czy kolejność zastępowania implementacji jest opisana i możliwa do zaobserwowania; jeśli wdrożenie jest niezmienne, nacisk przenosi się na potwierdzenie braku ścieżek administracyjnych do zmiany logiki.

Audyty powinny być sprawdzane według wersji. Należy zapisać skrót commitu lub dokładną wersję poddaną audytowi, listę wykrytych luk, ich status naprawy oraz fakt ponownego przetestowania. Raport bez późniejszego potwierdzenia poprawek nie ma praktycznej wartości. Jeśli zmiany zostały uwzględnione w wydaniu po audycie, należy sprawdzić, czy ponowny test obejmował te zmiany i które części pozostały poza zakresem. Idealnie byłoby, gdyby projekt udostępnił publiczne materiały uzupełniające: informacje o poprawkach, linki do scaleń i krótki retest z datami. Dodatkowym silnym argumentem może być zewnętrzny audyt przeprowadzony przez poważnych graczy, którzy już uznali się za dokładnych audytorów i cenią swoją reputację, na przykład Webisoft, CertiK lub OpenZeppelin.

Jednorazowe audyty są dobre, ale należy również sprawdzić cykl życia podatności i praktyki reagowania. Zwróć uwagę na politykę odpowiedzialnego ujawniania informacji, zadeklarowane terminy wstępnej reakcji i naprawy, procedurę informowania użytkowników oraz obecność raportów z incydentów z działaniami naprawczymi. Działający program bug bounty jest silnym wskaźnikiem dojrzałości procesu, potwierdzonym historią zweryfikowanych zgłoszeń i wypłat; oczywiście jego brak nie jest tożsamy z niską jakością, ale jest niezwykle silnym argumentem przemawiającym za odpornością i bezpieczeństwem.

Minimalny wniosek dla mapy ryzyka tutaj:

• Ustalony kanał wydania i jego powiązanie z wdrożeniem;
• Potwierdzone adresy i metoda aktualizacji kluczowych umów;
• Audyt powiązany z konkretną wersją, z ponownym testem i zamkniętymi elementami;
• Obecność polityki ujawniania luk, postmortemów i działającego bug bounty jest wskaźnikiem dojrzałości procesu.

Przewodnik po due diligence tokenów

Przechodzimy do drugiego poziomu, a mianowicie badania due diligence tokenów, w którym analizuje się mapę podaży i praw, profil odblokowania i jego przecięcia z oknami o niskiej płynności, odporność na popyt, źródła i pochłaniacze tokenów, zachowanie ceny przy jednostronnym przepływie zamówień, a także możliwość zarządzania parametrami emisji.

Weex Banner

Jak analizować tokenomikę?

Zacznij od podstawowych wielkości podaży tokena, takich jak początkowa podaż, podaż w obiegu, w pełni rozcieńczona podaż oraz obecność lub brak maksymalnej podaży. Oddzielnie zanotuj mechanikę, która zmienia całkowitą lub krążącą część. Należy rozróżnić dwa reżimy: formalny, w którym warunki wzrostu lub zmniejszenia podaży są opisane z wyprzedzeniem i można je przewidzieć, oraz uznaniowy, w którym parametry mogą być zmieniane przez operatora. W systemie uznaniowym należy sprawdzić, kto dokładnie zmienia parametry, w jaki sposób jest to sformalizowane i jakie są ograniczenia.

Następnie, prawa posiadacza rekordu i powiązanie tokena z projektem. Co daje prosta własność, co wymaga wydania tokena, a gdzie działanie jest niemożliwe bez niego. Ważne jest, aby zrozumieć, czy token jest naprawdę niezbędny do kluczowych funkcji, czy też jego rolę można zastąpić innym aktywem lub fiatem. Jeśli zastąpienie jest możliwe, może to osłabić odporność popytu.

Przejdź do emisji i spalania. Przeanalizuj, skąd pochodzi nowa podaż i jak można ją zmniejszyć: nagrody, opłata za spalanie, odkup, wykup. Wyjaśnij, kto zmienia współczynniki i według jakiej procedury, czy istnieją blokady czasowe i publiczne okno powiadomień. W przypadku głosowania - jakie progi i kworum; w przypadku administracji - jakie granice władzy. Im bardziej ręczna kontrola i im krótsze powiadomienia, tym bardziej rygorystyczne powinny być warunki unieważnienia hipotezy.

Po podstawowych metrykach, powinieneś zagłębić się osobno w trzy kluczowe, z których pierwszą jest dystrybucja. Zbierz potwierdzone adresy lub skarbce dla skarbu, funduszy ekosystemowych, animatorów rynku, dotacji i rezerw. Sprawdź, czy adresy są publicznie powiązane z kategoriami i czy ruchy między nimi są odzwierciedlone w oficjalnych ogłoszeniach. Podziel według podmiotów, a nie etykiet marketingowych, aby zobaczyć rzeczywistą kontrolę wolumenów i zgodność z określonymi celami. Oddzielnie odnotuj ograniczenia transferu dla niektórych skarbców - techniczne lub umowne - oraz warunki ich zniesienia. W rezultacie powinieneś uzyskać rzeczywisty stopień koncentracji wśród pojedynczych kontrolerów i ryzyko zsynchronizowanego uwolnienia wolumenów do obiegu poza ogłoszonymi procedurami.

Kolejnym kluczowym wskaźnikiem jest alokacja, czyli tabela projektu udziałów i praw według kategorii, która zazwyczaj jest publicznie dostępna. Zapisz wartości procentowe i bezwzględne dla zespołu, inwestorów, ekosystemu, społeczności, marketingu, skarbu i dopasuj je do adresów z dystrybucji. Dla każdej kategorii wyjaśnij warunki handlowe: blokady, ograniczenia transferu, trasy OTC i wsparcie animatora rynku. Sprawdź również, czy istnieją formalne ograniczenia szybkości wypłat i w jaki sposób są one sformalizowane publicznie. Jeśli kategoria może zmienić swoje warunki, zapisz procedurę takiej zmiany. Powinno to dać ci pogląd na to, które kategorie mogą szybko zwiększyć obieg i kto ma do tego motywację.

Trzecią miarą jest nabywanie uprawnień, które odzwierciedla moment, w którym zablokowane tokeny stają się zbywalne. Rejestruj klify, kurs, typ krzywej (liniowa, stopniowa, łączona), a także warunki ponownego zablokowania lub zmiany harmonogramu. Opracuj miesięczny lub tygodniowy kalendarz i zaznacz klastry podwyższonych odblokowań. Wyjaśnij również, w jaki sposób vesting jest wdrażany technicznie - poprzez umowę lub poza łańcuchem - i które artefakty potwierdzają przestrzeganie harmonogramu. Jeśli występują przyspieszenia lub wczesne konwersje, zapisz warunki i kto je wyzwala. Zapewni to wgląd w konkretne okna potencjalnej presji podażowej i oznaki jej łagodzenia.

W rezultacie powinieneś otrzymać prawie kompletną mapę przepływu tokenów:

• Baza podaży. Podaż początkowa/obiegowa/w pełni rozcieńczona, maksymalny stan podaży; zarejestrowane mechanizmy, które zmieniają całkowitą i obiegową podaż.
• System kontroli podaży. Formuła a uznaniowość; kto zmienia parametry, jak to jest sformalizowane, limity i okna powiadomień / blokad czasowych.
• Konieczność tokena. Co daje własność, co wymaga wydatków; czy istnieją substytuty bez tokena jako oznaka słabej odporności popytu.
• Emisja/spalanie. Źródła zwiększania i zmniejszania podaży (nagrody, opłata za spalenie, odkup, wykup) oraz potwierdzona procedura ich zmiany.
• Dystrybucja. Potwierdzone adresy według kategorii, publiczne śledzenie ruchów, koncentracja wśród kontrolerów, aktywne ograniczenia transferu i warunki ich zniesienia.
• Przydziały. Procenty i wartości bezwzględne według kategorii dopasowanych do adresów; blokady, ograniczenia transferu, trasy OTC; kategorie zdolne do szybkiego zwiększenia obiegu i posiadające zachęty.
• Nabycie uprawnień. Kalendarz klifów / stawek z klastrami; wykonanie w łańcuchu / poza łańcuchem i artefakty przestrzegania; warunki przyspieszenia / ponownego zablokowania i inicjatory; okna potencjalnej presji.
• Sygnały zatrzymania. Skrócenie okna powiadomień, przejście do ręcznej edycji bez środków kompensacyjnych, pojawienie się nowych kanałów podaży lub rewizja nabywania uprawnień, która gwałtownie zwiększa obieg.

Banner Weex

Wnioski

Jak już wiesz, istnieje więcej niż jedno podejście do DYOR, a aspekty, które może zawierać lista kontrolna kryptowalut DYOR, są liczne. Jednak wszystkie z nich opierają się na kilku wskazówkach dotyczących bezpiecznego inwestowania w kryptowaluty, a mianowicie inwestowania nie w obietnice, ale w obserwowalne fakty i potwierdzone artefakty, gdzie zaufanie pojawia się dopiero po weryfikacji. Zbuduj spójną, kompleksową i aktualną mapę ryzyka. Traktuj ściśle swoje predefiniowane sygnały stop i nie myl szumu ze wskaźnikami. Wiedza specjalistyczna, kultura i dyscyplina mają większe znaczenie niż szum, a konsekwentna częstotliwość kontroli i aktualizacji mapy ryzyka jest obowiązkową praktyką, aby uniknąć oszustw kryptowalutowych z DYOR. Bądź na bieżąco z najnowszymi aktualizacjami i możliwościami w nowej branży ekonomicznejycryptoindustryblockchaindevelopments

Często zadawane pytania

1. Co oznacza DYOR w kryptowalutach?

DYOR w kryptowalutach to powtarzalny proces oceny projektu jako systemu ludzi, kodu i operacji wraz z tokenem jako odrębną gospodarką, którego wynikiem jest mapa ryzyka z priorytetami, warunkami unieważnienia i granicami akceptowalnej ekspozycji.

2. Jak prawidłowo zbadać projekt kryptograficzny przed dokonaniem inwestycji?

Przeprowadź krótkie praktyczne analizy scenariuszy użytkownika, rozbij architekturę i zależności, zweryfikuj model zmian i bezpieczeństwo, dopasuj białą księgę do kodu, wdrożenia i audytów, oceń operacje produktu, ramy prawne i dyscyplinę dostarczania, a następnie skonsoliduj obserwacje w mapę ryzyka i dopasuj pozycję do płynności i opóźnień w zmianie parametrów.

3. Jak mogę sprawdzić, czy token jest bezpieczny, czy to oszustwo?

Poszukaj weryfikowalnych artefaktów: przejrzystych zasad podaży i praw, publicznej dystrybucji / przydziałów / inwestowania z potwierdzonymi adresami, możliwości zarządzania emisją za pomocą jasnych procedur z opóźnieniami, aktualnych audytów z ponownymi testami i wystarczającej płynności bez pojedynczego punktu awarii; traktuj brak lub niedopasowanie w którymkolwiek z tych punktów jako podwyższone ryzyko.

4. Na jakie sygnały ostrzegawcze należy uważać w projektach kryptowalutowych?

Natychmiastowe zmiany administracyjne bez blokady czasowej, brak lub nieaktualne audyty, rozbieżności między białą księgą a faktycznym wdrożeniem, skoncentrowane odblokowania w okresach niskiej płynności, nieprzejrzyste ruchy skarbowe, zawyżone partnerstwa bez działających integracji, aktywność tylko w zakresie zachęt i brak raportów po incydencie.

5. Jaki jest najlepszy sposób na śledzenie postępów projektu w czasie?

Utrzymuj mapę ryzyka na żywo i aktualizuj ją regularnie w oparciu o informacje o wersji, działania w łańcuchu kluczowych adresów i zmiany parametrów, kalendarz odblokowań, wskaźniki płynności i raporty o incydentach, sprawdzając wszystko to w odniesieniu do planu pracy i rzeczywistych integracji, a także dostosowuj ekspozycję tylko na obserwowalne sygnały.