Binance Square
林木森Woody
976 Posting

林木森Woody

这里的每一条动态都是为了早日实现财务自由,告别 996
64 Mengikuti
133 Pengikut
665 Disukai
Posting
·
--
Lihat terjemahan
这周重看 @Dusk_Foundation 的 tokenomics,我原来只记得“上限 10 亿、四年减半”,顺着奖励分配才发现,出块者并不会拿走每块发行的全部。当前首个周期按计划每块发行约 19.8574 DUSK,再加当块交易费;区块生成者基础拿 70%,根据证书里的 credits 最多再加 10%,开发基金 10%,验证委员会和批准委员会各 5%,没有分出去的部分会烧掉。 这套设计想解决的不是单一 APR,而是让提议、验证、批准三种共识动作都有收入。问题也随之变了:如果链上交易费很低,安全预算主要依赖持续发行;如果节点参与质量不足,额外奖励发不满,实际新增供应又会低于名义曲线。所以看 $DUSK 不能拿“每块 19.8574”直接乘区块数,当成所有人都能拿到的固定产出。 官方排出的长期模型是初始 5 亿,再用约 36 年发行另外 5 亿,最大供应 10 亿;每四年把区块发行率减半。这个上限清楚,但“有上限”不等于短期没有稀释,前四年本来就是排放最集中的阶段。另一方面,早期排放也确实在为节点和委员会买安全,不该只用通胀两个字一笔抹掉。 我看 #dusk 的供给会同时盯三件事:实际铸造、活跃质押占比、交易费在奖励中的占比。只有费用和真实使用慢慢接过发行的安全预算,减半才不是单纯把节点收入砍掉。你们更在意最大供应写死,还是网络能不能在排放下降后继续付得起安全成本?
这周重看 @Dusk 的 tokenomics,我原来只记得“上限 10 亿、四年减半”,顺着奖励分配才发现,出块者并不会拿走每块发行的全部。当前首个周期按计划每块发行约 19.8574 DUSK,再加当块交易费;区块生成者基础拿 70%,根据证书里的 credits 最多再加 10%,开发基金 10%,验证委员会和批准委员会各 5%,没有分出去的部分会烧掉。

这套设计想解决的不是单一 APR,而是让提议、验证、批准三种共识动作都有收入。问题也随之变了:如果链上交易费很低,安全预算主要依赖持续发行;如果节点参与质量不足,额外奖励发不满,实际新增供应又会低于名义曲线。所以看 $DUSK 不能拿“每块 19.8574”直接乘区块数,当成所有人都能拿到的固定产出。

官方排出的长期模型是初始 5 亿,再用约 36 年发行另外 5 亿,最大供应 10 亿;每四年把区块发行率减半。这个上限清楚,但“有上限”不等于短期没有稀释,前四年本来就是排放最集中的阶段。另一方面,早期排放也确实在为节点和委员会买安全,不该只用通胀两个字一笔抹掉。

我看 #dusk 的供给会同时盯三件事:实际铸造、活跃质押占比、交易费在奖励中的占比。只有费用和真实使用慢慢接过发行的安全预算,减半才不是单纯把节点收入砍掉。你们更在意最大供应写死,还是网络能不能在排放下降后继续付得起安全成本?
Lihat terjemahan
我把 @Dusk_Foundation 、NPEX 和 Chainlink 的合作公告拆开看,发现真正要落地的不是一句“RWA 跨链”,而是三种完全不同的数据和资产通道。CCIP 负责链间消息与资产移动,CCT 给 $DUSK 这类代币提供受控的 burn/mint 路径;DataLink 把 NPEX 的官方交易所数据送上链,Data Streams 再处理更低延迟的价格更新。 为啥这层数据比“把债券铸成 token”更麻烦?受监管资产不能只证明某个合约里有一串份额。二级市场要知道价格从哪来、发行人是否仍有控制权、跨链时速率限制和升级权限归谁、异常数据怎样暂停。公告里强调 Dusk 与 NPEX 保留代币合约所有权,并可设置 rate limit 和 upgrade path,这对机构是控制能力,对普通用户也是必须盯住的治理权限。 正面看,NPEX 提供真实的发行和交易场景,Chainlink 补互操作与官方行情入口,Dusk 才有机会把发行、交易、结算和披露接成一条链。反面也很清楚:合作、采用标准和资产真正活跃是三件事。没有可查的发行数量、成交、持有人和赎回记录,任何“机构大规模上链”都还只是建设阶段。 所以我接下来盯 #dusk ,不会只数 partner logo,而会等三类证据:真实资产合约、连续市场数据、可验证的结算流。你们觉得 RWA 最难的是资产跨链,还是让链上价格、法律权利和线下兑付始终对得上?
我把 @Dusk 、NPEX 和 Chainlink 的合作公告拆开看,发现真正要落地的不是一句“RWA 跨链”,而是三种完全不同的数据和资产通道。CCIP 负责链间消息与资产移动,CCT 给 $DUSK 这类代币提供受控的 burn/mint 路径;DataLink 把 NPEX 的官方交易所数据送上链,Data Streams 再处理更低延迟的价格更新。

为啥这层数据比“把债券铸成 token”更麻烦?受监管资产不能只证明某个合约里有一串份额。二级市场要知道价格从哪来、发行人是否仍有控制权、跨链时速率限制和升级权限归谁、异常数据怎样暂停。公告里强调 Dusk 与 NPEX 保留代币合约所有权,并可设置 rate limit 和 upgrade path,这对机构是控制能力,对普通用户也是必须盯住的治理权限。

正面看,NPEX 提供真实的发行和交易场景,Chainlink 补互操作与官方行情入口,Dusk 才有机会把发行、交易、结算和披露接成一条链。反面也很清楚:合作、采用标准和资产真正活跃是三件事。没有可查的发行数量、成交、持有人和赎回记录,任何“机构大规模上链”都还只是建设阶段。

所以我接下来盯 #dusk ,不会只数 partner logo,而会等三类证据:真实资产合约、连续市场数据、可验证的结算流。你们觉得 RWA 最难的是资产跨链,还是让链上价格、法律权利和线下兑付始终对得上?
Dua hari terakhir saya menggambar ulang Core Components untuk @Dusk_Foundation , dan baru setelah itu saya bisa membedakan DuskVM, DuskEVM, dan DuskDS. Awalnya saya juga mengira ini cuma “satu chain yang kompatibel dengan dua virtual machine”, tetapi pembagian tugas sebenarnya lebih mirip tiga lapisan: DuskDS menangani konsensus, finalitas, dan ketersediaan data; DuskVM memungkinkan kontrak Rust/WASM berjalan langsung di L1; sedangkan DuskEVM adalah lingkungan eksekusi yang setara dengan EVM, berbasis OP Stack, yang menyerahkan penyelesaian transaksi dan publikasi data kepada DuskDS. Artinya, developer tidak bisa asal memilih salah satu. Kalau sudah punya kontrak Solidity dan bergantung pada dompet serta toolchain EVM, biaya menggunakan DuskEVM lebih rendah. Namun, jika ingin berinteraksi langsung dengan aset L1, model privasi Phoenix, kemampuan zero-knowledge, atau kontrol protokol yang lebih mendasar, DuskVM adalah jalur native. Kedua jalur berbagi lapisan penyelesaian transaksi, tetapi bukan berarti fitur dan asumsi keamanannya sepenuhnya sama. Saya cukup skeptis terhadap klaim “kompatibel dengan EVM = ekosistem otomatis ikut pindah”. Kompatibilitas hanya menurunkan hambatan deployment, bukan menggantikan konektivitas dompet, RPC yang stabil, pengindeks, likuiditas, dan pengguna nyata. Sebaliknya, hanya menonjolkan Rust/ZK native juga tidak cukup. Kalau tooling-nya terlalu kaku, developer tidak akan menulis ulang seluruh produk demi kemurnian teknis. Jadi, saat melihat perkembangan teknis $DUSK , saya akan memisahkan metriknya: apakah DuskEVM punya aplikasi Solidity pihak ketiga, apakah DuskVM punya kontrak nonresmi, dan apakah jalur penyelesaian transaksi keduanya ke DuskDS stabil. Jika keunggulan kompetitif #dusk memang terbukti, seharusnya keunggulan itu berupa “pengguna bisa masuk dengan tooling yang sudah familier, lalu beralih ke lapisan yang lebih dalam saat membutuhkan privasi”, bukan sekadar menumpuk tiga istilah baru. Kalian akan memilih kompatibilitas dulu atau kemampuan native?
Dua hari terakhir saya menggambar ulang Core Components untuk @Dusk , dan baru setelah itu saya bisa membedakan DuskVM, DuskEVM, dan DuskDS. Awalnya saya juga mengira ini cuma “satu chain yang kompatibel dengan dua virtual machine”, tetapi pembagian tugas sebenarnya lebih mirip tiga lapisan: DuskDS menangani konsensus, finalitas, dan ketersediaan data; DuskVM memungkinkan kontrak Rust/WASM berjalan langsung di L1; sedangkan DuskEVM adalah lingkungan eksekusi yang setara dengan EVM, berbasis OP Stack, yang menyerahkan penyelesaian transaksi dan publikasi data kepada DuskDS.

Artinya, developer tidak bisa asal memilih salah satu. Kalau sudah punya kontrak Solidity dan bergantung pada dompet serta toolchain EVM, biaya menggunakan DuskEVM lebih rendah. Namun, jika ingin berinteraksi langsung dengan aset L1, model privasi Phoenix, kemampuan zero-knowledge, atau kontrol protokol yang lebih mendasar, DuskVM adalah jalur native. Kedua jalur berbagi lapisan penyelesaian transaksi, tetapi bukan berarti fitur dan asumsi keamanannya sepenuhnya sama.

Saya cukup skeptis terhadap klaim “kompatibel dengan EVM = ekosistem otomatis ikut pindah”. Kompatibilitas hanya menurunkan hambatan deployment, bukan menggantikan konektivitas dompet, RPC yang stabil, pengindeks, likuiditas, dan pengguna nyata. Sebaliknya, hanya menonjolkan Rust/ZK native juga tidak cukup. Kalau tooling-nya terlalu kaku, developer tidak akan menulis ulang seluruh produk demi kemurnian teknis.

Jadi, saat melihat perkembangan teknis $DUSK , saya akan memisahkan metriknya: apakah DuskEVM punya aplikasi Solidity pihak ketiga, apakah DuskVM punya kontrak nonresmi, dan apakah jalur penyelesaian transaksi keduanya ke DuskDS stabil. Jika keunggulan kompetitif #dusk memang terbukti, seharusnya keunggulan itu berupa “pengguna bisa masuk dengan tooling yang sudah familier, lalu beralih ke lapisan yang lebih dalam saat membutuhkan privasi”, bukan sekadar menumpuk tiga istilah baru. Kalian akan memilih kompatibilitas dulu atau kemampuan native?
Dulu, setiap kali melihat @Dusk_Foundation membahas Moonlight dan Phoenix sekaligus, saya selalu mengira keduanya menyediakan satu model untuk “transfer biasa” dan satu lagi untuk “transfer privat”, dengan fungsi yang tumpang tindih. Setelah membaca dokumen model transaksi dan panduan integrasi bursa secara berdampingan, saya baru menyadari bahwa dua model ini bukan sekadar pamer teknologi. Keduanya secara sadar mengakui bahwa dalam lapisan penyelesaian yang sama, ada arus dana yang harus terbuka, sementara yang lain tidak seharusnya mengungkapkan jumlah dan relasi kepada semua orang. Moonlight adalah model akun publik: saldo, pengirim, penerima, dan jumlah transaksi terlihat. Model ini lebih mudah diintegrasikan untuk setoran ke bursa, kas negara, dan skenario yang memerlukan rekonsiliasi publik. Phoenix menyimpan dana dalam note terenkripsi dan menggunakan bukti tanpa pengetahuan untuk memastikan tidak terjadi pembelanjaan ganda dan dana mencukupi, tanpa mengungkapkan jumlah spesifik maupun note yang terkait kepada pengamat. Jika diperlukan audit, pengungkapan selektif dapat dilakukan melalui viewing key. Kesalahpahaman terbesar di sini adalah anggapan bahwa “karena ada privasi, browser tidak bisa melihat apa pun”. Browser resmi tetap dapat menampilkan metadata publik seperti blok, jenis transaksi, biaya, dan gas. Detail yang terlihat bergantung pada model transaksi dan kontraknya. Sebaliknya, bursa juga tidak bisa langsung memindai Phoenix seperti Moonlight: dokumentasi integrasi resmi secara jelas menyarankan penggunaan Moonlight untuk setoran. Saldo privat harus lebih dulu dipindahkan ke akun publik; logika kustodi dan pemindaiannya sama sekali berbeda. Jadi, tantangan $DUSK bukan membuktikan bahwa privasi bisa diwujudkan, melainkan memastikan pengguna tidak salah jalur saat beralih antara transaksi publik dan privat. Jika #dusk benar-benar ingin masuk ke arus dana yang teregulasi, privasi sebagai pengaturan bawaan, pengungkapan sesuai kebutuhan, dan kustodi yang dapat diprediksi harus terpenuhi sekaligus. Mana yang lebih kalian khawatirkan: posisi aset bocor karena transparansi penuh, atau kompleksitas produk yang meningkat akibat dua model?
Dulu, setiap kali melihat @Dusk membahas Moonlight dan Phoenix sekaligus, saya selalu mengira keduanya menyediakan satu model untuk “transfer biasa” dan satu lagi untuk “transfer privat”, dengan fungsi yang tumpang tindih. Setelah membaca dokumen model transaksi dan panduan integrasi bursa secara berdampingan, saya baru menyadari bahwa dua model ini bukan sekadar pamer teknologi. Keduanya secara sadar mengakui bahwa dalam lapisan penyelesaian yang sama, ada arus dana yang harus terbuka, sementara yang lain tidak seharusnya mengungkapkan jumlah dan relasi kepada semua orang.

