Binance Square
东京小姐
4.7k 貼文

东京小姐

绿色就是目标 🗼🔥
實盤交易
中頻交易者
4.9 年
312 關注
22.6K+ 粉絲
12.8K+ 點讚數
貼文
投資組合
·
--
看漲
docs.dusk.network 的遷移指南里在 FAQ 中藏着一個我之前沒在別處見過的“舍入細節”。如果你遷移一筆不是 1 lux 的整倍數的 erc20 或 bep20 dusk,合約會直接把它向下取整——而我在腦中把他們自己的示例反覆推演了兩遍,直到我真正理解了:遷移 1234567890 wei 的 dusk,它會被精確地舍入到 1000000000 wei,即整整 1 個乾淨的 lux;其餘部分不算作任何“部分抵扣”。 所以餘數不會退還,也不會排隊等你之後再補充,它只是從你在原生側收到的金額中被扣掉了。這是遷移機制本身內置的真實成本,不是漏洞;因爲原生的 dusk 使用 9 位小數,而 erc20/bep20 使用 18 位小數,因此在某些轉換過程中不可避免地會出現數學上的舍入。 對大多數人來說,如果遷移的是普通錢包餘額,這大概率只是幾分(甚至更小)級別的差異,確實不會造成影響。但沒有人會在第一次遷移時期待:在一個圍繞確定性結算精度構建的網絡上,默認行爲竟然是“向下取整並丟失差額”。 遷移界面實際是在你確認之前就把“精確的舍入後金額”展示給用戶,還是要等確認之後你才發現? 🧐 #dusk $DUSK @Dusk_Foundation
docs.dusk.network 的遷移指南里在 FAQ 中藏着一個我之前沒在別處見過的“舍入細節”。如果你遷移一筆不是 1 lux 的整倍數的 erc20 或 bep20 dusk,合約會直接把它向下取整——而我在腦中把他們自己的示例反覆推演了兩遍,直到我真正理解了:遷移 1234567890 wei 的 dusk,它會被精確地舍入到 1000000000 wei,即整整 1 個乾淨的 lux;其餘部分不算作任何“部分抵扣”。
所以餘數不會退還,也不會排隊等你之後再補充,它只是從你在原生側收到的金額中被扣掉了。這是遷移機制本身內置的真實成本,不是漏洞;因爲原生的 dusk 使用 9 位小數,而 erc20/bep20 使用 18 位小數,因此在某些轉換過程中不可避免地會出現數學上的舍入。
對大多數人來說,如果遷移的是普通錢包餘額,這大概率只是幾分(甚至更小)級別的差異,確實不會造成影響。但沒有人會在第一次遷移時期待:在一個圍繞確定性結算精度構建的網絡上,默認行爲竟然是“向下取整並丟失差額”。
遷移界面實際是在你確認之前就把“精確的舍入後金額”展示給用戶,還是要等確認之後你才發現? 🧐

#dusk $DUSK @Dusk
@Dusk_Foundation i去核對“零信任託管”("zero-trust custody")在 dusk-cordial-npex 的公告裏到底是什麼意思,因爲那個說法通常意味着某種特定的密碼學架構;我以爲新聞稿很可能只是把它鬆散地用在“自託管而不是第三方 SaaS”上。結果我錯了——說實話,在我真正翻到 cordial 自己的技術文檔之前,我差點就基於那個錯誤的假設把這整篇帖子寫完了。結果發現:cordial 的資金產品確實在用 mpc 閾值簽名,針對 ed25519 用 frost,以及在獨立節點之間運行的 bft 共識層;密鑰份額從來不會在某一個地方被重建。 這纔是真正的分佈式信任密碼學,而不是把營銷包裝成某種“可信”東西。 所以 npex 選擇自託管部署,同時又擁有真正的零信任架構——並不像我一開始想的那樣彼此衝突。cordial 的整個主張就是讓機構自己來運行這種架構,而不是去信任某個 SaaS 供應商的雲。 我目前還不知道的是:npex 到底是在運行完整的多節點 bft 設置,還是更接近單節點部署——因爲 cordial 的文檔裏提到這兩種在技術上都是可用的。即便在同一套底層軟件之上,它們在實踐中也並不等同於“零信任”。 有人知道 npex 目前實際部署的 cordial 是單節點,還是一個真正的多節點閾值方案嗎?🧐 #dusk $DUSK
@Dusk
i去核對“零信任託管”("zero-trust custody")在 dusk-cordial-npex 的公告裏到底是什麼意思,因爲那個說法通常意味着某種特定的密碼學架構;我以爲新聞稿很可能只是把它鬆散地用在“自託管而不是第三方 SaaS”上。結果我錯了——說實話,在我真正翻到 cordial 自己的技術文檔之前,我差點就基於那個錯誤的假設把這整篇帖子寫完了。結果發現:cordial 的資金產品確實在用 mpc 閾值簽名,針對 ed25519 用 frost,以及在獨立節點之間運行的 bft 共識層;密鑰份額從來不會在某一個地方被重建。 這纔是真正的分佈式信任密碼學,而不是把營銷包裝成某種“可信”東西。
所以 npex 選擇自託管部署,同時又擁有真正的零信任架構——並不像我一開始想的那樣彼此衝突。cordial 的整個主張就是讓機構自己來運行這種架構,而不是去信任某個 SaaS 供應商的雲。
我目前還不知道的是:npex 到底是在運行完整的多節點 bft 設置,還是更接近單節點部署——因爲 cordial 的文檔裏提到這兩種在技術上都是可用的。即便在同一套底層軟件之上,它們在實踐中也並不等同於“零信任”。
有人知道 npex 目前實際部署的 cordial 是單節點,還是一個真正的多節點閾值方案嗎?🧐

