Kakalabas lang ng Uniswap ng bagong pamantayan sa pag-apruba ng token, Permit2, na naiiba sa tradisyonal na ERC20 at EIP-2612. Ang Permit2 ay nagbibigay-daan sa mga user na maiwasan ang pangangailangan para sa isang chain-level na "pag-apruba" na operasyon bago makipag-ugnayan sa iba't ibang DApps, na nagpapahintulot sa DApp protocol na makuha muna ang iyong pag-apruba ng token. Ayon sa paglalarawan, ang bagong protocol ng Permit2 ay may mga bentahe ng pagtitipid ng gas, na nagbibigay-daan para sa mga batch na operasyon ng pag-apruba/paglipat at pagiging mas flexible kaysa sa tradisyonal na pag-apruba ng ERC20, at pagsuporta sa one-stop na pamamahala sa pag-apruba.

Una nang inisip ng Uniswap ang Permit2 at Universal Router upang pahusayin ang sarili nitong produkto, i-optimize ang mga gastos sa gas, pasimplehin ang proseso ng transaksyon ng user, at pahusayin ang seguridad. Sa panahon ng konseptong proseso, nadama ng Uniswap na ang ibang mga application ay maaaring makinabang nang malaki sa pagsasama ng mga kontratang ito. Ang Uniswap mismo ay nakatuon sa pagbuo ng pampublikong imprastraktura, kaya idinisenyo nito ang mga kontratang ito para magamit ng buong ecosystem ng developer, kabilang ang malawak na dokumentasyon at SDK.

Upang ilarawan kung gaano ka rebolusyonaryo ang Permit2, suriin natin ang mga nakaraang solusyon sa pamamagitan ng pagkuha ng halimbawa ng isang kontrata na kailangang ilipat ang mga token na hawak ni Alice.

Ang tradisyonal na paraan ng pagpapatupad ay ipinapakita sa sumusunod na diagram.

1. Tinatawag ni Alice ang approve() function sa ERC20 para bigyan ang kontrata ng limitasyon sa pagkontrol.

2. Tumawag si Alice ng isang function ng pakikipag-ugnayan sa kontrata, na tumatawag naman sa transferFrom() sa kontrata ng token ng ERC20 upang ilipat ang kanyang mga token. Maliwanag na ang modelong ito ay magagawa (dahil ito ay malawak na umiiral) at sa huli ay maaaring maging napaka-flexible, dahil patuloy na maa-access ng protocol ang mga token ng user sa loob ng mahabang panahon.

Ang kontrata sa pag-apruba ay binibigyan ng pag-apruba upang kontrolin ang maximum na halaga ng mga token bilang default, nang walang anumang limitasyon sa oras. Ang bawat DApp ay nangangailangan ng isang beses na pag-apruba para sa unang pagpapatupad, na nagdudulot ng malalaking panganib.

Ngunit nahaharap ito sa dalawang kilalang problema sa totoong mundo:

1. Hindi magandang karanasan ng user: Dapat magbigay ang mga user ng pag-apruba para sa bawat bagong protocol na nilalayon nilang gamitin sa bawat token, na halos palaging isang hiwalay na transaksyon (halimbawa, pagsasagawa ng pag-apruba ng token sa Uniswap, ngunit kailangan pa ring aprubahang muli kung gumagamit ng Transit).

