{"content":"Trong bài [CZ tuyên bố Binance bị tấn công]({{\u003c relref \"su-co-vi-nong-binance.md\" \u003e}}), tôi đã nêu diễn biến và các con số của vụ hơn 3 tỷ USD rời ví nóng Binance rạng sáng 30/10/2026. Bài này đi vào một chi tiết kỹ thuật nằm ở giữa vụ việc: hợp đồng thông minh mà kẻ tấn công dùng để quét ví, địa chỉ 0x63e8…6fae.[^hd]\n\nĐiều đáng nói là kịch bản này không hề mới. Ngày 1/6/2025, chưa đầy một tháng sau khi EIP-7702 được kích hoạt trên mạng chính Ethereum cùng bản nâng cấp Pectra, hãng tạo lập thị trường Wintermute đã cảnh báo công khai: phần lớn các ủy quyền EIP-7702 khi đó trỏ về những bản sao của cùng một hợp đồng, được viết để tự động vét sạch ví bị lộ khóa ngay khi có tiền vào. Họ đặt tên cho nó là CrimeEnjoyor.[^wm] Bản thân đặc tả EIP-7702 cũng viết thẳng rằng mã được ủy quyền \"có quyền truy cập không giới hạn vào tài khoản\", và \"không có cách nào an toàn\" để một ví cho phép ký ủy quyền tùy ý.[^eips]\n\nHợp đồng quét ví Binance 14 là phiên bản quy mô lớn của đúng kịch bản đã được cảnh báo: ủy quyền cho một hợp đồng quét, rồi vét toàn bộ ETH và token trong một giao dịch. Cần nói cho công bằng, các cảnh báo ấy nhắm vào một lớp rủi ro chung chứ không dự báo riêng về Binance, và EIP-7702 không tự làm lộ khóa. Như chuyên gia bảo mật Taylor Monahan nhận xét lúc đó, nó chỉ làm việc vét ví rẻ và nhanh hơn cho kẻ đã nắm được khóa.[^wm] Với một ví nóng giữ hàng tỷ USD, \"nhanh hơn\" nghĩa là một khóa bị lộ có thể bị khai thác gần như trọn vẹn chỉ trong một giao dịch.\n\nLý do đáng mổ xẻ nó rất đơn giản. Mọi lời giải thích về vụ việc, dù là lộ khóa, hệ thống ký bị thao túng hay nội gián, cuối cùng đều phải khớp với những gì hợp đồng này làm trên chuỗi. Và trên chuỗi thì không có gì bị xóa.\n\nĐịa chỉ các ví và giao dịch chính lấy từ truy vết của ChainTracer.[^ct] Phần phân tích bytecode, khôi phục chữ ký và đối chiếu nonce dưới đây là do tôi tự kiểm lại từ dữ liệu công khai trên Ethereum. Nhận định trong bài là quan điểm cá nhân.\n\n## Một tệp mã 1.674 byte\n\nHợp đồng quét chỉ có 1.674 byte mã chạy (runtime bytecode), tương đương khoảng một trăm dòng Solidity. Nó không có biến lưu trữ, không có chủ sở hữu thay đổi được, không có cơ chế nâng cấp. Toàn bộ quyền điều khiển nằm trong một hằng số khắc cứng vào mã: địa chỉ ví khởi phát 0x7c86…5ca0. Mọi hàm quan trọng đều kiểm tra người gọi có phải ví này không, nếu không thì dừng với lỗi `NotAuthorized`.\n\n| Hàm | Mã hàm | Việc làm |\n|---|---|---|\n| `sweep(to, tokens[])` | 0x8a179be4 | Duyệt danh sách token, chuyển toàn bộ số dư về địa chỉ `to` |\n| `callExecute(target, to, value, data)` | 0x043ff9d2 | Gọi hàm `execute` của một hợp đồng khác, nhân danh ví đang bị chiếm |\n| `withdrawETH(to, amount)` | 0x4782f779 | Rút một lượng ETH cụ thể |\n| `withdrawToken(token, to, amount)` | 0x01e33667 | Rút một lượng token cụ thể |\n| `authorizedCaller()` | 0x97dc97cb | Trả về địa chỉ duy nhất được phép ra lệnh |\n\nTrên Etherscan, hợp đồng này đang hiển thị mã nguồn \"đã xác minh\". Cần đọc kỹ: phần chú thích đầu tệp ghi rõ đây là mã do một mô hình AI dựng lại từ bytecode, không phải mã gốc của kẻ tấn công.[^src] Tôi không dùng nguyên văn bản dựng lại mà biên dịch lại nó bằng solc 0.8.28 với đúng cấu hình ghi kèm. Kết quả trùng từng byte với mã đang chạy trên chuỗi, chỉ khác đoạn metadata cuối tệp. Vì vậy logic mô tả dưới đây là chắc chắn; tên biến bên trong là phỏng đoán, còn tên hàm khớp với mã hàm 4 byte trên chuỗi.\n\n## Không phải một két sắt, mà là một bộ não thay thế\n\nĐiểm khác thường nhất của hợp đồng này là nó không giữ tiền và không được gọi trực tiếp. Nó được thiết kế để chạy như mã của chính ví nạn nhân, thông qua EIP-7702.[^eip]\n\nVới EIP-7702, chủ một ví thông thường có thể ký một \"phiếu ủy quyền\" nói rằng: từ nay, khi ai đó gọi vào địa chỉ của tôi, hãy chạy mã của hợp đồng X. Sau khi phiếu được đưa lên chuỗi, địa chỉ Binance 14 vẫn là địa chỉ cũ, số dư vẫn nằm đó, nhưng mã chạy tại địa chỉ ấy là mã của hợp đồng quét. Khi ví khởi phát gọi `sweep` vào địa chỉ Binance 14, câu lệnh `balanceOf(address(this))` hỏi số dư của chính Binance 14, và lệnh `transfer` được các hợp đồng token hiểu là Binance 14 tự chuyển tiền đi.\n\n{{\u003c diagram \"hop-dong-quet-vi-nong-binance/co-che\" \"Ví khởi phát không cần khóa của Binance 14 để ra lệnh. Nó chỉ cần một phiếu ủy quyền EIP-7702 do khóa đó ký; sau đó mã của hợp đồng quét chạy tại chính địa chỉ Binance 14 và chỉ nghe lệnh ví khởi phát. Theo dữ liệu on-chain ngày 29–30/10/2026.\" \u003e}}\n\nĐây là lý do tôi gọi hợp đồng này là bộ não thay thế. Kẻ tấn công không cần lấy trộm từng khoản tiền. Họ cần đúng một chữ ký hợp lệ để thay bộ não của ví, sau đó ví tự làm theo lệnh của họ với bất kỳ tài sản nào đang có hoặc sẽ được nạp vào.\n\n### Nếu đặt vào một ngân hàng\n\nVới người quen nghiệp vụ ngân hàng hơn là Solidity, mỗi thành phần của bộ não này đều có một hình ảnh tương đương khá sát. Điểm khác nằm ở cột thứ ba, và chính các điểm khác đó làm nên vụ việc.\n\n| Trên chuỗi | Ở ngân hàng, nó giống | Khác biệt quan trọng |\n|---|---|---|\n| Phiếu ủy quyền EIP-7702 | Giấy ủy quyền toàn quyền định đoạt tài khoản, nộp cho ngân hàng | Không giới hạn phạm vi hay thời hạn, có hiệu lực ngay khi lên chuỗi, không giao dịch viên nào đối chiếu |\n| `authorizedCaller` | Mẫu chữ ký đăng ký: ngân hàng chỉ nhận lệnh có chữ ký này | \"Mẫu chữ ký\" là của kẻ tấn công, khắc cứng vào mã, chủ tài khoản không đổi được |\n| `sweep` | Lệnh quét số dư tự động, như dịch vụ gom tiền cuối ngày về tài khoản tập trung của doanh nghiệp | Quét mọi loại tài sản cùng lúc trong một giao dịch, không có giờ chốt, chạy bất cứ khi nào được gọi |\n| Chừa lại 1 ETH | Số dư tối thiểu để tài khoản tiếp tục hoạt động | Ở đây có thể là để giao dịch thường ngày của sàn không bị lỗi và lộ sự cố sớm |\n| `callExecute` | Dùng quyền của tài khoản mẹ để ra lệnh chi từ tài khoản con trong hệ thống quản lý dòng tiền tập trung | Tài khoản con (Hot Wallet 34) không kiểm tra lại lệnh, chỉ cần lệnh đến từ đúng tài khoản mẹ |\n| `withdrawETH`, `withdrawToken` | Ủy nhiệm chi một khoản tiền cụ thể | Không cần duyệt hạn mức |\n\nGhép lại, vụ việc tương đương một tình huống như sau ở ngân hàng. Ai đó có được chữ ký hợp lệ của giám đốc tài chính một doanh nghiệp. Họ nộp giấy ủy quyền toàn quyền cho một người lạ, kèm yêu cầu cài lệnh quét toàn bộ số dư, mọi loại tiền, về một tài khoản ở nơi khác. Ngân hàng chấp nhận vì chữ ký đúng mẫu. Từ đó, mỗi lần người lạ gọi một cuộc điện thoại, toàn bộ số dư bị chuyển đi, kể cả khoản tiền khách hàng vừa nộp vào lúc trước. Và vì doanh nghiệp này còn dùng tài khoản ấy để điều hành một tài khoản con, người lạ ra lệnh chi luôn từ tài khoản con.\n\nỞ ngân hàng, một giấy ủy quyền như vậy thường phải qua giao dịch viên, đối chiếu và phê duyệt trước khi có hiệu lực, và giao dịch bất thường có thể bị giữ lại hoặc đảo ngược. Trên Ethereum, phiếu ủy quyền có hiệu lực trong một khối 12 giây, và không có ai đứng giữa để từ chối hay hoàn tác.\n\n## Hàm quét được viết để không dừng giữa chừng\n\nPhần lõi của hàm `sweep` rút gọn như sau:\n\n```solidity\nfor (uint256 i = 0; i \u003c tokens.length; i++) {\n    address token = tokens[i];\n    if (token == address(0)) {                 // ETH\n        uint256 bal = address(this).balance;\n        if (bal \u003e 1 ether) to.call{value: bal - 1 ether}(\"\");\n    } else {                                    // token ERC-20\n        uint256 bal = IERC20(token).balanceOf(address(this));\n        if (bal \u003e 0 \u0026\u0026 !token.call(transfer(to, bal))) emit SweepItemFailed(token, 2);\n    }\n}\n```\n\nCó ba lựa chọn thiết kế đáng chú ý.\n\nThứ nhất, danh sách token do người gọi truyền vào, không khắc cứng trong mã. Lần quét đầu tiên lúc 03:24:23 truyền 65 mục: ETH và 64 token ERC-20, trong đó có USDT, RLUSD, UNI, PEPE, LINK, WBTC, SHIB.[^q1] Một hợp đồng, nhiều lần dùng, mỗi lần một danh sách khác.\n\nThứ hai, token nào lỗi thì ghi sự kiện `SweepItemFailed` rồi đi tiếp, không làm hỏng cả giao dịch. Trong lần quét đầu, token Kite chuyển thất bại nhưng 63 token còn lại vẫn đi. Với kẻ tấn công, đây là bảo hiểm: một token có cơ chế chặn chuyển không thể làm hỏng cả mẻ quét trị giá hàng tỷ USD.\n\nThứ ba, ETH luôn được chừa lại đúng 1 ETH. Mã không nói lý do. Tôi cho rằng có hai khả năng: giữ cho ví đủ phí gas để các giao dịch thường ngày của sàn không bị lỗi và gây báo động sớm, hoặc đơn giản là chừa phí cho các thao tác tiếp theo. Đây là suy luận, không phải dữ kiện. Dữ kiện là trong buổi diễn tập, kẻ tấn công đã dùng `withdrawETH` để rút đúng 1 ETH chừa lại này.\n\n## Hàm thứ năm được thêm vào sau cùng\n\nHợp đồng quét không phải phiên bản đầu tiên. Lúc 09:28 sáng 29/10 giờ Việt Nam, gần 18 tiếng trước vụ tấn công, ví khởi phát đã triển khai một hợp đồng khác tại 0x19be…f2bf.[^v1] Tôi biên dịch thử bản dựng lại sau khi bỏ hàm `callExecute` và nhận được bytecode trùng khớp với hợp đồng này. Nghĩa là phiên bản đầu có đủ các hàm quét, rút ETH, rút token, chỉ thiếu đúng một hàm.\n\nHàm được thêm vào trong phiên bản thứ hai, triển khai lúc 22:59 cùng ngày, là `callExecute`. Nó cho phép ví đang bị chiếm gọi hàm `execute` của một hợp đồng khác. Đối chiếu với lịch sử giao dịch, mục đích rất rõ: Hot Wallet 34 là một ví hợp đồng mà Binance 14 vẫn điều khiển hằng ngày bằng chính hàm `execute`, chẳng hạn để chuyển USDC tới các địa chỉ bên ngoài. Chiếm được Binance 14 nghĩa là chiếm luôn quyền ra lệnh cho Hot Wallet 34. Hai lệnh `callExecute` lúc 03:41:23 và 03:59:47 đã rút 780 triệu và 43 triệu USDC theo đúng đường này.[^hw34]\n\nViệc thêm hàm này sau khi đã có bản đầu cho thấy kẻ tấn công đã khảo sát cấu trúc ví của Binance khá kỹ, và điều chỉnh công cụ trong ngày chuẩn bị.\n\n## Một buổi diễn tập trên ví riêng\n\nLịch sử giao dịch của ví khởi phát cho thấy một quy trình kiểm thử bài bản trước giờ tấn công.\n\n{{\u003c diagram \"hop-dong-quet-vi-nong-binance/dien-tap\" \"Từ triển khai thử tới ra tay, kẻ tấn công thử mỗi phiên bản hợp đồng trên ví do chính họ kiểm soát. Giờ Việt Nam, theo lịch sử giao dịch on-chain của ví khởi phát 0x7c86…5ca0.\" \u003e}}\n\nVới phiên bản đầu, họ ủy quyền hai ví thử do chính họ giữ khóa, rồi gọi `sweep` để kiểm tra luồng quét. Với phiên bản thứ hai, họ ủy quyền thêm một ví thử 0x43ae…04bd, quét thử bốn mục ETH, USDT, USDC, DAI, rồi gọi `withdrawETH` rút đúng 1 ETH sang một ví trung gian.[^test] Lúc 01:20 sáng 30/10, ví trung gian này chuyển lại 1,08 ETH cho ví khởi phát. Số ETH đó trở thành phí gas cho giao dịch ủy quyền hai giờ sau.\n\nMột chi tiết nhỏ nhưng nhất quán: mỗi lần ủy quyền thử nghiệm đều kèm hai hoặc ba phiếu ký sẵn cho các nonce liên tiếp, bắt đầu từ 0. Tới lúc nhắm vào Binance 14, con số này là 50.\n\n## Năm mươi chữ ký và một cửa sổ vài phút\n\nPhiếu ủy quyền EIP-7702 chỉ có hiệu lực khi số nonce ghi trong phiếu đúng bằng nonce hiện tại của ví ký. Với một ví cá nhân ít giao dịch, việc này dễ. Với Binance 14, một ví nóng gửi trung bình hơn hai giao dịch mỗi khối, nonce nhảy liên tục và kẻ tấn công không thể biết chắc giao dịch của mình sẽ được xếp vào lúc nào.\n\nLời giải là ký trước cả một dải nonce. Hình dung một xấp séc ký sẵn, mỗi tờ in một số thứ tự, và ngân hàng chỉ nhận tờ mang đúng số kế tiếp của tài khoản: không biết số kế tiếp là bao nhiêu, người ta ký cả xấp. Giao dịch lúc 03:20:59 mang 50 phiếu ủy quyền, cùng trỏ về hợp đồng quét. Tôi khôi phục khóa công khai từ từng chữ ký theo công thức của EIP-7702: cả 50 phiếu đều do khóa của Binance 14 ký, với 50 nonce liên tiếp từ 18.914.775 đến 18.914.824.[^auth]\n\n{{\u003c diagram \"hop-dong-quet-vi-nong-binance/cua-so-nonce\" \"Ngay trước giao dịch ủy quyền trong cùng khối 26.300.753, Binance 14 vừa dùng nonce 18.914.808; giao dịch kế tiếp của sàn ở khối sau mang nonce 18.914.810. Phiếu được áp dụng vì vậy mang nonce 18.914.809, nằm giữa dải 50 nonce đã ký sẵn.\" \u003e}}\n\nĐối chiếu với giao dịch của chính Binance 14 cho thấy phiếu nào đã có hiệu lực. Trong cùng khối 26.300.753, giao dịch thường ngày của sàn với nonce 18.914.808 đứng ngay trước giao dịch ủy quyền. Giao dịch kế tiếp của sàn ở khối sau mang nonce 18.914.810. Vậy phiếu được áp dụng là phiếu nonce 18.914.809, và nonce bị tiêu thụ đúng một bước.[^b14]\n\nChi tiết này mang ý nghĩa lớn hơn vẻ ngoài. Ở nhịp khoảng 20 giao dịch trong 9 khối 12 giây quanh thời điểm đó, dải 50 nonce chỉ tương ứng chừng 4–5 phút hoạt động của Binance 14, từ khoảng 03:18 tới 03:22. Điều đó cho thấy người chuẩn bị đã ước tính đúng nonce của ví quanh thời điểm thực thi. Nó gợi ý, nhưng chưa chứng minh, rằng chữ ký được tạo sát giờ gửi: các phiếu cũng có thể được ký trước cho một dải nonce dự đoán rồi chờ tới lúc thích hợp mới gửi. Thêm nữa, phiếu ủy quyền là một loại thông điệp riêng, được băm với tiền tố 0x05, khác hẳn một giao dịch rút tiền. Một hệ thống ký chỉ chấp nhận giao dịch rút tiền theo khuôn mẫu sẽ không ký nó.\n\nTừ đó, theo tôi, có thể thu hẹp các giả thuyết như sau:\n\n| Giả thuyết | Điều dữ liệu ủng hộ | Điều dữ liệu chưa khớp hoặc chưa trả lời |\n|---|---|---|\n| Khóa riêng của ví nóng bị lộ | Ký được phiếu ủy quyền EIP-7702, một loại thông điệp khác giao dịch rút tiền; Binance 16 cũng tự ký chuyển tiền | Không giải thích vì sao ví nóng được quản lý bằng khóa đơn lẻ có thể bị trích xuất |\n| Hệ thống ký bị thao túng | Ký được cho hai ví trong cùng khung giờ, nhịp nhàng với hoạt động của sàn | Hệ thống phải chịu ký một băm tùy ý, điều mà chính sách ký chặt sẽ chặn |\n| Nội gián | Phù hợp nếu chữ ký được tạo sát giờ gửi | Không có dữ liệu on-chain nào phân biệt được với hai giả thuyết trên |\n\nTôi không gán xác suất cho từng giả thuyết. Dữ liệu trên chuỗi chỉ cho thấy người tạo các chữ ký đã có được 50 phiếu ủy quyền hợp lệ bằng khóa của Binance 14, với dải nonce khớp thời điểm thực thi quanh 03:20 sáng 30/10. Muốn đi xa hơn cần nhật ký nội bộ của sàn.\n\n## Khi kịch bản tự động gặp lệnh phong tỏa\n\nHợp đồng quét chạy đúng thiết kế, nhưng kịch bản điều khiển nó có một lỗ hổng: địa chỉ nhận được truyền vào mỗi lần gọi, và kẻ tấn công không đổi nó kịp thời.\n\nLúc 04:01:35, Tether đưa ví nhận chính 0x5227…2f8c vào danh sách phong tỏa.[^tether] Hợp đồng USDT chỉ chặn ví bị phong tỏa gửi tiền đi, không chặn nhận vào, giống một tài khoản ngân hàng bị phong tỏa theo kiểu chỉ cấm rút: tiền vẫn chảy vào được, nhưng không ra được nữa. Ba phút sau, lần quét thứ hai vẫn chuyển 3,92 triệu USDT tới đúng ví ấy. Lần quét thứ ba lúc 04:44:11 chuyển tiếp 200,4 triệu USDT vừa được nạp vào Binance 14, cũng tới ví ấy.[^q23] Khoảng 204 triệu USDT vì vậy rơi thẳng vào một ví đã bị khóa.\n\nLúc 05:06:23, Tether phong tỏa luôn chính Binance 14.[^tether] Lần quét thứ tư lúc 05:39:35 đã đổi sang một ví nhận mới 0xa97b…8d10 và chuyển 122 loại token, nhưng mục USDT thất bại, được hợp đồng ghi lại bằng sự kiện `SweepItemFailed`.[^q4] Từ 06:36 tới 06:56, ví khởi phát còn gọi `sweep` sáu lần nữa, chỉ với mục ETH, và không lần nào phát sinh lệnh chuyển tài sản.\n\nHai bài học nằm trong đoạn này. Phong tỏa của tổ chức phát hành có tác dụng thật, kể cả với một công cụ tự động. Nhưng nó có tác dụng nhờ kẻ tấn công chậm điều chỉnh, và chỉ với tài sản có chủ thể phát hành. ETH thì không.\n\n## Điều các đơn vị lưu ký nên rút ra\n\nHợp đồng quét không khai thác lỗ hổng nào của Ethereum hay của EIP-7702. Nó chỉ tận dụng đúng chức năng được thiết kế. Vì vậy, phòng thủ phải đặt ở phía người giữ khóa.\n\nThứ nhất, coi phiếu ủy quyền EIP-7702 là loại chữ ký nguy hiểm nhất. Hệ thống ký của ví nóng nên từ chối mặc định mọi thông điệp có tiền tố 0x05, trừ khi hợp đồng đích nằm trong danh sách được phê duyệt trước. Một ví nóng của sàn hầu như không có lý do gì để ủy quyền mã cho bên ngoài.\n\nThứ hai, giám sát giao dịch loại 4 theo thời gian thực. Bất kỳ giao dịch nào chứa phiếu ủy quyền ký bởi ví của mình đều phải kích hoạt cảnh báo mức cao nhất, ngừng nạp tiền vào ví đó và chuẩn bị sẵn quy trình ký phiếu ủy quyền về địa chỉ rỗng để thu hồi. Trong vụ này, từ lúc phiếu ủy quyền lên chuỗi tới lần quét thứ ba là 83 phút, và hệ thống của sàn vẫn nạp thêm hơn 200 triệu USDT vào ví đã bị thay bộ não.\n\nThứ ba, tách ví điều khiển khỏi ví giữ tiền. Hot Wallet 34 mất 823 triệu USDC không phải vì bị tấn công trực tiếp, mà vì nó tin tuyệt đối vào một ví nóng khác. Một ví hợp đồng giữ hàng trăm triệu USD nên có hạn mức theo thời gian hoặc yêu cầu nhiều chữ ký cho các lệnh lớn, thay vì chỉ cần một chủ.\n\nVới thị trường Việt Nam, các yêu cầu này nên được đưa vào chuẩn mực vận hành của tổ chức cung cấp dịch vụ tài sản mã hóa, bên cạnh cấp độ an toàn hệ thống thông tin mà Nghị quyết số 05/2025/NQ-CP đã đặt ra và tôi đã phân tích trong bài trước.\n\nMột tệp mã 1.674 byte không làm nên vụ tấn công. Nó chỉ là bằng chứng rõ nhất rằng, trong một thế giới mà chữ ký là quyền lực, câu hỏi quan trọng nhất của mọi hệ thống lưu ký là: ai có thể ký, và ký những gì.\n\n[^hd]: Hợp đồng [0x63e842b0…9c6fae](https://etherscan.io/address/0x63e842b054bd624a465454d533c33f573e9c6fae#code), triển khai bởi ví khởi phát 0x7c86…5ca0 trong giao dịch [0x97408e75…](https://etherscan.io/tx/0x97408e7562eb2b28efcd24ba01609607b5749bc89448d007fa8b50ecf290329c) lúc 15:59:11 UTC ngày 29/10/2026.\n[^ct]: [Vụ tấn công ví nóng Binance 29/10/2026: truy vết dòng tiền on-chain](https://blockchain.vn/blog/news-4/vu-tan-cong-vi-nong-binance-29-10-2026-truy-vet-dong-tien-on-chain-70), báo cáo của [ChainTracer](https://www.chaintracer.org/vi), chương trình truy vết và phòng chống lừa đảo tài sản số của Hiệp hội Blockchain và Tài sản số Việt Nam, ngày 30/10/2026.\n[^wm]: Zack Abrams, [Wintermute warns Pectra upgrade leaves Ethereum users at risk of automated attacks](https://www.theblock.co/post/356481/wintermute-warns-pectra-upgrade-leaves-ethereum-users-at-risk-of-automated-attacks), The Block, 1/6/2025. Bài dẫn số liệu hơn 80% ủy quyền EIP-7702 trỏ về các bản sao CrimeEnjoyor và nhận định của Taylor Monahan.\n[^eips]: Mục Rationale của [đặc tả EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) (trạng thái Final): \"The code specified by an authorization has unrestricted access to the account\" và \"There is no safe way to provide this interface\".\n[^src]: Mã nguồn hiển thị trên [Etherscan](https://etherscan.io/address/0x63e842b054bd624a465454d533c33f573e9c6fae#code) ghi \"AI-reconstructed source, not the original source code\". Tôi biên dịch lại bằng solc 0.8.28, via-IR, tối ưu 200 lượt, EVM Cancun: 1.674 byte mã chạy trùng khớp, trừ phần metadata.\n[^eip]: Theo [đặc tả EIP-7702](https://eips.ethereum.org/EIPS/eip-7702), mã của tài khoản được ủy quyền là chuỗi 0xef0100 nối với địa chỉ hợp đồng đích; phiếu ủy quyền phải do khóa của tài khoản đó ký.\n[^q1]: Giao dịch [0x53bd38b8…](https://etherscan.io/tx/0x53bd38b816c23e74134786c29a8c18d792777998a3b9326047b583100e88e2f3), khối 26.300.770, 20:24:23 UTC: 63 lệnh chuyển token thành công, 1 sự kiện SweepItemFailed (token Kite), cùng 167.464,25 ETH.\n[^v1]: Giao dịch triển khai phiên bản đầu [0x6b76e874…](https://etherscan.io/tx/0x6b76e8748ba1c6bc81e674c830a0b3603db6bde04ec4bd4a2d3126c1a12706d8) lúc 02:28:59 UTC ngày 29/10/2026, tạo hợp đồng 0x19be…f2bf, chưa xác minh mã nguồn trên Etherscan.\n[^hw34]: Giao dịch [0xdc102dd8…](https://etherscan.io/tx/0xdc102dd89dded5a83f1008906883ffb7c81ff3b7d7965d8c7277d170b5e17481) (780 triệu USDC) và [0x3b9625b3…](https://etherscan.io/tx/0x3b9625b33788daeba68420459ae15bf05c5b3639ccfb8e92067e84b560479ca7) (43 triệu USDC), cùng gọi Hot Wallet 34 (0xee7a…4055). Giao dịch thường ngày của Binance 14 gọi đúng hàm này, ví dụ [0x316a878f…](https://etherscan.io/tx/0x316a878f14b47061e020cd560878a3e2e0847e980ecd58f9c7768c573ace0f95).\n[^test]: Ủy quyền ví thử [0xb2148eb8…](https://etherscan.io/tx/0xb2148eb825cac75efe0ae7fb5c319e6b66df62631738ba252185960e50dc5782), quét thử [0x9c2dbed1…](https://etherscan.io/tx/0x9c2dbed15322072e35e767c0c9b4cd962abf58fe51937e62a7020c742b834f2f), rút 1 ETH [0x2b8eb62a…](https://etherscan.io/tx/0x2b8eb62a32408e96bd7cb6740ede11a054549581534de5d5111289c47355f58f), chuyển lại 1,08 ETH [0x96cae1ec…](https://etherscan.io/tx/0x96cae1ec044b4b3e34c1f2113a7bcd1b0d3257370788f5d8a2b91e9c99c0ebe5).\n[^auth]: Giao dịch [0xad99264d…](https://etherscan.io/tx/0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b), khối 26.300.753. Khôi phục khóa ký từ keccak256(0x05 ‖ rlp([chain_id, địa chỉ, nonce])) cho cả 50 phiếu đều ra 0x28C6…1d60 (Binance 14).\n[^b14]: Giao dịch của Binance 14 với nonce 18.914.808 [0xca63641e…](https://etherscan.io/tx/0xca63641eaeb49779d80ba11ce4fe894d635f2e98c032e9efd5bb4ce304ae56da) cùng khối 26.300.753, và nonce 18.914.810 [0x5cb8ca9e…](https://etherscan.io/tx/0x5cb8ca9e0554167938e40454de5ca0df7057ec57f3b42e2e567aa3912f6d73e3) ở khối 26.300.754.\n[^tether]: Sự kiện AddedBlackList của hợp đồng USDT: ví 0x5227…2f8c trong giao dịch [0x7baba482…](https://etherscan.io/tx/0x7baba482077843514d9c72bac0110ba0916b0814288a72917e2c3bb27a9d8659) lúc 21:01:35 UTC; Binance 14 trong giao dịch [0x312e166c…](https://etherscan.io/tx/0x312e166cb9e602582f426288f755a4b08e1eddb456b7e4bd614adae11080d305) lúc 22:06:23 UTC.\n[^q23]: Lần quét thứ hai [0x31c4c9fe…](https://etherscan.io/tx/0x31c4c9fe287d54fb9d3b79980477a8c793a11f774b98d0a9a92de1dad888a91d) (3.917.639,77 USDT) và thứ ba [0x55ba4dab…](https://etherscan.io/tx/0x55ba4dabc41b468e580751373ad31acdee6f5ba398682df2c93e5a8340870556) (200.397.771,82 USDT), cùng tới ví 0x5227…2f8c.\n[^q4]: Giao dịch [0x4a4aed83…](https://etherscan.io/tx/0x4a4aed833556814c16fe176fc8abc70ce124eadc73da3bcdf42a67ef44f9ad6b) lúc 22:39:35 UTC: 122 lệnh chuyển token tới 0xa97b…8d10 và một sự kiện SweepItemFailed cho USDT.\n","jws":"eyJhbGciOiJFZERTQSIsImtpZCI6ImRpZDp3ZWI6YmxvZy5waGR0cnVuZy5jb20ja2V5LTEifQ.eyJkaWQiOiJkaWQ6d2ViOmJsb2cucGhkdHJ1bmcuY29tIiwia2lkIjoiZGlkOndlYjpibG9nLnBoZHRydW5nLmNvbSNrZXktMSIsInNoYTI1NiI6IjY3NjQ5OGEwYmM1MTI3NjAwMWIwMWExOWM0ZDk3NzdlNDg2NjJkYmQzYzI3NjE2YTU1ZmM0ZWRjNjIzNTNjNjMiLCJzaWduZWRBdCI6IjIwMjYtMTEtMDFUMjM6NTU6MzErMDc6MDAiLCJ0eXBlIjoiYmxvZy1wb3N0LXNpZ25hdHVyZS12MSIsInVybCI6Imh0dHBzOi8vYmxvZy5waGR0cnVuZy5jb20vcG9zdHMvaG9wLWRvbmctcXVldC12aS1ub25nLWJpbmFuY2UvIn0.Old56c2S1XWtJAUkkkK7pTJstdOsO4fLa4HeJojwNMCkVClTLi51kNOn3l_sU9Pky_JBX6h2KCequ7wTi_MYDw","payload":{"did":"did:web:blog.phdtrung.com","kid":"did:web:blog.phdtrung.com#key-1","sha256":"676498a0bc51276001b01a19c4d9777e48662dbd3c27616a55fc4edc62353c63","signedAt":"2026-11-01T23:55:31+07:00","type":"blog-post-signature-v1","url":"https://blog.phdtrung.com/posts/hop-dong-quet-vi-nong-binance/"}}