#dusk $DUSK
·
--
看漲
chainlink 對於在以太坊和 Solana 之間移動 Dusk 的 cct 標準在 2025 年 11 月就已宣佈——而在我們已知 1 月那起橋樑事件發生在 Dusk 的另一條跨鏈路徑之前已經過去了數月。我去核實這兩者是否實際上是同一座橋、只是名字不同——說實話,我半期待它們會是同一件事、換了不同的品牌——但事實並不是。Dusk 自己的架構頁面描述了一座由驗證者運行的獨立原生橋,用於在 Dusk 自身的內部層之間轉移價值;而 chainlink cct 則在 chainlink 自己的去中心化預言機網絡上運行,用於外部的 eth-solana 轉賬。這是兩個真正彼此獨立的系統。 因此,具體在 1 月份原生橋上遭到打擊的那次事件,根本不會碰到 chainlink 那條路徑——從這兩者截然不同的架構方式來看就是如此。以某種我事先沒預料到的方式來說,這反而令人安心。 但下面這點依然讓人不太舒服——當事件通告發出時,沒有任何人解釋這種區分。如果你只是知道“Dusk 在一月份遇到了橋樑問題”,那就沒有任何線索會指向“這隻影響了兩個獨立橋樑系統中的一個”,而弄清這一點的責任完全落在我自己去交叉比對兩則彼此無關的公告上。 有沒有任何一頁資料能真正把 Dusk 的每一座橋各自負責什麼對應起來?還是說確認這一切需要像我剛纔那樣把多份獨立的新聞稿拼起來? 🧐 #dusk $DUSK @Dusk_Foundation
chainlink 對於在以太坊和 Solana 之間移動 Dusk 的 cct 標準在 2025 年 11 月就已宣佈——而在我們已知 1 月那起橋樑事件發生在 Dusk 的另一條跨鏈路徑之前已經過去了數月。我去核實這兩者是否實際上是同一座橋、只是名字不同——說實話,我半期待它們會是同一件事、換了不同的品牌——但事實並不是。Dusk 自己的架構頁面描述了一座由驗證者運行的獨立原生橋,用於在 Dusk 自身的內部層之間轉移價值;而 chainlink cct 則在 chainlink 自己的去中心化預言機網絡上運行,用於外部的 eth-solana 轉賬。這是兩個真正彼此獨立的系統。
因此,具體在 1 月份原生橋上遭到打擊的那次事件,根本不會碰到 chainlink 那條路徑——從這兩者截然不同的架構方式來看就是如此。以某種我事先沒預料到的方式來說,這反而令人安心。
但下面這點依然讓人不太舒服——當事件通告發出時,沒有任何人解釋這種區分。如果你只是知道“Dusk 在一月份遇到了橋樑問題”,那就沒有任何線索會指向“這隻影響了兩個獨立橋樑系統中的一個”,而弄清這一點的責任完全落在我自己去交叉比對兩則彼此無關的公告上。
有沒有任何一頁資料能真正把 Dusk 的每一座橋各自負責什麼對應起來?還是說確認這一切需要像我剛纔那樣把多份獨立的新聞稿拼起來? 🧐
#dusk $DUSK @Dusk
·
--
看漲
我去核實一下,看看 Boreas 過去到底有沒有真正上線到主網,因爲它一直被當作一個重要里程碑在傳播。結果我發現:同名下其實有兩個獨立的測試網事件,相隔兩週。說實話,我差點就停在 5 月 12 日這個日期上,假設那就是整個故事。Dusk 在 5 月 12 日於測試網上啓用了 Boreas,並將其定位爲增強韌性以及 DuskEVM 的就緒。然後到了 5 月 27 日,“boreas release candidate 1”(Boreas 發佈候選 1)上線,同樣在測試網,並且明確被稱爲在主網之前的最終驗證步驟。 所以 5 月 12 日的啓用並不是真正的終點線;它只是更早的一個階段。之後還有一個檢查點,我在別處從沒見過提及,直到我特意去查才發現。到目前爲止,我仍找不到任何公告能確認在這次發佈候選(RC)之後,Boreas 確實已經進入主網。 這本來就是進行硬分叉(hard fork)的常見流程:先測試網、再 RC、最後主網。過程本身沒什麼問題。我只是覺得很多報道把“boreas activated”(Boreas 已啓用)當作一次乾淨利落的單次事件來講,但實際上它至少包含兩個測試網階段,而且可能到現在還沒跨過最後那個階段。 自 5 月 27 日以來,Boreas 是否已經上線主網?還是說發佈候選(RC)仍然是目前爲止確認過的最新一步?🧐 #dusk $DUSK @Dusk_Foundation
我去核實一下,看看 Boreas 過去到底有沒有真正上線到主網,因爲它一直被當作一個重要里程碑在傳播。結果我發現:同名下其實有兩個獨立的測試網事件,相隔兩週。說實話,我差點就停在 5 月 12 日這個日期上,假設那就是整個故事。Dusk 在 5 月 12 日於測試網上啓用了 Boreas,並將其定位爲增強韌性以及 DuskEVM 的就緒。然後到了 5 月 27 日,“boreas release candidate 1”(Boreas 發佈候選 1)上線,同樣在測試網,並且明確被稱爲在主網之前的最終驗證步驟。
所以 5 月 12 日的啓用並不是真正的終點線;它只是更早的一個階段。之後還有一個檢查點,我在別處從沒見過提及,直到我特意去查才發現。到目前爲止,我仍找不到任何公告能確認在這次發佈候選(RC)之後,Boreas 確實已經進入主網。
這本來就是進行硬分叉(hard fork)的常見流程:先測試網、再 RC、最後主網。過程本身沒什麼問題。我只是覺得很多報道把“boreas activated”(Boreas 已啓用)當作一次乾淨利落的單次事件來講,但實際上它至少包含兩個測試網階段,而且可能到現在還沒跨過最後那個階段。
自 5 月 27 日以來,Boreas 是否已經上線主網?還是說發佈候選(RC)仍然是目前爲止確認過的最新一步?🧐
#dusk $DUSK @Dusk
·
--
看漲
@Dusk_Foundation i went to check exactly what the aegis upgrade touched, since march 3rd gets cited as a major milestone but different sources describe it differently — one says mandatory for all node operators, another calls it a testnet-only prep step. turns out both are just incomplete versions of the same thing, and honestly i almost stopped at "one of these is just wrong" before digging into dusk's actual github repo. their rusk release notes list separate aegis activation block heights for mainnet and testnet, 3,590,904 and 2,773,727, confirming it hit both networks, just not at the same block number. 所以其實並沒有什麼範圍衝突,而是存在覆蓋缺口——媒體報道時沒有把這件事完整地寫出來;他們把它寫成了“mainnet 和 testnet,下面是兩者的激活高度”。實際上,他們各自只挑了一個網絡來講,並把那當成了全部故事。 這算是一種很常見的硬分叉上線方式:讓 testnet 的時間點和 mainnet 略微錯開;單就這一點來說並不特別、也談不上有多令人擔心。我只是覺得值得留意的是:當一個本來就很簡單的雙網絡上線經過二次報道後,居然被“拉平”成了兩套互相競爭但不完整的敘事。 有人知道這兩個激活高度在真實的時間線上是否對齊?還是說 testnet 實際上是在 mainnet 之前就激活了?🧐 #dusk $DUSK
@Dusk
i went to check exactly what the aegis upgrade touched, since march 3rd gets cited as a major milestone but different sources describe it differently — one says mandatory for all node operators, another calls it a testnet-only prep step. turns out both are just incomplete versions of the same thing, and honestly i almost stopped at "one of these is just wrong" before digging into dusk's actual github repo. their rusk release notes list separate aegis activation block heights for mainnet and testnet, 3,590,904 and 2,773,727, confirming it hit both networks, just not at the same block number.
所以其實並沒有什麼範圍衝突,而是存在覆蓋缺口——媒體報道時沒有把這件事完整地寫出來;他們把它寫成了“mainnet 和 testnet,下面是兩者的激活高度”。實際上,他們各自只挑了一個網絡來講,並把那當成了全部故事。
這算是一種很常見的硬分叉上線方式:讓 testnet 的時間點和 mainnet 略微錯開;單就這一點來說並不特別、也談不上有多令人擔心。我只是覺得值得留意的是:當一個本來就很簡單的雙網絡上線經過二次報道後,居然被“拉平”成了兩套互相競爭但不完整的敘事。
有人知道這兩個激活高度在真實的時間線上是否對齊?還是說 testnet 實際上是在 mainnet 之前就激活了?🧐
#dusk $DUSK
·
--
看漲
我去查了一下黃昏支付(dusk pay)到底有沒有真正上線:因爲它在 2025 年 1 月的路線圖裏被列爲第一季度交付項,但之後我在讀到的大多數 2026 年相關寫作中都好像消失了。結果發現是我找錯了地方——事實上,我幾乎要得出它根本從未上線過的結論,直到我找到一篇 2026 年 5 月的開發進展追蹤文章,裏面直接寫明:黃昏支付在今年 1 月下旬到 4 月之間的某個時間上線,同時上線的還有雙向橋(two-way bridge)激活以及 Cordial Systems 託管(custody)集成。 所以它確實上線了,只是沒有像 Duskevm 或 Npex 合作那樣獲得那種“頭條式”的報道。這其實也在某種程度上說明了它自身的特點——在歐盟穩定幣(eu stablecoin)規則收緊的同一段時間裏,一個符合 MICA 的支付產品登陸,卻幾乎沒被任何地方注意到;而更“炫”的架構公告反而到處都被報道。 我不認爲這一定是壞事,“安靜地發佈”不等同於“沒能交付”。但對一個與監管高度相關的產品來說,"duskevm is live" 那類頭條與 "dusk pay is live" 的沉默之間的報道落差,更能說明的是加密媒體的優先級,而不是 dusk 的執行情況。 黃昏支付自上線以來有沒有任何實際使用數據?還是說它上線了,但沒人去追蹤採用情況?🧐 #dusk $DUSK @Dusk_Foundation
我去查了一下黃昏支付(dusk pay)到底有沒有真正上線:因爲它在 2025 年 1 月的路線圖裏被列爲第一季度交付項,但之後我在讀到的大多數 2026 年相關寫作中都好像消失了。結果發現是我找錯了地方——事實上,我幾乎要得出它根本從未上線過的結論,直到我找到一篇 2026 年 5 月的開發進展追蹤文章,裏面直接寫明:黃昏支付在今年 1 月下旬到 4 月之間的某個時間上線,同時上線的還有雙向橋(two-way bridge)激活以及 Cordial Systems 託管(custody)集成。
所以它確實上線了,只是沒有像 Duskevm 或 Npex 合作那樣獲得那種“頭條式”的報道。這其實也在某種程度上說明了它自身的特點——在歐盟穩定幣(eu stablecoin)規則收緊的同一段時間裏,一個符合 MICA 的支付產品登陸,卻幾乎沒被任何地方注意到;而更“炫”的架構公告反而到處都被報道。
我不認爲這一定是壞事,“安靜地發佈”不等同於“沒能交付”。但對一個與監管高度相關的產品來說,"duskevm is live" 那類頭條與 "dusk pay is live" 的沉默之間的報道落差,更能說明的是加密媒體的優先級,而不是 dusk 的執行情況。
黃昏支付自上線以來有沒有任何實際使用數據?還是說它上線了,但沒人去追蹤採用情況?🧐
#dusk $DUSK @Dusk
·
--
看漲
termmax 的利基在於固定利率的代幣化債務,而且它並不是在那裏唯一的玩家——pendle、notional 和 term finance 正從不同角度圍繞同一個問題運轉。pendle 將收益型資產拆分爲本金代幣和收益代幣。notional 則通過流動性池來讓 fcash 貫穿其中。termmax 自身的方案是 range order amm:由策展人發佈分段定價曲線,借款人和出借人直接在這些曲線上進行匹配。 我反覆權衡了爲什麼選擇這種特定做法,而不是拍賣模型或純粹的收益拆分,我認爲核心在於控制力——range order 的設定者可以精確塑造流動性在曲線上的落點,而不是僅僅接受一個成交清算價格。對做市商來說這更“手動”,利弊兩面:如果有人確實在良好管理這條曲線,就能獲得更好的利率;但如果沒人去按條件變化更新它,就會更糟。 我還沒有把同一筆交易規模同時在 pendle 和 termmax 上逐筆跑對比真實執行效果,所以這是結構性的判斷,而不是基於回測的結論 📐 #termmax @termmax
termmax 的利基在於固定利率的代幣化債務,而且它並不是在那裏唯一的玩家——pendle、notional 和 term finance 正從不同角度圍繞同一個問題運轉。pendle 將收益型資產拆分爲本金代幣和收益代幣。notional 則通過流動性池來讓 fcash 貫穿其中。termmax 自身的方案是 range order amm:由策展人發佈分段定價曲線,借款人和出借人直接在這些曲線上進行匹配。
我反覆權衡了爲什麼選擇這種特定做法,而不是拍賣模型或純粹的收益拆分,我認爲核心在於控制力——range order 的設定者可以精確塑造流動性在曲線上的落點,而不是僅僅接受一個成交清算價格。對做市商來說這更“手動”,利弊兩面:如果有人確實在良好管理這條曲線,就能獲得更好的利率;但如果沒人去按條件變化更新它,就會更糟。
我還沒有把同一筆交易規模同時在 pendle 和 termmax 上逐筆跑對比真實執行效果,所以這是結構性的判斷,而不是基於回測的結論 📐
#termmax @TermMax
·
--
看漲
edge capital's vault 現已上線,而且這正是會出現披露差距的那種設置。根據其“vault mechanics”文檔,策展人會就他們的金庫所產生的任何利潤收取 10% 到 20% 的績效費用,寫得清清楚楚、直截了當。真正沒有得到同等程度清晰說明——實際上幾乎完全沒有提到的——是:如果像這樣的金庫遇到艱難時期,存款人到底會面臨什麼風險:訂單被逐步平倉時的排隊贖回,或者更糟的是,如果市場進入實物交割,你可能最終拿到的是已交付的抵押品,而不是你最初投入的債務代幣。 所以,策展人的上行是一個乾淨且已披露的百分比。存款人的下行則是排隊位置,且可能會拿到與其存入不一樣的資產。這裏並不是在說這是一場醜聞——因爲在一個主動管理的金庫裏,流動性風險必須有人來承擔,而那從來不可能是運行它的人。我只是覺得,“最高 20% 的績效費用”和“可能收到已交付的抵押品而不是你的存款”——放在同一份文檔的同一段裏——讀起來並不對稱。 我真的在糾結:這算不算對專業管理來說公平的交換,還是說不論是不是 DeFi,每一種金庫結構最終都會走到類似的分配結果 🤷 #termmax @termmax
edge capital's vault 現已上線,而且這正是會出現披露差距的那種設置。根據其“vault mechanics”文檔,策展人會就他們的金庫所產生的任何利潤收取 10% 到 20% 的績效費用,寫得清清楚楚、直截了當。真正沒有得到同等程度清晰說明——實際上幾乎完全沒有提到的——是:如果像這樣的金庫遇到艱難時期,存款人到底會面臨什麼風險:訂單被逐步平倉時的排隊贖回,或者更糟的是,如果市場進入實物交割,你可能最終拿到的是已交付的抵押品,而不是你最初投入的債務代幣。
所以,策展人的上行是一個乾淨且已披露的百分比。存款人的下行則是排隊位置,且可能會拿到與其存入不一樣的資產。這裏並不是在說這是一場醜聞——因爲在一個主動管理的金庫裏,流動性風險必須有人來承擔,而那從來不可能是運行它的人。我只是覺得,“最高 20% 的績效費用”和“可能收到已交付的抵押品而不是你的存款”——放在同一份文檔的同一段裏——讀起來並不對稱。
我真的在糾結:這算不算對專業管理來說公平的交換,還是說不論是不是 DeFi,每一種金庫結構最終都會走到類似的分配結果 🤷