2. Hindi magandang seguridad: Ang mga kontrata ay karaniwang nangangailangan ng walang limitasyong limitasyon sa pag-apruba, at ang pag-apruba ay dapat isagawa sa tuwing may swap o ibang kontrata na ginagamit. Nangangahulugan ito na kung ang protocol ay pinagsamantalahan, ang bawat user na nag-apruba sa protocol na ubusin ang kanilang mga token ay maaaring ilipat ang lahat ng kanilang mga naaprubahang token. (Halimbawa, madalas kaming nakakaranas ng pag-apruba sa paggamit ng token, gaya ng pag-apruba sa pagpapatakbo ng DeFi, pag-apruba sa palitan, at pag-apruba para sa unang beses na paggamit ng iba't ibang DApps)

Ang EIP-2612 ay umuulit sa pag-apruba ng token. Maaaring makipag-ugnayan ang mga user sa kontrata ng aplikasyon sa pamamagitan ng pag-attach ng impormasyon ng pirma sa pag-apruba (Permit) sa kanilang transaksyon, nang hindi kinakailangang mag-pre-approve.

Tingnan natin ang mga pamamaraan na pinagana ng EIP-2612 extension ng ERC20, na kadalasang ganito:

1. Pumirma si Alice ng isang "permit" na mensahe sa labas ng chain, na nagsasaad na nais niyang bigyan ang isang kontrata ng karapatang gumamit ng isang (EIP-2612) token.

2. Isinumite ni Alice ang pinirmahang mensahe bilang bahagi ng kanyang pakikipag-ugnayan sa nasabing kontrata.

3. Tinatawag ng kontrata ang "permit()" na paraan sa token, na gumagamit ng signature approval information at signature para bigyan ang kontrata ng pahintulot.

4. Ang kontrata ay mayroon na ngayong pahintulot, kaya maaari nitong tawagan ang transferFrom() sa token, paglilipat ng mga token na hawak ni Alice.

Dahil sa pangangailangan ng EIP-2612 (Permit) na maisulat ang mga nauugnay na pamamaraan sa loob ng kontrata ng token ng ERC20, hindi maaaring suportahan ang mga kasalukuyang naka-deploy na kontrata ng ERC20.

Niresolba nito ang dalawang problema sa karaniwang paraan ng pag-apruba ng ERC20:

1. Ang user ay hindi kailangang magsumite ng karagdagang aprubahan() transaksyon on-chain.

2. Dahil ang isang on-chain na operasyon ay tinanggal, ang karaniwang mas makatwirang halaga ng pag-apruba ay maaaring piliin sa halip na walang limitasyon, at higit sa lahat, maaaring magtakda ng oras ng pag-expire kapag pumirma sa mensahe ng pag-apruba.

Habang ginagawang mas secure ng EIP-2612 ang pag-apruba ng token, ang mga token na inilabas bago ang EIP-2612 ay hindi sumusuporta sa pag-apruba ng lagda at hindi lahat ng mas bagong token ay nagpatibay ng feature na ito. Samakatuwid, ang protocol ay hindi malawakang ginagamit.

Pinagsasama ng Permit2 ang parehong mga modelo, na nagpapalawak sa karanasan ng gumagamit at mga pakinabang sa seguridad ng EIP-2612 upang masakop din ang mga karaniwang ERC20 token.

1. Tumawag si Alice ng approve() sa isang ERC20, sa karaniwang paraan, na nagbibigay ng walang limitasyong pag-apruba sa kontrata ng Permit2.

2. Pumirma si Alice ng isang Permit2 na mensahe sa labas ng chain, na nagsasaad na pinapayagan ang kontrata ng protocol na maglipat ng mga token sa ngalan niya.

3. Tinatawag ni Alice ang function ng pakikipag-ugnayan sa kontrata ng protocol, na ipinapasa ang nilagdaang Permit2 na mensahe bilang argumento.

4. Tinatawag ng kontrata ng protocol ang permitTransferFrom() sa kontrata ng Permit2, at ginagamit ng kontrata ng Permit2 ang pag-apruba nito (ibinigay sa 1) para tawagan ang “transferFrom()” sa kontrata ng ERC20, na naglilipat ng mga token na hawak ni Alice.

Sa pamamagitan ng pagbibigay ng pag-apruba sa Permit2, kailangan lang ng mga DApp na gumagamit ng Permit2 protocol na magsagawa ng 712 local signature nang isang beses, na inaalis ang pangangailangan para sa karagdagang pag-apruba sa antas ng chain at binabawasan ang mga bayarin sa Gas, habang pinapataas ang kakayahang magamit at seguridad. Ang pag-apruba ay limitado sa oras, halimbawa, kung ipinagkaloob sa loob ng isang buwan, pagkatapos ay pagkatapos mag-expire ang buwan, nangangailangan lamang ito ng isang 712 na lagda upang magamit muli.

Ang protocol ay hindi direktang tatawag sa transferFrom() sa ERC20 token para isagawa ang transfer ngunit sa halip ay tatawagan ang karaniwang Permit2 contract's permitTransferFrom(). Nasa pagitan ng protocol at ng token ng ERC20 ang Permit2, sinusubaybayan at pinapatunayan ang mensahe ng permit2, at sa huli ay ginagamit ang pag-apruba nito upang maisagawa ang direktang () tawag sa transferFrom sa ERC20. Ang hindi direktang ito ay nagpapahintulot sa Permit2 na palawigin ang mga benepisyong katulad ng EIP-2612 sa bawat umiiral na token ng ERC20.

1. Pinag-isang pamamahala ng token

2. Kinokontrol na oras ng pag-apruba

3. Hindi na kailangang magpadala ng transaksyon para sa pag-apruba sa bawat oras

Ang Permit2 ay hinango mula sa EIP 2612 at isang extension ng EIP 20 protocol, kaya sa huli, ang Permit2 ay pandagdag lamang sa ERC20, hindi isang kapalit. Pagkatapos ng lahat, ang Permit2 ay hindi nagmamana ng lahat ng umiiral na data ng ERC20, at ang tinatawag na one-stop na pamamahala ay nangangailangan pa rin ng pagtawag sa approve function ng kontrata ng ERC20 upang makumpleto ang ilang mga paunang operasyon.

Ang kumpletong proseso ng Permit2 ay dapat na:

1. Ibinibigay ng user ang maximum na pag-apruba ng mga token ng ERC20 sa kontrata ng Permit2.

2. Pinamamahalaan ng user ang mga partikular na pag-apruba sa pamamagitan ng permit function sa kontrata ng Permit2.

3. Ang mga protocol ng third-party at mga user ay maaaring maglipat ng mga token sa pamamagitan ng kontrata ng Permit2 bilang isang tagapamagitan batay sa impormasyon ng pag-apruba na available na sa Permit2.

1. Bagama't sinasabi nitong lutasin ang problema sa pag-apruba ng infinity, inililipat lang nito ang object ng pag-apruba mula sa nakikipag-ugnayang DApp patungo sa kontrata ng Permit2, at ang seguridad ng kontrata ng Permit2 ay nangangailangan ng mas matataas na pamantayan para sa sentralisadong pamamahala ng mga pag-apruba.

2. Bagama't ang pag-apruba ng token ay may oras ng pag-expire, ang oras na ito ay maaari pa ring maging walang limitasyon, at kailangan pa rin ng Dapps na magtakda ng mga makatwirang oras ng pag-expire.

3. Dahil ang proseso ng pagtawag sa function ng permit ay maaaring isagawa nang hindi nagpapadala ng transaksyon, pagbibigay lamang ng pirma sa isang third party para sa pagpapasa, maaari itong mas maitago kung ito ay ginagamit para sa phishing. Ang halaga ng pagsuri sa signature message ay tumataas, at ang ilang mga third-party na wallet ay maaaring hindi mag-decode at magpakita ng signature na impormasyon, na nagpapataas ng panganib ng pag-atake ng user.

Ang mga kalamangan at panganib ay umiiral sa parehong oras, na nangangailangan sa atin na magkaroon ng isang tiyak na kakayahan sa pag-unawa. Sa partikular, kailangan ding magkaroon ng paunang pag-iwas ang wallet para sa posibleng malakihang suporta ng Permit2 sa hinaharap (hindi pa sinusuportahan ng TokenPocket ang pag-parse ng Permit2, ngunit malapit na). Halimbawa, ang kasalukuyang mga pop-up window ng babala sa panganib sa pag-apruba ng TokenPocket ay maaaring maipakita nang maayos ang nilalaman ng peligro, kaya maiiwasan ang mga panganib tulad ng phishing o malisyosong pag-apruba mula sa mga third party.

Huwag buksan ang mga hindi kilalang website at isagawa ang mga ito nang walang ingat. Tiyaking gumamit ng mga regular na DApp at kontrolin ang dami ng mga token na ibinibigay sa mga kontrata hangga't maaari. Regular na gumamit ng mga tool sa pagsusuri ng awtorisasyon para sa inspeksyon.

Ang TokenPocket ay ang nangungunang multi-chain na self-custodial wallet sa mundo, na sumusuporta sa mga pangunahing public chain kabilang ang BTC, ETH, BSC, TRON, Polygon, Solana, HECO, Klaytn, Avalanche, OKC, HSC, Fantom, Polkadot, Kusama, atbp. Ang trinity ng TokenPocket mobile wallet, chrome extension wallet, at hardware wallet ay pormal na nabuo. Ang Secret Recovery Phrase at Private Key ay naka-store sa sariling device ng user at ganap na makokontrol ng user ang sarili niyang crypto asset. Ang TokenPocket ay nagbigay ng maaasahang mga serbisyo para sa higit sa 20 milyong mga gumagamit sa buong mundo. Ang bilang ng buwanang aktibong user ay lumampas sa 3.5 milyon at ang mga user ay matatagpuan sa higit sa 200 bansa sa buong mundo.

Website | Twitter | Telegram | Extension | Hardware Wallet | Fans Forum

Kakalabas lang ng Uniswap ng bagong pamantayan sa pag-apruba ng token, Permit2, na naiiba sa tradisyonal na ERC20 at EIP-2612. Ang Permit2 ay nagbibigay-daan sa mga user na maiwasan ang pangangailangan para sa isang chain-level na "pag-apruba" na operasyon bago makipag-ugnayan sa iba't ibang DApps, na nagpapahintulot sa DApp protocol na makuha muna ang iyong pag-apruba ng token. Ayon sa paglalarawan, ang bagong protocol ng Permit2 ay may mga bentahe ng pagtitipid ng gas, na nagbibigay-daan para sa mga batch na operasyon ng pag-apruba/paglipat at pagiging mas flexible kaysa sa tradisyonal na pag-apruba ng ERC20, at pagsuporta sa one-stop na pamamahala sa pag-apruba.

Una nang inisip ng Uniswap ang Permit2 at Universal Router upang pahusayin ang sarili nitong produkto, i-optimize ang mga gastos sa gas, pasimplehin ang proseso ng transaksyon ng user, at pahusayin ang seguridad. Sa panahon ng konseptong proseso, nadama ng Uniswap na ang ibang mga application ay maaaring makinabang nang malaki sa pagsasama ng mga kontratang ito. Ang Uniswap mismo ay nakatuon sa pagbuo ng pampublikong imprastraktura, kaya idinisenyo nito ang mga kontratang ito para magamit ng buong ecosystem ng developer, kabilang ang malawak na dokumentasyon at SDK.

Upang ilarawan kung gaano ka rebolusyonaryo ang Permit2, suriin natin ang mga nakaraang solusyon sa pamamagitan ng pagkuha ng halimbawa ng isang kontrata na kailangang ilipat ang mga token na hawak ni Alice.

Ang tradisyonal na paraan ng pagpapatupad ay ipinapakita sa sumusunod na diagram.

1. Tinatawag ni Alice ang approve() function sa ERC20 para bigyan ang kontrata ng limitasyon sa pagkontrol.

2. Tumawag si Alice ng isang function ng pakikipag-ugnayan sa kontrata, na tumatawag naman sa transferFrom() sa kontrata ng token ng ERC20 upang ilipat ang kanyang mga token. Maliwanag na ang modelong ito ay magagawa (dahil ito ay malawak na umiiral) at sa huli ay maaaring maging napaka-flexible, dahil patuloy na maa-access ng protocol ang mga token ng user sa loob ng mahabang panahon.

Ang kontrata sa pag-apruba ay binibigyan ng pag-apruba upang kontrolin ang maximum na halaga ng mga token bilang default, nang walang anumang limitasyon sa oras. Ang bawat DApp ay nangangailangan ng isang beses na pag-apruba para sa unang pagpapatupad, na nagdudulot ng malalaking panganib.

Ngunit nahaharap ito sa dalawang kilalang problema sa totoong mundo:

1. Hindi magandang karanasan ng user: Dapat magbigay ang mga user ng pag-apruba para sa bawat bagong protocol na nilalayon nilang gamitin sa bawat token, na halos palaging isang hiwalay na transaksyon (halimbawa, pagsasagawa ng pag-apruba ng token sa Uniswap, ngunit kailangan pa ring aprubahang muli kung gumagamit ng Transit).

2. Hindi magandang seguridad: Ang mga kontrata ay karaniwang nangangailangan ng walang limitasyong limitasyon sa pag-apruba, at ang pag-apruba ay dapat isagawa sa tuwing may swap o ibang kontrata na ginagamit. Nangangahulugan ito na kung ang protocol ay pinagsamantalahan, ang bawat user na nag-apruba sa protocol na ubusin ang kanilang mga token ay maaaring ilipat ang lahat ng kanilang mga naaprubahang token. (Halimbawa, madalas kaming nakakaranas ng pag-apruba sa paggamit ng token, gaya ng pag-apruba sa pagpapatakbo ng DeFi, pag-apruba sa palitan, at pag-apruba para sa unang beses na paggamit ng iba't ibang DApps)

Ang EIP-2612 ay umuulit sa pag-apruba ng token. Maaaring makipag-ugnayan ang mga user sa kontrata ng aplikasyon sa pamamagitan ng pag-attach ng impormasyon ng pirma sa pag-apruba (Permit) sa kanilang transaksyon, nang hindi kinakailangang mag-pre-approve.

Tingnan natin ang mga pamamaraan na pinagana ng EIP-2612 extension ng ERC20, na kadalasang ganito:

1. Pumirma si Alice ng isang "permit" na mensahe sa labas ng chain, na nagsasaad na nais niyang bigyan ang isang kontrata ng karapatang gumamit ng isang (EIP-2612) token.

2. Isinumite ni Alice ang pinirmahang mensahe bilang bahagi ng kanyang pakikipag-ugnayan sa nasabing kontrata.

3. Tinatawag ng kontrata ang "permit()" na paraan sa token, na gumagamit ng signature approval information at signature para bigyan ang kontrata ng pahintulot.

4. Ang kontrata ay mayroon na ngayong pahintulot, kaya maaari nitong tawagan ang transferFrom() sa token, paglilipat ng mga token na hawak ni Alice.

Dahil sa pangangailangan ng EIP-2612 (Permit) na maisulat ang mga nauugnay na pamamaraan sa loob ng kontrata ng token ng ERC20, hindi maaaring suportahan ang mga kasalukuyang naka-deploy na kontrata ng ERC20.

Niresolba nito ang dalawang problema sa karaniwang paraan ng pag-apruba ng ERC20:

1. Ang user ay hindi kailangang magsumite ng karagdagang aprubahan() transaksyon on-chain.

2. Dahil ang isang on-chain na operasyon ay tinanggal, ang karaniwang mas makatwirang halaga ng pag-apruba ay maaaring piliin sa halip na walang limitasyon, at higit sa lahat, maaaring magtakda ng oras ng pag-expire kapag pumirma sa mensahe ng pag-apruba.

Habang ginagawang mas secure ng EIP-2612 ang pag-apruba ng token, ang mga token na inilabas bago ang EIP-2612 ay hindi sumusuporta sa pag-apruba ng lagda at hindi lahat ng mas bagong token ay nagpatibay ng feature na ito. Samakatuwid, ang protocol ay hindi malawakang ginagamit.

Pinagsasama ng Permit2 ang parehong mga modelo, na nagpapalawak sa karanasan ng gumagamit at mga pakinabang sa seguridad ng EIP-2612 upang masakop din ang mga karaniwang ERC20 token.

1. Tumawag si Alice ng approve() sa isang ERC20, sa karaniwang paraan, na nagbibigay ng walang limitasyong pag-apruba sa kontrata ng Permit2.

2. Pumirma si Alice ng isang Permit2 na mensahe sa labas ng chain, na nagsasaad na pinapayagan ang kontrata ng protocol na maglipat ng mga token sa ngalan niya.

3. Tinatawag ni Alice ang function ng pakikipag-ugnayan sa kontrata ng protocol, na ipinapasa ang nilagdaang Permit2 na mensahe bilang argumento.

4. Tinatawag ng kontrata ng protocol ang permitTransferFrom() sa kontrata ng Permit2, at ginagamit ng kontrata ng Permit2 ang pag-apruba nito (ibinigay sa 1) para tawagan ang “transferFrom()” sa kontrata ng ERC20, na naglilipat ng mga token na hawak ni Alice.

Sa pamamagitan ng pagbibigay ng pag-apruba sa Permit2, kailangan lang ng mga DApp na gumagamit ng Permit2 protocol na magsagawa ng 712 local signature nang isang beses, na inaalis ang pangangailangan para sa karagdagang pag-apruba sa antas ng chain at binabawasan ang mga bayarin sa Gas, habang pinapataas ang kakayahang magamit at seguridad. Ang pag-apruba ay limitado sa oras, halimbawa, kung ipinagkaloob sa loob ng isang buwan, pagkatapos ay pagkatapos mag-expire ang buwan, nangangailangan lamang ito ng isang 712 na lagda upang magamit muli.

Ang protocol ay hindi direktang tatawag sa transferFrom() sa ERC20 token para isagawa ang transfer ngunit sa halip ay tatawagan ang karaniwang Permit2 contract's permitTransferFrom(). Nasa pagitan ng protocol at ng token ng ERC20 ang Permit2, sinusubaybayan at pinapatunayan ang mensahe ng permit2, at sa huli ay ginagamit ang pag-apruba nito upang maisagawa ang direktang () tawag sa transferFrom sa ERC20. Ang hindi direktang ito ay nagpapahintulot sa Permit2 na palawigin ang mga benepisyong katulad ng EIP-2612 sa bawat umiiral na token ng ERC20.

1. Pinag-isang pamamahala ng token

2. Kinokontrol na oras ng pag-apruba

3. Hindi na kailangang magpadala ng transaksyon para sa pag-apruba sa bawat oras

Ang Permit2 ay hinango mula sa EIP 2612 at isang extension ng EIP 20 protocol, kaya sa huli, ang Permit2 ay pandagdag lamang sa ERC20, hindi isang kapalit. Pagkatapos ng lahat, ang Permit2 ay hindi nagmamana ng lahat ng umiiral na data ng ERC20, at ang tinatawag na one-stop na pamamahala ay nangangailangan pa rin ng pagtawag sa approve function ng kontrata ng ERC20 upang makumpleto ang ilang mga paunang operasyon.

Ang kumpletong proseso ng Permit2 ay dapat na:

1. Ibinibigay ng user ang maximum na pag-apruba ng mga token ng ERC20 sa kontrata ng Permit2.

2. Pinamamahalaan ng user ang mga partikular na pag-apruba sa pamamagitan ng permit function sa kontrata ng Permit2.

3. Ang mga protocol ng third-party at mga user ay maaaring maglipat ng mga token sa pamamagitan ng kontrata ng Permit2 bilang isang tagapamagitan batay sa impormasyon ng pag-apruba na available na sa Permit2.

1. Bagama't sinasabi nitong lutasin ang problema sa pag-apruba ng infinity, inililipat lang nito ang object ng pag-apruba mula sa nakikipag-ugnayang DApp patungo sa kontrata ng Permit2, at ang seguridad ng kontrata ng Permit2 ay nangangailangan ng mas matataas na pamantayan para sa sentralisadong pamamahala ng mga pag-apruba.

2. Bagama't ang pag-apruba ng token ay may oras ng pag-expire, ang oras na ito ay maaari pa ring maging walang limitasyon, at kailangan pa rin ng Dapps na magtakda ng mga makatwirang oras ng pag-expire.

3. Dahil ang proseso ng pagtawag sa function ng permit ay maaaring isagawa nang hindi nagpapadala ng transaksyon, pagbibigay lamang ng pirma sa isang third party para sa pagpapasa, maaari itong mas maitago kung ito ay ginagamit para sa phishing. Ang halaga ng pagsuri sa signature message ay tumataas, at ang ilang mga third-party na wallet ay maaaring hindi mag-decode at magpakita ng signature na impormasyon, na nagpapataas ng panganib ng pag-atake ng user.

Ang mga kalamangan at panganib ay umiiral sa parehong oras, na nangangailangan sa atin na magkaroon ng isang tiyak na kakayahan sa pag-unawa. Sa partikular, kailangan ding magkaroon ng paunang pag-iwas ang wallet para sa posibleng malakihang suporta ng Permit2 sa hinaharap (hindi pa sinusuportahan ng TokenPocket ang pag-parse ng Permit2, ngunit malapit na). Halimbawa, ang kasalukuyang mga pop-up window ng babala sa panganib sa pag-apruba ng TokenPocket ay maaaring maipakita nang maayos ang nilalaman ng peligro, kaya maiiwasan ang mga panganib tulad ng phishing o malisyosong pag-apruba mula sa mga third party.

Huwag buksan ang mga hindi kilalang website at isagawa ang mga ito nang walang ingat. Tiyaking gumamit ng mga regular na DApp at kontrolin ang dami ng mga token na ibinibigay sa mga kontrata hangga't maaari. Regular na gumamit ng mga tool sa pagsusuri ng awtorisasyon para sa inspeksyon.

Ang TokenPocket ay ang nangungunang multi-chain na self-custodial wallet sa mundo, na sumusuporta sa mga pangunahing public chain kabilang ang BTC, ETH, BSC, TRON, Polygon, Solana, HECO, Klaytn, Avalanche, OKC, HSC, Fantom, Polkadot, Kusama, atbp. Ang trinity ng TokenPocket mobile wallet, chrome extension wallet, at hardware wallet ay pormal na nabuo. Ang Secret Recovery Phrase at Private Key ay naka-store sa sariling device ng user at ganap na makokontrol ng user ang sarili niyang crypto asset. Ang TokenPocket ay nagbigay ng maaasahang mga serbisyo para sa higit sa 20 milyong mga gumagamit sa buong mundo. Ang bilang ng buwanang aktibong user ay lumampas sa 3.5 milyon at ang mga user ay matatagpuan sa higit sa 200 bansa sa buong mundo.

Website | Twitter | Telegram | Extension | Hardware Wallet | Fans Forum