近期Beosin安全團隊研究發現，通縮代幣引起的安全事件依然頻發，造成眾多項目方資金的損失，因此，Beosin安全團隊準備了這篇詳解通縮代幣的文章，與大家分享。

本文將對通縮代幣與pair結合過程中容易出現的問題以及歷史發生的真實通縮代幣安全事件兩個方面進行介紹，通過本文，我們將徹底搞清楚通縮代幣是什麼意思以及通縮代幣發生安全問題所涉及的原理，使我們在之後的項目中避坑。

1 通縮代幣是哪種類型的幣？

通縮代幣是一種在交易過程中會進行相關比例銷毀的代幣，這是一種很好的激勵用戶持有代幣的方式。

在代幣交易過程中，會扣除部分代幣用於手續費、獎勵以及銷毀，而隨著代幣的銷毀，總供應量便會不斷減少，就能使得用戶持有代幣所佔比例增加，從而使得用戶更願意持有代幣來被動獲取更高的收益。

看似完美的金融方案，但在代碼實現上並不像預想的那麼完美。代碼中存在銷毀過程，此過程將繞過swap過程直接修改地址餘額，這種情況與pair相結合，便會出現一些意想不到的問題。

2 通縮代幣存在哪些問題？

（1）添加流動性問題

通縮代幣在轉賬時會收取一定比例的手續費給當前合約，並在手續費達到某個閾值（當前代幣數量大於等於合約設置的某個變量）時會調用pair合約進行swap、addLiquidity或sync等操作。

如果在通縮代幣交易過程中，沒有排除to地址等於pair合約地址，並且該通縮代幣在pair中為TokenB時，那麼在進行TokenA與TokenB添加流動性的操作中可能導致失敗。

為什麼會出現交易失敗的問題呢？添加流動性是將TokenA與TokenB兩種代幣打入pair合約，然後調用pair合約的mint函數（下方詳情），該函數會根據本合約的當前餘額與儲備量的差值來判斷用戶傳入了多少代幣。

用戶將TokenA的代幣發送至pair後，進行TokenB代幣轉賬，當收取的手續費正好達到上述的閾值時，代幣合約調用pair的swap、mint或sync函數，這幾個函數都會調用pair的_update函數，從而將用戶最開始發送至pair的TokenA更新為reserve。

最後，用戶再調用mint函數，會導致TokenA的balance和reserve是相等的，結果將導致該筆交易失敗。

Mint函數代碼如下：

整個調用過程如下：

過程詳情圖

（2）Skim問題

Pair合約擁有一個skim函數（下方詳情），該函數會將pair合約中超出儲備量的代幣發送到調用者指定地址，數量計算方式是根據pair合約所擁有的代幣數量與儲備量之間的差值來實現的，這本身是一個平衡pair供應量的功能，但遇到其中一個代幣為通縮代幣，便可能出現問題。

通縮代幣在交易過程中會扣取一部分的費用，那麼如果在skim函數中代幣轉賬過程扣取的費用是由from“買單”，會出現什麼問題呢？

此時扣取的費用將會是pair的供應量，這樣就能提前向pair中轉入代幣，通過不斷的skim函數與sync函數消耗掉pair的供應量，使得該種代幣在pair中的價格不斷飆升，最終使用少部分該通縮代幣就能兌換出大量的另一種代幣（一般為usdt、eth等價值幣）。

Skim函數代碼如下：

function skim(address to) external lock {address _token0 = token0; address _token1 = token1; _safeTransfer(_token0,to,IERC20(_token0).balanceOf(address(this)).sub(reserve0)); _safeTransfer(_token1, to, IERC20(_token1).balanceOf(address(this)).sub(reserve1));}

整個調用過程如下：

過程詳情圖

（3）銷毀問題

該問題主要出現在使用“映射”機制的通縮代幣中，這種代幣的機制是存在兩種代幣餘額存儲變量，分別為tOwned和rOwned，而tOwned存儲的是實際代幣數量，rOwned存儲的是通過currentRate變量放大映射之後的值。

rOwned的作用是什麼呢？在文章開始說過，通縮代幣能激勵用戶持有代幣，這種激勵目的使用的方式便是對交易者扣除rOwned值，同時扣除rTotal，這樣其他用戶rOwned所佔rTotal的比例就會被動增加，實現被動收益。 （rOwned與rTotal可理解為用戶的股份以及總股份）