#termmax @TermMax
·
--
看漲
我去核實了 zedger,因爲人們仍然把它當作“現行基礎設施”來引用,但它實際上仍然是——dusk 自己的最新文檔把 phoenix 和 zedger 列爲當前可用的兩種交易模型,所以我最初以爲它悄悄消失了是錯的。 真正的情況是:dusk trade,也就是本應建立在其之上的應用層,來給用戶提供一個實際交易代幣化資產的地方。我直接查看了 trade.dusk.network,它仍然只有等候名單(waitlist-only)——目前頁面上“加入等候名單(join the waitlist)”就是整段號召行動。 這和我最初以爲的“缺口”不一樣,說得更具體一點——最初主網之後的路線圖最後一階段承諾“完整的 zedger”,包括完全可運行的資產發行、清算和結算,並將其定位爲 dusk 2025 願景的一部分。底層交易模型確實存在,但基於它構建的實際交易場所仍處於上線前階段,在等候名單頁面本身上也看不到任何時間表。 有人知道 dusk trade 是否在任何地方有明確的上線日期,還是仍然處於沒有日期的等候名單階段?🧐 #dusk $DUSK @Dusk_Foundation
我去核實了 zedger,因爲人們仍然把它當作“現行基礎設施”來引用,但它實際上仍然是——dusk 自己的最新文檔把 phoenix 和 zedger 列爲當前可用的兩種交易模型,所以我最初以爲它悄悄消失了是錯的。
真正的情況是:dusk trade,也就是本應建立在其之上的應用層,來給用戶提供一個實際交易代幣化資產的地方。我直接查看了 trade.dusk.network,它仍然只有等候名單(waitlist-only)——目前頁面上“加入等候名單(join the waitlist)”就是整段號召行動。
這和我最初以爲的“缺口”不一樣,說得更具體一點——最初主網之後的路線圖最後一階段承諾“完整的 zedger”,包括完全可運行的資產發行、清算和結算,並將其定位爲 dusk 2025 願景的一部分。底層交易模型確實存在,但基於它構建的實際交易場所仍處於上線前階段,在等候名單頁面本身上也看不到任何時間表。
有人知道 dusk trade 是否在任何地方有明確的上線日期,還是仍然處於沒有日期的等候名單階段?🧐

