Buyback-and-Distribute System Development

Buyback-and-Distribute System Development

Buyback-and-distribute is mechanism where protocol uses part of income to buy its own token from open market and distribute purchased tokens (or burn them) among stakers or holders. This is alternative to direct dividend distribution in stablecoin and more tax-friendly scheme in some jurisdictions.

GMX implemented version of this mechanics (esGMX rewards + buyback), Curve used as basic precedent. But implementations differ strongly in details, and details determine whether mechanics work economically or just create sell pressure.

Economic Logic

Direct fee distribution in USDC is clear to holders, but doesn't affect token price. Buyback theoretically creates buy pressure. In practice, effect depends on several factors:

• Buyback size relative to daily trading volume: if buyback = 0.1% of daily volume, price impact is minimal
• Execution method: large one-time buyback easily front-run by MEV bots; even TWAP buyback is more effective
• What happens with purchased tokens: burn reduces supply (deflationary effect), distribute to stakers creates staking incentive

Honest answer: buyback-and-distribute is tool to reward committed holders, not mechanism for managing price.

System Architecture

System consists of four components:

FeeCollector — accumulates protocol income (trading fees, interest, protocol fees) in one contract.

BuybackExecutor — receives stablecoin from FeeCollector, executes swap on DEX, returns purchased tokens.

RewardDistributor — receives purchased tokens and distributes them among stakers proportionally to stake.

Staking contract — stores stake information and is source of truth for RewardDistributor.

contract BuybackExecutor {
    ISwapRouter public immutable router;  // Uniswap V3 Router
    IERC20 public immutable revenueToken;  // USDC/WETH
    IERC20 public immutable protocolToken; // protocol token
    address public immutable distributor;

    uint24 public poolFee = 3000; // 0.3% pool
    uint256 public minBuybackInterval = 24 hours;
    uint256 public lastBuybackTime;

    // Maximum slippage: 1% in basis points
    uint256 public maxSlippageBps = 100;

    event BuybackExecuted(uint256 revenueSpent, uint256 tokensBought);

    function executeBuyback(uint256 amountIn) external onlyRole(EXECUTOR_ROLE) {
        require(block.timestamp >= lastBuybackTime + minBuybackInterval, "Too soon");
        require(amountIn <= revenueToken.balanceOf(address(this)), "Insufficient revenue");

        // Get quote via Quoter before execution
        uint256 expectedOut = _getQuote(amountIn);
        uint256 minOut = expectedOut * (10000 - maxSlippageBps) / 10000;

        revenueToken.approve(address(router), amountIn);

        ISwapRouter.ExactInputSingleParams memory params = ISwapRouter.ExactInputSingleParams({
            tokenIn: address(revenueToken),
            tokenOut: address(protocolToken),
            fee: poolFee,
            recipient: distributor,
            deadline: block.timestamp + 15 minutes,
            amountIn: amountIn,
            amountOutMinimum: minOut,
            sqrtPriceLimitX96: 0
        });

        uint256 amountOut = router.exactInputSingle(params);
        lastBuybackTime = block.timestamp;

        emit BuybackExecuted(amountIn, amountOut);
    }
}

TWAP vs Instant Buyback

Instant buyback (entire volume in one transaction) is vulnerable: MEV bot sees transaction in mempool, sandwich-attacks (buy before, sell after). Losses can reach 2-5% of volume.

TWAP buyback splits volume over time:

contract TWAPBuyback {
    uint256 public totalAllocation;    // how much to spend total
    uint256 public spentAmount;        // spent
    uint256 public tranchSize;         // size of one tranche
    uint256 public tranchInterval;     // interval between tranches

    function executeNextTranch() external {
        require(block.timestamp >= lastExecution + tranchInterval, "Too soon");
        require(spentAmount < totalAllocation, "Allocation exhausted");

        uint256 amount = min(tranchSize, totalAllocation - spentAmount);
        spentAmount += amount;
        lastExecution = block.timestamp;

        _swap(amount);
    }
}

For small protocols (buyback < $10K/month) instant buyback via private mempool (Flashbots protect) is sufficient. TWAP needed for amounts comparable to pool depth.

RewardDistributor: Distribution Mechanics

Two main approaches:

Push: contract iterates through all stakers and transfers to each. Simple, but gas-limited with large number of stakers.

Pull (reward-per-token): contract stores accumulated reward-per-token, staker claims reward themselves. Scales to any number of stakers.

contract RewardDistributor {
    uint256 public rewardPerTokenStored;
    uint256 public totalStaked;

    mapping(address => uint256) public userRewardPerTokenPaid;
    mapping(address => uint256) public rewards;
    mapping(address => uint256) public stakes;

    // Called on every stake change or reward update
    modifier updateReward(address account) {
        rewardPerTokenStored = rewardPerToken();
        if (account != address(0)) {
            rewards[account] = earned(account);
            userRewardPerTokenPaid[account] = rewardPerTokenStored;
        }
        _;
    }

    function rewardPerToken() public view returns (uint256) {
        if (totalStaked == 0) return rewardPerTokenStored;
        return rewardPerTokenStored + (pendingRewards * 1e18 / totalStaked);
    }

    function earned(address account) public view returns (uint256) {
        return stakes[account]
            * (rewardPerToken() - userRewardPerTokenPaid[account])
            / 1e18
            + rewards[account];
    }

    // Called by BuybackExecutor when new tokens arrive
    function notifyRewardAmount(uint256 amount) external onlyBuybackExecutor {
        rewardPerTokenStored = rewardPerToken();
        pendingRewards = amount;
    }

    function claimReward() external updateReward(msg.sender) {
        uint256 reward = rewards[msg.sender];
        require(reward > 0, "Nothing to claim");
        rewards[msg.sender] = 0;
        protocolToken.safeTransfer(msg.sender, reward);
    }
}

This is classic Synthetix staking rewards model — battle-tested, used in hundreds of protocols.

Automation: Chainlink Keepers vs Gelato

Buyback can't be left to manual execution — this is centralization and manipulation risk (owner chooses purchase moment). Automation solves this:

Chainlink Automation (former Keepers): on-chain conditions (checkUpkeep) trigger performUpkeep. Decentralized, reliable, has gas limit. Cost: LINK tokens for funded tasks.

Gelato Network: web3 automation with more flexible triggers (time, on-chain condition, off-chain event). Simpler to setup, supports ERC-4337. Cost: 1BALANCE prepaid.

For most protocols, Gelato with time-based trigger is sufficient: check accumulated fees once per 24 hours, if > threshold — execute buyback.

Parameters and Governance

Critical parameters should be managed via governance, not stored with owner:

Changing these via timelock (48-72 hour delay) is mandatory. Otherwise owner can manipulate buyback for own interest.

Process

Analysis (3-5 days). Protocol income sources, volume and frequency, target DEX and token liquidity, desired mechanics (burn vs distribute), governance model.

Development (3-4 weeks). FeeCollector → BuybackExecutor → TWAP logic → RewardDistributor → Staking contract → automation via Gelato/Chainlink.

Testing (1 week). Fork tests on Foundry with real DEX pools, MEV attack simulation.

Audit. Contracts manage protocol treasury. External audit mandatory.

Cost and timeline — after clarifying parameters.