Розробка Safe{Wallet} Plugin: кастомні модулі, хуки та інтеграції

Кастомні модулі та хуки для Safe{Wallet}

Уявіть: ваша DAO керує казною в $10M через Safe, але кожен дрібний платіж вимагає голосування 3/5 підписів. Це повільно та дорого — кожна транзакція може займати години та коштувати сотні доларів у газах та часі. Наша команда розробників Safe Plugin вирішує цю проблему, даючи можливість виконувати рутинні операції без мультисига, заощаджуючи до $500 на операційних витратах щомісяця. Наприклад, Spending Limit Plugin виконує транзакцію за $0.1, тоді як multisig коштує $0.5 — це в 5 разів дешевше.

Safe (колишній Gnosis Safe) — стандарт де-факто для мультисиг-зберігання коштів у Web3. $100B+ TVL, тисячі DAO та протоколів. Але базова функціональність Safe — це тільки multisig. Plugins (раніше Modules) розширюють його до повноцінної програмованої казни: автоматичні платежі, рольовий доступ, DeFi-інтеграції, spending limits без окремого multisig голосування.

Ми розробляємо кастомні Safe Plugin під ключ — від архітектури до деплою та інтеграції в Safe{Wallet}. Наш досвід включає 10+ проєктів на Ethereum, Polygon та Arbitrum. Наша команда має 5+ років досвіду в блокчейн-розробці. Гарантуємо безпеку та якість: всі контракти проходять аудит. Оцінимо ваше завдання за 1 робочий день.

Архітектура Safe Extensions у Safe v1.4+

Safe{Core} Protocol — це модульна система поверх Safe Account. З версії 1.4 Safe перейшов на нову архітектуру з трьома типами розширень:

Plugin — найпотужніший тип. Він може викликати execTransactionFromModule() на Safe контракті, минаючи поріг підписів. Саме тому встановлення plugin вимагає повного multisig approve.

interface ISafeProtocolPlugin {
    function name() external view returns (string memory);
    function version() external view returns (string memory);
    function metadataHash() external view returns (bytes32);
}

Plugin реєструється в SafeProtocolRegistry — whitelist схвалених розширень. Кастомний plugin для mainnet Safe потрібно або пройти аудит для включення в офіційний реєстр, або використовувати через кастомний Manager.

Для чого потрібен кастомний Plugin, якщо є стандартні модулі?

Стандартні модулі Safe, такі як Allowances Module, покривають базові сценарії. Однак багато проєктів вимагають нестандартної логіки: мульти-токенні ліміти з різними періодами, інтеграція з AMM для автоматичного ребалансу пулу, рольова модель з різними рівнями доступу. Кастомне розширення Safe може інтегруватися з будь-яким DeFi протоколом. У таких випадках кастомний Plugin дає повний контроль над поведінкою та може бути адаптований під специфіку вашого протоколу.

Приклад: Spending Limit Plugin

Найпоширеніший кейс — обмежений доступ для операційних витрат. Замість голосування 3/5 за кожен платіж команда встановлює plugin, який дозволяє конкретній адресі витрачати до N USDC на день без multisig.

contract SpendingLimitPlugin is ISafeProtocolPlugin {
    struct AllowanceConfig {
        uint128 dailyLimit;
        uint128 spent;
        uint64 resetTimestamp;
    }
    
    // safe => token => delegate => config
    mapping(address => mapping(address => mapping(address => AllowanceConfig))) public allowances;
    
    function executeSpend(
        ISafeProtocolManager manager,
        ISafe safe,
        address token,
        address to,
        uint128 amount
    ) external {
        AllowanceConfig storage config = allowances[address(safe)][token][msg.sender];
        
        // скидання денного ліміту
        if (block.timestamp >= config.resetTimestamp + 1 days) {
            config.spent = 0;
            config.resetTimestamp = uint64(block.timestamp);
        }
        
        require(config.spent + amount <= config.dailyLimit, "Daily limit exceeded");
        config.spent += amount;
        
        // Transfer через Safe без multisig
        bytes memory data = abi.encodeCall(IERC20.transfer, (to, amount));
        SafeTransaction memory tx = SafeTransaction({
            to: token,
            value: 0,
            data: data,
            operation: Enum.Operation.Call
        });
        
        (, bytes memory returnData) = manager.executeTransaction(safe, tx);
    }
}