#dusk $DUSK @Dusk
·
--
看漲
我去查了“傍晚(dusk)”的第三方安全評分,因爲他們對“主網上線前十次審計(ten audits before mainnet)”的營銷宣傳得很用力,而且 Certik 的 Skynet 評分顯示“dusk”爲 100 分中的 62。我原本以爲這個數字大致會和審計次數掛鉤——結果我得停下來重新讀一遍 Certik 的方法學頁面,因爲我以爲安全評分基本上就是一個審計統計彙總;但不是,它是把六個獨立類別混合在一起後的綜合結果。 這些審計本身都是真實的:dusk 自己的審計倉庫以及 Zellic 的遷移合約報告都公開可查,且那裏沒有發現漏洞。所以,單項審計報告本身並不存疑。問題在於:一疊“乾淨”的審計報告和一個“複合”的信任評分,回答的是不同的問題,而營銷文案往往把兩者當作可互換的概念,但它們並不等同。 坦白說,我沒有一個衡量基準來判斷在 dusk 這個階段,某個 L1 應該是什麼樣的“良好”Skynet 分數;因此我不能直接說 62 就一定很糟,只能說:僅憑審計歷史本身,62 並沒有被清楚地解釋出來。 有人知道具體是哪六個 Skynet 類別中的哪一項,正在把“dusk”的分數拉低到這個水平嗎?🧐 #dusk $DUSK @Dusk_Foundation {future}(DUSKUSDT)
我去查了“傍晚(dusk)”的第三方安全評分,因爲他們對“主網上線前十次審計(ten audits before mainnet)”的營銷宣傳得很用力,而且 Certik 的 Skynet 評分顯示“dusk”爲 100 分中的 62。我原本以爲這個數字大致會和審計次數掛鉤——結果我得停下來重新讀一遍 Certik 的方法學頁面,因爲我以爲安全評分基本上就是一個審計統計彙總;但不是,它是把六個獨立類別混合在一起後的綜合結果。
這些審計本身都是真實的:dusk 自己的審計倉庫以及 Zellic 的遷移合約報告都公開可查,且那裏沒有發現漏洞。所以,單項審計報告本身並不存疑。問題在於:一疊“乾淨”的審計報告和一個“複合”的信任評分,回答的是不同的問題,而營銷文案往往把兩者當作可互換的概念,但它們並不等同。
坦白說,我沒有一個衡量基準來判斷在 dusk 這個階段,某個 L1 應該是什麼樣的“良好”Skynet 分數;因此我不能直接說 62 就一定很糟,只能說:僅憑審計歷史本身,62 並沒有被清楚地解釋出來。
有人知道具體是哪六個 Skynet 類別中的哪一項,正在把“dusk”的分數拉低到這個水平嗎?🧐

