Avoiding Staking Errors with Transfer-Tax Tokens: The Before-After Pattern
Smart contract development requires a deep understanding of the peculiarities of various token standards and implementations. Transfer-tax tokens present a particular challenge, especially when combined with staking mechanisms, as they can lead to serious accounting errors. This article explains how the "Before-After Pattern" elegantly solves this problem.
What Are Transfer-Tax Tokens?
Transfer-tax tokens are ERC20 tokens with a special feature: every transfer automatically incurs a fee or "tax". This implementation is particularly popular in DeFi projects that aim to:
- Incentivize long-term holding
- Automatically fill liquidity pools
- Burn tokens to create deflation
- Fund development treasuries
Example: With a token that has a 5% transfer tax, when transferring 100 tokens, the recipient only receives 95 tokens. The remaining 5 tokens are redistributed, burned, or otherwise utilized according to the tokenomics.
The Problem: Staking Mechanisms and Transfer Tax
Staking contracts typically follow a simple pattern:
- The user transfers tokens to the staking contract
- The contract updates the user's staking balance based on the transferred amount
- During withdrawal, tokens are returned according to the recorded balance
This is where the problem with transfer-tax tokens arises: the staking contract records the full amount that the user intended to transfer but receives fewer tokens due to the transfer tax.
solidity
function stake(uint256 amount) external {
// Transfer tokens from user to contract
tokenContract.transferFrom(msg.sender, address(this), amount);
// Update the user's staking balance
// PROBLEM: The contract receives less than 'amount' tokens!
userStake[msg.sender] += amount;
}
function stake(uint256 amount) external {
// Transfer tokens from user to contract
tokenContract.transferFrom(msg.sender, address(this), amount);
// Update the user's staking balance
// PROBLEM: The contract receives less than 'amount' tokens!
userStake[msg.sender] += amount;
}
This discrepancy leads to overbooking in the contract. Over time, a growing deficit develops, which can lead to the following problems:
- Users cannot withdraw all their stakes
- "First come, first served" situations where early withdrawers are favored
- Faulty reward calculations
- In the worst case: Complete blocking of the withdrawal mechanism
The Solution: The Before-After Pattern
The most elegant solution to this problem is the "Before-After Pattern", which accurately measures the tokens actually received:
solidity
function stake(uint256 amount) external nonReentrant {
// Store the current token balance of the contract
uint256 balanceBefore = tokenContract.balanceOf(address(this));
// Transfer tokens from user to contract
tokenContract.transferFrom(msg.sender, address(this), amount);
// Calculate the amount actually received (after deducting transfer tax)
uint256 balanceAfter = tokenContract.balanceOf(address(this));
uint256 actualAmount = balanceAfter - balanceBefore;
// Update the staking balance with the amount actually received
userStake[msg.sender] += actualAmount;
emit Staked(msg.sender, actualAmount);
}
function stake(uint256 amount) external nonReentrant {
// Store the current token balance of the contract
uint256 balanceBefore = tokenContract.balanceOf(address(this));
// Transfer tokens from user to contract
tokenContract.transferFrom(msg.sender, address(this), amount);
// Calculate the amount actually received (after deducting transfer tax)
uint256 balanceAfter = tokenContract.balanceOf(address(this));
uint256 actualAmount = balanceAfter - balanceBefore;
// Update the staking balance with the amount actually received
userStake[msg.sender] += actualAmount;
emit Staked(msg.sender, actualAmount);
}
This approach has several advantages:
- Precise accounting: The contract only records tokens that were actually transferred
- Transparency: The user can track the actually staked amount via events
- Robustness: The mechanism works regardless of the amount of transfer tax
- Future-proofing: Even if the transfer tax is dynamic or changes, the solution remains functional
Important: Add Reentrancy Protection
Since the Before-After Pattern breaks the Check-Effects-Interaction (CEI) principle, reentrancy protection is essential:
solidity
// Import ReentrancyGuard from OpenZeppelin
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
contract SecureStaking is ReentrancyGuard {
// Add nonReentrant modifier to all affected functions
function stake(uint256 amount) external nonReentrant {
// Implementation as above
}
function withdraw(uint256 amount) external nonReentrant {
// Implementation with similar safeguards
}
}
// Import ReentrancyGuard from OpenZeppelin
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
contract SecureStaking is ReentrancyGuard {
// Add nonReentrant modifier to all affected functions
function stake(uint256 amount) external nonReentrant {
// Implementation as above
}
function withdraw(uint256 amount) external nonReentrant {
// Implementation with similar safeguards
}
}
The nonReentrant modifier prevents a function from being called recursively before the first execution is completed. This is crucial as a malicious token could intervene between the balance check and the balance update.
Complete Example of a Secure Staking Contract
Here is a complete, secure staking contract that is compatible with transfer-tax tokens:
solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
contract SafeTaxTokenStaking is ReentrancyGuard {
IERC20 public stakingToken;
mapping(address => uint256) public userStake;
event Staked(address indexed user, uint256 actualAmount);
event Withdrawn(address indexed user, uint256 amount);
constructor(address _stakingToken) {
stakingToken = IERC20(_stakingToken);
}
function stake(uint256 amount) external nonReentrant {
require(amount > 0, "Cannot stake zero tokens");
uint256 balanceBefore = stakingToken.balanceOf(address(this));
// Transfer tokens
bool success = stakingToken.transferFrom(msg.sender, address(this), amount);
require(success, "Token transfer failed");
uint256 balanceAfter = stakingToken.balanceOf(address(this));
uint256 actualAmount = balanceAfter - balanceBefore;
userStake[msg.sender] += actualAmount;
emit Staked(msg.sender, actualAmount);
}
function withdraw(uint256 amount) external nonReentrant {
require(amount > 0, "Cannot withdraw zero tokens");
require(userStake[msg.sender] >= amount, "Insufficient staked amount");
userStake[msg.sender] -= amount;
bool success = stakingToken.transfer(msg.sender, amount);
require(success, "Token transfer failed");
emit Withdrawn(msg.sender, amount);
}
function getStakedAmount(address user) external view returns (uint256) {
return userStake[user];
}
}
pragma solidity ^0.8.0;
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
contract SafeTaxTokenStaking is ReentrancyGuard {
IERC20 public stakingToken;
mapping(address => uint256) public userStake;
event Staked(address indexed user, uint256 actualAmount);
event Withdrawn(address indexed user, uint256 amount);
constructor(address _stakingToken) {
stakingToken = IERC20(_stakingToken);
}
function stake(uint256 amount) external nonReentrant {
require(amount > 0, "Cannot stake zero tokens");
uint256 balanceBefore = stakingToken.balanceOf(address(this));
// Transfer tokens
bool success = stakingToken.transferFrom(msg.sender, address(this), amount);
require(success, "Token transfer failed");
uint256 balanceAfter = stakingToken.balanceOf(address(this));
uint256 actualAmount = balanceAfter - balanceBefore;
userStake[msg.sender] += actualAmount;
emit Staked(msg.sender, actualAmount);
}
function withdraw(uint256 amount) external nonReentrant {
require(amount > 0, "Cannot withdraw zero tokens");
require(userStake[msg.sender] >= amount, "Insufficient staked amount");
userStake[msg.sender] -= amount;
bool success = stakingToken.transfer(msg.sender, amount);
require(success, "Token transfer failed");
emit Withdrawn(msg.sender, amount);
}
function getStakedAmount(address user) external view returns (uint256) {
return userStake[user];
}
}
Recommendations for Smart Contract Audits
At BailSec, we have analyzed numerous staking implementations and found that the correct handling of transfer-tax tokens is often overlooked. As part of our comprehensive audit process, we specifically check for:
- Correct implementation of the Before-After Pattern
- Appropriate reentrancy protection measures
- Precise event emissions for transparency
- Edge cases, such as changes to the transfer tax rate
Our proven workflow ensures that these and other potential vulnerabilities are systematically identified before they lead to problems in production.
Conclusion: Robust Smart Contracts Through Thoughtful Implementation
Transfer-tax tokens require special attention when integrated into staking mechanisms. The Before-After Pattern offers an elegant and robust solution for the precise accounting of tokens actually transferred. Combined with reentrancy protection, this approach can effectively prevent potential accounting problems.
For more information on smart contract security and best practices, regularly visit our blog or contact our team of experts for individual consultation