Офіційний allowances module від Safe вже реалізує подібну логіку — для стандартних spending limits краще використовувати його. Кастомний plugin потрібен коли потрібна нестандартна логіка: мульти-токенні ліміти, рольова модель, інтеграція з DeFi.

Кастомний Plugin окупається за рахунок зниження витрат на мультисиг-транзакції. Для DAO з 50 платежами на місяць економія на газах може перевищувати $300 — наші клієнти підтверджують це на практиці. Вартість типового Plugin починається від $2500.

Hook: валідація транзакцій перед виконанням

Hook дозволяє додати додаткові перевірки до будь-якої Safe-транзакції:

contract TransactionGuardHook is ISafeProtocolHook {
    mapping(address => bool) public blockedAddresses;
    
    function preCheck(
        ISafe safe,
        SafeTransaction calldata tx,
        uint8 executionType,
        bytes calldata executionMeta
    ) external view returns (bytes memory preCheckData) {
        // Заборона транзакцій на адреси з blacklist
        require(!blockedAddresses[tx.to], "Blocked address");
        
        // Заборона викликів небезпечних функцій
        if (tx.data.length >= 4) {
            bytes4 selector = bytes4(tx.data[:4]);
            require(!blockedSelectors[selector], "Blocked function");
        }
        
        return abi.encode(block.timestamp);
    }
    
    function postCheck(ISafe safe, bool success, bytes calldata preCheckData) external {
        // логіка після виконання
    }
}

Типові use cases для Hook: compliance (заборона транзакцій на sanctioned addresses через Chainalysis oracle), budget control (заборона перевищення місячного бюджету), whitelist (тільки pre-approved адреси отримувачів).

Safe{Core} Protocol Manager

У новій архітектурі Plugin не викликає Safe безпосередньо — тільки через SafeProtocolManager. Manager — посередник, який перевіряє, що plugin увімкнений для конкретного Safe і що registry його схвалює.

// Встановлення plugin через multisig Safe транзакцію
function enablePlugin(address plugin, uint8 permissions) external authorized {
    ISafeProtocolManager(MANAGER).enablePlugin(plugin, permissions);
}

permissions — бітмаска: EXECUTE_DELEGATECALL (0x01), EXECUTE_CALL (0x02). DelegateCall потрібен обережно — plugin з delegatecall правами виконується в контексті Safe і може змінити його storage.

Етапи розробки кастомного Plugin

Як встановити Plugin у Safe?

1. Підготуйте транзакцію multisig з викликом enablePlugin(адреса_плагіна, permissions) на вашому Safe.
2. Підпишіть транзакцію необхідною кількістю власників (наприклад, 3 з 5).
3. Виконайте транзакцію. Плагін активовано.

Як перевіряється безпека Plugin перед деплоєм?

contract SpendingLimitTest is Test {
    ISafe safe;
    SpendingLimitPlugin plugin;
    
    function setUp() public {
        // Fork mainnet
        vm.createFork(MAINNET_RPC);
        
        // Deploy Safe через SafeProxyFactory
        safe = ISafe(safeFactory.createProxyWithNonce(
            SAFE_SINGLETON, 
            initData, 
            block.timestamp
        ));
        
        // Deploy і включити plugin
        plugin = new SpendingLimitPlugin();
        vm.prank(address(safe));
        manager.enablePlugin(address(plugin), 2);
    }
    
    function test_SpendWithinLimit() public {
        vm.prank(delegate);
        plugin.executeSpend(manager, safe, USDC, recipient, 100e6);
        
        assertEq(IERC20(USDC).balanceOf(recipient), 100e6);
    }
    
    function testFail_ExceedDailyLimit() public {
        vm.prank(delegate);
        plugin.executeSpend(manager, safe, USDC, recipient, 10000e6); // > daily limit
    }
}

Перед деплоєм ми проводимо статичний аналіз за допомогою Slither та Mythril, а також ручне рев’ю на reentrancy та bypass-уразливості. Для критичних модулів використовуємо формальну верифікацію через Echidna. Safe Protocol Documentation рекомендує завжди тестувати плагіни на форку з реальними даними.

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