#dusk $DUSK @Dusk
·
--
看漲
termmax 同時使用兩個預言機(chainlink 與 redstone),而文件也把這樣的設計描述成:用來防止單一訊源失效。可以理解。不過我查看了他們文件中實際的預言機資產清單,現在已經是好幾打各自獨立的 pt-token、lrts 與穩定幣衍生品了;每一種都需要各自正確設定對應的價格預言機,而且新的項目也相當定期地被加入。 所以——真正的風險其實不在於雙預言機的設計本身,而在於冗餘是在「某一個訊源停擺」時保護你;卻不是在「兩個訊源同時都對某個薄、且剛上架的新資產給出錯誤資訊」時仍能保護你。更多的擔保資產種類確實有助於資本效率,我懂。只是這意味著預言機風險這一段並不是靜態的,而是每次新資產被允許加入白名單時都在擴大。 對我來說,真正能解決疑慮的是:看到到底是哪一個具體供應商(provider)對應到哪一個具體資產(asset)的對應關係,並且在某個地方有公開列出;而不是只用一句「chainlink 與 redstone」當作涵蓋一切的萬用句 🔍 #termmax @termmax
termmax 同時使用兩個預言機(chainlink 與 redstone),而文件也把這樣的設計描述成:用來防止單一訊源失效。可以理解。不過我查看了他們文件中實際的預言機資產清單,現在已經是好幾打各自獨立的 pt-token、lrts 與穩定幣衍生品了;每一種都需要各自正確設定對應的價格預言機,而且新的項目也相當定期地被加入。
所以——真正的風險其實不在於雙預言機的設計本身,而在於冗餘是在「某一個訊源停擺」時保護你;卻不是在「兩個訊源同時都對某個薄、且剛上架的新資產給出錯誤資訊」時仍能保護你。更多的擔保資產種類確實有助於資本效率,我懂。只是這意味著預言機風險這一段並不是靜態的,而是每次新資產被允許加入白名單時都在擴大。
對我來說,真正能解決疑慮的是:看到到底是哪一個具體供應商(provider)對應到哪一個具體資產(asset)的對應關係,並且在某個地方有公開列出;而不是只用一句「chainlink 與 redstone」當作涵蓋一切的萬用句 🔍

