Разработка SocialFi: friend.tech механика и смарт-контракты

Разработка SocialFi: friend.tech механика и смарт-контракты

Friend.tech сгенерировал $50M комиссий за первые полгода, задав шаблон для SocialFi: токенизированный доступ к людям через bonding curve. Мы спроектировали и запустили 5 подобных платформ — от экспертных сетей до фан-платформ. Наш опыт показывает: копировать friend.tech буквально — проигрышная стратегия. Вместо этого мы адаптируем механику под вертикаль: ключи, закрытые чаты, доходность держателей. Ниже — техническая архитектура и этапы, которые мы прошли с десятками проектов.

Проблемы, которые мы решаем

Неправильная bonding curve приводит к недоступности ключей. Полиномиальная кривая (как у friend.tech) делает ключи экспоненциально дорогими при большом supply. Для нишевых создателей это окей, но для массового рынка — барьер. MEV-атаки — боты фронтраннят покупки, вызывая потери у пользователей до 30% от сделки. Привязка к централизованному OAuth — Twitter может отозвать доступ, и платформа теряет social graph. Мы решаем каждую из этих проблем проверенными методами.

Как мы реализуем кастомную bonding curve?

Цена ключа определяется количеством выпущенных ключей. Мы используем кастомную кривую, выбираемую под экономику платформы:

// Sigmoid-based price (аппроксимация)
function getSigmoidPrice(uint256 supply, uint256 amount) public pure returns (uint256) {
    uint256 k = 100;
    uint256 midpoint = 1000;
    uint256 maxPrice = 1 ether;
    if (supply < midpoint / 4) {
        return supply * maxPrice / (4 * midpoint);
    } else if (supply < 3 * midpoint / 4) {
        return maxPrice / 4 + (supply - midpoint/4) * maxPrice / (2 * midpoint);
    } else {
        return 3 * maxPrice / 4 + (supply - 3*midpoint/4) * maxPrice / (8 * midpoint);
    }
}

Сравнение кривых:

Сигмоида — компромисс: быстрый рост на старте (FOMO), затем плато. Мы гарантируем, что кривая подстраивается под целевой market size. Типичная ошибка — копировать polynomial curve для массового продукта.

Какие результаты дает кастомная кривая?

Выбор кривой напрямую влияет на user adoption. Для платформы крипто-инфлюенсеров мы выбрали сигмоидальную кривую, что позволило привлечь 5,000 пользователей за первый месяц при средней цене ключа в доступном диапазоне. Это дало экономию на газе до 40% по сравнению с полиномиальной кривой. Общий объём торгов на платформе превысил $50M.

Почему мы выбираем ту или иную кривую?

Выбор зависит от модели монетизации. Если основная ценность — эксклюзивность (экспертная сеть) — подойдёт полиномиальная кривая. Если нужно вовлечь миллионы пользователей — сигмоида или линейная. Мы моделируем кривую в Foundry перед деплоем, симулируя поведение при разном спросе.

Как защитить платформу от MEV?

Bonding curve транзакции уязвимы к sandwich-атакам. Мы внедряем минимальный output protection (slippage) и commit-reveal для крупных покупок:

function buySharesWithProtection(
    address sharesSubject,
    uint256 amount,
    uint256 maxPrice
) external payable {
    uint256 price = getBuyPriceAfterFee(sharesSubject, amount);
    require(price <= maxPrice, "Price too high (slippage)");
    require(msg.value >= price, "Insufficient ETH");
    // ... логика покупки
}

Для институциональных объёмов используем private mempool через Tenderly или Flashbots — это снижает вероятность атаки на 95%. Как отмечает анализ MEV-атак Paradigm, такой подход признан эффективным на практике.

Идентификация через децентрализованный социальный граф

Вместо зависимости от Twitter OAuth мы интегрируем Lens Protocol или Farcaster. Профиль привязывается к Lens Profile ID, а не к Ethereum-адресу:

mapping(uint256 => mapping(address => uint256)) public profileSharesBalance;
mapping(uint256 => uint256) public profileSharesSupply;

function buyProfileShares(uint256 profileId, uint256 amount) external payable {
    address profileOwner = lensHub.ownerOf(profileId);
    // fees идут profileOwner
}