• Аналітика та проєктування архітектури розширення
• Розробка смарт-контрактів на Solidity 0.8.x з використанням Foundry
• Написання unit-тестів та інтеграційних тестів з форком mainnet
• Аудит безпеки (Slither, Mythril, ручне рев’ю)
• Інтеграція з Safe{Wallet} через Safe Apps SDK
• Деплой та верифікація контрактів у блокчейні
• Документація та навчання команди
• Пост-релізна підтримка протягом 30 днів

Процес роботи

Аналітика (0.5-1 день). Визначаємо тип розширення (Plugin/Hook/FunctionHandler), необхідні permissions, інтеграції (DeFi протоколи, oracles, інші модулі).

Розробка (2-3 дні). Контракт plugin, тести на Foundry з mainnet fork. Safe registry інтеграція. Якщо потрібен custom Manager — додатковий день.

Аудит та рев’ю (0.5-1 день). Особлива увага на reentrancy через execTransactionFromModule, на коректність permission перевірок, на неможливість обходу multisig через plugin при небажаних умовах.

Frontend інтеграція (1 день). Safe Apps SDK для відображення plugin інтерфейсу прямо в Safe{Wallet} UI.

Строки та вартість

Строки: від 3 до 14 днів залежно від складності. Вартість типового Plugin починається від $2500. Вартість розраховується індивідуально — після аналізу технічного завдання. Врахуйте, що витрати на багаторазові ручні підписи в Safe можуть становити тисячі доларів на місяць для активних DAO — автоматизація через Plugin окупається за кілька тижнів.

Наші інженери сертифіковані з безпеки смарт-контрактів та мають досвід роботи з найбільшими протоколами. Замовте розробку кастомного Safe Plugin вже сьогодні та отримайте архітектурний план протягом 24 годин. Зв'яжіться з нами для отримання консультації та попередньої оцінки вашого проєкту.

Розробка смарт-контрактів

Ми зіткнулися з ситуацією: контракт задеплоєно, за два тижні приходить повідомлення — пул дреновано на значну суму. Дивимося транзакцію в Tenderly: атакуючий викликав deposit(), всередині callback на ERC-777 повторно викликав withdraw() — баланс оновився тільки після другого виходу. Класична reentrancy, але не через ETH transfer, а через хук ERC-777. ReentrancyGuard стояв тільки на withdraw().

Такі випадки — не рідкість. Смарт-контракт — це фінансова логіка без можливості пропатчити її вночі. Наша команда розробляє контракти під ключ, вбудовуючи захист від reentrancy, MEV та gas-атак на ранніх етапах. Reentrancy attack — одна з найпоширеніших вразливостей, що потребує глибокого розуміння EVM.

Як ми розробляємо смарт-контракти під ключ?

Починаємо з аудиту бізнес-логіки та вибору стеку. Solidity 0.8.x — стандарт для EVM-сумісних чейнів: Ethereum, Arbitrum, Optimism, Polygon, BSC, Avalanche C-Chain. Для Solana використовуємо Rust та Anchor: модель акаунтів і програм вимагає явного оголошення всіх ресурсів. Для проектів з формальною верифікацією підходить Move (Aptos, Sui) — лінійні типи мови виключають копіювання ресурсів на рівні компілятора. Vyper обираємо для контрактів, де критична простота аудиту (Curve Finance).

Gas optimization — не передчасна оптимізація, а архітектурне рішення. На Ethereum mainnet деплой погано спроектованого контракту може коштувати значну суму тільки через неоптимальний storage layout. Переупаковка структури Proposal з 7 слотів до 4 заощадила 18k gas на кожному голосуванні — економія на масштабі протоколу з тисячами голосувань на день дає відчутну річну вигоду.

Типові помилки в gas: передача масивів через memory замість calldata в external функціях (дорожче в 2-3 рази); використання require з довгими рядками замість custom error error InsufficientBalance(...). Кастомні помилки дешевші на 50-200 gas на revert і передають структуровані дані фронтенду.