#termmax @TermMax
·
--
看漲
我去看了傍晚(dusk)的區塊獎勵到底是如何拆分的,結果發現裏面有一種我之前沒注意到的燃燒(burn)機制。區塊生成器會獲得基礎 70% 的分配,此外還最多能再加 10%——取決於證書(certificate)裏包含了多少積分(credits)。但無論這額外 10% 裏有多少部分沒有被分配出去,都不會被結轉到下一次分配或重新分配出去,它只是被燃燒掉了。我不得不把那句話又讀了一遍,因爲我原本以爲“未分配(undistributed)”只是會帶到下一個區塊的資金池裏。 所以和大多數在出塊參與度上不區分質量、整個獎勵池都會照付的 PoS 鏈不同,dusk 在每一個區塊的邊際上都在悄悄地形成通縮:取決於生成器的證書完成度。另一端還有一條鏈運行的是 36 年、基於減半(halving)的發放計劃;同樣也會根據執行質量燃燒一些小額的部分。我還沒見過有人把它當作真實的淨供應(net-supply)因素來進行討論或闡述。 這每區塊只是一小個百分比,我並不是說這會讓供應曲線發生根本性的改變。但“36 年發放計劃”聽起來像是一個可預測的、可累加的曲線,而這個燃燒機制意味着實際的淨髮行量會稍微更低一些、也稍微不那麼可預測——這與公告裏的發放計劃所暗示的並不完全一致。 有人統計過從主網(mainnet)開始 dusk 通過這種方式實際被燃燒掉了多少嗎?還是說這個數字在任何地方都沒有公開? 🧐#dusk $DUSK @Dusk_Foundation
我去看了傍晚(dusk)的區塊獎勵到底是如何拆分的,結果發現裏面有一種我之前沒注意到的燃燒(burn)機制。區塊生成器會獲得基礎 70% 的分配,此外還最多能再加 10%——取決於證書(certificate)裏包含了多少積分(credits)。但無論這額外 10% 裏有多少部分沒有被分配出去,都不會被結轉到下一次分配或重新分配出去,它只是被燃燒掉了。我不得不把那句話又讀了一遍,因爲我原本以爲“未分配(undistributed)”只是會帶到下一個區塊的資金池裏。
所以和大多數在出塊參與度上不區分質量、整個獎勵池都會照付的 PoS 鏈不同,dusk 在每一個區塊的邊際上都在悄悄地形成通縮:取決於生成器的證書完成度。另一端還有一條鏈運行的是 36 年、基於減半(halving)的發放計劃;同樣也會根據執行質量燃燒一些小額的部分。我還沒見過有人把它當作真實的淨供應(net-supply)因素來進行討論或闡述。
這每區塊只是一小個百分比,我並不是說這會讓供應曲線發生根本性的改變。但“36 年發放計劃”聽起來像是一個可預測的、可累加的曲線,而這個燃燒機制意味着實際的淨髮行量會稍微更低一些、也稍微不那麼可預測——這與公告裏的發放計劃所暗示的並不完全一致。
有人統計過從主網(mainnet)開始 dusk 通過這種方式實際被燃燒掉了多少嗎?還是說這個數字在任何地方都沒有公開? 🧐#dusk $DUSK @Dusk
·
--
看漲
termax 說的那個功能就像它已經在運行一樣——而且還不是那種“智能解套”。它被定位爲讓槓桿使用者提前退出 gt 持倉的方式:通過設置目標年化收益率(target APR)或目標價格,讓套利者或新的槓桿使用者在到期前把倉位“接走”。從紙面上看聽起來很棒。但它的實際文檔頁面最底部卻有一行在提醒:"not live yet."(還未上線。) 所以到現在爲止,如果你已經在用槓桿並想提前退出,你只能繼續使用在這個功能被宣佈之前就已經存在的選項——手動平倉,承擔市場給你的任何滑點。我理解爲什麼會提前被炒作:團隊這麼做是爲了給 v2 造勢。但消息所暗示的“你今天可以做到的事”和合約實際允許你“今天能做的事”之間,確實存在明顯差距。 我的實際判斷:它會和 2026 年第二季度的其餘 v2 版本一起上線,而不是更早,也不會相差太久——像這種功能通常不會以單獨的形式發佈。也許我在時間點上會判斷錯,但我會把它放在這裏 🎯 #termmax @termmax
termax 說的那個功能就像它已經在運行一樣——而且還不是那種“智能解套”。它被定位爲讓槓桿使用者提前退出 gt 持倉的方式:通過設置目標年化收益率(target APR)或目標價格,讓套利者或新的槓桿使用者在到期前把倉位“接走”。從紙面上看聽起來很棒。但它的實際文檔頁面最底部卻有一行在提醒:"not live yet."(還未上線。)
所以到現在爲止,如果你已經在用槓桿並想提前退出,你只能繼續使用在這個功能被宣佈之前就已經存在的選項——手動平倉,承擔市場給你的任何滑點。我理解爲什麼會提前被炒作:團隊這麼做是爲了給 v2 造勢。但消息所暗示的“你今天可以做到的事”和合約實際允許你“今天能做的事”之間,確實存在明顯差距。
我的實際判斷:它會和 2026 年第二季度的其餘 v2 版本一起上線,而不是更早,也不會相差太久——像這種功能通常不會以單獨的形式發佈。也許我在時間點上會判斷錯,但我會把它放在這裏 🎯
#termmax @TermMax
·
--
看漲
keyrock和hardcoded lab現在都在運行實時vault,而且有一個關於termmax如何處理閒置資本的細節,我還沒看到有人真正討論過——任何尚未被借走的放貸訂單資本都會自動被路由到aave、morpho或venus裏,這樣就不會只是白白閒置不動。老實說,這是一個很聰明的資金管理舉措。 但這也意味着,你所謂的“固定利率”說法,實際上會在一段時間內悄悄地依賴浮動利率協議:等你的資金匹配到賬之前,它會被放在這層浮動機制上。我並不把這當成缺陷——相比讓usdc賺到零收益,顯然更優;不過在目前有兩位在運行策略的curator的情況下,我無法判斷他們宣傳的apys中,有多少真正來自已完成匹配的固定利率放貸,而有多少來自這層在“慢日子”裏承擔主要工作量的浮動利率部分📊 我很好奇:有沒有人見過有人把這種拆分具體、清晰地列出來。 #termmax @termmax
keyrock和hardcoded lab現在都在運行實時vault,而且有一個關於termmax如何處理閒置資本的細節,我還沒看到有人真正討論過——任何尚未被借走的放貸訂單資本都會自動被路由到aave、morpho或venus裏,這樣就不會只是白白閒置不動。老實說,這是一個很聰明的資金管理舉措。
但這也意味着,你所謂的“固定利率”說法,實際上會在一段時間內悄悄地依賴浮動利率協議:等你的資金匹配到賬之前,它會被放在這層浮動機制上。我並不把這當成缺陷——相比讓usdc賺到零收益,顯然更優;不過在目前有兩位在運行策略的curator的情況下,我無法判斷他們宣傳的apys中,有多少真正來自已完成匹配的固定利率放貸,而有多少來自這層在“慢日子”裏承擔主要工作量的浮動利率部分📊
我很好奇:有沒有人見過有人把這種拆分具體、清晰地列出來。
#termmax @TermMax
@Dusk_Foundation i去挖掘了暮色(dusk)的委員會規模究竟是如何運作的,因爲“每輪64個學分”的說法到處都被當作固定值重複。找到了一個GitHub issue,描述的卻是不同的情況——委員會規模上限是64,但當沒有足夠符合條件的提供者(eligible provisioners)時會降到更低;並且法定人數(quorum)也是基於這個更小的數字計算的。除非……當我去核對這個 issue 是提交到哪個代碼庫時,發現它對應的是 dusk-blockchain(舊的 Go 客戶端),並且在2025年6月已由其自身團隊歸檔。 所以這是一種在主網(pre-mainnet)實現中記錄過的行爲,不一定就是現在正在運行的情況——等等,我得更準確點:並不是說現在就一定不同,而是我確實找不到任何能證明“現在不同”或“現在相同”的資料。主網使用的是 rusk(完整的 Rust 重寫),而這種精確的分選(sortition)邏輯是否被繼承過來,或是在過程中被重新設計,我無法確認。 這對一個已經深入到公開文檔層面的網絡來說,確實是一個非常“具體到令人不適”的空白——歷史行爲是真實存在且可追溯的,但我找到的任何東西都並沒有實際確認或否認它在當前在線代碼庫中的情況。 有人真的檢查過當前 rusk 的分選(sortition)代碼嗎?還是大家只是把舊 Go 客戶端的行爲當作仍然成立在重複傳述?🧐 #dusk $DUSK
@Dusk
i去挖掘了暮色(dusk)的委員會規模究竟是如何運作的,因爲“每輪64個學分”的說法到處都被當作固定值重複。找到了一個GitHub issue,描述的卻是不同的情況——委員會規模上限是64,但當沒有足夠符合條件的提供者(eligible provisioners)時會降到更低;並且法定人數(quorum)也是基於這個更小的數字計算的。除非……當我去核對這個 issue 是提交到哪個代碼庫時,發現它對應的是 dusk-blockchain(舊的 Go 客戶端),並且在2025年6月已由其自身團隊歸檔。
所以這是一種在主網(pre-mainnet)實現中記錄過的行爲,不一定就是現在正在運行的情況——等等,我得更準確點:並不是說現在就一定不同,而是我確實找不到任何能證明“現在不同”或“現在相同”的資料。主網使用的是 rusk(完整的 Rust 重寫),而這種精確的分選(sortition)邏輯是否被繼承過來,或是在過程中被重新設計,我無法確認。
這對一個已經深入到公開文檔層面的網絡來說,確實是一個非常“具體到令人不適”的空白——歷史行爲是真實存在且可追溯的,但我找到的任何東西都並沒有實際確認或否認它在當前在線代碼庫中的情況。
有人真的檢查過當前 rusk 的分選(sortition)代碼嗎?還是大家只是把舊 Go 客戶端的行爲當作仍然成立在重複傳述?🧐
#dusk $DUSK
·
--
看漲
我在翻閱 Dusk 關於懲罰(penalization)的工程更新時注意到:這些百分比實際上是逐次複利疊加的——第一次暫停成本爲質押額的 10%,第二次爲 20%,然後是 30%,每次都在遞增。這不是“固定不變的平鋪”——而是在升級。 這意味着:運行在接近 1000 的 Dusk 最低門檻附近的分配者(provisioner),幾乎沒有太多緩衝空間來恢復。兩到三次連續失誤,就可能把小型質押者直接壓到最低線以下。此時文檔說質押會被凍結,必須把質押完全取消再重新質押,才能恢復——不是單純等待某次暫停結束,而是實際的重置。 相反,大型分配者喫掉同樣的 10-20-30% 這組序列,相對其總質押額幾乎沒有感覺。所以,原本用於“同等懲罰不良行爲”的懲罰計劃,最後反而會對小型驗證者(validators)打擊更重。我回頭把這些百分比又重新讀了一遍,實際上讀了兩次,因爲我一直以爲我可能看錯了——把“增加 10%”誤讀成了某種固定重複的 10%。 有沒有任何地方建議的最低質押緩衝(buffer),以避免較小的分配者在不小心的情況下被推入這種重置循環?🧐 #dusk $DUSK @Dusk_Foundation {spot}(DUSKUSDT)
我在翻閱 Dusk 關於懲罰(penalization)的工程更新時注意到:這些百分比實際上是逐次複利疊加的——第一次暫停成本爲質押額的 10%,第二次爲 20%,然後是 30%,每次都在遞增。這不是“固定不變的平鋪”——而是在升級。
這意味着:運行在接近 1000 的 Dusk 最低門檻附近的分配者(provisioner),幾乎沒有太多緩衝空間來恢復。兩到三次連續失誤,就可能把小型質押者直接壓到最低線以下。此時文檔說質押會被凍結,必須把質押完全取消再重新質押,才能恢復——不是單純等待某次暫停結束,而是實際的重置。
相反,大型分配者喫掉同樣的 10-20-30% 這組序列,相對其總質押額幾乎沒有感覺。所以,原本用於“同等懲罰不良行爲”的懲罰計劃,最後反而會對小型驗證者(validators)打擊更重。我回頭把這些百分比又重新讀了一遍,實際上讀了兩次,因爲我一直以爲我可能看錯了——把“增加 10%”誤讀成了某種固定重複的 10%。
有沒有任何地方建議的最低質押緩衝(buffer),以避免較小的分配者在不小心的情況下被推入這種重置循環?🧐
#dusk $DUSK @Dusk
@Dusk_Foundation i went back to read how dusk's citadel actually works instead of just repeating the "privacy plus selective disclosure" pitch, and something doesn't line up. citadel describes the user as fully in charge of their data — they choose what to share, with whom, and can even withdraw access to it later. that's still the current framing too — actually i went in expecting this to be some shelved 2023 idea, but it's sitting right there in dusk's post-mainnet roadmap as the live zk-kyc/aml piece. but regulators generally don't want optional access. audit and reporting requirements usually mean mandatory, revocable-by-no-one visibility, not something a user consents to once and can pull back later. if citadel gives users the power to withdraw disclosure, i'm not sure how that squares with the "regulator can see what they need" framing dusk uses elsewhere — unless there's a separate compliance layer sitting underneath that i just haven't found yet. worth saying: user-controlled data is a genuinely strong privacy feature for dusk, i'm not knocking that part. i just don't think "user-revocable" and "regulator-guaranteed" can both be true of the same disclosure at the same time. anyone seen documentation on what happens if a dusk user withdraws access after a regulator already requested it? 🧐 #dusk $DUSK
@Dusk
i went back to read how dusk's citadel actually works instead of just repeating the "privacy plus selective disclosure" pitch, and something doesn't line up. citadel describes the user as fully in charge of their data — they choose what to share, with whom, and can even withdraw access to it later. that's still the current framing too — actually i went in expecting this to be some shelved 2023 idea, but it's sitting right there in dusk's post-mainnet roadmap as the live zk-kyc/aml piece.
but regulators generally don't want optional access. audit and reporting requirements usually mean mandatory, revocable-by-no-one visibility, not something a user consents to once and can pull back later. if citadel gives users the power to withdraw disclosure, i'm not sure how that squares with the "regulator can see what they need" framing dusk uses elsewhere — unless there's a separate compliance layer sitting underneath that i just haven't found yet.
worth saying: user-controlled data is a genuinely strong privacy feature for dusk, i'm not knocking that part. i just don't think "user-revocable" and "regulator-guaranteed" can both be true of the same disclosure at the same time.
anyone seen documentation on what happens if a dusk user withdraws access after a regulator already requested it? 🧐
#dusk $DUSK
·
--
看漲
部分真實
@Dusk_Foundation i was cross-checking the emission schedule for something else entirely and noticed two of dusk's own domains don't even agree with each other. docs.dusk.network — the actual tokenomics page — says a flat 36-year emission window, geometric decay, halving every 4 years, straightforward. wiki.dusk.network, which sits on their own subdomain, not some random third-party mirror, says something looser: an 18 to 36 year range depending on network conditions. that's not a rounding difference, it's basically a 2x spread on how long the reward tail runs — and i almost dismissed it as a fan wiki thing until i noticed it's literally hosted under dusk.network, not somewhere external. i get that block-time variance shifts the real calendar length a little, that part tracks. but a document called "tokenomics" citing one fixed number while a page on the team's own domain cites a range isn't a rounding issue, it's two different answers to "when does emission stop." for a project built on regulated-grade precision, that's not the kind of gap i'd expect between two pages they both control. anyone know which one's actually current, or are both just stale in different directions? 🧐 #dusk $DUSK
@Dusk
i was cross-checking the emission schedule for something else entirely and noticed two of dusk's own domains don't even agree with each other. docs.dusk.network — the actual tokenomics page — says a flat 36-year emission window, geometric decay, halving every 4 years, straightforward. wiki.dusk.network, which sits on their own subdomain, not some random third-party mirror, says something looser: an 18 to 36 year range depending on network conditions.
that's not a rounding difference, it's basically a 2x spread on how long the reward tail runs — and i almost dismissed it as a fan wiki thing until i noticed it's literally hosted under dusk.network, not somewhere external.
i get that block-time variance shifts the real calendar length a little, that part tracks. but a document called "tokenomics" citing one fixed number while a page on the team's own domain cites a range isn't a rounding issue, it's two different answers to "when does emission stop." for a project built on regulated-grade precision, that's not the kind of gap i'd expect between two pages they both control.
anyone know which one's actually current, or are both just stale in different directions? 🧐

