今天提議對 @Walletbeat 的方法論和顯示進行兩項重大變更： - 將「可驗證性」作為與評級本身不同的獨立維度；問題 #503 - 將非零階段錢包移至類似 L2BEAT 的單獨「其他」標籤；問題 #504 以下是一些想法 🧐

Walletbeat 大部分要查找的內容可以用兩種方式評估： 1⃣ "就用錢包吧兄弟"：通過使用錢包來檢查某個功能是否存在。例如：在發送代幣時，它是否能解析 ENS 地址？它是否有某個地方的代幣接收地址簿？

2⃣ 黑箱測試：在受控環境中運行錢包，觀察其行為。 - L1 提供者獨立性：阻止所有網絡，僅允許 L1 RPC 端點 - 數據收集：分析網絡流量 - 輕客戶端：與一個不誠實的 RPC 節點運行，看看錢包是否會注意到

但有些功能無法由任何一方進行測試： - 錢包使用哪個加密庫？ - 熱錢包的私鑰材料存放在哪裡？ - MPC 錢包如何重建密鑰？ - 我的訂單流數據在發送到交易模擬服務後是否被轉售？

區分錢包對這些事情的 _聲明_ 與這些聲明是否 _可驗證_ 是很有用的。 例如，可驗證的聲明在圓餅圖中顯示為全綠色的切片，而不可驗證的聲明則可以顯示為綠色但有紅色輪廓或類似的樣式。

為了進行階段評估，只有可驗證的聲明才符合資格。此外，Walletbeat 要求源代碼可用性才能達到僅僅是零階段，因此任何沒有可用源代碼的錢包在這一變更下將在方法論上 "領先"。

這個好處在於更清晰的錢包評級和比較，以及屬性之間的相互依賴性減少。源代碼的授權和可用性已經是它們自己的屬性；僅因為源代碼不可用而使其他屬性變紅會損害可理解性。

請在問題 #503 上發表您的看法：

另一個變更是將所有不符合階段 0 的錢包移至 "其他" 標籤，類似於 L2BEAT 對於 "甚至不是 L2 的" 類型項目所做的。

理由：無法來源驗證的錢包在許多屬性上是無法驗證的。通過上述變更，即使我們清楚地表明無法驗證的評級，這些錢包與可驗證錢包的並列也會降低達到階段 0 的動機。

階段 0 是錢包的最低要求：只需提供您的源代碼。 當今人們使用的每個網頁瀏覽器都是源代碼可用的。與網頁瀏覽器相比，錢包的風險更高，因此這並不是一個高標準。

請分享您對問題 #504 的看法：

我不喜歡延長在啟動前仍需解決的問題清單，但將這些問題標記為啟動阻礙者。這是因為雖然從技術上來說，這兩者都不會是方法論的變更，但從 UI/顯示的角度來看，可能會讓人感覺像是一種變更。 感謝您的閱讀！