原文标题：《一文读懂「延时貔貅」的实现原理和防范措施》
原文来源：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 币计算流程如下图（仅关注红色部分）。
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 合约，远离包含不常见代码片区的项目。
原文链接
