每個代幣的傳遞功能

   function deliver(uint256 tAmount) public {
       address sender = _msgSender();
       require(!_isExcluded[sender], "Excluded addresses cannot call this function");
       (uint256 rAmount,,,,,) = _getValues(tAmount);
       _rOwned[sender] = _rOwned[sender].sub(rAmount);
       _rTotal = _rTotal.sub(rAmount);
       _tFeeTotal = _tFeeTotal.add(tAmount);
   }

在今天發布的每個可能的令牌上，應對 Safemoon 反射方法，有一個在程式碼中任何地方都沒有調​​用的傳遞函式，有人知道它的用途嗎？

這是一個瘋狂的猜測，但從我對 safemoon 合約的了解來看，這似乎允許使用者（不排除在費用之外）放棄tAmount代幣作為反射。

編輯：是的，實際上也許有人可以確認，但我幾乎 100% 確定就是這樣

deliver(uint256 tAmount)允許反射地址中的“標準”/非排除地址減少其反射代幣數量，以增加所有其他非排除地址餘額（通過彈性供應比率）。

Deliver中的倒數第二行_rTotal = _rTotal.sub(rAmount);表示“反射總量”減少了與反射令牌中的量相等的量。這增加了用於計算任何使用者餘額的“token/reflected token”比率：

未排除的餘額是基於tokenFromReflection 的反映tokenowned 的數量：

function balanceOf(address account) public view override returns (uint256) {
 if (_isExcluded[account]) return _tOwned[account];
 return tokenFromReflection(_rOwned[account]);
}

這是所擁有的反射代幣數量除以目前比率：

function tokenFromReflection(uint256 rAmount) public view returns(uint256) {
   require(rAmount <= _rTotal, "Amount must be less than total reflections");
   uint256 currentRate =  _getRate();
   return rAmount.div(currentRate);
}

目前費率為（反射代幣總數）/（代幣總數）：

function _getRate() private view returns(uint256) {
   (uint256 rSupply, uint256 tSupply) = _getCurrentSupply();
   return rSupply.div(tSupply);
}

function _getCurrentSupply() private view returns(uint256, uint256) {
   uint256 rSupply = _rTotal;
   uint256 tSupply = _tTotal;      
   for (uint256 i = 0; i < _excluded.length; i++) {
       if (_rOwned[_excluded[i]] > rSupply || _tOwned[_excluded[i]] > tSupply) return (_rTotal, _tTotal);
       rSupply = rSupply.sub(_rOwned[_excluded[i]]);
       tSupply = tSupply.sub(_tOwned[_excluded[i]]);
   }
   if (rSupply < _rTotal.div(_tTotal)) return (_rTotal, _tTotal);
   return (rSupply, tSupply);
}

支付的總費用的增加看起來更像是一種解釋方式，而不影響代幣的其他參數。

引用自：https://ethereum.stackexchange.com/questions/110173