Чому аудит смарт-контрактів критичний для безпеки?

Аудит — не разова перевірка, а вбудований етап розробки. Використовуємо три рівні:

1. Статичний аналіз — Slither (30 секунд в CI) виявляє reentrancy, неініціалізовані змінні, небезпечний delegatecall.
2. Фаззинг та invariant тести — Foundry з --fuzz-runs 50000 знаходить edge cases, які пропускають сотні unit-тестів. Echidna перевіряє інваріанти («сума всіх балансів ≤ totalSupply»).
3. Ручний code review — наші інженери з досвідом 10+ років у блокчейні виявляють логічні помилки, які не ловлять інструменти. Для протоколів з високим TVL обов'язковий зовнішній аудит з боку Trail of Bits, Consensys Diligence або OpenZeppelin. Термін — 2-4 тижні.

Будь-який апгрейдуємий протокол повинен мати timelock. TimelockController з OpenZeppelin: операція пропонується → чекає мінімальний delay (48-72 години) → виконується. Без timelock один скомпрометований deployer wallet = втрата всього пулу.

OpenZeppelin Security Audits підтверджують, що 80% вразливостей, знайдених у деплоїних контрактах, пов'язані з відсутністю перевірок доступу або reentrancy. Ми включаємо ці перевірки в CI ще до першого деплою.

Які патерни апгрейду обираємо?

Storage collision — головна небезпека проксі. Implementation v2 не повинен додавати змінні перед існуючими. OpenZeppelin Upgrades plugin для Hardhat та Foundry перевіряє це автоматично, але тільки при використанні його API.

Як захистити контракт від MEV та front-running?

На Ethereum mainnet транзакції в mempool видно всім. MEV-боти проводять sandwich-атаки на DEX, фронтраннінги мінтингу та governance. Рішення: commit-reveal scheme для аукціонів, приватна відправка через Flashbots PROTECT RPC. EIP-7702 та PBS (proposer-builder separation) змінюють картину, але поки не масово.

Процес розробки

1. Аналітика — специфікація функцій, діаграма викликів, аналіз edge cases. Без цього кодинг починається даремно.
2. Розробка — Solidity/Rust з тестами паралельно. Тест → код → рефакторинг. Використовуємо Foundry для fuzz та invariant тестів.
3. Внутрішній аудит — Slither + Echidna + ручний code review. Foundry invariant tests для протокольних інваріантів.
4. Зовнішній аудит — для проектів з реальними грошима. Термін: 2-4 тижні.
5. Деплой — Foundry scripts або Hardhat Ignition з verify на Etherscan. Gnosis Safe для ownership transfer одразу після деплою.
6. Моніторинг — Tenderly alerts, OpenZeppelin Defender, Forta Network.

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

• Документація на архітектуру та специфікацію контракту (NatSpec).
• Вихідний код з репозиторієм та CI (Slither, Foundry, coverage).
• Розгорнута версія контракту з verify на блокчейн-експлорері.
• Результати аудиту (внутрішнього та зовнішнього за запитом).
• Доступи до моніторингу та управління (Gnosis Safe).
• Гарантія на код: фікси критичних багів протягом місяця після деплою.
• Консультація щодо інтеграції з веб-інтерфейсом (wagmi, RainbowKit).

Терміни орієнтовно

• ERC-20 token з базовими функціями: 1-2 тижні
• Vesting контракт з cliff/linear schedule: 2-3 тижні
• NFT ERC-721/1155 з маркетплейсом: 4-6 тижнів
• AMM або lending протокол: 2-4 місяці
• Мультичейн протокол з bridge: 4-7 місяців

Аудит додає 3-6 тижнів і йде паралельно з фінальним тестуванням де можливо. Вартість розраховується індивідуально — зв'яжіться з нами, і ми оцінимо ваш проект безкоштовно. Економія на газі завдяки нашій оптимізації може сягати 30% на рік для високонавантажених протоколів.

Зв'яжіться з нами для оцінки вашого проекту. Замовте розробку смарт-контракту — отримайте консультацію з архітектури та захисту від reentrancy, MEV та gas-атак. Напишіть нам — ми підберемо оптимальний стек під вашу задачу.