隻能買不能賣？一文讀懂「延時貔貅」的實現原理與防範措施

本文將通過簡易概述 ERC 20 和 Uniswap 的原理，講解延時貔貅是如何實現的。

原創| Odaily星球日報

作者| 南枳

代幣貔貅，通常指某個代幣隻能購買而不能出售的情況，而開發者會在一段時間後撤除 LP 獲利，對購買者 Rug Pull。而延時貔貅則是在代幣剛開放交易的短時間內可以交易，而後變成了貔貅狀態。對於此類 Rug Pull 手法，許多合約偵測工具暫未加入對應的偵測功能，正成為惡意開發者的主要獲利手段之一。

下面，Odaily星球日報將透過簡易概述 ERC 20 和Uniswap的原理，講解延遲貔貅是如何實現的。

註：文章中的部分類比，為便於理解，並不完全嚴謹。

ERC 20 基礎

市面上絕大部分代幣遵守 ERC-20 標準，而 ERC-20 是什麼，ChatGPT 答案如下：

ERC-20 是一種以太坊（ Ethereum ）區塊鏈上的代幣標準，它定義了代幣合約必須遵循的一組規則和介面。這個標準規範了代幣的基本功能，包括轉帳、餘額查詢、授權代表他人花費代幣等。

以下是一些主要的 ERC-20 代幣標準規則和功能：

轉帳（Transfer）：ERC-20 代幣可以透過智慧合約的方法進行轉賬，使用戶能夠向其他以太坊地址發送代幣。
餘額查詢（BalanceOf）：用戶可以查詢他們的 ERC-20 代幣餘額，以查看他們擁有的代幣數量。

餘額查詢（BalanceOf）：

實際上，該函數不僅具有「查詢」功能，用戶「擁有」多少代幣也由該函數定義。每個代幣可以理解為一個“銀行”，而每個錢包地址在交易代幣後，從“銀行”獲得了一張“儲蓄卡”，記錄了每個地址的餘額（Balance），用戶即可以向銀行申請查詢自己的餘額狀況，也可以向銀行提出資產變更請求進行交易。

註：以太坊採用了帳本（Account- Based ）模型。

因此，用戶本質上並不「擁有」其資產，而是由一個函數「定義」了你可以去」花費「的代幣數量。

即：X 代幣 Balance Of [A 帳戶]=A 帳戶可以對外花費的 X 代幣數

註：現實世界中的銀行存款是銀行對客戶的債務，銀行具備資產所有權。

轉帳（Transfer）

所有的ERC-20 代幣都要完善transfer 函數，而基於前面的帳本模型，在發生一筆轉帳的時候，也並非A 帳戶向B 帳戶「交付」了一筆代幣，而是從A 帳戶扣款代幣數量X，在B 帳戶增加代幣數量X。

即：Balance Of [A 帳號]-X 同時Balance Of [B 帳號]+X

而開發者可以修改 transfer 函數，對轉帳數量、轉帳人等進行限製。

轉帳函數，是絕大多數貔貅機製的根本源頭。

Uniswap

前一節將每個代幣類比成一個“銀行”，則 Uniswap 在此可以理解為一個承兌的中間人，透過 xy=k 的 AMM 原則兌換兩種代幣。

而兌換的流程如下：

用戶向 Uniswap 合約轉帳代幣 A
Uniswap 將收到的代幣，透過 y=k/x 計算應返還的代幣，並扣除手續費
Uniswap 向 LP 池子轉入代幣 A，並取出代幣 B
Uniswap 向用戶轉帳代幣 B

當然，Uniswap 實際上涉及多個函數和流程，本處需要了解的重點是， Uniswap 僅基於「收到的代幣」進行交易，而在用戶進行「轉帳」操作的時候，數量或已發生了變化。

貔貅機製

本節，將貔貅機製分為兩類：

①高交易稅，導致用戶收不到銷售代幣回款；

②無法轉賬，導致用戶無法與 Uniswap 交易。

高交易稅

本小節展示一個具備交易稅的 Meme 幣計算流程如下圖（僅關注紅色部分）。

計算交易稅（S）
從用戶裡錢包足額扣錢（BalancerOf[用戶] 減少代幣 A）
向開發者錢包或 LP 等地址轉帳（BalancerOf[Dev] 增加代幣 A×稅 S）
向 Uniswap 轉帳部分代幣兌換代幣 B（代幣 A×( 1-S））
用戶收到不足額的代幣B

如前節所述，Uniswap 隻對「收到的代幣」進行處理，而開發者可以任意修改轉帳給 Uniswap 和用戶的數量。

此處，若將交易稅率修改為 100% ，則在第三步驟「③向開發者錢包或 LP 等地址轉帳「實現了貔貅，用戶無法再收到代幣。

無法轉帳

Solidity 中，開發者可以透過 require 對交易進行限製：

若開發者限製兌換代幣的物件僅限某些白名單地址，則用戶無法將手中的代幣向Uniswap 發送，則在第二步「②從用戶錢包扣錢」實現了貔貅，而開發者可以設定Uniswap 的Router可以傳送代幣，結果就為：

用戶隻能購買（Uniswap 向用戶轉帳代幣），但不能出售（因為不能把代幣轉帳到 Uniswap 兌換 ETH 等）。

也或者開發者可以將轉帳上限設定為 0、關閉交易開關等多種路徑操作，但最終都是對「轉帳」這一行為進行控製。

延時貔貅

進一步的延時貔貅則是透過對時間（區塊高度）進行 require 限製來實現貔貅。

例如在某代幣中，其限製如下：

require（block.number < _allowance）

則隨著區塊高度的增加，到了某個閾值時用戶將無法轉賬，實現了貔貅。

此外，還有透過交易次數達到一定閾值實現的貔貅，此類延時貔貅在某些合約安全檢測工具檢查時，若未有針對性設置，初始情況下均能正常交易，誘使用戶進入陷阱。

如何預防

鑑於此類收割手法常見於“沖土狗”，購買者往往追求效率、忽略安全，且我們暫未看到哪家成熟的安全公司針對這一手法推出專項檢測工具，所以Odaily星球日報在此提示，有一定程式碼能力的購買者為了自身資產，還應過一遍合約代碼（或藉ChatGPT 等工具速覽），尤其關注selpair 合約，遠離包含不常見代碼片區的項目。

聯系郵箱：0xniumao@gmail.com