#dusk $DUSK
·
--
看漲
{spot}(DUSKUSDT) @Dusk_Foundation i今天早些時候把 dusk 的 github 和它的價格圖表放在一起對照,只是想看看數字是否和故事一致,結果不是——差得很遠。在主網之前進行了十次獨立的安全審計,chainlink ccip 在線,cordial systems 已爲機構託管完成上鍊接入,dusk pay 已發貨,雙向橋已激活。對任何 l1 來說,這都絕不是一個“安靜”的季度。 而價格卻停在大約 0.10 美元附近,遠離其 ATH,彷彿這些事從未發生。 我知道僅靠提交次數並不說明太多——你可以通過補文檔、更新依賴來給倉庫“填充”活躍度。但十次審計和一個真實的託管集成絕不是裝飾性的東西,它們在機構觸達鏈之前就必須真的能工作。所以要麼市場在錯誤定價執行風險(而這風險已經被消除),要麼它在定價某些其他東西,而從開發者那邊我看不到的東西。 到底是哪一種?如果是第二種——那個 github 上看不出來、究竟在被定價的東西是什麼? 🧐 #dusk $DUSK
@Dusk
i今天早些時候把 dusk 的 github 和它的價格圖表放在一起對照,只是想看看數字是否和故事一致,結果不是——差得很遠。在主網之前進行了十次獨立的安全審計,chainlink ccip 在線,cordial systems 已爲機構託管完成上鍊接入,dusk pay 已發貨,雙向橋已激活。對任何 l1 來說,這都絕不是一個“安靜”的季度。
而價格卻停在大約 0.10 美元附近,遠離其 ATH,彷彿這些事從未發生。
我知道僅靠提交次數並不說明太多——你可以通過補文檔、更新依賴來給倉庫“填充”活躍度。但十次審計和一個真實的託管集成絕不是裝飾性的東西,它們在機構觸達鏈之前就必須真的能工作。所以要麼市場在錯誤定價執行風險(而這風險已經被消除),要麼它在定價某些其他東西,而從開發者那邊我看不到的東西。
到底是哪一種?如果是第二種——那個 github 上看不出來、究竟在被定價的東西是什麼? 🧐
#dusk $DUSK
@babylonlabs_io babylon 米幣在固定時間表下每年大約會多生 8% 的 baby,每次都不例外。用來抵消它的機制根本沒有按計劃運行——它只有在 bsns 將真實的質押獎勵通過 genesis 的拍賣路由時,纔會燃燒 baby。而多質押 mainnet 仍然尚未上線,所以這部分賬本目前大多是空的。 在紙面上,把燃燒與實際收入掛鉤的設計,比設定一個任意的燃燒目標要更好。不過在現實裏,“與實際收入掛鉤”目前只是描述了一個公式,但裏面還沒有填入任何數據。 我找了一下當前的總燃燒量,但沒有在任何地方看到公佈的數字,可能不是因爲有人在刻意隱藏,而是因爲目前還沒多少。 等到多質押 ships 上線,bsns 開始路由真實規模的流量後,燃燒這一側要多久纔會追上到足以對抗那 8% 的差距?$BABY #baby 🔥
@BabylonLabs_io
babylon 米幣在固定時間表下每年大約會多生 8% 的 baby,每次都不例外。用來抵消它的機制根本沒有按計劃運行——它只有在 bsns 將真實的質押獎勵通過 genesis 的拍賣路由時,纔會燃燒 baby。而多質押 mainnet 仍然尚未上線,所以這部分賬本目前大多是空的。

在紙面上,把燃燒與實際收入掛鉤的設計,比設定一個任意的燃燒目標要更好。不過在現實裏,“與實際收入掛鉤”目前只是描述了一個公式,但裏面還沒有填入任何數據。

我找了一下當前的總燃燒量,但沒有在任何地方看到公佈的數字,可能不是因爲有人在刻意隱藏,而是因爲目前還沒多少。

等到多質押 ships 上線,bsns 開始路由真實規模的流量後,燃燒這一側要多久纔會追上到足以對抗那 8% 的差距?$BABY #baby 🔥
登入以探索更多內容
加入幣安廣場中的全球加密貨幣用戶
⚡️ 獲取加密貨幣的最新和實用資訊。
💬 受到全球最大加密貨幣交易所的信任。
👍 發掘來自經過驗證創作者的真實見解。
電子郵件 / 電話號碼
網站地圖
Cookie 偏好設定
平台條款