用戶查詢餘額的方式有兩種情況，一種是除外地址，直接返回tOwned的值，另一種是非除外地址，返回rOwned/currentRate，而currentRate計算方式為rTotal/tTotal。如果有辦法使得rTotal減小，那麼用戶查詢出的實際餘額將變大，而如果pair查詢餘額變大，則可以通過skim函數將多餘的代幣轉移出去。

而該類通縮代幣存在一個deliver()函數，非除外地址可調用，該函數會將調用者的rOwned銷毀，並銷毀相同數量的_rTotal，使得所有非除外地址的餘額查詢增加，pair如果非除外的話，便可使用上述方式套利攻擊。

3 通縮代幣相關安全事件剖析

（1）AES安全事件

北京時間2023年1月30日，Beosin旗下Beosin EagleEye安全風險監控、預警與阻斷平台監測到，AES遭受到黑客攻擊，該項目便存在上述的Skim問題。

AES-USDT pair合約有一個skim函數，該函數可以強制平衡pair的供應量，將多餘資金發送給指定地址。

攻擊者在本次攻擊過程中，首先向pair裡面直接轉入了部分AES代幣，導致供應量不平衡，從而攻擊者調用skim函數時，會將多餘的這部分代幣轉到攻擊者指定地址，而攻擊者在此處指定了pair合約為接收地址，使得多餘的AES又發送到了pair合約，導致強制平衡之後pair合約依然處於不平衡狀態，攻擊者便可重複調用強制平衡函數，而AES發送過程會調用到AES合約的transfer函數，如下圖。

另外一點，當調用AES代幣合約的transfer函數時，若發送者為合約設置的pair合約時，會將一部分費用記錄在swapFeeTotal之中（如上圖過程），在最後的時候可以統一調用distributeFee函數（如下圖）將swapFeeTotal記錄的費用從pair中轉出，這里相比上述的過程，攻擊者可以不用做sync函數調用操作，而是在最後將費用轉移出去之後調用一次sync函數即可。

攻擊者經過反复的強制平衡操作，費用記錄變得異常大，基本接近pair的總餘額，最後攻擊者調用distributeFee函數將pair裡面的AES轉出，pair的AES餘額變得非常少，導致攻擊者利用少量AES兌換了大量的USDT。

（2）BevoToken安全事件

北京時間2023年1月30日，Beosin旗下Beosin EagleEye安全風險監控、預警與阻斷平台監測到，BevoToken遭受到閃電貸攻擊，該項目便是上面所說的“映射”機制通縮代幣。

由於BevoToken合約的balanceOf函數（如下圖）並非ERC20標準的函數，該函數在經過一些計算處理後再返回餘額，而轉賬或其他操作可能使前後計算返回的餘額不一致，當攻擊者在swap操作前後可憑藉這個問題來操控pair合約的餘額，從而skim出多餘的代幣。

攻擊者首先在pancake貸出192.5個BNB，之後換成約302,877個BEVO代幣，再調用被攻擊合約的deliver函數（如下圖），此時_rTotal的值減小，_rTotal的值減小會導致_getRate中計算的值偏小，此時balanceOf返回的餘額則會偏大，導致攻擊者能skim出多餘的BEVO。

之後，攻擊者再將skim出的代幣進行deliver，此時_rTotal的值已經很小了，在進行_getRate計算時，會減去除外地址的rOwned（如下圖），此值固定且被攻擊者在之前通過burn異常放大的，在最開始_rTotal正常的時候，減去該值對結果的影響不大，但是現在_rTotal被攻擊者操控得異常小，再減去這個異常放大的固定值後，對結果產生了巨大的影響，第一次deliver導致pair計算結果偏大3倍，而第二次deliver之後，pair計算結果則偏大了數百倍，這也是為什麼攻擊者獲得的代幣要比自己銷毀的代幣多得多的原因。

4 Beosin總結

通縮項目在業務設計的時候一定要考慮到與pair交互的情況，自身的通縮機制是否會對pair產生影響。我們也建議相關項目上線前尋找專業的安全審計機構進行全面的代碼以及業務的安全審計工作。