Moonlight adalah model akun publik: saldo, pengirim, penerima, dan jumlah transaksi terlihat. Model ini lebih mudah diintegrasikan untuk setoran ke bursa, kas negara, dan skenario yang memerlukan rekonsiliasi publik. Phoenix menyimpan dana dalam note terenkripsi dan menggunakan bukti tanpa pengetahuan untuk memastikan tidak terjadi pembelanjaan ganda dan dana mencukupi, tanpa mengungkapkan jumlah spesifik maupun note yang terkait kepada pengamat. Jika diperlukan audit, pengungkapan selektif dapat dilakukan melalui viewing key.

Kesalahpahaman terbesar di sini adalah anggapan bahwa “karena ada privasi, browser tidak bisa melihat apa pun”. Browser resmi tetap dapat menampilkan metadata publik seperti blok, jenis transaksi, biaya, dan gas. Detail yang terlihat bergantung pada model transaksi dan kontraknya. Sebaliknya, bursa juga tidak bisa langsung memindai Phoenix seperti Moonlight: dokumentasi integrasi resmi secara jelas menyarankan penggunaan Moonlight untuk setoran. Saldo privat harus lebih dulu dipindahkan ke akun publik; logika kustodi dan pemindaiannya sama sekali berbeda.

Jadi, tantangan $DUSK bukan membuktikan bahwa privasi bisa diwujudkan, melainkan memastikan pengguna tidak salah jalur saat beralih antara transaksi publik dan privat. Jika #dusk benar-benar ingin masuk ke arus dana yang teregulasi, privasi sebagai pengaturan bawaan, pengungkapan sesuai kebutuhan, dan kustodi yang dapat diprediksi harus terpenuhi sekaligus. Mana yang lebih kalian khawatirkan: posisi aset bocor karena transparansi penuh, atau kompleksitas produk yang meningkat akibat dua model?
Minggu ini saya mengurus dokumen staking @Dusk_Foundation dari status aktif sampai keluar sampai benar-benar beres, dan baru sadar bahwa dua kalimat “minimum 1000 DUSK, tidak ada periode tunggu berdasarkan perjanjian” adalah yang paling mudah disalahpahami. Staking langsung bukan berarti tinggal klik koin lalu menunggu imbal hasil dengan suku bunga tetap; yang diperlukan adalah menjalankan provisioner yang terus online dan berjalan normal. Imbal hasil bergantung pada kondisi saat Anda terpilih untuk ikut serta dalam konsensus dan pada porsi staking yang valid, bukan janji imbal hasil tetap dari protokol. Timeline-nya juga punya detail. Stake baru baru mulai efektif pada “batas epoch berikutnya dan setelahnya”. Estimasi resmi berdasarkan target waktu pembuatan blok biasanya sekitar 6—12 jam, tetapi yang paling akurat tetap yang ditampilkan di wallet: active from block. Untuk keluar (exit) sendiri tidak ada penguncian dari protokol, namun Anda juga tidak otomatis menarik semua akumulasi reward sekaligus; withdraw reward adalah operasi terpisah. Yang lebih tidak intuitif adalah tambahan staking (top-up): setelah posisi awal sudah active, bagian yang di-top-up hanya 90% yang langsung masuk active, sementara 10% sisanya dicatat sebagai locked stake. Dana yang terkunci tetap milik Anda, tetapi tidak ikut berpartisipasi dalam konsensus; agar bagian ekor itu bisa diambil kembali, mungkin Anda perlu melakukan unstake untuk seluruh posisi yang tersisa. Desain ini tidak selalu buruk, tapi bisa membuat orang yang hanya melihat APR di panel salah menghitung efisiensi modal. Kolam pihak ketiga bisa menghilangkan hambatan operasional, tetapi pendelegasian/penitipan, kontrak, pihak operator, dan aturan exit berubah menjadi kelompok risiko yang lain. Jadi menurut saya, saat seseorang staking $DUSK , mereka tidak hanya bertanya “imbalan berapa”, tapi juga: siapa yang mengendalikan node, bagaimana pembagian reward, dan bagaimana perlakuan untuk bagian locked. Pengguna #dusk lebih cocok menjalankan node sendiri, atau menerima lapisan risiko dari kolam agar operasinya lebih sederhana?
Minggu ini saya mengurus dokumen staking @Dusk dari status aktif sampai keluar sampai benar-benar beres, dan baru sadar bahwa dua kalimat “minimum 1000 DUSK, tidak ada periode tunggu berdasarkan perjanjian” adalah yang paling mudah disalahpahami. Staking langsung bukan berarti tinggal klik koin lalu menunggu imbal hasil dengan suku bunga tetap; yang diperlukan adalah menjalankan provisioner yang terus online dan berjalan normal. Imbal hasil bergantung pada kondisi saat Anda terpilih untuk ikut serta dalam konsensus dan pada porsi staking yang valid, bukan janji imbal hasil tetap dari protokol.

Timeline-nya juga punya detail. Stake baru baru mulai efektif pada “batas epoch berikutnya dan setelahnya”. Estimasi resmi berdasarkan target waktu pembuatan blok biasanya sekitar 6—12 jam, tetapi yang paling akurat tetap yang ditampilkan di wallet: active from block. Untuk keluar (exit) sendiri tidak ada penguncian dari protokol, namun Anda juga tidak otomatis menarik semua akumulasi reward sekaligus; withdraw reward adalah operasi terpisah.

Yang lebih tidak intuitif adalah tambahan staking (top-up): setelah posisi awal sudah active, bagian yang di-top-up hanya 90% yang langsung masuk active, sementara 10% sisanya dicatat sebagai locked stake. Dana yang terkunci tetap milik Anda, tetapi tidak ikut berpartisipasi dalam konsensus; agar bagian ekor itu bisa diambil kembali, mungkin Anda perlu melakukan unstake untuk seluruh posisi yang tersisa. Desain ini tidak selalu buruk, tapi bisa membuat orang yang hanya melihat APR di panel salah menghitung efisiensi modal.

Kolam pihak ketiga bisa menghilangkan hambatan operasional, tetapi pendelegasian/penitipan, kontrak, pihak operator, dan aturan exit berubah menjadi kelompok risiko yang lain. Jadi menurut saya, saat seseorang staking $DUSK , mereka tidak hanya bertanya “imbalan berapa”, tapi juga: siapa yang mengendalikan node, bagaimana pembagian reward, dan bagaimana perlakuan untuk bagian locked. Pengguna #dusk lebih cocok menjalankan node sendiri, atau menerima lapisan risiko dari kolam agar operasinya lebih sederhana?
Saya menaruh whitepaper TMX @termmax dan dokumen insentif dalam satu rangkaian bacaan, lalu menemukan pertanyaan yang lebih pantas diajukan terlebih dahulu daripada “berapa banyak yang akan didrop”: durasi yang disebut dalam roadmap, apakah bisa langsung dianggap sebagai TGE yang sudah terjadi? Jawabannya, setidaknya dari dokumen publik saat ini, belum bisa disamakan. Whitepaper versi Maret 2026 mendefinisikan TMX sebagai token tata kelola dan utilitas, totalnya tetap 1 miliar, dengan perkiraan suplai awal sekitar 20%. Tabel alokasi mencantumkan ekosistem 29%, investor 28%, tim 15%, komunitas 15%, sisanya untuk likuiditas, yayasan, dan konsultan. Roadmap menempatkan TGE, likuiditas bursa, distribusi, dan pool staking pada kuartal II 2026. Namun, pada bagian parameter dari whitepaper yang sama, tanggal TGE masih tertulis To Be Announced. Dokumen pre-mining hanya mengatakan bahwa jumlah yang terakumulasi pengguna adalah batas yang belum dapat dialihkan, dan klaim baru dilakukan 1:1 setelah TGE. Pihak resmi telah mencantumkan alamat token di Ethereum dan BNB Chain—ini menunjukkan kesiapan kontrak sudah dipublikasikan, tetapi tidak cukup untuk membuktikan bahwa generasi, klaim, dan peredaran semuanya sudah selesai secara penuh. Perbedaan ini sangat penting. Deploy kontrak adalah peristiwa teknis, TGE adalah peristiwa distribusi, sedangkan pembukaan deposit/withdrawal dan perdagangan di bursa adalah peristiwa pasar. Ketiganya bisa berurutan, atau bisa juga terpaut cukup lama. Menggabungkan “alamat sudah ada”, “roadmap sudah berakhir”, dan “halaman ada angkanya” menjadi satu kalimat “sudah live” membuat informasi menjadi tidak akurat. Saya menilai progres TMX hanya dengan empat sinyal: waktu TGE yang jelas; halaman resmi klaim beserta aturan; peredaran di block explorer yang sesuai dengan deskripsi alokasi; serta pengumuman listing dan deposit/withdrawal dari bursa. Jika ada salah satu yang kurang, tahapan harus dideskripsikan sesuai kondisi aktual, bukan diisi seolah-olah proyek telah menyelesaikan langkah-langkah setelahnya. Risikonya juga tidak hanya soal tanggal. Whitepaper menyebutkan tim memiliki cliff 12 bulan lalu pelepasan linear, investor juga memiliki cliff 12 bulan, kemudian vesting selama 24 bulan. Yang benar-benar memengaruhi pasar bukanlah angka total 1 miliar, melainkan berapa banyak yang dilepas pada setiap jendela, lewat alamat mana penerima menangani, dan apakah bisa diselaraskan dengan tabel publik. Jadi, saya tidak akan—karena kuartal yang disebut dalam roadmap sudah lewat—menganggap TMX #TermMax sebagai “seharusnya sudah selesai”. Roadmap adalah rencana, sedangkan distribusi di-chain dan pengumuman resmi adalah status. Daripada menebak lebih cepat satu hari, lebih berguna untuk menghitung ulang estimasi valuasi yang dibayangkan, satu kali lebih teliti.
Saya menaruh whitepaper TMX @TermMax dan dokumen insentif dalam satu rangkaian bacaan, lalu menemukan pertanyaan yang lebih pantas diajukan terlebih dahulu daripada “berapa banyak yang akan didrop”: durasi yang disebut dalam roadmap, apakah bisa langsung dianggap sebagai TGE yang sudah terjadi?

Jawabannya, setidaknya dari dokumen publik saat ini, belum bisa disamakan.

