Розробка системи крипто-чайових: смарт-контракти, інтеграція, аудит

Контент-платформи втрачають до 15% виручки через комісії централізованих сервісів донатів. Патентовані рішення (Patreon, Boosty) стягують 10–20%, а автори не контролюють виведення коштів. Крипто-чайові на смарт-контрактах змінюють правила: прозорість, миттєві транзакції та можливість отримувати до 95% суми напряму. Вибір блокчейна визначає економіку: на Polygon фіксована комісія ~$0.002, на Ethereum — до $15 в години пік, що робить Polygon у 500 разів дешевшим для мікроплатежів. Ми оптимізуємо контракти за рахунок batch-обробки та storage patterns, знижуючи витрати ще на 30%. У середньому клієнти економлять $3,000–10,000 на рік на комісіях.

Які типи токенів підходять для tipping?

Soulbound (non-transferable) токени (ERC-721 з блокуванням _beforeTokenTransfer) — для систем, де важливий статус, а не ліквідність. Transferable ERC-20 points — дають ринкову ціну, але вимагають захисту від купівлі репутації. Tiered NFT (ERC-1155) — різні рівні нагород. Гібрид: soulbound points + claimable reward токен — production-модель, яку використовує Blur, знижує газ за рахунок відстроченого mint.

Архітектура смарт-контракту

Points-токен з обмеженим transfer:

contract TippingPoints is ERC20 {
    address public immutable minter; // тільки авторизований контракт
    mapping(address => bool) public transferWhitelist;

    modifier onlyMinter() {
        require(msg.sender == minter, "Not minter");
        _;
    }

    function _beforeTokenTransfer(
        address from,
        address to,
        uint256 amount
    ) internal override {
        // Дозволяємо: mint (from == 0), burn (to == 0),
        // transfers в whitelist (reward контракт, staking)
        if (from != address(0) && to != address(0)) {
            require(transferWhitelist[to] || transferWhitelist[from], "Non-transferable");
        }
    }

    function mint(address user, uint256 amount) external onlyMinter {
        _mint(user, amount);
    }
}

Whitelist включає адреси reward-контракту та staking-контракту. Користувач не може відправити points напряму іншому адресу — це виключає накрутку через торгівлю.

Reward контракт з дефляційною механікою:

contract TippingRewards {
    TippingPoints public immutable points;
    IERC20 public immutable rewardToken;

    struct RewardTier {
        uint256 pointsRequired;
        uint256 rewardAmount;
        uint256 cooldown;
    }

    mapping(uint256 => RewardTier) public tiers;
    mapping(address => uint256) public lastClaim;

    function claimReward(uint256 tierId) external {
        RewardTier memory tier = tiers[tierId];
        require(points.balanceOf(msg.sender) >= tier.pointsRequired, "Insufficient points");
        require(block.timestamp >= lastClaim[msg.sender] + tier.cooldown, "Cooldown active");
        lastClaim[msg.sender] = block.timestamp;
        points.burnFrom(msg.sender, tier.pointsRequired);
        rewardToken.safeTransfer(msg.sender, tier.rewardAmount);
    }
}

Спалювання points при claim стимулює регулярну активність — без нього rewards безкінечні при стабільному накопиченні. Ми тестували обидві моделі на OpenZeppelin і зупинилися на дефляційній: у тесті з 1000 користувачів кількість points скорочується на 15% за 3 місяці.

Нарахування балів: on-chain vs Merkle claim

On-chain тригери дають повну прозорість, але оновлення правил вимагає upgrade контракту. Off-chain розрахунок з Merkle-claim гнучкіший: правила змінюються раз на тиждень без upgrade, а користувач claim-ить через Merkle-доказ, економлячи газ. Для платформ із частою зміною механік (наприклад, сезонні бонуси) Merkle-claim — стандарт.

Streak і multiplier: зберігання lastActivityDay та currentStreak — при пропуску більше 1 дня streak скидається. Множник збільшує нарахування points до x2, мотивуючи щоденне використання.

Як захистити систему від накрутки?

Ключові заходи:

• Rate limiting: макс. points за транзакцію (наприклад, 1000) і за період (10 000 на годину).
• Activity verification: мінімальний обсяг взаємодії та випадкові інтервали — bot-скрипти з постійною частотою блокуються.
• Sybil resistance: Gitcoin Passport або World ID для відкритих систем; для закритих — whitelist з KYC.

Порівняння методів:

Для більшості контент-платформ оптимальний другий варіант: комбінація off-chain розрахунку з он-чейн claim і зовнішньою верифікацією через Passport.

Що входить у роботу

У результаті ви отримуєте:

• Вихідний код смарт-контрактів з коментарями
• Документацію з розгортання та інтеграції
• Доступ до приватного репозиторію та звітів аудиту
• Навчання команди з використання системи
• Технічну підтримку на 2 місяці після деплою

Етапи впровадження

1. Аналітика — вибір блокчейну, токена, механік (економіка, газ, аудиторія).
2. Смарт-контракти — Points + Reward з можливістю upgrade через proxy-патерни.
3. Off-chain сервіс — TypeScript + The Graph + PostgreSQL для розрахунків і логування.
4. Frontend — wagmi + viem + React (баланс, claim, стейкінг).
5. Аудит і тестнет — Slither, Mythril, Echidna (фаззинг) та формальна верифікація за потреби.
6. Деплой — скрипти, мультисиг, документація.
7. Підтримка — гарантія 2 місяці, моніторинг через Tenderly.

Типові помилки новачків: ігнорування cooldown (без тирів користувачі моментально claim-ять всі points, убиваючи економіку), відсутність whitelist для transfer (points стають ліквідними — накрутка через купівлю в інших користувачів), зберігання всіх даних on-chain (газовий жах при високій активності — використовуйте Merkle-докази).

Терміни розробки

Разом MVP: 4–6 тижнів. Production-система з антифродом, аналітикою та governance — 2–3 місяці. Вартість розраховується індивідуально залежно від складності. Отримайте консультацію — оцінимо ваш проєкт. Наш досвід: 5+ років у блокчейні, 50+ реалізованих проєктів (DeFi, NFT, інфраструктура). Зв'яжіться, щоб отримати готовий tipping модуль за 4 тижні.