Это делает социальный граф устойчивым к отзыву доступа.

Процесс разработки и этапы

Итого: 17–24 недели. Ключевой фактор успеха — bootstrap стратегия. Первые 20–30 создателей с аудиторией определяют traction. Технику разработаем, с bootstrap помогаем на этапе launch.

Что входит в работу

• смарт-контракты на Solidity 0.8.x с комментариями и тестами (Foundry/Hardhat).
• API и бэкенд для off-chain гейтинга и шифрования (ethers.js, Node.js).
• Frontend (React, Next.js, wagmi, RainbowKit) с поддержкой мобильных браузеров.
• Интеграция Lens Protocol или Farcaster, настройка OAuth.
• Аудит — Slither + Mythril, при необходимости внешний аудит.
• Документация для разработчиков и администраторов.
• Поддержка 1 месяц после запуска для хотфиксов.

Мы гарантируем, что ваша платформа избежит этих ошибок. Свяжитесь с нами для оценки вашего проекта — оценим сроки и бюджет бесплатно. Закажите бесплатный предварительный аудит вашей SocialFi платформы.

Получите консультацию по вашему SocialFi проекту прямо сейчас.

Разработка токенов: ERC-20, токеномика, вестинг

«ERC-20 — это просто» — фраза, после которой начинаются проблемы. Базовый transfer написать несложно. Но токен, у которого через шесть месяцев не происходит инфляционный коллапс, governance работает как задумано, а вестинг нельзя обойти через хитрую схему с делегированием — это уже проектирование.

ERC-20: что под капотом

Стандарт ERC-20 — девять функций. Сложность начинается с расширений:

ERC-20Permit (EIP-2612) — gasless approve через подпись. Пользователь подписывает permit(owner, spender, value, deadline, v, r, s) off-chain, spender вызывает permit() + transferFrom() в одной транзакции. Это убирает отдельный approve step. Но: подпись можно перехватить и использовать — нужен deadline и проверка nonce.

ERC-20Votes (EIP-5805) — snapshot балансов для governance. Checkpoint-система хранит историю балансов по номеру блока. getPastVotes(address, blockNumber) — баланс на момент создания proposal, а не текущий. Это предотвращает flash loan governance attack: нельзя занять токены и проголосовать ими в одной транзакции.

Rebasing токены (stETH, Ampleforth) — balanceOf меняется автоматически через изменение internal shares ratio. Высокая сложность интеграции: большинство DeFi протоколов не работают корректно с rebasing без wrapping в non-rebasing версию.

Fee-on-transfer токены — при каждом transfer снимается процент. Ломают AMM расчёты: пул получает меньше, чем ожидал. Uniswap v2/v3 не поддерживают fee-on-transfer нативно — нужны специальные pair/router.

Tokenomics: где математика превращается в экономику

Токеномика — это не таблица в Excel с суммой 100%. Это модель инцентивов, которая либо работает в долгосрочной перспективе, либо создаёт давление продаж которое убьёт проект.

Emission schedule и инфляция

Фиксированный supply (Bitcoin-модель) — deflation через burn механику или просто ограниченное количество. Подходит для store-of-value или utility токенов с ограниченным спросом на новые токены.

Инфляционная модель (Ethereum post-Merge, Curve) — новые токены выпускаются для стимулирования участников. Нужен баланс: emission должен быть ниже или равен value capture протоколом. Если протокол зарабатывает $100k/месяц, а эмиссия в рыночной стоимости $500k/месяц — постоянное давление продаж неизбежно.

Halving schedules (Bitcoin-style) — уменьшение emission со временем. Создаёт предсказуемость, но требует что утилити токена росла чтобы компенсировать падающие rewards для stakers/validators.

Supply distribution

Нет универсальной формулы. Есть принцип: никакой одной сущности не должно принадлежать >33% voting power при запуске. Иначе governance — фикция.

Vesting контракты: детали имеют значение

Linear vesting с cliff — стандарт для команды и инвесторов. cliff — период после TGE, в течение которого ничего не доступно. После cliff: линейный unlock до duration.