Whitepaper versi Maret 2026 mendefinisikan TMX sebagai token tata kelola dan utilitas, totalnya tetap 1 miliar, dengan perkiraan suplai awal sekitar 20%. Tabel alokasi mencantumkan ekosistem 29%, investor 28%, tim 15%, komunitas 15%, sisanya untuk likuiditas, yayasan, dan konsultan. Roadmap menempatkan TGE, likuiditas bursa, distribusi, dan pool staking pada kuartal II 2026.

Namun, pada bagian parameter dari whitepaper yang sama, tanggal TGE masih tertulis To Be Announced. Dokumen pre-mining hanya mengatakan bahwa jumlah yang terakumulasi pengguna adalah batas yang belum dapat dialihkan, dan klaim baru dilakukan 1:1 setelah TGE. Pihak resmi telah mencantumkan alamat token di Ethereum dan BNB Chain—ini menunjukkan kesiapan kontrak sudah dipublikasikan, tetapi tidak cukup untuk membuktikan bahwa generasi, klaim, dan peredaran semuanya sudah selesai secara penuh.

Perbedaan ini sangat penting. Deploy kontrak adalah peristiwa teknis, TGE adalah peristiwa distribusi, sedangkan pembukaan deposit/withdrawal dan perdagangan di bursa adalah peristiwa pasar. Ketiganya bisa berurutan, atau bisa juga terpaut cukup lama. Menggabungkan “alamat sudah ada”, “roadmap sudah berakhir”, dan “halaman ada angkanya” menjadi satu kalimat “sudah live” membuat informasi menjadi tidak akurat.

Saya menilai progres TMX hanya dengan empat sinyal: waktu TGE yang jelas; halaman resmi klaim beserta aturan; peredaran di block explorer yang sesuai dengan deskripsi alokasi; serta pengumuman listing dan deposit/withdrawal dari bursa. Jika ada salah satu yang kurang, tahapan harus dideskripsikan sesuai kondisi aktual, bukan diisi seolah-olah proyek telah menyelesaikan langkah-langkah setelahnya.

Risikonya juga tidak hanya soal tanggal. Whitepaper menyebutkan tim memiliki cliff 12 bulan lalu pelepasan linear, investor juga memiliki cliff 12 bulan, kemudian vesting selama 24 bulan. Yang benar-benar memengaruhi pasar bukanlah angka total 1 miliar, melainkan berapa banyak yang dilepas pada setiap jendela, lewat alamat mana penerima menangani, dan apakah bisa diselaraskan dengan tabel publik.

Jadi, saya tidak akan—karena kuartal yang disebut dalam roadmap sudah lewat—menganggap TMX #TermMax sebagai “seharusnya sudah selesai”. Roadmap adalah rencana, sedangkan distribusi di-chain dan pengumuman resmi adalah status. Daripada menebak lebih cepat satu hari, lebih berguna untuk menghitung ulang estimasi valuasi yang dibayangkan, satu kali lebih teliti.
Lihat terjemahan
我把 @Dusk_Foundation 新钱包和 Dusk Connect 的说明对照了一遍,才明白他们补的不是“再做一个钱包皮肤”,而是 dApp 一直缺的连接层。旧 Web Wallet 能单独转账、质押,但应用没法用统一接口发现钱包、请求账户、签名和发交易,开发者只能围着某个钱包单独适配。 Dusk Connect 做的事很像把这段胶水标准化:钱包发现借了 EIP-6963 的思路,RPC 按命名空间处理账户、签名、交易和网络请求,还给钱包实现者准备一致性测试。新的第一方钱包再从一开始就按这个 provider 接口来,覆盖浏览器扩展、桌面和移动端;公开与隐私转账、shield/unshield、质押、领收益、DRC-20 和 DRC-721 都放进同一条交互路径。 最容易被宣传稿带偏的地方,是把“仓库开放”直接等同于“产品成熟”。官方目前给它的定位仍是 developer preview。密钥本地保存、扩展端用 PBKDF2 和 AES-GCM、原生端用 Stronghold 与 Argon2,这些是正确的安全底座,但真正决定体验的是断连恢复、权限提示、失败交易反馈和多端状态一致性。 这也是我最近看 #dusk 不只盯协议名词的原因:没有稳定的钱包连接层,再漂亮的隐私合约也只是开发者演示。$DUSK 需要的下一步不是多一张界面截图,而是第三方 dApp 真能无痛接入。你们判断一个新钱包可用,会先看功能表,还是先看它在失败场景里怎么表现?
我把 @Dusk 新钱包和 Dusk Connect 的说明对照了一遍,才明白他们补的不是“再做一个钱包皮肤”,而是 dApp 一直缺的连接层。旧 Web Wallet 能单独转账、质押,但应用没法用统一接口发现钱包、请求账户、签名和发交易,开发者只能围着某个钱包单独适配。

Dusk Connect 做的事很像把这段胶水标准化:钱包发现借了 EIP-6963 的思路,RPC 按命名空间处理账户、签名、交易和网络请求,还给钱包实现者准备一致性测试。新的第一方钱包再从一开始就按这个 provider 接口来,覆盖浏览器扩展、桌面和移动端;公开与隐私转账、shield/unshield、质押、领收益、DRC-20 和 DRC-721 都放进同一条交互路径。

最容易被宣传稿带偏的地方,是把“仓库开放”直接等同于“产品成熟”。官方目前给它的定位仍是 developer preview。密钥本地保存、扩展端用 PBKDF2 和 AES-GCM、原生端用 Stronghold 与 Argon2,这些是正确的安全底座,但真正决定体验的是断连恢复、权限提示、失败交易反馈和多端状态一致性。

这也是我最近看 #dusk 不只盯协议名词的原因:没有稳定的钱包连接层,再漂亮的隐私合约也只是开发者演示。$DUSK 需要的下一步不是多一张界面截图,而是第三方 dApp 真能无痛接入。你们判断一个新钱包可用,会先看功能表,还是先看它在失败场景里怎么表现?
Setelah membaca pengumuman peluncuran V2 dari @termmax , saya terlebih dahulu mencari ulasan mereka tentang V1. Masalah protokol suku bunga tetap mungkin bukan karena tidak ada kuotasi, melainkan dana tersebar di halaman berbagai order, pasar, dan chain: melihat satu suku bunga bukan berarti seluruh jumlah dana bisa ditransaksikan dengan suku bunga tersebut. Di V1, range order milik kurator dan limit order milik pengguna ditampilkan secara terpisah. Jika ingin meminjam dana dalam jumlah agak besar, pengguna harus membandingkan order satu per satu, lalu menanggung perubahan harga yang timbul dari kedalaman setiap level. Suku bunganya bisa disebut “tetap”, tetapi biaya untuk masuk belum tentu terlihat jelas sekilas. V2 mengubah bagian ini. Order terpadu membaca range order kurator dan limit order individual, lalu menggabungkannya menjadi satu jalur eksekusi; pengguna melihat satu kuotasi dan menandatangani sekali, sementara sistem menyusun transaksi dari likuiditas di pasar yang sama. Limit order juga tersedia di setiap pasar: pemberi pinjaman memasang suku bunga minimum yang dapat diterima, sedangkan peminjam memasang suku bunga maksimum yang bersedia dibayar. Jadi, mereka tak harus menerima harga pasar begitu saja saat kedalaman pasar tipis. Ini bukan berarti suku bunga dibuat lebih tetap, melainkan friksi di dalam order book dibuat lebih transparan. Ibaratnya, konter mencantumkan satu harga, tetapi yang benar-benar penting adalah apakah jumlah yang Anda inginkan bisa diperoleh dengan harga yang mendekati itu. V2 menyusun order, lalu menyajikan jalur eksekusi yang bisa dijalankan. Namun, ada batasan yang tidak boleh diabaikan. Pihak resmi menyebut bahwa pasar lintas-chain dan vault ditampilkan, difilter, dan dibandingkan dalam satu antarmuka, bukan bahwa dana dari berbagai chain secara fisik digabungkan menjadi satu pool. Kedalaman pasar di Ethereum tidak otomatis berpindah untuk mengeksekusi transaksi Anda hanya karena bisa dilihat dari halaman Base. Likuiditas on-chain, Gas, waktu tunggu limit order, dan jumlah aktual yang bisa dieksekusi tetap harus diperhitungkan masing-masing. Hal lain yang perlu diamati adalah kinerja untuk order besar. Jalur yang lebih mulus bukan berarti semua ukuran order bisa memperoleh suku bunga yang ditampilkan di halaman utama. Yang patut diperhatikan adalah selisih kuotasi untuk jumlah yang berbeda, waktu tunggu limit order, serta berapa banyak sumber likuiditas yang digabungkan dalam satu transaksi. Hal-hal ini lebih menjelaskan kualitas eksekusi daripada “berapa banyak chain yang didukung”. Jadi, nilai V2 dari #TermMax bukan terletak pada antarmuka yang lebih ringkas, melainkan pada pemisahan antara “kepastian suku bunga” dan “kepastian eksekusi”. Yang pertama ditentukan oleh FT dan tanggal jatuh tempo, sedangkan yang kedua tetap harus dibuktikan oleh kedalaman pasar. Antarmuka bisa memperjelas jalurnya, tetapi apakah tersedia cukup kendaraan di sepanjang jalan tetap bergantung pada transaksi nyata. $BOME $BTC
Setelah membaca pengumuman peluncuran V2 dari @TermMax , saya terlebih dahulu mencari ulasan mereka tentang V1. Masalah protokol suku bunga tetap mungkin bukan karena tidak ada kuotasi, melainkan dana tersebar di halaman berbagai order, pasar, dan chain: melihat satu suku bunga bukan berarti seluruh jumlah dana bisa ditransaksikan dengan suku bunga tersebut.

Di V1, range order milik kurator dan limit order milik pengguna ditampilkan secara terpisah. Jika ingin meminjam dana dalam jumlah agak besar, pengguna harus membandingkan order satu per satu, lalu menanggung perubahan harga yang timbul dari kedalaman setiap level. Suku bunganya bisa disebut “tetap”, tetapi biaya untuk masuk belum tentu terlihat jelas sekilas.

V2 mengubah bagian ini. Order terpadu membaca range order kurator dan limit order individual, lalu menggabungkannya menjadi satu jalur eksekusi; pengguna melihat satu kuotasi dan menandatangani sekali, sementara sistem menyusun transaksi dari likuiditas di pasar yang sama. Limit order juga tersedia di setiap pasar: pemberi pinjaman memasang suku bunga minimum yang dapat diterima, sedangkan peminjam memasang suku bunga maksimum yang bersedia dibayar. Jadi, mereka tak harus menerima harga pasar begitu saja saat kedalaman pasar tipis.

Ini bukan berarti suku bunga dibuat lebih tetap, melainkan friksi di dalam order book dibuat lebih transparan. Ibaratnya, konter mencantumkan satu harga, tetapi yang benar-benar penting adalah apakah jumlah yang Anda inginkan bisa diperoleh dengan harga yang mendekati itu. V2 menyusun order, lalu menyajikan jalur eksekusi yang bisa dijalankan.

Namun, ada batasan yang tidak boleh diabaikan. Pihak resmi menyebut bahwa pasar lintas-chain dan vault ditampilkan, difilter, dan dibandingkan dalam satu antarmuka, bukan bahwa dana dari berbagai chain secara fisik digabungkan menjadi satu pool. Kedalaman pasar di Ethereum tidak otomatis berpindah untuk mengeksekusi transaksi Anda hanya karena bisa dilihat dari halaman Base. Likuiditas on-chain, Gas, waktu tunggu limit order, dan jumlah aktual yang bisa dieksekusi tetap harus diperhitungkan masing-masing.

Hal lain yang perlu diamati adalah kinerja untuk order besar. Jalur yang lebih mulus bukan berarti semua ukuran order bisa memperoleh suku bunga yang ditampilkan di halaman utama. Yang patut diperhatikan adalah selisih kuotasi untuk jumlah yang berbeda, waktu tunggu limit order, serta berapa banyak sumber likuiditas yang digabungkan dalam satu transaksi. Hal-hal ini lebih menjelaskan kualitas eksekusi daripada “berapa banyak chain yang didukung”.

