盲簽指的是硬體錢包裝置在簽署交易時，收到的只是一串未經解析的原始十六進位資料或雜湊值，裝置本身沒有能力把這串資料還原成「你正在授權誰、動用多少金額、進行什麼操作」這類人類看得懂的資訊。以太坊早期的 eth_sign 方法正是這種模式的原型——使用者面對的從頭到尾只是一串無法驗證意義的字串，硬體裝置忠實地對這串資料簽名，至於背後真正的交易內容是什麼，裝置完全不知情，使用者也只能選擇相信軟體介面告訴他的說法。
盲簽之所以危險，關鍵不在於「使用者看不懂」這件事本身，而在於「判讀交易內容」這項工作被整個外包給了硬體裝置以外的軟體層——而那層軟體，正是攻擊者最常鎖定竄改的目標。一旦這層軟體被入侵，使用者簽下的內容跟他以為自己在簽的內容，可能完全是兩回事。
盲簽之所以存在，根本原因在於硬體錢包裝置本身的運算與顯示能力極為有限——這些裝置的設計初衷是把私鑰安全地隔離在斷網環境裡，本身的螢幕與處理器通常非常陽春，不足以承擔複雜的資料解析工作。早期以太坊生態系的簽署機制設計時，也還沒有一套標準化的方式讓開發者能把交易資料標註成裝置容易解析的格式，這導致絕大多數交易在裝置端只能以最原始的雜湊值形式呈現，裝置除了忠實簽署這個雜湊值，沒有其他選項。
2017 年出現的 EIP-712 標準試圖解決這個問題，定義了一套「結構化資料簽署」規範，讓開發者能把交易資料按照固定格式標註欄位名稱與型別。但這個標準要真正發揮作用，需要裝置事先擁有對應的「描述檔」才能正確解析特定合約或特定交易類型的資料，這代表面對新部署的合約或標準未涵蓋的交易結構，裝置依然只能退回盲簽模式——這也是為什麼即使 EIP-712 推出多年，盲簽仍未在許多實際使用場景裡真正消失。
硬體錢包廠商依照能否解析交易內容，發展出三種簽署等級：盲簽（完全無法解析，只顯示原始雜湊值或十六進位字串）、透明簽署（transparent signing，能顯示完整的技術欄位，但欄位充滿使用者難以理解的技術細節，例如合約位址、函式選擇器等）、以及明文簽署（clear signing，裝置能正確解析並清楚顯示這筆交易的實際意圖，例如直接顯示「轉出 100 USDC 給 0x1234...」）。這三個等級的差異，本質上取決於裝置端是否擁有對應的描述檔資料庫。
值得特別注意的是，即使裝置支援明文簽署、螢幕顯示的內容清楚易懂，這仍然不保證使用者看到的內容是真的——裝置顯示的「解析結果」，是由某段軟體計算出來的，如果負責生成這段顯示內容的軟體本身遭到入侵（例如遭竄改的錢包管理介面），裝置忠實顯示的就會是被竄改過的假象，鏈上看到的簽名本身依然完全合法有效。這正是為什麼近年業界開始推動 ERC-7730 這類「結構化資料明瞭簽署格式」標準，嘗試把描述檔的產生與驗證流程去中心化、標準化，讓更多合約類型能更快被納入明文簽署範圍，但這仍然是一個持續進行中的產業課題。
如果你使用硬體錢包簽署交易，看到螢幕上顯示一串看不懂的十六進位資料，這是明確的盲簽警訊，尤其在金額較大或合約較陌生的情境下，值得暫停操作，先用交易模擬工具（多數主流軟體錢包已內建）核對一次「這筆交易實際上會讓我的資產發生什麼變化」，再決定是否簽署。但更重要的是記住：即使畫面顯示的是清楚易讀的明文簽署內容，也不代表萬無一失——這份「清楚易讀」同樣是由某段可能遭竄改的軟體算出來的。
對於金額特別大的操作，值得養成的習慣是用一個完全獨立於主要簽署介面之外的來源（例如區塊鏈瀏覽器的解碼工具）額外核對一次交易的原始呼叫資料，而不是只看單一畫面顯示的內容就直接按下確認。這個習慣一旦養成，能同時防範盲簽風險（看不懂原始資料）與更進階的介面偽造風險（看得懂，但內容是假的），是目前業界公認相對務實的自我保護做法。
2025 年 2 月的 Bybit 事件是盲簽風險最具代表性的案例：三位負責核准多簽錢包交易的簽名者，看到的介面顯示這是一筆例行的 3 萬枚 ETH 轉帳，畫面上的收款地址與交易描述看起來完全正常，屬於技術上合格的「明文」呈現，簽名者依照公司規定核對了畫面內容並完成簽署。但這個顯示介面本身已遭攻擊者透過供應鏈攻擊植入惡意程式碼竄改，三位簽名者實際簽署的鏈上內容，是把整個多簽錢包的邏輯合約替換成攻擊者部署的惡意合約，最終導致超過 15 億美元資產被盜，成為加密貨幣史上最大單一竊案——這起事件證明了即使裝置或介面支援明文簽署，只要負責生成顯示內容的軟體本身遭到入侵，「清楚易讀」本身也可能是精心偽造的假象。