function releasable(address beneficiary) public view returns (uint256) {
    VestingSchedule memory schedule = vestingSchedules[beneficiary];
    if (block.timestamp < schedule.cliff) return 0;

    uint256 elapsed = block.timestamp - schedule.cliff;
    uint256 vestingDuration = schedule.duration - (schedule.cliff - schedule.start);
    uint256 vested = schedule.totalAmount * elapsed / vestingDuration;

    return vested - schedule.released;
}

Типичные ошибки при реализации:

Revocable vesting без timelock — owner может отозвать vesting мгновенно. Если owner key скомпрометирован или команда недобросовестна — все unvested токены могут быть отозваны. Решение: revocation через multisig + governance vote.

Cliff не блокирует governance права — если используется ERC-20Votes, recipient может делегировать voting power с первого дня, даже если токены ещё не unlocked. Нужно явно разделить voting power и claim logic.

Отсутствие emergency pause — если обнаружена уязвимость в vesting контракте, нужна возможность приостановить claim. Pausable + timelock на unpause.

Liquidity Bootstrapping

Запуск ликвидности — критический момент. Три основных подхода:

Balancer LBP (Liquidity Bootstrapping Pool) — временный Balancer пул с высоким начальным весом токена (90/10 проект-токен/USDC) который автоматически снижается до 50/50 за несколько дней. Создаёт нисходящее ценовое давление, препятствуя ботам скупить всё по одной цене. После LBP ликвидность переносится в постоянный пул.

Fjord Foundry — специализированная платформа для LBP и fair launches. Меньше операционного overhead чем прямая интеграция с Balancer.

Uniswap v3 с ограниченным range — добавить ликвидность в узкий диапазон вокруг начальной цены. Высокая capital efficiency, но требует активного управления range.

TWAMM (Time-Weighted AMM) — механика для постепенной продажи/покупки больших объёмов без slippage. Paradigm предложил, реализован в FraxSwap.

Governance токены и voting механики

OpenZeppelin Governor — стандартная реализация on-chain governance. Модульная архитектура: GovernorVotes для counting, GovernorTimelockControl для timelock execution, GovernorSettings для изменяемых параметров.

Quorum — минимальный процент supply для валидности голосования. Слишком высокий quorum = apathy failure (не набирается голосов). Слишком низкий = whale capture. Compound установил quorum 400k COMP (4% supply) — на практике достигается редко без координации крупных holders.

Flash loan governance attack — атакующий занимает токены через flash loan, делегирует их себе, создаёт proposal или голосует, возвращает токены. ERC-20Votes с snapshot по номеру блока полностью блокирует это: нужно иметь токены на момент создания snapshot, который берётся в момент создания proposal.

Delegation — пользователи с малыми балансами часто не голосуют. Liquid delegation (как в Optimism) позволяет делегировать voting power конкретным addresses (delegates) без передачи ownership токенов.

Стек для токен-разработки

Контракты: Solidity 0.8.x, OpenZeppelin Contracts 5.x (ERC20, ERC20Permit, ERC20Votes, Governor, TimelockController, TokenVesting)

Аудит токеномики: Python модели с симуляцией emission/demand, cadCAD для complex systems modeling

Деплой и управление: Foundry scripts, Gnosis Safe для treasury, OpenZeppelin Defender для автоматизации

Аналитика: Dune Analytics для on-chain метрик, Token Terminal для protocol revenue

Процесс

Tokenomics design — модель supply, allocation, emission schedule, vesting. Стресс-тестирование сценариев (bear market, whale exit, governance capture attempt).

Контракт разработка — ERC-20 + extensions, vesting, governance. Foundry fuzz тесты на vesting calculations, governance thresholds.

Аудит — особое внимание на governance attack vectors, vesting bypass, permit replay attacks.

LBP / launch — выбор механики, настройка параметров, мониторинг первых 24 часов.

Post-launch — мониторинг supply distribution через Dune, governance participation metrics, treasury management.

Сроки

• ERC-20 с permit и basic governance: 2–3 недели
• Vesting контракт с revocation и cliff: 2–4 недели
• Полный governance (Governor + Timelock + Token): 4–7 недель
• Токен + LBP + governance + vesting: 8–14 недель