Jadi, nilai V2 dari #TermMax bukan terletak pada antarmuka yang lebih ringkas, melainkan pada pemisahan antara “kepastian suku bunga” dan “kepastian eksekusi”. Yang pertama ditentukan oleh FT dan tanggal jatuh tempo, sedangkan yang kedua tetap harus dibuktikan oleh kedalaman pasar. Antarmuka bisa memperjelas jalurnya, tetapi apakah tersedia cukup kendaraan di sepanjang jalan tetap bergantung pada transaksi nyata.
$BOME $BTC
Dua hari ini saya menelaah analisis keamanan AEGIS @Dusk_Foundation . Awalnya saya hanya mengingat “39 perbaikan, 7 critical”, tetapi setelah membaca detailnya, saya baru sadar bahwa angka yang besar justru bukan poin utamanya. Tujuh masalah serius itu pada akhirnya mengerucut menjadi 4 kategori akar masalah: masalah alias di sandbox VM, deserialisasi tidak aman di sisi host, biaya transaksi dan pengembalian dana Phoenix yang tidak terikat secara menyeluruh, serta jalur pemalsuan tanda tangan BLS. Mengapa kita perlu melihat akar masalah, bukan hanya jumlah kerentanan? Karena batas kepercayaan yang tidak dirancang dengan baik bisa terus memunculkan masalah di berbagai modul. Misalnya, deserialisasi sebelum input divalidasi tampak seperti kesalahan parsing biasa, tetapi sebenarnya bisa mengancam keamanan memori host. Masalah Phoenix juga bukan sekadar “biaya transaksi salah hitung sedikit”, melainkan bukti, tanda tangan, dan eksekusi pengembalian dana tidak menggunakan semantik yang sama. Dalam skenario terburuk, hal ini dapat mengancam integritas pasokan dan keamanan dana. Pihak resmi menyatakan bahwa sejauh ini tidak ditemukan eksploitasi terhadap kerentanan critical tersebut sebelum diperbaiki. Saya bersedia menerima itu sebagai kesimpulan investigasi, tetapi tidak akan mengubahnya menjadi klaim bahwa “pasti tidak pernah terjadi”. Bagi $DUSK , sinyal positif dari AEGIS adalah tim memublikasikan temuan internal hingga mencakup akar masalah dan logika perbaikannya. Sinyal negatifnya juga jelas: setelah mainnet diluncurkan, stack inti memang pernah memiliki celah berisiko tinggi yang dapat memengaruhi eksekusi, autentikasi konsensus, dan ketersediaan blockchain. Jadi, saya tidak akan langsung memberi #dusk cap aman hanya karena “sudah banyak diaudit”. Hal yang lebih berguna untuk diamati adalah apakah temuan akan terus diungkap pada putaran berikutnya, apakah batas serupa sudah memiliki pengujian regresi, dan apakah audit eksternal mencakup kode setelah AEGIS. Mana yang lebih kalian hargai: proyek yang tak pernah mengalami masalah besar, atau proyek yang setelah masalah terungkap mampu menjelaskan akar masalah, dampak, dan rangkaian perbaikannya dengan jelas? $USELESS $BOME
Dua hari ini saya menelaah analisis keamanan AEGIS @Dusk . Awalnya saya hanya mengingat “39 perbaikan, 7 critical”, tetapi setelah membaca detailnya, saya baru sadar bahwa angka yang besar justru bukan poin utamanya. Tujuh masalah serius itu pada akhirnya mengerucut menjadi 4 kategori akar masalah: masalah alias di sandbox VM, deserialisasi tidak aman di sisi host, biaya transaksi dan pengembalian dana Phoenix yang tidak terikat secara menyeluruh, serta jalur pemalsuan tanda tangan BLS.

Mengapa kita perlu melihat akar masalah, bukan hanya jumlah kerentanan? Karena batas kepercayaan yang tidak dirancang dengan baik bisa terus memunculkan masalah di berbagai modul. Misalnya, deserialisasi sebelum input divalidasi tampak seperti kesalahan parsing biasa, tetapi sebenarnya bisa mengancam keamanan memori host. Masalah Phoenix juga bukan sekadar “biaya transaksi salah hitung sedikit”, melainkan bukti, tanda tangan, dan eksekusi pengembalian dana tidak menggunakan semantik yang sama. Dalam skenario terburuk, hal ini dapat mengancam integritas pasokan dan keamanan dana.

Pihak resmi menyatakan bahwa sejauh ini tidak ditemukan eksploitasi terhadap kerentanan critical tersebut sebelum diperbaiki. Saya bersedia menerima itu sebagai kesimpulan investigasi, tetapi tidak akan mengubahnya menjadi klaim bahwa “pasti tidak pernah terjadi”. Bagi $DUSK , sinyal positif dari AEGIS adalah tim memublikasikan temuan internal hingga mencakup akar masalah dan logika perbaikannya. Sinyal negatifnya juga jelas: setelah mainnet diluncurkan, stack inti memang pernah memiliki celah berisiko tinggi yang dapat memengaruhi eksekusi, autentikasi konsensus, dan ketersediaan blockchain.

Jadi, saya tidak akan langsung memberi #dusk cap aman hanya karena “sudah banyak diaudit”. Hal yang lebih berguna untuk diamati adalah apakah temuan akan terus diungkap pada putaran berikutnya, apakah batas serupa sudah memiliki pengujian regresi, dan apakah audit eksternal mencakup kode setelah AEGIS. Mana yang lebih kalian hargai: proyek yang tak pernah mengalami masalah besar, atau proyek yang setelah masalah terungkap mampu menjelaskan akar masalah, dampak, dan rangkaian perbaikannya dengan jelas?
$USELESS $BOME
Aku membaca ulang dokumen suku bunga tetap untuk @termmax . Yang paling dulu mengganjalku bukan cara menghitung bunganya, tapi masalah yang lebih mendasar: biaya dana untuk pinjaman on-chain berubah setiap hari—lalu dengan dasar apa suku bunga sebuah utang bisa “dipaku” lebih dulu sampai tanggal jatuh tempo? Kalau jawabannya hanya “komitmen protokol tidak berubah”, maka suku bunga tetap ini tidak ada yang menarik untuk diteliti. Lanjutkan ke hubungan FT, XT, dan GT; baru di situ logikanya lengkap. FT adalah bukti yang dapat ditukar menjadi aset utang sebesar nilai nominal pada saat jatuh tempo. Pemberi pinjaman membeli FT dengan diskon, lalu menebusnya pada jatuh tempo sebesar nilai nominal; selisihnya adalah keuntungan yang dikunci sejak awal. XT adalah bagian komplemennya; hubungan yang diberikan dokumen adalah: pada sembarang titik waktu, 1 FT ditambah 1 XT setara dengan 1 unit aset utang. Peminjam membentuk nilai yang akan dibayar di masa depan menjadi FT, lalu menjual bagian bunganya kepada order—hari ini ia mendapatkan likuiditas, dan biayanya pun dipastikan saat terjadi transaksi. GT lebih mirip selubung posisi. Ia adalah ERC-721: mencatat agunan dan utang, bukan menciptakan lagi “koin pendapatan” yang bisa diperdagangkan sesuka hati. Berapa banyak agunan yang dibutuhkan, berapa banyak FT yang terutang, dan kapan jatuh tempo—semuanya dikemas dalam satu lokasi on-chain yang sama. Kalau diubah jadi penjelasan yang lebih intuitif: pool suku bunga mengambang biasa setelah pinjaman terus-menerus mengubah harga utang; TermMax justru lebih dulu mengubah “berapa yang harus dibayar saat jatuh tempo” menjadi piutang yang bisa diperdagangkan, lalu pasar yang menentukan berapa nilai yang bersedia dibayarkan hari ini untuk aset itu. Yang “tetap” bukan harga aset, dan agunannya tidak selamanya aman; yang tetap adalah waktu dan biaya dari utang tersebut setelah transaksi. Ada juga batas yang mudah tertutup oleh slogan. Suku bunga tetap tidak berarti tidak akan terjadi likuidasi. Dokumentasi resmi Market tetap menetapkan MLTV dan LLTV; saat harga agunan turun atau aset utang menguat sehingga LTV menyentuh LLTV, posisi tetap akan masuk likuidasi. Yang dihilangkan adalah ketidakpastian bahwa suku bunga tiba-tiba lonjak—bukan hilangnya volatilitas agunan, risiko oracle, maupun risiko pembayaran saat jatuh tempo. Jadi sekarang ketika aku melihat #TermMax , aku tidak langsung bertanya apakah APY-nya tinggi atau tidak. Yang pertama aku cek adalah tanggal jatuh tempo FT, kedalaman transaksi (liquidity depth), dan seberapa jauh GT dari garis likuidasi. Memahami “suku bunga tetap” sebagai “tidak akan ada masalah” akan mengarahkan pemikiran ke arah yang salah; yang dipasangnya adalah bagian harga dalam utang yang paling sulit diprediksi dalam penganggaran. $CLO $ETH
Aku membaca ulang dokumen suku bunga tetap untuk @TermMax . Yang paling dulu mengganjalku bukan cara menghitung bunganya, tapi masalah yang lebih mendasar: biaya dana untuk pinjaman on-chain berubah setiap hari—lalu dengan dasar apa suku bunga sebuah utang bisa “dipaku” lebih dulu sampai tanggal jatuh tempo?

Kalau jawabannya hanya “komitmen protokol tidak berubah”, maka suku bunga tetap ini tidak ada yang menarik untuk diteliti. Lanjutkan ke hubungan FT, XT, dan GT; baru di situ logikanya lengkap.

FT adalah bukti yang dapat ditukar menjadi aset utang sebesar nilai nominal pada saat jatuh tempo. Pemberi pinjaman membeli FT dengan diskon, lalu menebusnya pada jatuh tempo sebesar nilai nominal; selisihnya adalah keuntungan yang dikunci sejak awal. XT adalah bagian komplemennya; hubungan yang diberikan dokumen adalah: pada sembarang titik waktu, 1 FT ditambah 1 XT setara dengan 1 unit aset utang. Peminjam membentuk nilai yang akan dibayar di masa depan menjadi FT, lalu menjual bagian bunganya kepada order—hari ini ia mendapatkan likuiditas, dan biayanya pun dipastikan saat terjadi transaksi.

GT lebih mirip selubung posisi. Ia adalah ERC-721: mencatat agunan dan utang, bukan menciptakan lagi “koin pendapatan” yang bisa diperdagangkan sesuka hati. Berapa banyak agunan yang dibutuhkan, berapa banyak FT yang terutang, dan kapan jatuh tempo—semuanya dikemas dalam satu lokasi on-chain yang sama.

Kalau diubah jadi penjelasan yang lebih intuitif: pool suku bunga mengambang biasa setelah pinjaman terus-menerus mengubah harga utang; TermMax justru lebih dulu mengubah “berapa yang harus dibayar saat jatuh tempo” menjadi piutang yang bisa diperdagangkan, lalu pasar yang menentukan berapa nilai yang bersedia dibayarkan hari ini untuk aset itu. Yang “tetap” bukan harga aset, dan agunannya tidak selamanya aman; yang tetap adalah waktu dan biaya dari utang tersebut setelah transaksi.

Ada juga batas yang mudah tertutup oleh slogan. Suku bunga tetap tidak berarti tidak akan terjadi likuidasi. Dokumentasi resmi Market tetap menetapkan MLTV dan LLTV; saat harga agunan turun atau aset utang menguat sehingga LTV menyentuh LLTV, posisi tetap akan masuk likuidasi. Yang dihilangkan adalah ketidakpastian bahwa suku bunga tiba-tiba lonjak—bukan hilangnya volatilitas agunan, risiko oracle, maupun risiko pembayaran saat jatuh tempo.

