Odwołaj uprawnienia tokena Sui - Zrzeknij się capów

Narzędzie odwołania uprawnień Sui od 20lab pozwala permanentnie zniszczyć obiekty capability (caps) monety Sui, usuwając możliwość mintowania, zamrażania, pauzowania, aktualizacji lub modyfikacji metadanych na zawsze. To sposób, w jaki projekty Sui udowadniają, że ich tokeny są niezmienne i minimalizują zaufanie.

Odwołanie jest nieodwracalne - po zniszczeniu capa, nikt nie może go przywrócić. To najczystszy sposób na pokazanie stałej podaży (odwołanie treasury cap), gwarantowanej przesyłalności (odwołanie deny cap), zablokowanego kodu (odwołanie upgrade cap) lub zablokowanej tokenomii (odwołanie metadata cap). Jeśli chcesz przenieść cap zamiast go wyłączać, użyj narzędzia transferu uprawnień.

Aby odwołać treasury cap na Sui:

1. Połącz portfel, który obecnie posiada treasury cap
2. Wprowadź coin type lub adres swojego tokena
3. Wybierz Odwołaj Treasury cap
4. Potwierdź transakcję

Po potwierdzeniu, podaż twojego tokena jest permanentnie ograniczona do bieżącej kwoty w obiegu, a metadane stają się niezmienne. Nikt - włącznie z tobą - nie może mintować dodatkowych tokenów ani zmieniać nazwy/symbolu/logo, nigdy. To najczęstsze odwołanie capa dla projektów zobowiązujących się do stałej podaży i jest zazwyczaj oczekiwane przez standardy listowania na DEXach przed wyświetleniem tokena jako godnego zaufania. Szczegółowy przewodnik: jak odwołać treasury cap na Sui.

Aby odwołać deny cap na Sui, użyj tego samego procesu co przy odwołaniu treasury cap, ale wybierz Odwołaj Deny cap. Po potwierdzeniu:

• Żaden portfel nigdy nie może być zamrożony dla twojego tokena ponownie
• Jeśli twój token używa Deny Cap V2 z włączoną pauzą, token nigdy nie może być zapauzowany ponownie
• Istniejące zamrożone konta nie mogą być odmrożone (odwołaj po odmrożeniu, jeśli to konieczne)

Odwołanie deny cap to jeden z najsilniejszych sygnałów zaufania, jaki możesz dać swojej społeczności na Sui - kryptograficznie gwarantuje, że ich tokeny nigdy nie mogą być zamrożone ani zapauzowane. Zobacz nasz przewodnik po zamrażalnym tokenie Sui dla kontekstu modelu deny cap.

"Zrzeczenie się własności" na Sui zazwyczaj odnosi się do odwołania wszystkich obiektów capability - treasury, metadata, upgrade i (gdzie dotyczy) deny cap - czyniąc właściwości tokena permanentnie ustalonymi.

W przeciwieństwie do wzorca Ownable w Ethereum, gdzie jedno wywołanie renounce porzuca pojedynczą rolę właściciela, Sui ma wiele oddzielnych capów na token. Pełne zrzeczenie się oznacza odwołanie każdego z osobna. Narzędzie wyświetla każdy aktywny cap na twoim tokenie i pozwala odwołać je w sekwencji lub selektywnie.

Odwołanie wszystkich capów to najsilniejsze możliwe zobowiązanie do decentralizacji, ale jest nieodwracalne - więc zazwyczaj robi się to tylko po osiągnięciu operacyjnej dojrzałości tokena. Transfer capów na multisig jako pierwszy krok jest bezpieczniejszym etapem pośrednim.

Narzędzie 20lab obsługuje odwoływanie każdego standardowego capa Sui:

• Treasury cap - Blokuje całkowitą podaż i metadane na zawsze
• Metadata cap - Blokuje nazwę, symbol i obraz permanentnie (zobacz nasz przewodnik po metadata cap)
• Upgrade cap - Blokuje kod smart kontraktu Move tokena permanentnie
• Deny cap / Deny cap V2 - Gwarantuje, że żadne konto nigdy nie może być zamrożone ani zapauzowane

Każdy może być odwołany niezależnie. Możesz zachować niektóre aktywne, wyłączając inne - najczęstszy wzorzec to odwołanie treasury i deny cap przy zachowaniu upgrade cap dostępnego dla łatek bezpieczeństwa.

Obie metody permanentnie wyłączają cap, ale różnią się:

• Odwołanie niszczy obiekt cap on-chain - najczystszy, najbardziej jednoznaczny sygnał permanentnego usunięcia. Łatwiejsze dla audytorów i DEXów do automatycznego wykrycia. Również odzyskuje trochę SUI ze zwrotów storage, ponieważ obiekt cap jest usuwany.
• Transfer na adres spalania przypisuje cap do portfela, którego nikt nie może podpisać. Funkcjonalnie identyczne, ale obiekt cap nadal istnieje on-chain, nieco trudniejszy do weryfikacji, i nie odzyskujesz zwrotu storage.

Odwołanie jest zalecanym podejściem. Jest czystsze w historii transakcji, odzyskuje storage i jest tym, czego sprawdza większość standardów listowania na DEXach Sui.

Tak - odwołanie capa jest absolutnie nieodwracalne. Po zniszczeniu obiektu cap:

• Cap nie może zostać przywrócony przez nikogo, włącznie z oryginalnym twórcą
• Nie ma mechanizmu odzyskiwania, nadpisania multisig ani ścieżki aktualizacji
• Odpowiednie działanie (mintowanie, zamrażanie, pauzowanie, aktualizacja, zmiany metadanych) jest permanentnie wyłączone

Z powodu tej permanencji, starannie rozważ, czy kiedykolwiek możesz potrzebować tej funkcjonalności ponownie. Jeśli nie jesteś w 100% pewien, przenieś cap na multisig zamiast tego - to nadal zapewnia silną decentralizację, zachowując opcję działania w prawdziwych sytuacjach awaryjnych.

Tak - odwołanie capów jest selektywne. Częste konfiguracje:

• Odwołaj treasury, zachowaj deny cap - Stała podaż z możliwością zamrażania podejrzanych portfeli
• Odwołaj deny cap, zachowaj treasury - Gwarantowanie nieodmrażalności tokena, ale zespół nadal może mintować zgodnie z opublikowanym harmonogramem
• Odwołaj treasury i deny cap, zachowaj upgrade cap - Zablokowana tokenomia z możliwością załatania kontraktu, jeśli zostanie znaleziona luka
• Odwołaj wszystko - W pełni zrzeczone, maksymalnie zdecentralizowane, niezmienne

Dopasuj konfigurację do etapu twojego tokena. Większość projektów odwołuje progresywnie w miarę dojrzewania ekosystemu.

Zależy od etapu i celów twojego tokena:

• Tak, dla tokenów społecznościowych / memecoinów - Odwołanie treasury i deny cap jest zasadniczo wymagane, aby być poważnie traktowanym przez DEXy Sui i trackery listowania
• Tak, dla tokenów DeFi o stałej podaży - Pokazuje, że podaż nigdy nie wzrośnie, a metadane nigdy się nie zmienią
• Jeszcze nie, dla projektów na wczesnym etapie - Zachowaj capy do ustabilizowania tokenomii i operacji
• W ogóle nie, dla regulowanych stablecoinów lub aktywów związanych z zgodnością - Zachowanie deny cap jest często wymogiem regulacyjnym

Wiele dojrzałych projektów stosuje podejście etapowe: najpierw transfer capów do zarządzania multisig, potem odwołanie po dojrzewaniu ekosystemu.