Keplr 復原地址確認：質押 ATOM 轉出，為何不能直接算新增失竊？（2026）

Keplr 在 2026 年 11 月 8 日的更新中轉述 Web3Auth 的確認，將列出的 Keplr 復原地址歸為復原行動相關，而非惡意或漏洞利用地址。其中完整可見的 Cosmos Hub 地址，也是一筆成功質押份額轉移的收款方。

這讓「質押部位轉到陌生地址」多了一項判讀依據：不能只看到轉出，就把它加進新增失竊；但轉入官方確認的復原地址，也還不能當成持有人已收到返還。關鍵在交易移動的是哪一種資產、由誰接收。

官方確認的是地址用途，先把完整字串對上

Keplr 這則原帖的發文時間是 11 月 8 日 06:31:35 UTC。可核對的 Cosmos Hub 地址如下；這裡列出它是為了辨識交易，請勿把它當成自己的入金地址：

cosmos1atuap9kfnt6y8ykvn3437e7j3z8qffh3qtnmwu

Web3Auth 同日的更新則表示，因應影響部分 Keplr 錢包的安全事件，團隊在 Keplr 協助下，持續把資產轉入其所稱的安全復原錢包。兩則聲明放在一起，提供的是官方對處置用途的說明；不能把「安全」這個用語當成本文對保管結果的獨立保證。

本次可讀取的 Keplr 原文在後段截斷，因此本文只拿完整可見的 Cosmos Hub 地址比對，不據此重建全部復原名單，也不把其他外觀相似的地址自動歸入同一類。先前的Keplr 私鑰外洩報導著重帳戶範圍與白帽保護；這次新增的依據，是可以連回具體交易的地址確認。

一筆成功批次，顯示份額如何進入復原地址

Cosmos Hub 的 liquid 模組文件說明，委託人可以把質押委託轉成 tokenized shares，也就是代表該委託請求權的份額代幣。底層 ATOM 仍在質押，代表部位的份額卻可以轉讓，無須先走完一般解除質押的 21 天等待。份額轉入另一個地址，不能讀成流動 ATOM 已到帳。

可重查的Cosmos Hub 交易原始資料，交易 ID 為 D2283D7E…5311599，區塊高度為 33,766,882，回傳結果 code: 0。資料列出的交易時間是 11 月 7 日 10:18:55 UTC，早於上述地址確認公告；11 月 8 日的新發展是用途被確認，不能把公告日期改當交易發生日期。

這個批次包含十個 MsgTokenizeShares 訊息。以記錄編號 123126 為例，原委託地址是 cosmos1hsdth4tkrnsx60nxffq7r8fn9k9vfsa3wldwd8。在原始 JSON 中，先看 tx.body.messages 的訊息，再對照 tx_response.events 的執行事件；下列訊息索引從 0 起算：

1. messages[1] 的 MsgSetWithdrawAddress，以 delegator_address 指向上述原委託地址，並將 withdraw_address 設為復原地址。
2. messages[2] 的 MsgTokenizeShares，其 delegator_address 仍是同一原地址。找出事件類型 tokenize_shares、屬性 msg_index: 2 的那筆，可看到 share_record_id: 123126；tokenized_shares 列出數量及完整代幣名稱（denom）：cosmosvaloper1zqgheeawp7cmqk27dgyctd80rd8ryhqs6la9wc/123126。斜線前是驗證者地址，後面是記錄編號。
3. messages[17] 的 MsgSend，其 from_address 是原委託地址，to_address 是公告復原地址；amount[0].denom 與上一項完整名稱相同，amount[0].amount 為 360024201。再找 transfer 事件中 msg_index: 17 的那筆，核對 sender、recipient 與 amount，就能對上實際轉移的同一種份額及數量。這是份額代幣的最小單位，不能直接讀成同樣枚數的 ATOM。

成功結果與實際轉帳事件支持份額已移到該地址；Keplr 的聲明則補上地址用途。兩者合起來，支持將這筆份額轉出辨識為官方所稱的復原處置。

底層 ATOM 仍在質押，移動的是可轉讓份額

份額持有人可以將份額贖回為一般質押委託；底層 ATOM 也仍承擔驗證者受罰時被扣減的風險。轉讓份額改變了誰持有部位的請求權，沒有替這筆部位免除質押風險。

這裡有三種角色：獎勵提領地址是 MsgSetWithdrawAddress 設定的提領目的地；份額持有人持有可轉讓、可贖回為一般委託的代幣；記錄擁有者則擁有該代幣化記錄對應的獎勵權利，依模組規格可另行轉移記錄擁有權。本例訊息的 tokenized_share_owner 與 tokenize_shares 事件的 share_owner 都指向復原地址，說明的是記錄擁有者；要確認份額實際轉入，仍須看後續成功的 MsgSend 與 transfer 事件。三種角色在本例指向同一地址，欄位所證明的事仍各有不同。

份額名稱也有意義：不同驗證者、不同記錄編號的份額是不同代幣種類。把全部數量直接相加，或者把代幣化與後續轉帳各算一次損失，都會忽略它們可能描述同一部位的不同處理階段。本文因此不拿這批次換算總失竊金額或美元復原價值。

用途確認、失竊追回與逐戶返還，要用不同證據驗收

要稱某筆資產是「從攻擊者手上追回」，還需把原先失竊的流向接到後續回收交易；官方使用 recovery 一詞，本身無法補齊這段路徑。上述地址確認與份額轉入，是對這筆復原相關轉移的判讀，不能擴張為整起事件或其他交易的結論。

要再往前確認「已返還給使用者」，則要有能對到持有人原有資產的明細、應收數量，以及實際收到資產的交易。收到的是流動 ATOM、份額代幣，或重新建立的質押委託，也會影響核對方式。這些是本文採用的驗收判準，不是官方已公布的返還程序。本文尚未核實真實攻擊損失總額、完整復原名單或逐戶返還完成。

自己的質押部位減少，先留下能逐項對照的紀錄

如果你正在查自己的部位，本文建議先保存鏈別、原地址、驗證者、完整交易 ID、查詢時間，以及每一筆資產的完整代幣名稱與原始數量。依上例從 messages 找原地址與代幣名稱，再從 events 找記錄編號與實際收款方；確認收款方完整符合官方可見地址，再將該筆列為「官方確認地址的復原相關轉移，個人返還待核對」。對不上的部分保留為未明交易，向官方詢問時附上原始紀錄。

下一項值得等的更新，是將份額記錄編號、後續處置交易、各持有人應收與實收資產接起來的對帳資料。用這份資料逐筆對照，才能確認自己的部位從復原地址走到了哪一步。