Jadi sekarang ketika aku melihat #TermMax , aku tidak langsung bertanya apakah APY-nya tinggi atau tidak. Yang pertama aku cek adalah tanggal jatuh tempo FT, kedalaman transaksi (liquidity depth), dan seberapa jauh GT dari garis likuidasi. Memahami “suku bunga tetap” sebagai “tidak akan ada masalah” akan mengarahkan pemikiran ke arah yang salah; yang dipasangnya adalah bagian harga dalam utang yang paling sulit diprediksi dalam penganggaran.
$CLO $ETH
Lihat terjemahan
我把 @Dusk_Foundation 今年那份跨链桥复盘重新顺了一遍,最值得看的不是“被盗”两个字,而是故障到底发生在哪一层。1 月 16 日出问题的是桥服务使用的签名钱包:攻击者拿到放款权限后从 Dusk 侧转走资产,再把一部分送到 BSC。官方明确说这不是共识失效,也不是 L1 协议被打穿。 但这不等于底层链没事,用户就该把桥风险忽略。旧架构把事件接收、签名和资金释放压在一条路径上,快是快,一旦签名端失守,权限就太集中。后来的重做才把三件事拆开:事件先落任务,worker 按状态机处理;签过的原始交易先保存,失败时重播同一笔;热钱包只留近期所需余额,低于阈值就暂停,冷钱包人工补充。 我以前也容易把“桥不是协议”当成免责句,现在更愿意反过来看:只要用户把它当流动性入口,桥就已经进入 $DUSK 的真实安全边界。链上共识安全和资产出入口安全,是两张必须同时及格的卷子。 这次补救方向是对的,风险点也没消失:密钥隔离是否长期执行、阈值是否合理、停机和补款是否可审计,都要继续盯。#dusk 社区更该问的不是“链有没有被黑”,而是“哪一把钥匙还拥有超出必要范围的权力”。你们看跨链桥,先看代码审计,还是先看运营权限怎么切? $TREE $ETH
我把 @Dusk 今年那份跨链桥复盘重新顺了一遍,最值得看的不是“被盗”两个字,而是故障到底发生在哪一层。1 月 16 日出问题的是桥服务使用的签名钱包:攻击者拿到放款权限后从 Dusk 侧转走资产,再把一部分送到 BSC。官方明确说这不是共识失效,也不是 L1 协议被打穿。

但这不等于底层链没事,用户就该把桥风险忽略。旧架构把事件接收、签名和资金释放压在一条路径上,快是快,一旦签名端失守,权限就太集中。后来的重做才把三件事拆开:事件先落任务,worker 按状态机处理;签过的原始交易先保存,失败时重播同一笔;热钱包只留近期所需余额,低于阈值就暂停,冷钱包人工补充。

我以前也容易把“桥不是协议”当成免责句,现在更愿意反过来看:只要用户把它当流动性入口,桥就已经进入 $DUSK 的真实安全边界。链上共识安全和资产出入口安全,是两张必须同时及格的卷子。

这次补救方向是对的,风险点也没消失:密钥隔离是否长期执行、阈值是否合理、停机和补款是否可审计,都要继续盯。#dusk 社区更该问的不是“链有没有被黑”,而是“哪一把钥匙还拥有超出必要范围的权力”。你们看跨链桥,先看代码审计,还是先看运营权限怎么切?
$TREE $ETH
Hari ini saya mengikuti alur dana pada dokumen @termmax dan menggambar FT, XT, serta GT. Baru sampai panah ketiga, saya sudah ingin tertawa: bagaimana pinjaman berjangka tetap bisa dipecah menjadi tiga jenis token? Desainnya memang cerdik, tetapi sebenarnya pengguna biasa harus memperhatikan yang mana? Saya coba luruskan dulu logikanya. FT mirip obligasi tanpa kupon; saat jatuh tempo, FT bisa ditukar kembali dengan aset utang sesuai nilai nominal. XT melengkapi bagian diskonto FT: menurut definisi protokol, 1 FT ditambah 1 XT selalu setara dengan 1 unit aset utang. GT adalah ERC-721 yang memuat agunan dan posisi utang. Peminjam mengunci agunan, mencetak FT, lalu memecah FT menjadi bagian pokok dan bunga untuk ditukar dengan XT, dan akhirnya menyatukannya kembali menjadi aset yang ingin dipinjam. Di atas kertas, mekanismenya cukup rapi dan tertutup. Saya akui ini lebih mudah diverifikasi daripada “suku bunga yang muncul begitu saja di halaman”. Namun, semakin jauh saya membaca, semakin banyak yang membuat saya bertanya-tanya. Harga FT berubah mengikuti sisa jangka waktu dan kurva pasar, nilai XT menjadi nol saat jatuh tempo, sedangkan GT menanggung risiko likuidasi. Ketiga token itu masing-masing mencatat jangka waktu, bunga, dan agunan serta utang. TermMax membuat sebuah pinjaman jadi sangat transparan, tetapi juga memecah status yang perlu dipahami pengguna menjadi bagian-bagian yang lebih rumit. Transaksi sekali klik di halaman bukan berarti otak kita juga bisa langsung memahaminya, kan? Yang lebih penting, peminjam bisa melunasi langsung dengan aset utang, atau membeli FT yang didiskon untuk melunasi. Kedengarannya fleksibel, tetapi artinya biaya keluar lebih awal tidak hanya bergantung pada suku bunga yang dikunci sejak awal, melainkan juga pada kedalaman pasar FT dan harga yang ditawarkan kurva saat itu. Suku bunga tetap memberi kepastian kontrak, tetapi harga untuk keluar tetap harus mengikuti pasar. Saya juga membandingkannya dengan kondisi saat jatuh tempo. Dalam keadaan normal, FT ditebus sesuai nilai nominal. Namun, jika peminjam terlambat membayar dan likuidasi tidak tuntas dalam jangka waktu yang ditentukan, kumpulan penebusan bisa saja tercampur dengan agunan. Jadi, FT memang mirip obligasi, tetapi perlindungan kreditnya bukan janji pembayaran dari suatu lembaga. Perlindungan itu bergantung pada rasio agunan, oracle, likuidator, dan likuiditas pasar yang saling menopang. Luput memperhatikan satu saja, kesimpulannya bisa meleset. Jadi, setelah meneliti #TermMax , yang paling ingin saya lihat bukan poster “APY tetap” lainnya, melainkan penjelasan yang mudah dipahami tentang perubahan FT, XT, dan GT di setiap posisi, serta jalur keluar terburuknya. Mekanisme rumit boleh disembunyikan di balik satu klik. Namun, kalau risikonya ikut disembunyikan, penyederhanaan ini sebenarnya melayani pengguna atau hanya mendorong transaksi? $PRL $CLO
Hari ini saya mengikuti alur dana pada dokumen @TermMax dan menggambar FT, XT, serta GT. Baru sampai panah ketiga, saya sudah ingin tertawa: bagaimana pinjaman berjangka tetap bisa dipecah menjadi tiga jenis token? Desainnya memang cerdik, tetapi sebenarnya pengguna biasa harus memperhatikan yang mana?

Saya coba luruskan dulu logikanya. FT mirip obligasi tanpa kupon; saat jatuh tempo, FT bisa ditukar kembali dengan aset utang sesuai nilai nominal. XT melengkapi bagian diskonto FT: menurut definisi protokol, 1 FT ditambah 1 XT selalu setara dengan 1 unit aset utang. GT adalah ERC-721 yang memuat agunan dan posisi utang. Peminjam mengunci agunan, mencetak FT, lalu memecah FT menjadi bagian pokok dan bunga untuk ditukar dengan XT, dan akhirnya menyatukannya kembali menjadi aset yang ingin dipinjam. Di atas kertas, mekanismenya cukup rapi dan tertutup. Saya akui ini lebih mudah diverifikasi daripada “suku bunga yang muncul begitu saja di halaman”.

Namun, semakin jauh saya membaca, semakin banyak yang membuat saya bertanya-tanya. Harga FT berubah mengikuti sisa jangka waktu dan kurva pasar, nilai XT menjadi nol saat jatuh tempo, sedangkan GT menanggung risiko likuidasi. Ketiga token itu masing-masing mencatat jangka waktu, bunga, dan agunan serta utang. TermMax membuat sebuah pinjaman jadi sangat transparan, tetapi juga memecah status yang perlu dipahami pengguna menjadi bagian-bagian yang lebih rumit. Transaksi sekali klik di halaman bukan berarti otak kita juga bisa langsung memahaminya, kan?

Yang lebih penting, peminjam bisa melunasi langsung dengan aset utang, atau membeli FT yang didiskon untuk melunasi. Kedengarannya fleksibel, tetapi artinya biaya keluar lebih awal tidak hanya bergantung pada suku bunga yang dikunci sejak awal, melainkan juga pada kedalaman pasar FT dan harga yang ditawarkan kurva saat itu. Suku bunga tetap memberi kepastian kontrak, tetapi harga untuk keluar tetap harus mengikuti pasar.

Saya juga membandingkannya dengan kondisi saat jatuh tempo. Dalam keadaan normal, FT ditebus sesuai nilai nominal. Namun, jika peminjam terlambat membayar dan likuidasi tidak tuntas dalam jangka waktu yang ditentukan, kumpulan penebusan bisa saja tercampur dengan agunan. Jadi, FT memang mirip obligasi, tetapi perlindungan kreditnya bukan janji pembayaran dari suatu lembaga. Perlindungan itu bergantung pada rasio agunan, oracle, likuidator, dan likuiditas pasar yang saling menopang. Luput memperhatikan satu saja, kesimpulannya bisa meleset.

Jadi, setelah meneliti #TermMax , yang paling ingin saya lihat bukan poster “APY tetap” lainnya, melainkan penjelasan yang mudah dipahami tentang perubahan FT, XT, dan GT di setiap posisi, serta jalur keluar terburuknya. Mekanisme rumit boleh disembunyikan di balik satu klik. Namun, kalau risikonya ikut disembunyikan, penyederhanaan ini sebenarnya melayani pengguna atau hanya mendorong transaksi?
$PRL $CLO
Lihat terjemahan
聊点不太性感、但真正决定网络能不能长期跑下去的东西:$DUSK 的发行与质押。看完 @Dusk_Foundation 最新文档,我发现不少讨论只盯着“最大供应量10亿”,却忽略了这10亿并不是一次性进入市场。 Dusk的模型是5亿初始供应,再用36年释放另外5亿作为网络奖励,排放按四年减半的几何节奏递减。代币用途目前很直接:支付Gas、参与质押并保护共识。直接成为Provisioner至少需要质押1000 DUSK,还要让节点持续在线和同步;官方给出的基础配置不夸张,但奖励是按共识参与和有效质押概率产生,不是存进去就固定收息。 这套设计的合理之处,是把网络使用和安全预算绑在一起。区块奖励由新增发行与交易费构成,早期用排放补贴节点,后期则更依赖真实手续费。如果生态调用增长,安全预算能逐步从“发新币”过渡到“用户为服务付费”,逻辑才算闭环。 但风险也很明确。36年排放意味着长期稀释不能只看总量口号;最低1000枚加上运维要求,会把直接质押挡在部分小持有者之外;奖励具有概率性,也容易被误读成稳定年化。更关键的是,如果链上交易和应用收入起不来,手续费无法接棒,网络安全最终仍主要靠发行补贴。 所以我观察 #dusk 不会只看质押比例高不高,而会把三个指标放在一起:活跃Provisioner是否分散、真实交易费占奖励的比例、节点升级后能否稳定在线。单看锁仓量可能很漂亮,锁得多却没人使用,只是把流动性藏起来,并没有证明需求。 你觉得一条新网络早期应该优先提高质押参与,还是先把真实手续费做起来?留下你的排序。 $ETH $RED
聊点不太性感、但真正决定网络能不能长期跑下去的东西:$DUSK 的发行与质押。看完 @Dusk 最新文档,我发现不少讨论只盯着“最大供应量10亿”,却忽略了这10亿并不是一次性进入市场。

Dusk的模型是5亿初始供应,再用36年释放另外5亿作为网络奖励,排放按四年减半的几何节奏递减。代币用途目前很直接:支付Gas、参与质押并保护共识。直接成为Provisioner至少需要质押1000 DUSK,还要让节点持续在线和同步;官方给出的基础配置不夸张,但奖励是按共识参与和有效质押概率产生,不是存进去就固定收息。

