Koneksi dompet Dusk pada senja terlihat seperti satu klik sederhana. Tapi saat saya mulai melihat apa yang ada di baliknya, saya menyadari ternyata ada banyak hal yang terjadi.
Saya menelusuri alur penemuan dompet terlebih dahulu. Sebuah dApp tidak langsung mengambil dompet Dusk mana pun yang kebetulan ada di halaman. Dompet akan mengumumkan dirinya, dApp menemukannya, dan jika terpasang lebih dari satu, penyedia harus dipilih. Masing-masing juga membawa identitasnya sendiri. Ini detail kecil, tetapi penting karena situs perlu tahu dompet mana yang benar-benar sedang diajak berbicara.
Lalu saya melihat sisi perizinannya. Permintaan profil, alamat terima yang disamarkan, transaksi, pemanggilan kontrak, atau tanda tangan tidak semuanya hal yang sama. Mereka melewati permintaan dompet yang berbeda, dan dompet juga dapat melaporkan perubahan profil, chain, serta node yang dipilih selama koneksi masih aktif. Jadi “terhubung” tidak benar-benar berarti dApp punya akses tak terbatas.
Bagian penandatanganan adalah yang paling menarik bagi saya. Dusk memasukkan origin dan chain ID ke dalam konteks pesan yang ditandatangani. Auth signing juga membawa nonce dan cap waktu. Jadi tanda tangan itu bukan sekadar “akun ini menandatangani sesuatu” — ada konteks di sekitar permintaannya juga.
Saya juga memeriksa perubahan dompet terbaru terkait hal ini. Pesan provider dibatasi sehingga provider Dusk lain yang terpasang tidak bisa menerima permintaan dApp yang sama. Penanganan origin dan izin diperketat, dan koneksi dApp RPC serta koneksi custom-node dibatasi hanya ke endpoint HTTPS atau untuk pengembangan lokal. Catatan keamanan Dusk sendiri juga menyebut batasan seperti memori JavaScript yang tidak dapat dihapus secara andal.
Bagi saya, ini mengubah cara tombol kecil “Connect Wallet” terlihat. Ini bukan benar-benar satu izin. Ada lapisan penuh di antara situs web dan kunci yang memutuskan dompet mana yang digunakan, apa yang bisa diminta dApp, dan apa yang sesungguhnya ditandatangani pengguna.
Saya pikir kita biasanya mengajukan pertanyaan yang salah ketika transaksi Dusk “gagal”.
“202 Accepted” hanya berarti node menerima permintaan untuk perutean (routing). Itu tidak berarti transaksi sudah ada di mempool atau sudah masuk ke sebuah blok. Salah satu contoh yang saya temukan menarik adalah nonce masa depan. Jika transaksi Moonlight datang dengan nonce yang lebih besar (masa depan) sementara nonce yang lebih awal masih hilang, Dusk dapat menahannya di luar mempool nyata (real mempool) dan menunggu celah nonce tersebut tertutup, alih-alih menolaknya segera. Selama proses itu, transaksi tersebut berada dalam status tertunda (deferred).
Itu hanya satu bagian dari ceritanya. Setelah sebuah transaksi lolos admission, transaksi tersebut masuk ke mempool lokal node itu. Node-node lain tetap memiliki mempool mereka sendiri dan menjalankan pemeriksaan admission mereka sendiri juga. Belakangan, sebuah transaksi bisa dipilih untuk sebuah blok, dieksekusi, dan akhirnya diselesaikan (finalized). Transaksi itu juga bisa keluar dari mempool lokal tanpa itu otomatis berarti transaksi gagal. Kedaluwarsa (expiry), penggantian (replacement), batas kapasitas, dan konflik semuanya dapat menyebabkan penghapusan.
Di sinilah menurut saya perbedaannya penting untuk wallet dan exchange. Panduan integrasi Dusk sendiri menyarankan untuk menyimpan transaksi bertanda tangan yang persis (exact signed transaction), memperlakukan “202 Accepted” hanya sebagai routing yang sukses, dan mengirim ulang (rebroadcast) byte transaksi bertanda tangan yang sama setelah timeout transport, bukan membuat transaksi baru secara membabi buta. Penarikan (withdrawal) seharusnya hanya ditandai selesai setelah eksekusi diperiksa dan blok sudah difinalisasi.
Semakin saya memeriksanya, semakin “transaction submitted” terdengar tidak terlalu seperti status yang berguna jika berdiri sendiri. Sebuah transaksi bisa saja sedang menunggu nonce, berada di mempool salah satu node, dieksekusi dengan error, atau berada di sebuah blok yang belum final. Itu semua adalah situasi yang sangat berbeda, meskipun dari luar semuanya bisa terlihat seperti “masih pending”.
Bagi saya, itu adalah pelajaran yang bermanfaat dari alur transaksi Dusk: “submitted” hanya permulaan. Yang penting adalah status yang benar-benar bisa Anda buktikan bahwa transaksi tersebut telah mencapai.
Transfer 280 itu menarik perhatian saya, tapi pada akhirnya saya lebih memperhatikan semua hal di sekelilingnya.
Saya menelusuri pekerjaan sign-off Hyperlane Dusk terbaru dan pengujian sejauh ini terlihat solid. Reproduksi bersih terbaru berhasil melewati build kontrak, uji VM, uji transaksi, dan pemeriksaan agen Hyperlane. Setelah itu, soak bervolume tinggi berjalan 7 siklus, dengan masing-masing siklus memuat 20 transfer dari EVM ke Dusk dan 20 transfer dari Dusk ke EVM. Itu menghasilkan total 280 transfer selama 7.282 detik sebelum jendela uji 120 menit berakhir.
Yang saya anggap lebih penting adalah checklist produksi yang berdampingan dengan hasil-hasil tersebut. Kustodian penandatangan produksi masih sedang diputuskan. Ada juga keputusan terbuka terkait pemulihan escrow yang tertunda, berapa lama soak harus dijalankan, serta bagaimana pengaturan CI dan kemampuan reproduksi akan bekerja. Hal-hal ini mudah terlewat ketika angka utama menunjukkan uji yang berhasil, tetapi justru hal-hal itulah yang ingin saya pahami sebelum likuiditas nyata terlibat.
Pertanyaan tentang signer menjadi sangat sulit untuk diabaikan setelah kejadian pada jembatan lama Dusk ke EVM di bulan Januari. Seorang penyerang mendapatkan akses ke dompet penandatangan jembatan, mencuri DUSK dari dompet tersebut, lalu memindahkan sebagian dana yang dicuri melalui jembatan ke BNB Smart Chain. Dusk menegaskan bahwa insiden tersebut adalah kompromi pada dompet jembatan, bukan eksploit konsensus atau protokol Dusk. Jembatan kemudian didesain ulang dengan pemisahan yang lebih kuat antara penandatangan, penanganan event, dan pelepasan dana, beserta pengendalian keseimbangan dan pemulihan yang lebih ketat.
Jadi saya tidak memandang 280 transfer itu sebagai lampu hijau atau bendera merah. Itu menunjukkan bahwa sistem sedang diuji dengan serius. Yang menjadi perhatian saya sekarang adalah bagaimana sistem seharusnya berperilaku ketika sesuatu terjadi yang salah, siapa yang mengendalikan bagian-bagian yang sensitif, dan bagaimana pemulihan ditangani.
Itulah yang ingin saya pastikan terselesaikan sebelum memperlakukan Dusk Hyperlane sebagai infrastruktur untuk likuiditas yang bermakna.
Hal kecil tentang transaksi Dusk yang terus mengganggu saya.
Saya sedang membaca alur transaksi Dusk dan mendapati bahwa satu transaksi saat ini membawa satu operasi. Untuk sesuatu yang mendasar, itu sebenarnya cukup masuk akal. Hal itu membuat validasi dan pemahaman menjadi lebih mudah. Namun kemudian saya memikirkan alur DeFi yang lebih kompleks, seperti menyiapkan dana, melakukan swap, lalu staking. Bagi pengguna, itu terasa seperti satu aksi. Di Dusk, itu berubah menjadi beberapa transaksi terpisah, masing-masing dengan nonce, tanda tangan, dan peluangnya sendiri untuk dimasukkan.
Di situlah saya mulai bertanya-tanya apa yang terjadi jika hanya sebagian dari rangkaian tersebut yang berhasil. Tidak ada rollback di tingkat protokol di antara transaksi-transaksi itu, sehingga Anda bisa berakhir setengah jalan dalam sebuah alur yang lebih besar. Untuk perdagangan biasa, mungkin bukan masalah besar. Tapi untuk DeFi, operasi settlement atau treasury, saya bisa melihat ini menjadi sakit kepala yang nyata.
Yang menarik bagi saya adalah Dusk sudah memiliki isu GitHub terbuka, #4058, yang membahas transaksi batch. Salah satu idenya adalah kontrak batcher yang memasukkan beberapa panggilan ke dalam satu transaksi, tetapi kontrak yang menggunakan caller() bisa melihat batcher, bukan pengguna asli. Opsi lainnya adalah batch tingkat protokol di mana beberapa operasi tetap berada di bawah identitas pengguna, tetapi itu berarti perubahan pada format transaksi, dukungan konsensus, aktivasi hard fork, dan SDK.
Jadi saya tidak akan menggantikan model operasi tunggal yang ada. Menurut saya masuk akal sebagai default yang sederhana. Saya lebih memilih adanya batch atomik yang opsional untuk workflow yang kompleks, di mana operasi dijalankan berurutan, seluruh batch bisa kembali (revert) jika salah satu gagal, dan pengguna asli tetap terlihat untuk setiap panggilan.
Apakah itu keseimbangan yang tepat untuk Dusk, atau kompleksitas protokol tambahan itu tidak sepadan?
#dusk $DUSK @Dusk Saya baru-baru ini melihat sisi UKM/SME dari Dusk, dan satu hal terus muncul dalam benak saya.
Menyusun token untuk sebuah SME terdengar sederhana kalau Anda mengatakannya dalam satu baris.
Taruh aset di onchain. Beri investor akses ke sana. Selesai.
Namun kenyataannya tidak sesederhana itu.
Masih ada pihak yang harus memutuskan siapa yang bisa berinvestasi, bagaimana kepemilikan dikelola, bagaimana transfer berjalan, informasi apa yang perlu diungkapkan, dan bagaimana uang sebenarnya diselesaikan.
Di sinilah saya merasa orang kadang meremehkan masalah RWA. Token itu sendiri hanyalah satu bagian dari prosesnya. Pasar di sekelilingnya tetap harus berfungsi.
Di sinilah pendekatan Dusk menurut saya menarik.
Fokus terbaru mereka pada pasar privat dan UKM/SME sebenarnya bukan sekadar soal menaruh aset lain di blockchain demi alasan semata. Lebih tentang menghubungkan bagian-bagian berbeda dari proses tersebut.
Karena bagian yang sulit bukanlah menciptakan token.
Bagian tersulit adalah membuat token tersebut bisa digunakan. Sebuah SME bisa memiliki sekuritas yang ditokenisasi, tetapi kalau investor tidak bisa mengaksesnya dengan benar, transfer jadi rumit, atau tidak ada pasar nyata di sekitarnya, maka perubahan yang terjadi tidak terlalu signifikan.
Itu juga alasan saya penasaran melihat bagaimana sisi Dusk Trade berkembang.
Jika itu bisa membuat proses lebih sederhana baik untuk perusahaan maupun investor, maka ini menjadi lebih menarik daripada sekadar narasi RWA yang lain.
Meski begitu, masih awal.
Bagi saya, ujian yang sesungguhnya itu sederhana:
Bisakah Dusk benar-benar membuat pasar privat lebih mudah digunakan, atau kita hanya memindahkan proses lama ke onchain dan menyebutnya baru?
Itulah bagian yang akan saya pantau dengan seksama saat Dusk Trade mulai terbentuk.
Sudah mulai melihat lebih dalam bagaimana Dusk menangani transaksi, dan saya menyadari ada sesuatu yang sebelumnya belum benar-benar saya pikirkan.
Moonlight dan Phoenix bukan sekadar dua versi dari hal yang sama.
Moonlight bersifat berbasis akun. Anda memiliki akun, saldo, nonce, dan kunci, lalu jaringan memeriksa transaksi berdasarkan keadaan tersebut.
Phoenix mengambil pendekatan yang berbeda.
Phoenix menggunakan catatan (notes) yang disimpan dalam pohon Merkle. Saat sebuah catatan dibelanjakan, dibuatlah sebuah nullifier sehingga catatan yang sama tidak bisa dibelanjakan lagi.
Yang menarik perhatian saya adalah jaringan tidak perlu mengungkap catatan spesifik mana yang dibelanjakan.
Di sinilah pembuktian ZK berperan—transaksi bisa diverifikasi tanpa mengekspos detail privat yang mendasarinya. Kunci catatan sekali pakai (one-time note keys) juga membantu mengurangi keterkaitan transaksi.
Ada juga mekanisme delegasi untuk hal-hal seperti pemindaian (scanning) dan pembuatan bukti (proof generation), tanpa memberi pihak yang didelegasikan akses untuk membelanjakan dana.
Jadi saya tidak akan menggambarkannya sesederhana “Moonlight itu transparan dan Phoenix itu privat.”
Keduanya adalah model transaksi yang berbeda, dirancang berdasarkan kebutuhan yang berbeda, sambil tetap beroperasi pada jaringan Dusk yang sama.
Dan jujur saja, menurut saya itu pilihan desain yang cukup menarik.
Token berada di blockchain hanyalah permulaan. Pertanyaan sebenarnya adalah: apakah aturan seputar aset tersebut juga bisa bergerak ke blockchain? Ambil obligasi yang teregulasi. Mengubahnya menjadi token mungkin bagian yang mudah. Namun pasar keuangan yang nyata membutuhkan lebih dari itu: • Hanya investor yang memenuhi syarat yang boleh memilikinya • Transfer mungkin perlu pembatasan bawaan • Posisi yang sensitif tidak seharusnya dipublikasikan secara default • Pihak yang tepat perlu akses ke informasi yang tepat • Kas dan penyerahan aset perlu diselesaikan bersamaan Di sinilah tokenisasi menjadi lebih dari sekadar pembungkus digital. Ia menjadi infrastruktur pasar. Itulah mengapa @Dusk menonjol bagi saya. Fokusnya bukan hanya sekadar menempatkan aset di blockchain, melainkan memungkinkan alur kerja teregulasi di sekelilingnya—transfer yang terkontrol, pengungkapan selektif, privasi, kelayakan, dan penyelesaian sebagai bagian-bagian yang terhubung dalam satu sistem. Peluang yang lebih besar bukan sekadar aset yang ditokenkan. Ini adalah pasar yang bisa diprogram: Aturan yang mengikuti asetnya. Privasi yang bisa berdampingan dengan akuntabilitas. Penyelesaian yang terjadi sebagai bagian dari transaksi. Perubahan kepemilikan yang tidak merusak persyaratan kepatuhan. Jika model itu bekerja dalam skala besar, keuangan on-chain bisa terlihat kurang seperti pasar tradisional dengan basis data baru—dan lebih seperti sistem keuangan yang didesain ulang. Menurut Anda, rintangan paling sulit untuk keuangan dunia nyata agar bisa berpindah ke blockchain adalah: identitas, privasi, perdagangan, penyelesaian, atau layanan aset? $DUSK #dusk @Dusk
Hampir tidak ada yang membahas biaya untuk mengingat.
Sebuah jaringan bisa memproses aktivitas dalam jumlah yang sangat besar, tetapi setiap blok, peristiwa, dan transisi keadaan juga menciptakan data historis yang pada akhirnya harus disimpan dan dipelihara.
Itulah mengapa saya menganggap pembaruan infrastruktur terbaru Dusk lebih menarik daripada sekadar judul TPS lainnya.
Dusk menurunkan penyimpanan event archive-node dari 310,7 MB menjadi 27,7 MB — lebih dari 90% pengurangan — sekaligus tetap mempertahankan hasil historis.
Bagian yang menarik bukan sekadar angkanya.
Melainkan apa yang dikatakannya tentang infrastruktur blockchain.
Jika jaringan pada akhirnya akan mendukung aset keuangan dan aplikasi yang mungkin memerlukan verifikasi historis selama bertahun-tahun, efisiensi penyimpanan menjadi bagian dari arsitektur itu sendiri.
Skalabilitas bukan hanya soal memproses lebih banyak. Skalabilitas juga berarti membawa lebih sedikit data tanpa kehilangan riwayat yang membuat jaringan dapat diverifikasi.
Peningkatan ini mungkin tidak akan menghasilkan judul yang paling ramai.
Namun, pekerjaan infrastruktur yang membosankan sering kali justru yang memungkinkan adopsi skala besar.
Dusk tidak hanya mengerjakan apa yang terjadi on-chain.
Mereka juga meningkatkan seberapa efisien jaringan bisa “mengingat” apa yang terjadi.
Satu pembaruan One Dusk yang menurut saya layak mendapat perhatian lebih adalah peluncuran testnet DuskEVM.
Sekilas, “lingkungan EVM lainnya” terdengar kurang menarik. Tapi arsitekturnya menceritakan kisah yang berbeda.
DuskEVM menghadirkan Solidity, Hardhat, dan alat standar ekosistem Ethereum ke Dusk, sementara eksekusi diselesaikan melalui DuskDS. Pemisahan ini penting karena pengembang dapat memakai tumpukan aplikasi yang sudah familiar tanpa harus melepaskan lapisan penyelesaian dan ketersediaan data native milik Dusk.
Bagian yang lebih menarik justru ada di sekelilingnya.
Dusk juga sedang membangun Dusk Trade sebagai lapisan aplikasi untuk aset keuangan yang ditokenisasi, dengan alur kerja seputar onboarding investor, pengikatan wallet, transfer terkontrol, koordinasi pembayaran, dan penyelesaian yang patuh regulasi.
Jadi, perkembangan terbaru ini bukan sekadar soal menambahkan kompatibilitas EVM.
Ini tampaknya lebih seperti Dusk sedang bergerak menuju full stack, di mana tiap bagian menangani masalah yang berbeda:
→ DuskDS: konsensus, penyelesaian, dan ketersediaan data → DuskEVM: eksekusi EVM yang familiar → DuskVM: eksekusi native Rust/WASM dengan akses langsung ke kapabilitas privasi Dusk → Dusk Trade: infrastruktur tingkat aplikasi untuk pasar yang ditokenisasi
Dan di sinilah tesis RWA menjadi makin menarik.
Men-tokenisasi sebuah aset relatif mudah untuk dijelaskan. Membangun infrastruktur nyata untuk penerbitan, kelayakan, transfer, privasi, keterbukaan, dan penyelesaian adalah masalah yang jauh lebih sulit.
Dengan DuskEVM yang kini tersedia untuk pengujian dan Dusk Trade sedang dibangun berlandaskan alur kerja pasar yang nyata, hal berikutnya yang akan saya pantau bukanlah pengumuman lain.
Yang akan saya lihat adalah apa yang benar-benar dibangun oleh pengembang dan aplikasi keuangan di atas tumpukan ini.
Semakin saya melihat tokenisasi, semakin saya berpikir kita sedang mengajukan pertanyaan yang salah.
Semua orang bertanya: “Bisakah aset ini ditempatkan di blockchain?”
Namun bayangkan aset itu sebenarnya sudah ada di sana.
Sekarang seorang investor ingin membelinya. Yang lain ingin menjualnya. Penerbit perlu memastikan siapa saja yang boleh memegangnya. Seorang regulator mungkin perlu bukti nanti. Dan di suatu tempat di tengahnya, informasi sensitif tetap tidak boleh berubah menjadi data publik.
Bagian yang menarik bagi saya adalah @Dusk . Infrastruktur pasarnya sedang dirancang untuk mengakomodasi seluruh alur kerja—kelayakan, transfer yang terkontrol, privasi, pengungkapan, dan penyelesaian—daripada sekadar memperlakukan token sebagai produk akhir.
Mungkin terobosan sesungguhnya dalam RWA bukanlah menciptakan lebih banyak token.
Mungkin itu adalah membuat token-token tersebut benar-benar berperilaku seperti aset keuangan.
Bagian mana dari alur kerja itu yang menurut Anda paling sulit untuk dipecahkan?
A few days ago I was thinking about what “tokenizing an asset” actually means. At first, it sounds simple — take a stock, bond, or financial asset and put it onchain. But creating the token is probably the easy part.
The harder questions start after that. Who can actually hold it? What happens when someone tries to transfer it to the wrong wallet? What information needs to be visible for compliance, and what should stay private?
That’s where $DUSK gets interesting to me. Real financial assets need more than just fast transfers — they need rules, privacy, verification and settlement to work together without turning everything into a public spreadsheet.
Maybe the real challenge of RWA isn’t putting assets onchain. Maybe it’s building a system where financial markets can actually operate there without giving up the privacy and controls they already depend on. What do you think is the biggest missing piece? 👀
Satu masalah pada biaya Phoenix dapat memengaruhi integritas suplai, ketersediaan chain, dan keamanan refund. Masalah BLS melibatkan konstruksi kriptografis yang digunakan untuk verifikasi tanda tangan.
AEGIS tidak sekadar menambal satu baris lalu lanjut. Dusk mengatakan mereka menyusun ulang model kepemilikan yang terdampak, memperkuat batas-batas kepercayaan, menambahkan pengecekan konsistensi biaya di beberapa lapisan, memperkuat jalur BLS, dan menambahkan regression test yang dibentuk menyerupai pola eksploit.
Dan menurut Dusk, mereka tidak menemukan bukti bahwa temuan-temuan kritis itu pernah dieksploitasi sebelum AEGIS.
Bagi saya, itulah pesan yang paling penting.
Dalam keuangan yang teregulasi, privasi itu penting.
Tapi privasi tanpa keamanan tidak ada gunanya.
Infrastruktur harus mampu bertahan terhadap pemikiran advesarial sebelum institusi bisa mempercayainya.
Itulah sisi dari @Dusk yang menurut saya layak untuk diperhatikan:
tidak hanya apa yang dijanjikan protokol,
tapi seberapa serius ia merespons ketika seseorang mencoba merusaknya.
Dusk sedang membangun infrastruktur untuk keuangan onchain yang teregulasi, tempat privasi, kepatuhan, dan penyelesaian yang deterministik dapat bekerja bersama.
→ Moonlight untuk arus publik yang transparan → Phoenix untuk transfer ber-pelindung yang rahasia → Selective disclosure saat pihak yang berwenang membutuhkan informasi spesifik → DuskVM untuk native Rust/WASM + smart contract ZK → DuskEVM untuk jalur pengembangan yang kompatibel dengan EVM
Dan gagasan besarnya melampaui sekadar “tokenisasi aset.”
Untuk sekuritas yang teregulasi, Anda perlu agar kelayakan investor, transfer yang terkontrol, privasi, pengungkapan, pelaporan, dan penyelesaian dapat bekerja bersama.
Itulah bagian yang menurut saya paling menarik dari Dusk.
Tokenisasi itu mudah dijelaskan. Membangun infrastruktur keuangan di sekelilingnya adalah bagian yang sulit.
Dusk bertaruh bahwa masa depan keuangan onchain membutuhkan keduanya:
Privasi saat itu penting. Transparansi saat itu berguna. Kepatuhan saat itu diperlukan. Penyelesaian yang bisa dipercaya.
⚡ POLLING TRADER FUTURES ⚡ RSI di atas 78 = zona overbought 📊 Para pemenang teratas ini sedang naik… apa langkahmu di futures? 👇 Risiko tinggi, imbalan tinggi — jangan sampai dilikuidasi! 💬 Komentari masukmu & leverage#CryptoPoll #SKLUSDT #CryptoPatience #FutureTradingSignals #MOVR/USDT $ZBT $KERNEL $SKL
🔥 PERKAWINAN EMA 9/20: Cetak Biru Anda untuk Menangkap Tren Crypto
Kelelahan dari indikator yang lambat memberikan sinyal terlambat? Jika Anda ingin menangkap momentum sebelum kerumunan, saatnya menguasai strategi Exponential Moving Average (EMA) 9/20. Berikut adalah cara tepat untuk mengaturnya dan memperdagangkannya seperti seorang profesional. 🧵👇 ━━━━━━━━━━━━━━━━━━━━━ ⚙️ PENYETELAN GRAFIK ━━━━━━━━━━━━━━━━━━━━━ Buka grafik Binance Anda (Terbaik untuk timeframe 15m, 1H, atau 4H) dan tambahkan dua EMA: 🟢 Garis Cepat: 9 EMA (Melacak momentum segera)
Polling Permata Tersembunyi yang Sedang Tren (Binance) 💎 Semua orang memperhatikan BTC & ETH… Tapi keuntungan nyata datang dari permata tersembunyi 👀 Altcoin yang sedang tren mana yang memiliki potensi 10x terbesar?$FET $RNDR $TIA 📊 Suara sekarang & komentar permata tersembunyi Anda Alpha terbaik selalu ada di komentar 👇 #crypto #CryptoPoll #BTC #BinanceSquareTalks #CryptoPoll
🚨 Jujurlah… kebanyakan orang akan salah dalam hal ini. asset mana yang sebenarnya memimpin siklus bull SELANJUTNYA? 📈 #CryptoPoll #Binance #BTC #Web3 #Ethereum $KITE $DENT $SENT