代幣貔貅，通常指某個代幣只能購買而不能出售的情況，而開發者會在一段時間後撤除 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 幣計算流程如下圖（僅關注紅色部分）。

1、計算交易稅（S）

2、從用戶里錢包足額扣錢（BalancerOf[用戶] 減少代幣 A）

3、向開發者錢包或 LP 等地址轉賬（BalancerOf[Dev] 增加代幣 A×稅收 S）

4、向 Uniswap 轉賬部分代幣兌換代幣 B（代幣 A×( 1-S））

5、用戶收到不足額的代幣 B

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

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

無法轉賬

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

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

用戶只能購買（Uniswap 向用戶轉賬代幣），但不能出售（因不能把代幣轉賬給 Uniswap 兌換 ETH 等）。

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

延時貔貅

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

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

 require（block.number _allowance）

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

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

如何預防

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

原文連結