这套设计的合理之处,是把网络使用和安全预算绑在一起。区块奖励由新增发行与交易费构成,早期用排放补贴节点,后期则更依赖真实手续费。如果生态调用增长,安全预算能逐步从“发新币”过渡到“用户为服务付费”,逻辑才算闭环。

但风险也很明确。36年排放意味着长期稀释不能只看总量口号;最低1000枚加上运维要求,会把直接质押挡在部分小持有者之外;奖励具有概率性,也容易被误读成稳定年化。更关键的是,如果链上交易和应用收入起不来,手续费无法接棒,网络安全最终仍主要靠发行补贴。

所以我观察 #dusk 不会只看质押比例高不高,而会把三个指标放在一起:活跃Provisioner是否分散、真实交易费占奖励的比例、节点升级后能否稳定在线。单看锁仓量可能很漂亮,锁得多却没人使用,只是把流动性藏起来,并没有证明需求。

你觉得一条新网络早期应该优先提高质押参与,还是先把真实手续费做起来?留下你的排序。
$ETH $RED
Saya membongkar ulang mekanisme fixed rate untuk @termmax , berkali-kali sampai rasanya kata “fixed” saja sudah cukup membuat orang lengah. Memang, suku bunga bisa dikunci saat transaksi, tapi apakah hasil akhir saya benar-benar ikut “fixed” juga? Pertama, soal pinjaman. TermMax di tiap market menentukan dulu aset utang, agunan, dan tanggal jatuh tempo. Lalu peminjam mengunci agunan ke GT, kemudian mencetak FT yang merepresentasikan utang yang akan jatuh tempo. Biaya tidak ikut loncat-loncat mengikuti tingkat pemanfaatan—saya akui ini bagus, minimal saya tidak perlu begadang mengawasi floating rate pinjaman. Tapi selama LTV menyentuh LLTV, posisi tetap akan masuk proses likuidasi. Yang “dikunci” adalah harga dana, bukan harga agunan, dan bukan juga keamanan pokok—tiga hal ini dicampur-adukkan dalam promosi, menurut saya itu mudah menyesatkan. Kedua, soal tanggal jatuh tempo. Dokumennya menjelaskan sangat jelas: jika tidak dibayar saat lewat jatuh tempo, itu akan memicu likuidasi, dan ada jendela likuidasi selama dua jam. Kalau utang belum diberes bersih, akan masuk ke physical delivery, dan pool tebusan yang diterima pemegang FT bisa sekaligus berisi aset dasar dan agunan. Awalnya saya kira membeli FT berarti menunggu sampai jatuh tempo lalu menerima aset utang yang sama seperti semula. Ternyata dalam kondisi ekstrem, bisa saja yang Anda pegang malah sekelompok agunan yang harus Anda urus sendiri. Ini masih termasuk “pendapatan tetap” seperti yang biasa dipahami orang awam? Bagian oracle juga tidak bisa diabaikan. TermMax sendiri menandai Chainlink dan sumber harga RedStone sebagai titik risiko. Jika ada anomali feed harga, bisa menyebabkan likuidasi yang keliru atau agunan yang tidak mencukupi. Fixed rate tidak bisa membantu saya menghalau sumber harga yang gagal—risiko ini hanya berpindah dari kurva suku bunga ke penilaian (valuasi) dan jalur likuidasi. Biaya likuidasi pun tidak bisa diselesaikan hanya dengan kalimat “over-collateralization”. Aturan publik menyebutkan: untuk nilai utang yang dilikuidasi ada penalti 10%, separuh untuk para pelikuidator dan separuh masuk ke cadangan protokol; ketika utang melebihi 10.000 dolar, biasanya per transaksi maksimum yang diproses adalah 50%. Ini membantu supaya posisi besar tidak langsung dipotong habis sekaligus. Tapi kalau pasar benar-benar terus anjlok beruntun, apakah pemrosesan bertahap cukup tepat waktu—itu tetap bergantung pada eksekusi on-chain dan likuiditas. Jadi saat saya melihat #TermMax , jangan cuma tanya apakah APY di halaman itu benar-benar dikunci. Lebih tepatnya tanya: agunannya apa, LLTV ada di mana, siapa yang bertanggung jawab membayar saat jatuh tempo, dan setelah physical delivery, apa yang sebenarnya akan saya terima. Suku bunga memang tertahan, tapi risikonya tidak “ditambatkan” di tempat yang sama, bukan? $GPS $ETH
Saya membongkar ulang mekanisme fixed rate untuk @TermMax , berkali-kali sampai rasanya kata “fixed” saja sudah cukup membuat orang lengah. Memang, suku bunga bisa dikunci saat transaksi, tapi apakah hasil akhir saya benar-benar ikut “fixed” juga?

Pertama, soal pinjaman. TermMax di tiap market menentukan dulu aset utang, agunan, dan tanggal jatuh tempo. Lalu peminjam mengunci agunan ke GT, kemudian mencetak FT yang merepresentasikan utang yang akan jatuh tempo. Biaya tidak ikut loncat-loncat mengikuti tingkat pemanfaatan—saya akui ini bagus, minimal saya tidak perlu begadang mengawasi floating rate pinjaman. Tapi selama LTV menyentuh LLTV, posisi tetap akan masuk proses likuidasi. Yang “dikunci” adalah harga dana, bukan harga agunan, dan bukan juga keamanan pokok—tiga hal ini dicampur-adukkan dalam promosi, menurut saya itu mudah menyesatkan.

Kedua, soal tanggal jatuh tempo. Dokumennya menjelaskan sangat jelas: jika tidak dibayar saat lewat jatuh tempo, itu akan memicu likuidasi, dan ada jendela likuidasi selama dua jam. Kalau utang belum diberes bersih, akan masuk ke physical delivery, dan pool tebusan yang diterima pemegang FT bisa sekaligus berisi aset dasar dan agunan. Awalnya saya kira membeli FT berarti menunggu sampai jatuh tempo lalu menerima aset utang yang sama seperti semula. Ternyata dalam kondisi ekstrem, bisa saja yang Anda pegang malah sekelompok agunan yang harus Anda urus sendiri. Ini masih termasuk “pendapatan tetap” seperti yang biasa dipahami orang awam?

Bagian oracle juga tidak bisa diabaikan. TermMax sendiri menandai Chainlink dan sumber harga RedStone sebagai titik risiko. Jika ada anomali feed harga, bisa menyebabkan likuidasi yang keliru atau agunan yang tidak mencukupi. Fixed rate tidak bisa membantu saya menghalau sumber harga yang gagal—risiko ini hanya berpindah dari kurva suku bunga ke penilaian (valuasi) dan jalur likuidasi.

Biaya likuidasi pun tidak bisa diselesaikan hanya dengan kalimat “over-collateralization”. Aturan publik menyebutkan: untuk nilai utang yang dilikuidasi ada penalti 10%, separuh untuk para pelikuidator dan separuh masuk ke cadangan protokol; ketika utang melebihi 10.000 dolar, biasanya per transaksi maksimum yang diproses adalah 50%. Ini membantu supaya posisi besar tidak langsung dipotong habis sekaligus. Tapi kalau pasar benar-benar terus anjlok beruntun, apakah pemrosesan bertahap cukup tepat waktu—itu tetap bergantung pada eksekusi on-chain dan likuiditas.

Jadi saat saya melihat #TermMax , jangan cuma tanya apakah APY di halaman itu benar-benar dikunci. Lebih tepatnya tanya: agunannya apa, LLTV ada di mana, siapa yang bertanggung jawab membayar saat jatuh tempo, dan setelah physical delivery, apa yang sebenarnya akan saya terima. Suku bunga memang tertahan, tapi risikonya tidak “ditambatkan” di tempat yang sama, bukan?
$GPS $ETH
Saya meninjau lagi panduan migrasi mainnet untuk @Dusk_Foundation , ada detail yang sangat mudah diabaikan: menekan Approve di dompet tidak berarti $DUSK sudah dipindahkan ke mainnet Dusk. Pemicu migrasinya sebenarnya adalah Execute transaction di langkah berikutnya. Di antara dua langkah tersebut, jika terjadi gangguan apa pun, pengguna bisa keliru mengira aset mereka “terkunci”. Prosedur resminya adalah mengunci DUSK ERC-20 di Ethereum atau BEP-20 DUSK di BNB Chain ke dalam kontrak migrasi, lalu mendistribusikan koin asli yang sesuai ke akun mainnet Dusk yang ditentukan. Pengguna perlu menyiapkan dompet EVM self-custody, akun Dusk, serta membayar biaya sumber chain berupa ETH atau BNB; setelah mengonfirmasi transaksi, biasanya masih perlu menunggu pemrosesan. Akun bursa umumnya tidak bisa menyelesaikan rangkaian ini langsung melalui WalletConnect; perlu menautkannya dengan dompet yang memang Anda kendalikan terlebih dahulu. Mekanismenya sendiri tidak sulit, tetapi jebakannya ada pada batas operasinya. Pertama, otorisasi hanya memberikan kuota ke kontrak, tidak otomatis memindahkan token; kedua, token di chain sumber memiliki 18 desimal, sedangkan DUSK di mainnet hanya 9 desimal. Nilai migrasi akan dibulatkan ke bawah ke unit minimum LUX; sisa ekor yang nilainya kurang dari 1 LUX akan tertinggal di dompet asal. Ketiga, ketika melihat saldo tidak masuk, seharusnya lebih dulu memverifikasi apakah transaksi Execute berhasil, bukan mengulang otorisasi. Desain penguncian satu arah lalu pendistribusian ini lebih jelas daripada meminta pengguna mencari pool lintas-chain sendiri, tetapi tetap saja memasukkan dua chain, dua dompet, dan dua kali konfirmasi ke dalam satu alur. Bagi pengguna lama cukup “lihat sekilas lebih”, tetapi bagi pendatang baru bisa saja memahami “otorisasi sukses” sebagai “migrasi selesai”. Jika mekanisme keamanan tidak dijelaskan dengan gamblang di antarmuka, pada akhirnya akan tetap berubah menjadi kesalahan manusia. Jadi saat saya melihat migrasi mainnet untuk #dusk , saya tidak hanya memeriksa apakah kontraknya sudah diaudit, tetapi juga apakah dompet menampilkan langkah yang sedang berlangsung, hash chain sumber, status pemrosesan yang diperkirakan, dan alamat penerimaan secara bersamaan. Dokumentasi resmi sudah memberikan jalur verifikasi yang jelas—ini nilai tambah. Langkah berikutnya seharusnya memasukkan pengingat-pengingat ini ke setiap tombol kunci, bukan menunggu pengguna gagal lalu baru mencari bantuan di pusat bantuan. Saat Anda memigrasikan aset, langkah mana yang paling Anda takutkan: otorisasi, salah memilih jaringan, atau status penerimaan yang tidak transparan? Ceritakan jebakan operasional yang pernah Anda alami. $ACE $BTC
Saya meninjau lagi panduan migrasi mainnet untuk @Dusk , ada detail yang sangat mudah diabaikan: menekan Approve di dompet tidak berarti $DUSK sudah dipindahkan ke mainnet Dusk. Pemicu migrasinya sebenarnya adalah Execute transaction di langkah berikutnya. Di antara dua langkah tersebut, jika terjadi gangguan apa pun, pengguna bisa keliru mengira aset mereka “terkunci”.

Prosedur resminya adalah mengunci DUSK ERC-20 di Ethereum atau BEP-20 DUSK di BNB Chain ke dalam kontrak migrasi, lalu mendistribusikan koin asli yang sesuai ke akun mainnet Dusk yang ditentukan. Pengguna perlu menyiapkan dompet EVM self-custody, akun Dusk, serta membayar biaya sumber chain berupa ETH atau BNB; setelah mengonfirmasi transaksi, biasanya masih perlu menunggu pemrosesan. Akun bursa umumnya tidak bisa menyelesaikan rangkaian ini langsung melalui WalletConnect; perlu menautkannya dengan dompet yang memang Anda kendalikan terlebih dahulu.

