Deflationary Token Development (with Burn)

Deflationary Token Development (with Burn)

Deflationary token is token whose total supply decreases over time. Burning mechanism is embedded in contract itself: part of each transfer automatically goes to zero address (address(0)). Sounds simple, but devil is in details of implementation — especially when token should work with DeFi protocols.

Two burn approaches

1. Fee-on-transfer (automatic burn on transfer)

On each transfer automatically burns X% of amount:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/Ownable2Step.sol";

contract DeflationaryToken is ERC20, Ownable2Step {
    uint256 public burnBps;  // basis points, 100 = 1%
    uint256 public constant MAX_BURN_BPS = 1000;  // 10% maximum
    
    // Addresses excluded from tax (LP pairs, routers)
    mapping(address => bool) public isBurnExempt;
    
    event BurnBpsUpdated(uint256 oldBps, uint256 newBps);
    
    constructor(
        string memory name,
        string memory symbol,
        uint256 initialSupply,
        uint256 _burnBps
    ) ERC20(name, symbol) Ownable2Step() {
        require(_burnBps <= MAX_BURN_BPS, "Burn too high");
        burnBps = _burnBps;
        _mint(msg.sender, initialSupply);
    }
    
    function _transfer(
        address from,
        address to,
        uint256 amount
    ) internal override {
        if (burnBps > 0 && !isBurnExempt[from] && !isBurnExempt[to]) {
            uint256 burnAmount = (amount * burnBps) / 10000;
            uint256 sendAmount = amount - burnAmount;
            
            super._transfer(from, address(0), burnAmount);  // burn
            super._transfer(from, to, sendAmount);          // transfer
        } else {
            super._transfer(from, to, amount);
        }
    }
    
    function setBurnBps(uint256 _burnBps) external onlyOwner {
        require(_burnBps <= MAX_BURN_BPS, "Burn too high");
        emit BurnBpsUpdated(burnBps, _burnBps);
        burnBps = _burnBps;
    }
    
    function setBurnExempt(address account, bool exempt) external onlyOwner {
        isBurnExempt[account] = exempt;
    }
}

Critical problem with fee-on-transfer in DeFi: Uniswap V2 and most AMM don't support fee-on-transfer tokens correctly out of box. Router sends amountIn to pool, but pool receives amountIn - burnAmount. This causes revert with error UniswapV2: INSUFFICIENT_INPUT_AMOUNT or incorrect calculation.

Solution — use Uniswap V2 functions with SupportingFeeOnTransferTokens suffix:

// Call from frontend or contract
IUniswapV2Router02(router).swapExactTokensForTokensSupportingFeeOnTransferTokens(
    amountIn,
    amountOutMin,
    path,
    to,
    deadline
);

But this is responsibility of frontend and integrators — your token should explicitly document it's fee-on-transfer.

2. Manual burn via buyback-and-burn

More predictable mechanism: part of protocol income periodically used to buy token on market and burn it. No DeFi compatibility issues, more transparent economics.

contract BuybackBurnVault is Ownable2Step {
    IERC20 public immutable token;
    IUniswapV2Router02 public immutable router;
    
    uint256 public totalBurned;
    
    event BuybackExecuted(uint256 bnbSpent, uint256 tokensBurned);
    
    constructor(address _token, address _router) Ownable2Step() {
        token = IERC20(_token);
        router = IUniswapV2Router02(_router);
    }
    
    // Receive BNB from protocol
    receive() external payable {}
    
    function executeBuyback(
        uint256 bnbAmount,
        uint256 minTokensOut,
        uint256 deadline
    ) external onlyOwner {
        require(address(this).balance >= bnbAmount, "Insufficient BNB");
        
        address[] memory path = new address[](2);
        path[0] = router.WETH();  // WBNB on BSC
        path[1] = address(token);
        
        uint256[] memory amounts = router.swapExactETHForTokens{value: bnbAmount}(
            minTokensOut,
            path,
            address(this),
            deadline
        );
        
        uint256 tokensBought = amounts[amounts.length - 1];
        
        // Burn bought tokens
        token.transfer(address(0), tokensBought);
        totalBurned += tokensBought;
        
        emit BuybackExecuted(bnbAmount, tokensBought);
    }
}

Deflationary model: important questions

Before choosing mechanism answer several questions that determine architecture:

Burn percentage: 1–2% is aggressive for high-frequency trading. Each swap on Uniswap = buy + sell = 2 transfer + AMM fee. At 1% burn token loses 2% per trade plus 0.3% LP fee. Discourages traders. For utility tokens with infrequent transfers — acceptable.

Fixed vs dynamic burn: dynamic (e.g., higher burn at high volume) creates complex tokenomics, but allows tuning pressure to market conditions.

Burn cap: at sufficiently high burn supply eventually drops to illiquid levels. Reasonable to set minimum threshold: if totalSupply < MIN_SUPPLY, burn disables.

uint256 public constant MIN_SUPPLY = 1_000_000 * 10**18;  // 1M tokens — minimum

function _transfer(address from, address to, uint256 amount) internal override {
    if (burnBps > 0 && !isBurnExempt[from] && !isBurnExempt[to]) {
        uint256 burnAmount = (amount * burnBps) / 10000;
        
        // Don't burn if we'll fall below minimum
        uint256 currentSupply = totalSupply();
        if (currentSupply > MIN_SUPPLY) {
            if (currentSupply - burnAmount < MIN_SUPPLY) {
                burnAmount = currentSupply - MIN_SUPPLY;
            }
            super._transfer(from, address(0), burnAmount);
            super._transfer(from, to, amount - burnAmount);
            return;
        }
    }
    super._transfer(from, to, amount);
}

Monitoring and analytics

Deflationary mechanics meaningless without transparency. Users should see burn dynamics:

// Event for tracking in subgraph
event TokensBurned(address indexed from, address indexed to, uint256 amount, uint256 newTotalSupply);

function _transfer(address from, address to, uint256 amount) internal override {
    // ... burn logic ...
    if (burnAmount > 0) {
        emit TokensBurned(from, address(0), burnAmount, totalSupply());
    }
}

Through The Graph subgraph build dashboard: daily burn rate, cumulative burned, projected supply after N years at current burn rate.

Security

Two specific risks of deflationary tokens:

Re-entrancy via approve: if _transfer has external calls (e.g., auto-swap part of burn to ETH) — classic re-entrancy attack. Solution: ReentrancyGuard + CEI pattern.

Exempt-list manipulation: if owner can add any address to isBurnExempt, attacker with compromised owner-key can disable burn and violate tokenomics promises. Use timelock on exempt-list changes for projects with serious TVL.

// Timelock for critical changes
uint256 public constant BURN_CHANGE_TIMELOCK = 48 hours;
mapping(bytes32 => uint256) public pendingChanges;

function scheduleBurnBpsChange(uint256 newBps) external onlyOwner {
    bytes32 changeId = keccak256(abi.encodePacked("burnBps", newBps));
    pendingChanges[changeId] = block.timestamp + BURN_CHANGE_TIMELOCK;
}

function executeBurnBpsChange(uint256 newBps) external onlyOwner {
    bytes32 changeId = keccak256(abi.encodePacked("burnBps", newBps));
    require(pendingChanges[changeId] != 0, "Not scheduled");
    require(block.timestamp >= pendingChanges[changeId], "Timelock active");
    burnBps = newBps;
    delete pendingChanges[changeId];
}

Timeline and scope

Development (contracts + tests) — 5–8 days. Compatibility testing with Uniswap/PancakeSwap — 1–2 days. Deployment + verification + LP pair setup — 1 day. Subgraph for burn analytics — optional, 2–3 days.