Mekanismenya sendiri tidak sulit, tetapi jebakannya ada pada batas operasinya. Pertama, otorisasi hanya memberikan kuota ke kontrak, tidak otomatis memindahkan token; kedua, token di chain sumber memiliki 18 desimal, sedangkan DUSK di mainnet hanya 9 desimal. Nilai migrasi akan dibulatkan ke bawah ke unit minimum LUX; sisa ekor yang nilainya kurang dari 1 LUX akan tertinggal di dompet asal. Ketiga, ketika melihat saldo tidak masuk, seharusnya lebih dulu memverifikasi apakah transaksi Execute berhasil, bukan mengulang otorisasi.

Desain penguncian satu arah lalu pendistribusian ini lebih jelas daripada meminta pengguna mencari pool lintas-chain sendiri, tetapi tetap saja memasukkan dua chain, dua dompet, dan dua kali konfirmasi ke dalam satu alur. Bagi pengguna lama cukup “lihat sekilas lebih”, tetapi bagi pendatang baru bisa saja memahami “otorisasi sukses” sebagai “migrasi selesai”. Jika mekanisme keamanan tidak dijelaskan dengan gamblang di antarmuka, pada akhirnya akan tetap berubah menjadi kesalahan manusia.

Jadi saat saya melihat migrasi mainnet untuk #dusk , saya tidak hanya memeriksa apakah kontraknya sudah diaudit, tetapi juga apakah dompet menampilkan langkah yang sedang berlangsung, hash chain sumber, status pemrosesan yang diperkirakan, dan alamat penerimaan secara bersamaan. Dokumentasi resmi sudah memberikan jalur verifikasi yang jelas—ini nilai tambah. Langkah berikutnya seharusnya memasukkan pengingat-pengingat ini ke setiap tombol kunci, bukan menunggu pengguna gagal lalu baru mencari bantuan di pusat bantuan.

Saat Anda memigrasikan aset, langkah mana yang paling Anda takutkan: otorisasi, salah memilih jaringan, atau status penerimaan yang tidak transparan? Ceritakan jebakan operasional yang pernah Anda alami.
$ACE $BTC
Setelah membandingkan lengkap dokumentasi pengembangan @Dusk_Foundation , saya baru menyadari bahwa yang paling layak diperhatikan sekarang bukanlah slogan TPS tertentu, melainkan pemisahan pintu masuk pengembangan menjadi dua lingkungan: DuskVM dan DuskEVM. Ini tampak seperti mengulang pekerjaan yang sudah ada, padahal sebenarnya bertujuan menyelesaikan masalah bahwa “kemampuan privasi native” dan “ekosistem pengembangan yang sudah tersedia” tidak bisa didapat sekaligus dalam satu langkah. DuskVM memungkinkan kontrak Rust/WASM berjalan langsung di L1, lebih dekat ke transaksi terlindungi Phoenix, kemampuan zero-knowledge, dan model aset native; sementara DuskEVM berbasis OP Stack, sehingga pengembang tetap bisa memakai Solidity, Hardhat, Foundry, dan alat dompet yang sudah familiar, lalu hasil eksekusi diselesaikan melalui DuskDS untuk settlement dan ketersediaan data. Singkatnya, yang pertama seperti laboratorium khusus dengan kemampuan kuat tetapi ambang belajar tinggi; yang kedua seperti antarmuka standar, cepat diintegrasikan, tetapi harus menangani koordinasi lintas lapisan. Jalur ini memang pragmatis. Banyak chain privasi yang teknologinya sangat berat, tetapi akhirnya terhambat karena tidak ada yang bisa mengembangkan di atasnya; sementara chain EVM biasa alatnya lengkap, tetapi sulit menangani secara native kerahasiaan dan pengungkapan selektif yang dibutuhkan aset teregulasi. Dusk mempertahankan kedua jenis pengembang, setidaknya menghindari masalah lama “teknologinya benar, ekosistemnya kosong”. Namun, dua lingkungan bukanlah keuntungan gratis. Kontrak ditempatkan di lapisan mana, aset berpindah antar lapisan bagaimana, dan saat terjadi kegagalan lapisan mana yang bertanggung jawab, semuanya akan menambah kompleksitas rekayasa. Terutama DuskEVM yang bergantung pada DuskDS untuk settlement dan ketersediaan data; yang dilihat pengguna adalah antarmuka EVM yang familiar, tetapi di bawahnya bukan sidechain Ethereum biasa. Jika dokumentasi, browser, dan petunjuk status lintas lapisan tidak mengikuti, kompatibilitas justru akan menciptakan biaya pemahaman baru. Saat ini saya tidak akan langsung menyimpulkan pertumbuhan pengembang #dusk hanya karena “mendukung Solidity”. Yang lebih layak dipantau berikutnya adalah: jumlah kontrak nyata di mainnet, apakah jalur aset lintas lapisan lancar, dan kapan kemampuan rahasia seperti Hedger menjadi komponen yang bisa dipakai ulang. $DUSK sebagai aset Gas dan keamanan di dua lingkungan ini, pada akhirnya juga harus dibuktikan lewat volume penggunaan nyata, bukan melalui diagram arsitektur yang berputar sendiri. Menurutmu, apakah dua lingkungan eksekusi ini merupakan pembagian tugas yang cerdas, atau justru memperbesar beban pemeliharaan? Silakan tinggalkan pendapatmu. $BTW $ETH
Setelah membandingkan lengkap dokumentasi pengembangan @Dusk , saya baru menyadari bahwa yang paling layak diperhatikan sekarang bukanlah slogan TPS tertentu, melainkan pemisahan pintu masuk pengembangan menjadi dua lingkungan: DuskVM dan DuskEVM. Ini tampak seperti mengulang pekerjaan yang sudah ada, padahal sebenarnya bertujuan menyelesaikan masalah bahwa “kemampuan privasi native” dan “ekosistem pengembangan yang sudah tersedia” tidak bisa didapat sekaligus dalam satu langkah.

DuskVM memungkinkan kontrak Rust/WASM berjalan langsung di L1, lebih dekat ke transaksi terlindungi Phoenix, kemampuan zero-knowledge, dan model aset native; sementara DuskEVM berbasis OP Stack, sehingga pengembang tetap bisa memakai Solidity, Hardhat, Foundry, dan alat dompet yang sudah familiar, lalu hasil eksekusi diselesaikan melalui DuskDS untuk settlement dan ketersediaan data. Singkatnya, yang pertama seperti laboratorium khusus dengan kemampuan kuat tetapi ambang belajar tinggi; yang kedua seperti antarmuka standar, cepat diintegrasikan, tetapi harus menangani koordinasi lintas lapisan.

Jalur ini memang pragmatis. Banyak chain privasi yang teknologinya sangat berat, tetapi akhirnya terhambat karena tidak ada yang bisa mengembangkan di atasnya; sementara chain EVM biasa alatnya lengkap, tetapi sulit menangani secara native kerahasiaan dan pengungkapan selektif yang dibutuhkan aset teregulasi. Dusk mempertahankan kedua jenis pengembang, setidaknya menghindari masalah lama “teknologinya benar, ekosistemnya kosong”.

Namun, dua lingkungan bukanlah keuntungan gratis. Kontrak ditempatkan di lapisan mana, aset berpindah antar lapisan bagaimana, dan saat terjadi kegagalan lapisan mana yang bertanggung jawab, semuanya akan menambah kompleksitas rekayasa. Terutama DuskEVM yang bergantung pada DuskDS untuk settlement dan ketersediaan data; yang dilihat pengguna adalah antarmuka EVM yang familiar, tetapi di bawahnya bukan sidechain Ethereum biasa. Jika dokumentasi, browser, dan petunjuk status lintas lapisan tidak mengikuti, kompatibilitas justru akan menciptakan biaya pemahaman baru.

Saat ini saya tidak akan langsung menyimpulkan pertumbuhan pengembang #dusk hanya karena “mendukung Solidity”. Yang lebih layak dipantau berikutnya adalah: jumlah kontrak nyata di mainnet, apakah jalur aset lintas lapisan lancar, dan kapan kemampuan rahasia seperti Hedger menjadi komponen yang bisa dipakai ulang. $DUSK sebagai aset Gas dan keamanan di dua lingkungan ini, pada akhirnya juga harus dibuktikan lewat volume penggunaan nyata, bukan melalui diagram arsitektur yang berputar sendiri.

Menurutmu, apakah dua lingkungan eksekusi ini merupakan pembagian tugas yang cerdas, atau justru memperbesar beban pemeliharaan? Silakan tinggalkan pendapatmu.
$BTW $ETH
Saya membaca ulang laporan evaluasi jembatan lintas rantai bulan Maret tahun ini, @Dusk_Foundation . Yang paling penting diingat bukanlah “konsensus mainnet tidak bermasalah”, melainkan fakta lain yang lebih menyakitkan: hak akses sebuah dompet penanda tangan pernah begitu besar hingga bisa menyeret seluruh jembatan ikut tenggelam. Pada 16 Januari, penyerang memperoleh akses ke dompet penanda tangan Dusk milik layanan jembatan. Mereka lebih dulu memindahkan dana dari sisi Dusk, lalu mengirim sebagian ke BSC. Dalam urutan kejadian yang diungkapkan secara resmi, ada 9.000, 89.700, 2.743.310, dan 8.068.000 token $DUSK yang dicuri; ada pula dua transaksi lintas jembatan yang berhasil. Percobaan terakhir sebesar 8.910.000 token gagal setelah layanan dihentikan. Ini bukan berarti konsensus DuskDS ditembus, dan bukan pula berarti kriptografi Phoenix mendadak gagal. Masalahnya ada pada alur operasional jembatan: penandatanganan, pemrosesan peristiwa, dan koneksi jaringan berada di jalur yang sama. Ibaratnya, brankas banknya sendiri tidak dibobol, tetapi pengemudi mobil pengangkut uang memegang sekaligus kunci ruang brankas, peta rute, dan stempel izin. Jika kredensial pengemudi bocor, setebal apa pun brankasnya, mobil tetap bisa melaju ke arah yang salah. Perbaikan setelah evaluasi memang cukup tepat sasaran: penandatanganan dan pemrosesan peristiwa dipisahkan; peristiwa lebih dulu dicatat sebagai tugas, lalu dikerjakan oleh worker terpisah; status transaksi dibagi menjadi seen, submitted, completed, failed, dan stuck; dompet panas hanya menyimpan saldo operasional minimum, dan jika saldo turun di bawah ambang batas, layanan otomatis dijeda, lalu dompet dingin digunakan untuk mengisi ulang secara manual. Sederhananya, jalur yang tadinya “langsung tembus dari ujung ke ujung” kini dipisah menjadi beberapa gerbang. Namun, saya tidak akan menganggap masalah ini selesai hanya karena perbaikannya sudah dilakukan. Hal paling rumit dari jembatan adalah pengguna sering menyamakan keamanan protokol dengan keamanan operasional. Aset yang kamu pegang tetap DUSK yang sama, dan mereknya juga sama, tetapi model kepercayaan yang harus kamu tanggung bisa sama sekali berbeda. Di dalam rantai, keamanan bergantung pada konsensus; saat itu, langkah lintas rantai bergantung pada jalur penandatanganan. Begitu aset melewati batas, asumsi keamanannya sudah berganti kendaraan. Penilaian saya: lini masa dan akar masalah yang diungkapkan secara terbuka jauh lebih baik daripada pernyataan samar seperti “layanan telah pulih”; tetapi evaluasi yang transparan hanyalah awal untuk menilai ulang, bukan sertifikat bebas pemeriksaan. Hal yang benar-benar perlu dipantau selanjutnya pada #dusk adalah apakah paparan dompet panas, mekanisme jeda, isolasi penandatanganan, dan penanganan anomali berjalan sesuai rancangan dalam jangka panjang. Jadi, berhentilah bertanya “Apakah Dusk aman?”—pertanyaan yang terlalu luas dan kosong. Yang seharusnya ditanyakan adalah: aset yang kamu pegang saat ini berada di lapisan mana, siapa yang menandatanganinya, dan jika gerbang mana yang gagal, dana bisa terdampak? Jembatannya sudah dibuat lebih rumit; apakah kepercayaannya benar-benar juga sudah dipecah? Lanjutkan membahasnya di kolom komentar. $BTC
Saya membaca ulang laporan evaluasi jembatan lintas rantai bulan Maret tahun ini, @Dusk . Yang paling penting diingat bukanlah “konsensus mainnet tidak bermasalah”, melainkan fakta lain yang lebih menyakitkan: hak akses sebuah dompet penanda tangan pernah begitu besar hingga bisa menyeret seluruh jembatan ikut tenggelam.

Pada 16 Januari, penyerang memperoleh akses ke dompet penanda tangan Dusk milik layanan jembatan. Mereka lebih dulu memindahkan dana dari sisi Dusk, lalu mengirim sebagian ke BSC. Dalam urutan kejadian yang diungkapkan secara resmi, ada 9.000, 89.700, 2.743.310, dan 8.068.000 token $DUSK yang dicuri; ada pula dua transaksi lintas jembatan yang berhasil. Percobaan terakhir sebesar 8.910.000 token gagal setelah layanan dihentikan.

Ini bukan berarti konsensus DuskDS ditembus, dan bukan pula berarti kriptografi Phoenix mendadak gagal. Masalahnya ada pada alur operasional jembatan: penandatanganan, pemrosesan peristiwa, dan koneksi jaringan berada di jalur yang sama. Ibaratnya, brankas banknya sendiri tidak dibobol, tetapi pengemudi mobil pengangkut uang memegang sekaligus kunci ruang brankas, peta rute, dan stempel izin. Jika kredensial pengemudi bocor, setebal apa pun brankasnya, mobil tetap bisa melaju ke arah yang salah.

Perbaikan setelah evaluasi memang cukup tepat sasaran: penandatanganan dan pemrosesan peristiwa dipisahkan; peristiwa lebih dulu dicatat sebagai tugas, lalu dikerjakan oleh worker terpisah; status transaksi dibagi menjadi seen, submitted, completed, failed, dan stuck; dompet panas hanya menyimpan saldo operasional minimum, dan jika saldo turun di bawah ambang batas, layanan otomatis dijeda, lalu dompet dingin digunakan untuk mengisi ulang secara manual. Sederhananya, jalur yang tadinya “langsung tembus dari ujung ke ujung” kini dipisah menjadi beberapa gerbang.

Namun, saya tidak akan menganggap masalah ini selesai hanya karena perbaikannya sudah dilakukan. Hal paling rumit dari jembatan adalah pengguna sering menyamakan keamanan protokol dengan keamanan operasional. Aset yang kamu pegang tetap DUSK yang sama, dan mereknya juga sama, tetapi model kepercayaan yang harus kamu tanggung bisa sama sekali berbeda. Di dalam rantai, keamanan bergantung pada konsensus; saat itu, langkah lintas rantai bergantung pada jalur penandatanganan. Begitu aset melewati batas, asumsi keamanannya sudah berganti kendaraan.

Penilaian saya: lini masa dan akar masalah yang diungkapkan secara terbuka jauh lebih baik daripada pernyataan samar seperti “layanan telah pulih”; tetapi evaluasi yang transparan hanyalah awal untuk menilai ulang, bukan sertifikat bebas pemeriksaan. Hal yang benar-benar perlu dipantau selanjutnya pada #dusk adalah apakah paparan dompet panas, mekanisme jeda, isolasi penandatanganan, dan penanganan anomali berjalan sesuai rancangan dalam jangka panjang.

Jadi, berhentilah bertanya “Apakah Dusk aman?”—pertanyaan yang terlalu luas dan kosong. Yang seharusnya ditanyakan adalah: aset yang kamu pegang saat ini berada di lapisan mana, siapa yang menandatanganinya, dan jika gerbang mana yang gagal, dana bisa terdampak? Jembatannya sudah dibuat lebih rumit; apakah kepercayaannya benar-benar juga sudah dipecah? Lanjutkan membahasnya di kolom komentar.
$BTC
Lihat terjemahan
我翻到 @Dusk_Foundation 的代币经济页,真正让我停住的不是十亿枚上限,而是一条不起眼的规则:节点最低质押1,000枚 $DUSK ,最高却不设上限。 先把账算明白。Dusk初始供应5亿,计划再用36年释放5亿,前四年每个区块约新增19.8574枚,此后大致每四年减半。区块奖励里,出块者拿70%,还能按证书里的credits多拿最多10%;开发基金10%,验证委员会5%,批准委员会5%,没分出去的部分会销毁。 这套分账像一家公司把奖金拆给前台销售、风控复核和总部预算。好处是每个角色都拿得到钱,验证和批准不再全靠情怀。更关键的是,手续费也并入区块奖励,理论上链上使用越多,安全预算越不只靠增发。 可“不设质押上限”这五个字,才是硬骨头。共识里,provisioner会被随机抽中去提议、验证和批准区块,收益又跟有效质押及参与度相关。大节点资金越厚,被抽中的经济期望越高,奖励再滚回质押,雪球就可能越滚越结实。规则不是明写着让大户垄断,但复利会替规则干脏活。 当然,Dusk也有软惩罚和硬惩罚:掉线可能被暂停并把部分有效质押转成锁定质押;无效投票或双签等可证明的恶意行为,可能直接烧掉部分本金。这像给巨鲸的保险柜装了自毁按钮,可按钮能约束作恶,不会自动解决权重集中。 我的看法挺拧巴:36年递减发行把长期安全预算写得很清楚,这点比拍脑袋调通胀强;但安全预算分给谁,比总量曲线更值得盯。#dusk 要看的不是“十亿上限”这个大标题,而是活跃质押集中度、节点在线率和奖励是否持续向头部回流。 别把供应上限直接翻译成稀缺,也别把质押收益直接翻译成安全。没有上限的节点权重,究竟是在奖励长期投入,还是慢慢把随机委员会变成有钱人的常客席?来广场掰清楚。 $VELVET $SNXXB
我翻到 @Dusk 的代币经济页,真正让我停住的不是十亿枚上限,而是一条不起眼的规则:节点最低质押1,000枚 $DUSK ,最高却不设上限。

先把账算明白。Dusk初始供应5亿,计划再用36年释放5亿,前四年每个区块约新增19.8574枚,此后大致每四年减半。区块奖励里,出块者拿70%,还能按证书里的credits多拿最多10%;开发基金10%,验证委员会5%,批准委员会5%,没分出去的部分会销毁。

这套分账像一家公司把奖金拆给前台销售、风控复核和总部预算。好处是每个角色都拿得到钱,验证和批准不再全靠情怀。更关键的是,手续费也并入区块奖励,理论上链上使用越多,安全预算越不只靠增发。

可“不设质押上限”这五个字,才是硬骨头。共识里,provisioner会被随机抽中去提议、验证和批准区块,收益又跟有效质押及参与度相关。大节点资金越厚,被抽中的经济期望越高,奖励再滚回质押,雪球就可能越滚越结实。规则不是明写着让大户垄断,但复利会替规则干脏活。

当然,Dusk也有软惩罚和硬惩罚:掉线可能被暂停并把部分有效质押转成锁定质押;无效投票或双签等可证明的恶意行为,可能直接烧掉部分本金。这像给巨鲸的保险柜装了自毁按钮,可按钮能约束作恶,不会自动解决权重集中。

我的看法挺拧巴:36年递减发行把长期安全预算写得很清楚,这点比拍脑袋调通胀强;但安全预算分给谁,比总量曲线更值得盯。#dusk 要看的不是“十亿上限”这个大标题,而是活跃质押集中度、节点在线率和奖励是否持续向头部回流。

别把供应上限直接翻译成稀缺,也别把质押收益直接翻译成安全。没有上限的节点权重,究竟是在奖励长期投入,还是慢慢把随机委员会变成有钱人的常客席?来广场掰清楚。
$VELVET $SNXXB
Lihat terjemahan
我对着 @Dusk_Foundation 的交易模型文档看了两遍,最扎眼的不是“隐私”两个字,而是同一条链上摆着两本账:Moonlight公开,Phoenix隐身。 翻成人话,Moonlight像玻璃柜台,地址和转账都能被看见;Phoenix则把资金装进加密票据,用零知识证明告诉网络“这笔钱合法、没双花”,却不把发送方、接收方和金额全摊开。一个账户画像里还能同时管这两种账户。听着像一只钱包装了透明卡和暗格卡,付款时自己选把哪张递出去。 这设计确实聪明。金融机构不是所有数据都能公开,监管也不可能接受什么都看不见。Dusk把选择权放进交易模型:普通结算走明账,敏感头寸走隐私账,需要审计时再用查看密钥做选择性披露。不是把隐私和合规狠狠干一架,而是让它们分桌吃饭。 可问题也藏在“双轨”里。交易所集成文档明确建议充值使用Moonlight,因为Phoenix的加密票据需要另一套托管和扫描逻辑。也就是说,协议给了隐私出口,现实入口却可能为了兼容性把所有人赶回透明通道。好比酒店修了隐蔽贵宾门,前台系统却只认正门身份证;门存在,不代表客人真走得进去。 那 $DUSK 在这里是什么?两种转账都用它付费,合约执行也离不开它。它不是单纯贴在隐私叙事上的标志,而是两套账本之间共同使用的燃料。可燃料有没有需求,最终看钱包、交易所和应用愿不愿意把Phoenix真正接出来,而不是文档里写得漂亮。 我现在的判断:双模型比“一刀切全公开”更贴近真实金融,但复杂性也被从链上搬到了接入方。#dusk 真正该盯的,不是隐私功能有没有,而是有多少入口愿意承担那套额外的扫描、托管和披露成本。 所以别只被“可选择隐私”四个字哄舒服。Moonlight和Phoenix这对双车道,最后会让用户自由选路,还是大多数入口只开放那条最省事的透明车道?评论区继续拆。 $AKE $ACU
我对着 @Dusk 的交易模型文档看了两遍,最扎眼的不是“隐私”两个字,而是同一条链上摆着两本账:Moonlight公开,Phoenix隐身。

翻成人话,Moonlight像玻璃柜台,地址和转账都能被看见;Phoenix则把资金装进加密票据,用零知识证明告诉网络“这笔钱合法、没双花”,却不把发送方、接收方和金额全摊开。一个账户画像里还能同时管这两种账户。听着像一只钱包装了透明卡和暗格卡,付款时自己选把哪张递出去。

这设计确实聪明。金融机构不是所有数据都能公开,监管也不可能接受什么都看不见。Dusk把选择权放进交易模型:普通结算走明账,敏感头寸走隐私账,需要审计时再用查看密钥做选择性披露。不是把隐私和合规狠狠干一架,而是让它们分桌吃饭。

可问题也藏在“双轨”里。交易所集成文档明确建议充值使用Moonlight,因为Phoenix的加密票据需要另一套托管和扫描逻辑。也就是说,协议给了隐私出口,现实入口却可能为了兼容性把所有人赶回透明通道。好比酒店修了隐蔽贵宾门,前台系统却只认正门身份证;门存在,不代表客人真走得进去。

那 $DUSK 在这里是什么?两种转账都用它付费,合约执行也离不开它。它不是单纯贴在隐私叙事上的标志,而是两套账本之间共同使用的燃料。可燃料有没有需求,最终看钱包、交易所和应用愿不愿意把Phoenix真正接出来,而不是文档里写得漂亮。

我现在的判断:双模型比“一刀切全公开”更贴近真实金融,但复杂性也被从链上搬到了接入方。#dusk 真正该盯的,不是隐私功能有没有,而是有多少入口愿意承担那套额外的扫描、托管和披露成本。

所以别只被“可选择隐私”四个字哄舒服。Moonlight和Phoenix这对双车道,最后会让用户自由选路,还是大多数入口只开放那条最省事的透明车道?评论区继续拆。
$AKE $ACU
Masuk untuk menjelajahi konten lainnya
Bergabunglah dengan pengguna kripto global di Binance Square
⚡️ Dapatkan informasi terbaru dan berguna tentang kripto.
💬 Dipercayai oleh bursa kripto terbesar di dunia.
👍 Temukan wawasan nyata dari kreator terverifikasi.
Email/Nomor Ponsel
Sitemap
Preferensi Cookie
S&K Platform