diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md
deleted file mode 100644
index 9b63345..0000000
--- a/docs/ARCHITECTURE.md
+++ /dev/null
@@ -1,269 +0,0 @@
-
-
-# Архитектура проекта DLE
-
-## 🎯 Общий принцип
-
-**Backend** - только для чтения данных из блокчейна
-**Frontend** - для выполнения транзакций через MetaMask
-
----
-
-## 📋 Что у нас есть:
-
-### 1. ✅ **Смарт контракт DLE.sol**
-- Находится в `backend/contracts/DLE.sol`
-- Содержит все функции для управления DLE
-- Деплоится в сеть Sepolia (Chain ID: 11155111)
-
-### 2. ✅ **Backend API (модульная архитектура)**
-- **Порт:** 8000
-- **Принцип:** Разделение по функциональности
-- **Функции только для чтения данных из блокчейна**
-
-### 3. ✅ **Frontend (выполнение транзакций)**
-- Файл: `frontend/src/utils/dle-contract.js`
-- Порт: 5173
-- **Функции для выполнения транзакций через MetaMask**
-
----
-
-## 🔄 Как это работает:
-
-### **Чтение данных:**
-```
-Frontend → Backend API → Blockchain
-```
-
-### **Выполнение транзакций:**
-```
-Frontend → MetaMask → Blockchain
-```
-
----
-
-## 📚 Backend API (модульная архитектура):
-
-### 🏗️ Структура модулей:
-
-```
-backend/routes/
-├── dleCore.js # Основные функции DLE
-├── dleProposals.js # Функции предложений
-├── dleModules.js # Функции модулей
-├── dleTokens.js # Функции токенов
-├── dleAnalytics.js # Аналитика и история
-├── dleMultichain.js # Мультичейн функции
-└── blockchain.js # Устаревший монолитный файл
-```
-
-### 🔧 Модули и их функции:
-
-#### **dleCore.js** - Основные функции DLE:
-- `POST /dle-core/read-dle-info` - информация о DLE
-- `POST /dle-core/get-governance-params` - параметры управления
-- `POST /dle-core/is-active` - проверка активности DLE
-- `POST /dle-core/deactivate-dle` - проверка возможности деактивации
-
-#### **dleProposals.js** - Функции предложений:
-- `POST /dle-proposals/get-proposals` - список предложений
-- `POST /dle-proposals/get-proposal-info` - информация о предложении
-- `POST /dle-proposals/get-proposal-state` - состояние предложения
-- `POST /dle-proposals/get-proposal-votes` - голоса по предложению
-- `POST /dle-proposals/get-proposals-count` - количество предложений
-- `POST /dle-proposals/list-proposals` - список с пагинацией
-- `POST /dle-proposals/get-voting-power-at` - голосующая сила
-- `POST /dle-proposals/get-quorum-at` - требуемый кворум
-
-#### **dleModules.js** - Функции модулей:
-- `POST /dle-modules/is-module-active` - активность модуля
-- `POST /dle-modules/get-module-address` - адрес модуля
-- `POST /dle-modules/get-all-modules` - все модули
-- `POST /dle-modules/create-add-module-proposal` - предложение добавления
-- `POST /dle-modules/create-remove-module-proposal` - предложение удаления
-
-#### **dleTokens.js** - Функции токенов:
-- `POST /dle-tokens/get-token-balance` - баланс токенов
-- `POST /dle-tokens/get-total-supply` - общее предложение
-- `POST /dle-tokens/get-token-holders` - держатели токенов
-
-#### **dleAnalytics.js** - Аналитика и история:
-- `POST /dle-analytics/get-dle-analytics` - аналитика DLE
-- `POST /dle-analytics/get-dle-history` - история событий
-
-#### **dleMultichain.js** - Мультичейн функции:
-- `POST /dle-multichain/get-supported-chains` - поддерживаемые сети
-- `POST /dle-multichain/is-chain-supported` - проверка поддержки сети
-- `POST /dle-multichain/get-supported-chain-count` - количество сетей
-- `POST /dle-multichain/get-supported-chain-id` - ID сети по индексу
-- `POST /dle-multichain/check-chain-connection` - подключение к сети
-- `POST /dle-multichain/check-sync-readiness` - готовность синхронизации
-- `POST /dle-multichain/sync-to-all-chains` - синхронизация
-- `POST /dle-multichain/execute-proposal-by-signatures` - исполнение по подписям
-
-### Что НЕ делает backend:
-- ❌ Не создает предложения
-- ❌ Не голосует
-- ❌ Не исполняет предложения
-- ❌ Не требует приватные ключи
-
----
-
-## 🔐 Frontend (транзакции через MetaMask):
-
-### Основные функции в `dle-contract.js`:
-```javascript
-// Создание предложения
-createProposal(dleAddress, proposalData)
-
-// Голосование
-voteForProposal(dleAddress, proposalId, support)
-
-// Исполнение предложения
-executeProposal(dleAddress, proposalId)
-
-// Подключение к кошельку
-checkWalletConnection()
-```
-
-### Как использовать:
-```javascript
-import { createProposal } from '@/utils/dle-contract.js';
-
-// Создаем предложение через MetaMask
-const result = await createProposal(dleAddress, {
- description: "Новое предложение",
- duration: 86400,
- operation: "0x...",
- governanceChainId: 11155111,
- targetChains: [11155111, 137]
-});
-```
-
----
-
-## 🔄 Frontend сервисы (модульная архитектура):
-
-### 📁 Структура сервисов:
-```
-frontend/src/services/
-├── dleV2Service.js # Основные функции DLE
-├── proposalsService.js # Функции предложений
-├── modulesService.js # Функции модулей
-├── tokensService.js # Функции токенов
-├── analyticsService.js # Аналитические данные
-├── multichainService.js # Мультичейн функциональность
-└── index.js # Индексный файл для импорта
-```
-
-### 🔗 Соответствие backend модулям:
-
-| Backend модуль | Frontend сервис | Описание |
-|----------------|-----------------|----------|
-| `dleCore.js` | `dleV2Service.js` | Основные функции DLE |
-| `dleProposals.js` | `proposalsService.js` | Управление предложениями |
-| `dleModules.js` | `modulesService.js` | Управление модулями |
-| `dleTokens.js` | `tokensService.js` | Работа с токенами |
-| `dleAnalytics.js` | `analyticsService.js` | Аналитика и история |
-| `dleMultichain.js` | `multichainService.js` | Мультичейн функции |
-
----
-
-## 🚀 Пример полного цикла:
-
-### 1. Чтение данных DLE:
-```javascript
-// Frontend → Backend API (новые модульные endpoints)
-const response = await fetch('/api/dle-core/read-dle-info', {
- method: 'POST',
- body: JSON.stringify({ dleAddress: '0x...' })
-});
-const dleInfo = response.data;
-```
-
-### 2. Создание предложения:
-```javascript
-// Frontend → MetaMask → Blockchain
-import { createProposal } from '@/utils/dle-contract.js';
-
-const result = await createProposal(dleAddress, proposalData);
-console.log('Предложение создано:', result.txHash);
-```
-
-### 3. Голосование:
-```javascript
-// Frontend → MetaMask → Blockchain
-import { voteForProposal } from '@/utils/dle-contract.js';
-
-const result = await voteForProposal(dleAddress, proposalId, true);
-console.log('Голосование выполнено:', result.txHash);
-```
-
----
-
-## 🔧 Порты и URL:
-
-- **Frontend:** `http://localhost:5173`
-- **Backend:** `http://localhost:8000`
-- **API через proxy:** `http://localhost:5173/api`
-
----
-
-## ✅ Преимущества модульной архитектуры:
-
-### 🔒 Безопасность:
-- Нет приватных ключей на сервере
-- Транзакции подписываются пользователем через MetaMask
-
-### 🏗️ Модульность:
-- Четкое разделение ответственности
-- Легко поддерживать и тестировать
-- Простое добавление новых функций
-
-### 📈 Масштабируемость:
-- Каждый модуль можно развивать независимо
-- Возможность переиспользования кода
-- Простое развертывание отдельных компонентов
-
-### 🎯 Читаемость:
-- Понятная структура файлов
-- Логическое группирование функций
-- Удобная навигация по коду
-
----
-
-## 🎯 Итог:
-
-### 📊 Статистика рефакторинга:
-
-| Модуль | Endpoints | Строк кода | Описание |
-|--------|-----------|------------|----------|
-| `dleCore.js` | 4 | ~200 | Основные функции DLE |
-| `dleProposals.js` | 10 | ~400 | Управление предложениями |
-| `dleModules.js` | 5 | ~150 | Управление модулями |
-| `dleTokens.js` | 3 | ~100 | Работа с токенами |
-| `dleAnalytics.js` | 2 | ~150 | Аналитика и история |
-| `dleMultichain.js` | 8 | ~300 | Мультичейн функции |
-
-### ✅ Результат:
-
-**Backend** = модульная архитектура для чтения данных из блокчейна
-**Frontend** = модульные сервисы + выполнение транзакций через MetaMask
-
-**Преимущества новой архитектуры:**
-- 🏗️ **Модульность** - четкое разделение ответственности
-- 🔒 **Безопасность** - нет приватных ключей на сервере
-- 📈 **Масштабируемость** - легко добавлять новые функции
-- 🎯 **Читаемость** - понятная структура и навигация
-
-Это современная, безопасная и масштабируемая архитектура! 🚀
diff --git a/docs/DLE_API_ENDPOINTS.md b/docs/DLE_API_ENDPOINTS.md
deleted file mode 100644
index 3d3aa11..0000000
--- a/docs/DLE_API_ENDPOINTS.md
+++ /dev/null
@@ -1,951 +0,0 @@
-
-
-# API Endpoints для обновленного смарт контракта DLE
-
-## Обзор
-
-Данный документ содержит полный список всех API endpoints, созданных для работы с обновленным смарт контрактом DLE (Digital Legal Entity). Все endpoints находятся в файле `backend/routes/blockchain.js` и обеспечивают полное покрытие функциональности смарт контракта.
-
-## Структура ответов
-
-Все API endpoints возвращают ответы в следующем формате:
-
-```javascript
-// Успешный ответ
-{
- "success": true,
- "data": {
- // Данные ответа
- }
-}
-
-// Ошибка
-{
- "success": false,
- "error": "Описание ошибки"
-}
-```
-
----
-
-## 📋 Основные функции DLE
-
-### 1. Чтение данных DLE из блокчейна
-```http
-POST /blockchain/read-dle-info
-```
-
-**Описание:** Получение основной информации о DLE из блокчейна.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "name": "Название DLE",
- "symbol": "DLE",
- "totalSupply": "1000000000000000000000000",
- "quorumPercentage": 51,
- "currentChainId": 11155111,
- "isActive": true
- }
-}
-```
-
-### 2. Получение параметров управления
-```http
-POST /blockchain/get-governance-params
-```
-
-**Описание:** Получение параметров управления DLE.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "quorumPercentage": 51,
- "chainId": 11155111,
- "supportedCount": 3
- }
-}
-```
-
-### 3. Проверка активности DLE
-```http
-POST /blockchain/is-active
-```
-
-**Описание:** Проверка активности DLE контракта.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "isActive": true
- }
-}
-```
-
----
-
-## 🗳️ Управление предложениями
-
-### 4. Получение списка предложений
-```http
-POST /blockchain/get-proposals
-```
-
-**Описание:** Получение списка всех предложений DLE.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "proposals": [
- {
- "id": 1,
- "description": "Описание предложения",
- "state": 1,
- "forVotes": "1000000000000000000000",
- "againstVotes": "0",
- "totalVotes": "1000000000000000000000"
- }
- ]
- }
-}
-```
-
-### 5. Получение информации о предложении
-```http
-POST /blockchain/get-proposal-info
-```
-
-**Описание:** Получение детальной информации о конкретном предложении.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `proposalId` (number) - ID предложения
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "proposalId": 1,
- "description": "Описание предложения",
- "duration": 86400,
- "operation": "0x...",
- "governanceChainId": 11155111,
- "targetChains": [11155111, 137],
- "state": 1,
- "forVotes": "1000000000000000000000",
- "againstVotes": "0",
- "totalVotes": "1000000000000000000000",
- "quorumRequired": "510000000000000000000"
- }
-}
-```
-
-### 6. Получение данных для создания предложения
-```http
-POST /blockchain/create-proposal
-```
-
-**Описание:** Получение данных для создания нового предложения. Фактическое создание выполняется через frontend с MetaMask.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `description` (string) - Описание предложения
-- `duration` (number) - Продолжительность голосования в секундах
-- `operation` (string) - Операция в формате bytes
-- `governanceChainId` (number) - ID сети управления
-- `targetChains` (array) - Массив целевых сетей
-- `userAddress` (string) - Адрес пользователя
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "proposalData": {
- "dleAddress": "0x...",
- "description": "Новое предложение",
- "duration": 86400,
- "operation": "0x...",
- "governanceChainId": 11155111,
- "targetChains": [11155111, 137],
- "userAddress": "0x...",
- "timelockDelay": 0
- },
- "message": "Используйте функцию createProposal из dle-contract.js для создания предложения через MetaMask"
- }
-}
-```
-
-### 7. Голосование за предложение
-```http
-POST /blockchain/vote-proposal
-```
-
-**Описание:** Голосование за предложение.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `proposalId` (number) - ID предложения
-- `support` (boolean) - Поддержка (true/false)
-- `userAddress` (string) - Адрес пользователя
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "transactionHash": "0x..."
- }
-}
-```
-
-### 8. Исполнение предложения
-```http
-POST /blockchain/execute-proposal
-```
-
-**Описание:** Исполнение предложения.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `proposalId` (number) - ID предложения
-- `userAddress` (string) - Адрес пользователя
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "transactionHash": "0x..."
- }
-}
-```
-
-### 9. Отмена предложения
-```http
-POST /blockchain/cancel-proposal
-```
-
-**Описание:** Отмена предложения.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `proposalId` (number) - ID предложения
-- `reason` (string) - Причина отмены
-- `userAddress` (string) - Адрес пользователя
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "transactionHash": "0x..."
- }
-}
-```
-
-### 10. Получение состояния предложения
-```http
-POST /blockchain/get-proposal-state
-```
-
-**Описание:** Получение текущего состояния предложения.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `proposalId` (number) - ID предложения
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "proposalId": 1,
- "state": 1
- }
-}
-```
-
-### 11. Получение голосов по предложению
-```http
-POST /blockchain/get-proposal-votes
-```
-
-**Описание:** Получение статистики голосования по предложению.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `proposalId` (number) - ID предложения
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "proposalId": 1,
- "forVotes": "1000000000000000000000",
- "againstVotes": "0",
- "totalVotes": "1000000000000000000000",
- "quorumRequired": "510000000000000000000"
- }
-}
-```
-
-### 12. Проверка результата предложения
-```http
-POST /blockchain/check-proposal-result
-```
-
-**Описание:** Проверка результата голосования по предложению.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `proposalId` (number) - ID предложения
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "proposalId": 1,
- "passed": true,
- "quorumReached": true
- }
-}
-```
-
-### 13. Получение количества предложений
-```http
-POST /blockchain/get-proposals-count
-```
-
-**Описание:** Получение общего количества предложений.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "count": 5
- }
-}
-```
-
-### 14. Получение списка предложений с пагинацией
-```http
-POST /blockchain/list-proposals
-```
-
-**Описание:** Получение списка предложений с поддержкой пагинации.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `offset` (number) - Смещение
-- `limit` (number) - Лимит
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "proposals": [1, 2, 3],
- "offset": 0,
- "limit": 10
- }
-}
-```
-
----
-
-## 🔧 Управление модулями
-
-### 15. Создание предложения добавления модуля
-```http
-POST /blockchain/create-add-module-proposal
-```
-
-**Описание:** Создание предложения для добавления нового модуля.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `moduleId` (string) - ID модуля
-- `moduleAddress` (string) - Адрес модуля
-- `userAddress` (string) - Адрес пользователя
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "proposalId": 1,
- "transactionHash": "0x..."
- }
-}
-```
-
-### 16. Создание предложения удаления модуля
-```http
-POST /blockchain/create-remove-module-proposal
-```
-
-**Описание:** Создание предложения для удаления модуля.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `moduleId` (string) - ID модуля
-- `userAddress` (string) - Адрес пользователя
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "proposalId": 1,
- "transactionHash": "0x..."
- }
-}
-```
-
-### 17. Проверка активности модуля
-```http
-POST /blockchain/is-module-active
-```
-
-**Описание:** Проверка активности модуля.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `moduleId` (string) - ID модуля
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "moduleId": "0x...",
- "isActive": true
- }
-}
-```
-
-### 18. Получение адреса модуля
-```http
-POST /blockchain/get-module-address
-```
-
-**Описание:** Получение адреса модуля по его ID.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `moduleId` (string) - ID модуля
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "moduleId": "0x...",
- "moduleAddress": "0x..."
- }
-}
-```
-
----
-
-## 🌐 Мульти-чейн функциональность
-
-### 19. Получение поддерживаемых сетей
-```http
-POST /blockchain/get-supported-chains
-```
-
-**Описание:** Получение списка поддерживаемых сетей.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "supportedChains": [11155111, 137, 1]
- }
-}
-```
-
-### 20. Проверка поддержки сети
-```http
-POST /blockchain/is-chain-supported
-```
-
-**Описание:** Проверка поддержки конкретной сети.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `chainId` (number) - ID сети
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "chainId": 11155111,
- "isSupported": true
- }
-}
-```
-
-### 21. Получение текущей сети
-```http
-POST /blockchain/get-current-chain-id
-```
-
-**Описание:** Получение ID текущей сети.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "currentChainId": 11155111
- }
-}
-```
-
-### 22. Исполнение предложения по подписям
-```http
-POST /blockchain/execute-proposal-by-signatures
-```
-
-**Описание:** Исполнение предложения с использованием подписей.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `proposalId` (number) - ID предложения
-- `signers` (array) - Массив адресов подписантов
-- `signatures` (array) - Массив подписей
-- `userAddress` (string) - Адрес пользователя
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "transactionHash": "0x..."
- }
-}
-```
-
-### 23. Проверка подключения к сети
-```http
-POST /blockchain/check-chain-connection
-```
-
-**Описание:** Проверка доступности подключения к сети.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `chainId` (number) - ID сети
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "chainId": 11155111,
- "isAvailable": true
- }
-}
-```
-
-### 24. Синхронизация во все сети
-```http
-POST /blockchain/sync-to-all-chains
-```
-
-**Описание:** Синхронизация предложения во все поддерживаемые сети.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `proposalId` (number) - ID предложения
-- `userAddress` (string) - Адрес пользователя
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "transactionHash": "0x..."
- }
-}
-```
-
-### 25. Получение количества поддерживаемых сетей
-```http
-POST /blockchain/get-supported-chain-count
-```
-
-**Описание:** Получение количества поддерживаемых сетей.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "count": 3
- }
-}
-```
-
-### 26. Получение ID поддерживаемой сети по индексу
-```http
-POST /blockchain/get-supported-chain-id
-```
-
-**Описание:** Получение ID поддерживаемой сети по индексу.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `index` (number) - Индекс сети
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "index": 0,
- "chainId": 11155111
- }
-}
-```
-
----
-
-## 📊 Аналитика и пагинация
-
-### 27. Получение голосующей силы на момент времени
-```http
-POST /blockchain/get-voting-power-at
-```
-
-**Описание:** Получение голосующей силы пользователя на определенный момент времени.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `voter` (string) - Адрес голосующего
-- `timepoint` (number) - Момент времени
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "voter": "0x...",
- "timepoint": 1234567890,
- "votingPower": "1000000000000000000000"
- }
-}
-```
-
-### 28. Получение требуемого кворума на момент времени
-```http
-POST /blockchain/get-quorum-at
-```
-
-**Описание:** Получение требуемого кворума на определенный момент времени.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `timepoint` (number) - Момент времени
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "timepoint": 1234567890,
- "quorum": "510000000000000000000"
- }
-}
-```
-
----
-
-## 🪙 Токены и балансы
-
-### 29. Получение баланса токенов
-```http
-POST /blockchain/get-token-balance
-```
-
-**Описание:** Получение баланса токенов пользователя.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-- `account` (string) - Адрес аккаунта
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "account": "0x...",
- "balance": "1000.0"
- }
-}
-```
-
-### 30. Получение общего предложения токенов
-```http
-POST /blockchain/get-total-supply
-```
-
-**Описание:** Получение общего предложения токенов DLE.
-
-**Параметры:**
-- `dleAddress` (string) - Адрес DLE контракта
-
-**Ответ:**
-```javascript
-{
- "success": true,
- "data": {
- "totalSupply": "1000000.0"
- }
-}
-```
-
----
-
-## 🔗 Frontend сервисы
-
-Для работы с API endpoints созданы следующие сервисы в frontend:
-
-### 1. dleV2Service.js
-Основной сервис для работы с DLE, содержащий все функции для взаимодействия с API.
-
-### 2. tokens.js
-Сервис для работы с токенами и балансами.
-
-### 3. proposalsService.js
-Сервис для работы с предложениями и голосованием.
-
-### 4. modulesService.js
-Сервис для работы с модулями DLE.
-
-### 5. analyticsService.js
-Сервис для работы с аналитикой и статистикой.
-
-### 6. multichainService.js
-Сервис для работы с мульти-чейн функциональностью.
-
-## 🔐 Выполнение транзакций через MetaMask
-
-Для выполнения транзакций (создание предложений, голосование, исполнение) используется файл `frontend/src/utils/dle-contract.js` с функциями:
-
-### Основные функции для транзакций:
-
-```javascript
-// Создание предложения
-import { createProposal } from '@/utils/dle-contract.js';
-const result = await createProposal(dleAddress, proposalData);
-
-// Голосование за предложение
-import { voteForProposal } from '@/utils/dle-contract.js';
-const result = await voteForProposal(dleAddress, proposalId, support);
-
-// Исполнение предложения
-import { executeProposal } from '@/utils/dle-contract.js';
-const result = await executeProposal(dleAddress, proposalId);
-
-// Проверка подключения к кошельку
-import { checkWalletConnection } from '@/utils/dle-contract.js';
-const walletInfo = await checkWalletConnection();
-```
-
-### Пример использования:
-
-```javascript
-// 1. Получаем данные для создания предложения от backend
-const response = await fetch('/api/blockchain/create-proposal', {
- method: 'POST',
- headers: { 'Content-Type': 'application/json' },
- body: JSON.stringify({
- dleAddress: '0x...',
- description: 'Новое предложение',
- duration: 86400,
- operation: '0x...',
- governanceChainId: 11155111,
- targetChains: [11155111, 137],
- userAddress: '0x...'
- })
-});
-
-const { proposalData } = response.data;
-
-// 2. Создаем предложение через MetaMask
-import { createProposal } from '@/utils/dle-contract.js';
-const result = await createProposal(proposalData.dleAddress, proposalData);
-console.log('Предложение создано:', result.txHash);
-```
-
-**Важно:** Все транзакции выполняются через MetaMask или другой Web3 кошелек для обеспечения безопасности пользователей.
-
----
-
-## 📋 Состояния предложений
-
-Справочник состояний предложений:
-
-- `0` - Pending (Ожидает)
-- `1` - Active (Активно)
-- `2` - Canceled (Отменено)
-- `3` - Defeated (Отклонено)
-- `4` - Succeeded (Успешно)
-- `5` - Queued (В очереди)
-- `6` - Expired (Истекло)
-- `7` - Executed (Исполнено)
-
----
-
-## 🚀 Использование
-
-Все API endpoints используют:
-- **Сеть:** Sepolia (Chain ID: 11155111)
-- **Формат:** JSON
-- **Метод:** POST
-- **Базовый URL:** `http://localhost:8000` (backend) или `/api` (через frontend proxy)
-
-### Пример использования:
-
-```javascript
-// Создание предложения (через frontend proxy)
-const response = await fetch('/api/blockchain/create-proposal', {
- method: 'POST',
- headers: {
- 'Content-Type': 'application/json'
- },
- body: JSON.stringify({
- dleAddress: '0x...',
- description: 'Новое предложение',
- duration: 86400,
- operation: '0x...',
- governanceChainId: 11155111,
- targetChains: [11155111, 137],
- userAddress: '0x...'
- })
-});
-
-const result = await response.json();
-
-// Или напрямую к backend
-const response = await fetch('http://localhost:8000/blockchain/create-proposal', {
- method: 'POST',
- headers: {
- 'Content-Type': 'application/json'
- },
- body: JSON.stringify({
- dleAddress: '0x...',
- description: 'Новое предложение',
- duration: 86400,
- operation: '0x...',
- governanceChainId: 11155111,
- targetChains: [11155111, 137],
- userAddress: '0x...'
- })
-});
-
-const result = await response.json();
-```
-
----
-
-## ✅ Покрытие функций смарт контракта
-
-Все функции смарт контракта `DLE.sol` имеют соответствующие API endpoints:
-
-| Функция смарт контракта | API Endpoint | Статус |
-|-------------------------|--------------|--------|
-| `getDLEInfo()` | `read-dle-info` | ✅ |
-| `getGovernanceParams()` | `get-governance-params` | ✅ |
-| `isActive()` | `is-active` | ✅ |
-| `createProposal()` | `create-proposal` | ✅ |
-| `vote()` | `vote-proposal` | ✅ |
-| `executeProposal()` | `execute-proposal` | ✅ |
-| `cancelProposal()` | `cancel-proposal` | ✅ |
-| `getProposalSummary()` | `get-proposal-info` | ✅ |
-| `getProposalState()` | `get-proposal-state` | ✅ |
-| `getProposalVotes()` | `get-proposal-votes` | ✅ |
-| `checkProposalResult()` | `check-proposal-result` | ✅ |
-| `getProposalsCount()` | `get-proposals-count` | ✅ |
-| `listProposals()` | `list-proposals` | ✅ |
-| `getVotingPowerAt()` | `get-voting-power-at` | ✅ |
-| `getQuorumAt()` | `get-quorum-at` | ✅ |
-| `createAddModuleProposal()` | `create-add-module-proposal` | ✅ |
-| `createRemoveModuleProposal()` | `create-remove-module-proposal` | ✅ |
-| `isModuleActive()` | `is-module-active` | ✅ |
-| `getModuleAddress()` | `get-module-address` | ✅ |
-| `listSupportedChains()` | `get-supported-chains` | ✅ |
-| `isChainSupported()` | `is-chain-supported` | ✅ |
-| `getCurrentChainId()` | `get-current-chain-id` | ✅ |
-| `executeProposalBySignatures()` | `execute-proposal-by-signatures` | ✅ |
-| `checkChainConnection()` | `check-chain-connection` | ✅ |
-| `syncToAllChains()` | `sync-to-all-chains` | ✅ |
-| `getSupportedChainCount()` | `get-supported-chain-count` | ✅ |
-| `getSupportedChainId()` | `get-supported-chain-id` | ✅ |
-| `balanceOf()` | `get-token-balance` | ✅ |
-| `totalSupply()` | `get-total-supply` | ✅ |
-
----
-
-## 🎯 Итог
-
-**Полное покрытие функциональности смарт контракта DLE достигнуто!**
-
-- ✅ **30 API endpoints** создано
-- ✅ **6 frontend сервисов** создано
-- ✅ **100% покрытие** функций смарт контракта
-- ✅ **Готово к использованию** в интерфейсе управления
-
-Система полностью готова для работы с обновленным функционалом смарт контракта DLE! 🚀
diff --git a/docs/DLE_CONSOLIDATED_ANALYSIS.md b/docs/DLE_CONSOLIDATED_ANALYSIS.md
deleted file mode 100644
index c3e7fdd..0000000
--- a/docs/DLE_CONSOLIDATED_ANALYSIS.md
+++ /dev/null
@@ -1,964 +0,0 @@
-
-
-# DLE v2 — краткие обновления
-
-- Single‑Chain Governance: голосование фиксируется в одной сети, исполнение в целевых сетях по EIP‑712 подписям без внешних мостов.
-- Снапшоты голосующей силы: `ERC20Votes` (`getPastVotes`, `getPastTotalSupply`) исключают перелив голосов.
-- Делегирование «только на себя»: 1 токен = 1 голос, запрет делегирования третьим лицам.
-- Модульность: казна, таймлок, деактивация, коммуникации выделены в отдельные модули, операции выполняются через ядро DLE.
-- «100% или ничего»: много-сетевые операции исполняются только при готовности всех целевых сетей.
-- Детерминированный деплой: CREATE с выровненным nonce для одинаковых адресов во всех выбранных сетях.
-- Аналитика: добавлены view‑функции для сводок, пагинации и агрегирования по предложениям.
-
----
-
-# DLE - Единый Смарт-Контракт с Модульной Архитектурой
-
-## 🎯 ПОЛНОЕ ПОНИМАНИЕ ЗАДАЧИ DLE
-
-### **1. ОСНОВНАЯ КОНЦЕПЦИЯ:**
-```
-DLE (Digital Legal Entity) = Универсальная цифровая юридическая организация
-├── Один смарт-контракт с одинаковым адресом во всех цепочках
-├── Управление только через токен-холдеров (никаких админских ролей)
-├── Модульная архитектура (основной контракт + добавляемые модули)
-└── Мульти-чейн синхронизация (работа в нескольких блокчейнах одновременно)
-```
-
-### **2. АРХИТЕКТУРА СИСТЕМЫ:**
-
-#### **Деплой в множественных цепочках:**
-```
-Пользователь выбирает цепочки (например, 4):
-├── Ethereum (ChainId = 1)
-├── Polygon (ChainId = 137)
-├── BSC (ChainId = 56)
-└── Arbitrum (ChainId = 42161)
-
-Деплой в каждой цепочке:
-├── Одинаковый адрес DLE (через CREATE2)
-├── Одинаковые токены для партнеров
-└── Синхронизированное состояние
-```
-
-#### **Распределение токенов:**
-```
-3 партнера получают по 1000 токенов в каждой из 4 цепочек:
-├── Партнер A: 1000 токенов (в 4 цепочках)
-├── Партнер B: 1000 токенов (в 4 цепочках)
-└── Партнер C: 1000 токенов (в 4 цепочках)
-
-Итого: 3000 токенов в каждой цепочке
-```
-
-### **3. СИСТЕМА УПРАВЛЕНИЯ:**
-
-#### **Голосование токен‑холдеров:**
-```
-- Только токен-холдеры участвуют в управлении
-- Каждый токен = одна голосующая сила
-- Кворум настраиваемый (например, 60% от общего количества токенов)
-- Коллективное голосование токен‑холдеров (ERC20Votes снапшоты)
-```
-
-#### **Создание предложений:**
-```
-1. Токен-холдер создает предложение
-2. Выбирает ОДНУ цепочку для сбора подписей/голосов
-3. Сбор происходит только в выбранной цепочке
-4. При достижении кворума - исполнение
-5. Синхронизация исполнения во все остальные цепочки
-```
-
-### **4. МУЛЬТИ-ЧЕЙН СИНХРОНИЗАЦИЯ:**
-
-#### **Передача токенов:**
-```
-Партнер A передает 500 токенов Партнеру B:
-├── Ethereum: A → B (500 токенов)
-├── Polygon: A → B (500 токенов)
-├── BSC: A → B (500 токенов)
-└── Arbitrum: A → B (500 токенов)
-
-Синхронизация происходит во всех цепочках одновременно
-```
-
-#### **Создание и исполнение предложений:**
-```
-Пример: "Передать 100 токенов от A к C"
-1. Создание в Ethereum
-2. Выбор Polygon для кворума
-3. Сбор подписей в Polygon
-4. Кворум: 60% от 3000 = 1800 токенов
-5. При достижении кворума:
- ├── Исполнение в Polygon: A → C (100 токенов)
- ├── Синхронизация в Ethereum: A → C (100 токенов)
- ├── Синхронизация в BSC: A → C (100 токенов)
- └── Синхронизация в Arbitrum: A → C (100 токенов)
-```
-
-### **5. МОДУЛЬНАЯ АРХИТЕКТУРА:**
-
-#### **Основной контракт DLE.sol:**
-```
-- ERC-20 токены
-- Система голосования
-- Мультичейн синхронизация
-- Управление модулями
-- DLEInfo (юридическая информация)
-```
-
-#### **Модули (отдельные контракты):**
-```
-- TreasuryModule.sol (казначейство)
-- HierarchicalVotingModule.sol (иерархическое голосование)
-- CommunicationModule.sol (коммуникации)
-- CustomModule.sol (пользовательские модули)
-```
-
-### **6. ПРИМЕРЫ ИСПОЛЬЗОВАНИЯ:**
-
-#### **Передача токенов:**
-```
-1. Создание предложения: "A → C (100 токенов)"
-2. Выбор цепочки для кворума: Polygon
-3. Сбор подписей в Polygon
-4. При кворуме: исполнение + синхронизация во все цепочки
-```
-
-#### **Удаление таблицы в приложении:**
-```
-1. Создание предложения: "Удалить таблицу пользователей"
-2. Выбор цепочки: Ethereum
-3. Сбор подписей в Ethereum
-4. При кворуме: информация добавляется в блокчейн
-5. Синхронизация во все цепочки
-6. Результат: таблица удаляется из приложения
-```
-
-### **7. КЛЮЧЕВЫЕ ПРИНЦИПЫ:**
-
-#### **Безопасность:**
-```
-- Только токен-холдеры управляют
-- Проверка баланса при каждой операции
-- Кворум голосов - все решения через коллективное голосование
-- Синхронизация между цепочками
-```
-
-#### **Масштабируемость:**
-```
-- Модульная архитектура
-- Добавление новых функций через модули
-- Поддержка новых цепочек
-- Иерархическое голосование
-```
-
-#### **Универсальность:**
-```
-- Один адрес во всех цепочках
-- Любая цепочка для создания предложений
-- Единый интерфейс управления
-- Совместимость с существующими стандартами
-```
-
----
-
-## 🎯 ОСНОВНАЯ КОНЦЕПЦИЯ
-
-### Один смарт-контракт с модулями
-```
-DLE.sol (Основной контракт) + Модули (добавляемые через голосование)
-```
-
-### Ключевые принципы:
-1. **Один основной контракт** - управление токенами, голосованием, мультиподписью
-2. **Модули** - специализированные функции (казначейство, иерархическое голосование, коммуникации)
-3. **Только токен-холдеры** - никаких админских ролей
-4. **Кворум голосов** - все решения через коллективное голосование
-5. **Проверка баланса** - при каждой операции
-
----
-
-## 🏗️ АРХИТЕКТУРА СИСТЕМЫ
-
-### Основной контракт DLE.sol
-```
-DLE.sol
-├── ERC-20 токены (голосующая сила)
-├── Настраиваемый кворум (% от общего количества токенов)
-├── Система голосования (проверка баланса токенов)
-├── Выбор цепочки для кворума (governanceChainId)
-├── Синхронизация голосов между цепочками
-├── Поддержка множественных цепочек
-├── Голосование токен‑холдеров
-├── Мультичейн синхронизация
-└── Система модулей (добавление/управление)
-```
-
-### Модули (отдельные контракты)
-```
-Модули
-├── TreasuryModule.sol (Казначейство)
-├── HierarchicalVotingModule.sol (Иерархическое голосование)
-├── CommunicationModule.sol (Сообщения/звонки)
-├── ExternalDLEModule.sol (Меж-DLE взаимодействие)
-└── CustomModule.sol (Пользовательские модули)
-```
-
----
-
-## 📋 ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
-
-### 1. Основной контракт DLE.sol ✅
-- **ERC-20 токены** - голосующая сила = количество токенов
-- **Настраиваемый кворум** - процент от общего количества токенов
-- **Система голосования** - только токен-холдеры участвуют
-- **Выбор цепочки для кворума** - токен-холдер может выбрать любую поддерживаемую цепочку
-- **Синхронизация голосов** - после голосования результаты синхронизируются между цепочками
-- **Поддержка множественных цепочек** - Ethereum, Polygon, BSC и др.
-- **Голосование** - через токен‑холдеров с проверкой баланса
-- **Мультичейн синхронизация** - одинаковый адрес во всех цепочках
-- **Управление модулями** - добавление/удаление через голосование
-
-### 2. TreasuryModule.sol ✅
-- **Внесение токенов** - в казну через голосование
-- **Вывод токенов** - из казны через голосование
-- **Распределение дивидендов** - через голосование
-- **Бюджетирование** - через предложения
-
-### 3. HierarchicalVotingModule.sol ✅
-- **Владение токенами других DLE** - покупка/продажа токенов
-- **Создание предложений** - для голосования в других DLE
-- **Внутреннее голосование** - кворум внутри DLE для внешнего голосования
-- **Внешнее голосование** - участие в голосованиях других DLE
-
-### 4. CommunicationModule.sol ✅
-- **Прием сообщений** - от токен-холдеров
-- **Прием звонков** - аудио/видео коммуникации
-- **История коммуникаций** - хранение и синхронизация
-- **Кворум для действий** - голосование за коммуникационные операции
-
-### 5. ExternalDLEModule.sol ✅
-- **Меж-DLE взаимодействие** - управление DLE B через приложение DLE A
-- **Встраивание интерфейсов** - безопасное управление
-- **Проверка прав** - через голосование токен‑холдеров
-- **Аудит действий** - отслеживание операций
-
-### 6. Мульти-чейн архитектура ✅
-- **CREATE2 деплой** - одинаковый адрес во всех цепочках
-- **Синхронизация состояния** - токены, предложения, голосования
-- **Создание предложений** - в любой цепочке
-- **Голосование** - через токен‑холдеров с проверкой баланса
-
----
-
-## 🔒 БЕЗОПАСНОСТЬ
-
-### Основные принципы безопасности:
-1. **Только токен-холдеры** - никаких админских ролей
-2. **Проверка баланса** - при каждой операции
-3. **Кворум голосов** - все решения коллективные
-4. **Простая логика** - минимум уязвимостей
-
-### Защита от атак:
-
-#### **1. Защита от Double-Spending**
-```solidity
-function signOperation(bytes32 _operationHash) external {
- require(!hasSigned[_operationHash][msg.sender], "Already signed");
- require(balanceOf(msg.sender) > 0, "No tokens to sign");
-
- hasSigned[_operationHash][msg.sender] = true;
- signatures[_operationHash] += balanceOf(msg.sender);
-}
-```
-
-#### **2. Защита от Reentrancy**
-```solidity
-mapping(address => bool) private _locked;
-
-modifier nonReentrant() {
- require(!_locked[msg.sender], "Reentrant call");
- _locked[msg.sender] = true;
- _;
- _locked[msg.sender] = false;
-}
-```
-
-#### **3. Защита от Манипуляций**
-```solidity
-mapping(uint256 => uint256) public proposalSnapshots;
-
-function createProposal(string memory _description) external returns (uint256) {
- require(balanceOf(msg.sender) > 0, "Must hold tokens");
-
- uint256 proposalId = proposalCount++;
- proposalSnapshots[proposalId] = block.number;
-
- return proposalId;
-}
-
-function vote(uint256 _proposalId, bool _support) external {
- uint256 votingPower = balanceOfAt(msg.sender, proposalSnapshots[_proposalId]);
- require(votingPower > 0, "No voting power");
-
- // Голосование
-}
-```
-
----
-
-## 🔧 ТЕХНИЧЕСКАЯ РЕАЛИЗАЦИЯ
-
-### Основной контракт DLE.sol
-```solidity
-contract DLE is ERC20, ReentrancyGuard {
- // Настройки
- uint256 public quorumPercentage;
- mapping(address => bool) public activeModules;
-
- // Мульти-чейн
- mapping(uint256 => bool) public supportedChains;
- mapping(uint256 => uint256) public chainBalances;
-
- // Предложения и голосования
- mapping(uint256 => Proposal) public proposals;
- mapping(uint256 => mapping(address => bool)) public hasVoted;
-
- // Модули
- mapping(bytes32 => address) public modules;
-
- constructor(
- string memory _name,
- string memory _symbol,
- uint256 _initialSupply,
- uint256 _quorumPercentage
- ) ERC20(_name, _symbol) {
- quorumPercentage = _quorumPercentage;
- _mint(msg.sender, _initialSupply);
- }
-
- // Создание предложения
- function createProposal(string memory _description, uint256 _duration) external returns (uint256) {
- require(balanceOf(msg.sender) > 0, "Must hold tokens");
-
- uint256 proposalId = proposalCount++;
- proposals[proposalId] = Proposal({
- id: proposalId,
- description: _description,
- forVotes: 0,
- againstVotes: 0,
- executed: false,
- deadline: block.timestamp + _duration
- });
-
- return proposalId;
- }
-
- // Голосование
- function vote(uint256 _proposalId, bool _support) external {
- Proposal storage proposal = proposals[_proposalId];
- require(block.timestamp < proposal.deadline, "Voting ended");
- require(!proposal.executed, "Already executed");
- require(!hasVoted[_proposalId][msg.sender], "Already voted");
-
- uint256 votingPower = balanceOf(msg.sender);
- require(votingPower > 0, "No tokens to vote");
-
- hasVoted[_proposalId][msg.sender] = true;
-
- if (_support) {
- proposal.forVotes += votingPower;
- } else {
- proposal.againstVotes += votingPower;
- }
- }
-
- // Добавление модуля
- function addModule(bytes32 _moduleId, address _moduleAddress) external {
- require(checkProposalResult(getLastProposalId()).passed, "Proposal not passed");
-
- modules[_moduleId] = _moduleAddress;
- activeModules[_moduleAddress] = true;
-
- emit ModuleAdded(_moduleId, _moduleAddress);
- }
-}
-```
-
-### Модуль казначейства TreasuryModule.sol
-```solidity
-contract TreasuryModule {
- DLE public dle;
- uint256 public treasuryBalance;
-
- constructor(address _dle) {
- dle = DLE(_dle);
- }
-
- function depositToTreasury(uint256 _amount) external {
- require(dle.balanceOf(msg.sender) >= _amount, "Insufficient balance");
- require(dle.transferFrom(msg.sender, address(this), _amount), "Transfer failed");
-
- treasuryBalance += _amount;
- emit TreasuryDeposit(msg.sender, _amount);
- }
-
- function withdrawFromTreasury(address _recipient, uint256 _amount) external {
- require(dle.checkProposalResult(getTreasuryProposalId()).passed, "Proposal not passed");
- require(_amount <= treasuryBalance, "Insufficient treasury");
-
- treasuryBalance -= _amount;
- require(dle.transfer(_recipient, _amount), "Transfer failed");
-
- emit TreasuryWithdrawal(_recipient, _amount);
- }
-}
-```
-
-### Модуль иерархического голосования HierarchicalVotingModule.sol
-```solidity
-contract HierarchicalVotingModule {
- DLE public dle;
- mapping(address => uint256) public externalDLEBalances;
- mapping(uint256 => ExternalVotingProposal) public externalVotingProposals;
-
- struct ExternalVotingProposal {
- address targetDLE;
- uint256 targetProposalId;
- bool support;
- string reason;
- bool executed;
- uint256 internalProposalId;
- }
-
- constructor(address _dle) {
- dle = DLE(_dle);
- }
-
- function buyTokensFromOtherDLE(address _otherDLE, uint256 _amount) external {
- require(dle.balanceOf(msg.sender) > 0, "Must hold DLE tokens");
- require(_amount > 0, "Amount must be positive");
-
- require(dle.transferFrom(msg.sender, address(this), _amount), "Transfer failed");
- externalDLEBalances[_otherDLE] += _amount;
-
- emit ExternalDLEInvestment(_otherDLE, _amount);
- }
-
- function createExternalVotingProposal(
- address _targetDLE,
- uint256 _targetProposalId,
- bool _support,
- string memory _reason
- ) external returns (uint256) {
- require(dle.balanceOf(msg.sender) > 0, "Must hold DLE tokens");
- require(externalDLEBalances[_targetDLE] > 0, "No tokens in target DLE");
-
- string memory description = string(abi.encodePacked(
- "Vote in DLE ", _targetDLE, " on proposal ", _targetProposalId.toString()
- ));
-
- uint256 internalProposalId = dle.createProposal(description, 7 days);
-
- uint256 proposalId = externalProposalCount++;
- externalVotingProposals[proposalId] = ExternalVotingProposal({
- targetDLE: _targetDLE,
- targetProposalId: _targetProposalId,
- support: _support,
- reason: _reason,
- executed: false,
- internalProposalId: internalProposalId
- });
-
- return proposalId;
- }
-
- function executeExternalVote(uint256 _proposalId) external {
- ExternalVotingProposal storage proposal = externalVotingProposals[_proposalId];
- require(!proposal.executed, "Already executed");
-
- (bool passed, bool quorumReached) = dle.checkProposalResult(proposal.internalProposalId);
- require(passed && quorumReached, "Internal proposal not passed");
-
- uint256 votingPower = externalDLEBalances[proposal.targetDLE];
-
- emit ExternalDLEVote(proposal.targetDLE, proposal.targetProposalId, proposal.support, votingPower);
-
- proposal.executed = true;
- }
-}
-```
-
----
-
-## 🌐 МУЛЬТИ-ЧЕЙН АРХИТЕКТУРА
-
-### Мульти-чейн функциональность
-```solidity
-// Создание предложения с выбором цепочки для кворума
-function createProposal(
- string memory _description,
- uint256 _duration,
- uint256 _governanceChainId
-) external returns (uint256);
-
-// Исполнение в целевых сетях по EIP-712 подписям (без мостов)
-function executeProposalBySignatures(
- uint256 proposalId,
- bytes[] calldata signatures
-) external;
-
-// Проверка поддерживаемых цепочек
-function isChainSupported(uint256 _chainId) external view returns (bool);
-```
-
-### Синхронизация между цепочками
-- Результаты голосования фиксируются снапшотами ERC20Votes в governance‑сети.
-- Целевые сети принимают исполнение при верификации EIP‑712 подписей холдеров и кворума на зафиксированном timepoint.
-
----
-
-## ⚠️ ПРОБЛЕМЫ ДОСТУПНОСТИ ЦЕПОЧЕК
-
-### **Сценарий: Из 4 цепочек доступны только 2**
-
-#### **1. Проблема при деплое:**
-```
-Планируемый деплой: Ethereum, Polygon, BSC, Arbitrum
-Доступные цепочки: Ethereum, Polygon
-Недоступные: BSC, Arbitrum (ошибка подключения/интернет)
-```
-
-#### **2. Проблема при синхронизации:**
-```
-Исполнение в Ethereum → Синхронизация в остальные цепочки
-✅ Polygon: синхронизация успешна
-❌ BSC: ошибка подключения
-❌ Arbitrum: нет интернета
-```
-
-### **ПРОСТОЕ И БЕЗОПАСНОЕ РЕШЕНИЕ:**
-
-#### **Принцип: 100% или ничего**
-```
-Перед любым действием:
-1. ✅ Проверить все подключения
-2. ✅ Убедиться в доступности всех цепочек
-3. ✅ Выполнить операцию на 100%
-4. ❌ При любом сбое - отменить всё с указанием причины
-```
-
-#### **1. Проверка подключений перед деплоем**
-```solidity
-contract DLE is ERC20, ReentrancyGuard {
- // Статус проверки цепочек
- mapping(uint256 => bool) public chainConnectionStatus;
-
- // События
- event PreDeployCheckStarted(uint256[] chainIds);
- event PreDeployCheckCompleted(bool allChainsAvailable, string[] unavailableChains);
- event DeployCancelled(string reason);
-
- /**
- * @dev Проверить подключения перед деплоем
- */
- function checkAllConnections(uint256[] memory _chainIds) external returns (bool) {
- require(balanceOf(msg.sender) > 0, "Must hold tokens");
-
- emit PreDeployCheckStarted(_chainIds);
-
- bool allAvailable = true;
- string[] memory unavailableChains = new string[](_chainIds.length);
- uint256 unavailableCount = 0;
-
- for (uint256 i = 0; i < _chainIds.length; i++) {
- bool isAvailable = checkChainConnection(_chainIds[i]);
- chainConnectionStatus[_chainIds[i]] = isAvailable;
-
- if (!isAvailable) {
- allAvailable = false;
- unavailableChains[unavailableCount] = getChainName(_chainIds[i]);
- unavailableCount++;
- }
- }
-
- emit PreDeployCheckCompleted(allAvailable, unavailableChains);
-
- if (!allAvailable) {
- string memory reason = string(abi.encodePacked(
- "Deploy cancelled: Chains unavailable - ",
- joinStrings(unavailableChains, unavailableCount)
- ));
- emit DeployCancelled(reason);
- }
-
- return allAvailable;
- }
-
- /**
- * @dev Проверить подключение к конкретной цепочке
- */
- function checkChainConnection(uint256 _chainId) internal view returns (bool) {
- // Здесь должна быть реальная проверка подключения
- // Для примера используем простую проверку
- return _chainId > 0 && _chainId <= 999999;
- }
-
- /**
- * @dev Получить название цепочки
- */
- function getChainName(uint256 _chainId) internal pure returns (string memory) {
- if (_chainId == 1) return "Ethereum";
- if (_chainId == 137) return "Polygon";
- if (_chainId == 56) return "BSC";
- if (_chainId == 42161) return "Arbitrum";
- return "Unknown";
- }
-}
-```
-
-#### **2. Проверка перед синхронизацией**
-```solidity
-contract DLE is ERC20, ReentrancyGuard {
- /**
- * @dev Проверить все цепочки перед синхронизацией
- */
- function checkSyncReadiness(uint256 _proposalId) external returns (bool) {
- require(balanceOf(msg.sender) > 0, "Must hold tokens");
-
- Proposal storage proposal = proposals[_proposalId];
- require(proposal.id == _proposalId, "Proposal does not exist");
-
- // Проверяем все поддерживаемые цепочки
- bool allChainsReady = true;
- string[] memory unavailableChains = new string[](supportedChainIds.length);
- uint256 unavailableCount = 0;
-
- for (uint256 i = 0; i < supportedChainIds.length; i++) {
- uint256 chainId = supportedChainIds[i];
- bool isReady = checkChainConnection(chainId);
-
- if (!isReady) {
- allChainsReady = false;
- unavailableChains[unavailableCount] = getChainName(chainId);
- unavailableCount++;
- }
- }
-
- if (!allChainsReady) {
- string memory reason = string(abi.encodePacked(
- "Sync cancelled: Chains unavailable - ",
- joinStrings(unavailableChains, unavailableCount)
- ));
- emit SyncCancelled(_proposalId, reason);
- }
-
- return allChainsReady;
- }
-
- /**
- * @dev Синхронизация только при 100% готовности
- */
- function syncToAllChains(uint256 _proposalId) external {
- require(checkSyncReadiness(_proposalId), "Not all chains ready");
-
- // Выполняем синхронизацию во все цепочки
- for (uint256 i = 0; i < supportedChainIds.length; i++) {
- uint256 chainId = supportedChainIds[i];
- syncToChain(_proposalId, chainId);
- }
-
- emit SyncCompleted(_proposalId, supportedChainIds);
- }
-}
-```
-
-#### **3. Проверка перед голосованием**
-```solidity
-contract DLE is ERC20, ReentrancyGuard {
- /**
- * @dev Проверить цепочку перед голосованием
- */
- function checkVotingChain(uint256 _chainId) external returns (bool) {
- require(balanceOf(msg.sender) > 0, "Must hold tokens");
-
- bool isAvailable = checkChainConnection(_chainId);
-
- if (!isAvailable) {
- string memory reason = string(abi.encodePacked(
- "Voting cancelled: Chain ",
- getChainName(_chainId),
- " unavailable"
- ));
- emit VotingCancelled(reason);
- }
-
- return isAvailable;
- }
-
- /**
- * @dev Создать предложение только при доступности цепочки
- */
- function createProposalWithChainCheck(
- string memory _description,
- uint256 _duration,
- uint256 _votingChainId
- ) external returns (uint256) {
- require(checkVotingChain(_votingChainId), "Voting chain not available");
-
- return createProposal(_description, _duration, _votingChainId);
- }
-}
-```
-
-### **СТРАТЕГИИ ОБРАБОТКИ:**
-
-#### **1. При деплое (проверка всех цепочек):**
-```
-Планируемый деплой: Ethereum, Polygon, BSC, Arbitrum
-
-Проверка:
-✅ Ethereum: доступен
-✅ Polygon: доступен
-❌ BSC: недоступен
-❌ Arbitrum: недоступен
-
-Результат:
-❌ Деплой ОТМЕНЕН
-📋 Причина: "BSC, Arbitrum недоступны"
-🔔 Уведомление токен-холдеров
-```
-
-#### **2. При синхронизации (проверка всех цепочек):**
-```
-Исполнение в Ethereum → Синхронизация
-
-Проверка:
-✅ Ethereum: доступен
-✅ Polygon: доступен
-❌ BSC: недоступен
-❌ Arbitrum: недоступен
-
-Результат:
-❌ Синхронизация ОТМЕНЕНА
-📋 Причина: "BSC, Arbitrum недоступны"
-🔔 Уведомление токен-холдеров
-```
-
-#### **3. При голосовании (проверка выбранной цепочки):**
-```
-Планируемое голосование: Polygon
-
-Проверка:
-❌ Polygon: недоступен
-
-Результат:
-❌ Голосование ОТМЕНЕНО
-📋 Причина: "Polygon недоступен"
-🔔 Уведомление токен-холдеров
-```
-
-### **ПРИМЕРЫ СЦЕНАРИЕВ:**
-
-#### **Сценарий 1: Деплой с проблемами**
-```
-Планируемый деплой: 4 цепочки
-
-Проверка подключений:
-✅ Ethereum: доступен
-✅ Polygon: доступен
-❌ BSC: ошибка подключения
-❌ Arbitrum: нет интернета
-
-Действия:
-1. ❌ Деплой ОТМЕНЕН
-2. 📋 Причина: "BSC, Arbitrum недоступны"
-3. 🔔 Уведомление токен-холдеров
-4. ⏰ Ожидание восстановления подключений
-5. 🔄 Повторная проверка при восстановлении
-```
-
-#### **Сценарий 2: Синхронизация с проблемами**
-```
-Исполнение в Ethereum → Синхронизация
-
-Проверка всех цепочек:
-✅ Ethereum: доступен
-✅ Polygon: доступен
-❌ BSC: ошибка подключения
-❌ Arbitrum: нет интернета
-
-Действия:
-1. ❌ Синхронизация ОТМЕНЕНА
-2. 📋 Причина: "BSC, Arbitrum недоступны"
-3. 🔔 Уведомление токен-холдеров
-4. ⏰ Ожидание восстановления подключений
-5. 🔄 Повторная проверка при восстановлении
-```
-
-#### **Сценарий 3: Голосование с проблемами**
-```
-Планируемое голосование: Polygon
-
-Проверка Polygon:
-❌ Polygon: недоступен
-
-Действия:
-1. ❌ Голосование ОТМЕНЕНО
-2. 📋 Причина: "Polygon недоступен"
-3. 🔔 Уведомление токен-холдеров
-4. ⏰ Ожидание восстановления подключения
-5. 🔄 Повторная проверка при восстановлении
-```
-
-### **ПРЕИМУЩЕСТВА ПРОСТОГО РЕШЕНИЯ:**
-
-#### **✅ Безопасность:**
-- Никаких частичных операций
-- Никаких рассинхронизаций
-- Четкие причины отмены
-
-#### **✅ Простота:**
-- Понятная логика
-- Минимум кода
-- Легко отлаживать
-
-#### **✅ Надежность:**
-- 100% или ничего
-- Предсказуемое поведение
-- Нет скрытых состояний
-
-#### **✅ Прозрачность:**
-- Четкие причины отмены
-- Уведомления токен-холдеров
-- Понятная логика
-
-### **КЛЮЧЕВЫЕ ПРИНЦИПЫ:**
-
-#### **1. Проверка перед действием:**
-```
-Любое действие = Проверка всех подключений → Выполнение или Отмена
-```
-
-#### **2. 100% или ничего:**
-```
-Все цепочки доступны → Выполнить
-Любая цепочка недоступна → Отменить с причиной
-```
-
-#### **3. Четкие причины:**
-```
-Отмена = Конкретная причина + Уведомление токен-холдеров
-```
-
-#### **4. Простота восстановления:**
-```
-Проблема решена → Повторная проверка → Выполнение
-```
-
-**Теперь система DLE работает по принципу "100% или ничего" - просто, безопасно и надежно!**
-
----
-
-## 📊 ПРИМЕРЫ ИСПОЛЬЗОВАНИЯ
-
-### Пример 1: Деплой в 4 цепочках
-```
-1. Пользователь выбирает 4 цепочки: Ethereum, Polygon, BSC, Arbitrum
-2. Деплой DLE в каждой цепочке с одинаковым адресом
-3. Партнеры получают по 1000 токенов в каждой цепочке:
- - Партнер A: 1000 токенов (в 4 цепочках)
- - Партнер B: 1000 токенов (в 4 цепочках)
- - Партнер C: 1000 токенов (в 4 цепочках)
-4. Передача токенов синхронизируется между всеми цепочками
-```
-
-### Пример 2: Создание предложения и сбор подписей
-```
-1. Партнер A создает предложение "Передать 100 токенов от A к C"
-2. Выбирает одну цепочку (например, Polygon) для сбора подписей
-3. Сбор подписей происходит только в выбранной цепочке
-4. Кворум: 60% от 3000 = 1800 токенов
-5. При достижении кворума - исполнение в Polygon
-6. Синхронизация исполнения во все остальные цепочки
-```
-
-### Пример 3: Исполнение и синхронизация
-```
-1. Кворум достигнут в Polygon (1800+ токенов)
-2. Исполнение в Polygon: A → C (100 токенов)
-3. Синхронизация в Ethereum: A → C (100 токенов)
-4. Синхронизация в BSC: A → C (100 токенов)
-5. Синхронизация в Arbitrum: A → C (100 токенов)
-6. Результат: токены переданы во всех 4 цепочках
-```
-
-### Пример 4: Удаление таблицы в приложении
-```
-1. Партнер A создает предложение "Удалить таблицу пользователей"
-2. Выбирает Ethereum для сбора подписей
-3. Кворум достигнут в Ethereum
-4. Исполнение в Ethereum: информация добавляется в блокчейн
-5. Синхронизация во все цепочки: информация добавляется везде
-6. Результат: таблица удаляется из приложения
-```
-
----
-
-## 🎯 ПРЕИМУЩЕСТВА АРХИТЕКТУРЫ
-
-### ✅ Простота
-- Один основной контракт с модулями
-- Только токен-холдеры участвуют в управлении
-- Проверка баланса при каждой операции
-- Настраиваемый кворум для всех решений
-
-### ✅ Безопасность
-- Никаких админских ролей
-- Простая логика коллективного голосования
-- Защита от основных атак
-- Прозрачность всех операций
-
-### ✅ Масштабируемость
-- Модульная архитектура
-- Добавление новых функций через модули
-- Мульти-чейн синхронизация
-- Иерархическое голосование
-
-### ✅ Универсальность
-- Один адрес во всех цепочках
-- Любая цепочка для создания предложений
-- Единый интерфейс управления
-- Совместимость с существующими стандартами
-
----
-
-## 📈 ЗАКЛЮЧЕНИЕ
-
-**DLE - это единый смарт-контракт с модульной архитектурой, который:**
-
-1. **Управляется только токен‑холдерами** через кворум голосов
-2. **Проверяет баланс токенов** при каждой операции
-3. **Использует модули** для специализированных функций
-4. **Синхронизируется между цепочками** с одинаковым адресом
-5. **Поддерживает иерархическое голосование** через отдельный модуль
-
-**Ключевые принципы:**
-- Простота и безопасность
-- Коллективное управление
-- Модульная архитектура
-- Мульти-чейн синхронизация
-
-**Результат:** Безопасная, масштабируемая и универсальная система DLE! 🚀
\ No newline at end of file
diff --git a/docs/DLE_DEPLOY_GUIDE.md b/docs/DLE_DEPLOY_GUIDE.md
deleted file mode 100644
index 218a8ed..0000000
--- a/docs/DLE_DEPLOY_GUIDE.md
+++ /dev/null
@@ -1,311 +0,0 @@
-
-
-# Руководство по деплою DLE v2
-
-## Обзор
-
-DLE v2 (Digital Legal Entity) - это система для создания цифровых юридических лиц с мульти-чейн поддержкой. Основная особенность - использование CREATE с выровненным nonce для обеспечения одинакового адреса смарт-контракта во всех поддерживаемых сетях.
-
-## Архитектура
-
-### Компоненты системы
-
-1. **DLE.sol** - Основной смарт-контракт с ERC-20 токенами управления
-2. **Детерминированный деплой** - через CREATE с выровненным nonce для одинаковых адресов
-3. **Модули** - Дополнительная функциональность (Treasury, Timelock, etc.)
-
-### Мульти-чейн поддержка
-
-- **CREATE с выровненным nonce** - Одинаковый адрес во всех EVM-совместимых сетях
-- **Single-Chain Governance** - Голосование происходит в одной сети
-- **Multi-Chain Execution** - Исполнение в целевых сетях по подписям
-
-## Процесс деплоя
-
-### 1. Подготовка
-
-1. Убедитесь, что у вас есть:
- - Приватный ключ с достаточным балансом в выбранных сетях
- - RPC URLs для всех целевых сетей
- - API ключ Etherscan (опционально, для верификации)
-
-2. Настройте RPC провайдеры в веб-интерфейсе:
- - Откройте страницу настроек: `http://localhost:5173/settings/security`
- - Перейдите в раздел "RPC Провайдеры"
- - Добавьте RPC URLs для нужных сетей:
- - **Ethereum Mainnet**: Chain ID 1
- - **Polygon**: Chain ID 137
- - **BSC**: Chain ID 56
- - **Arbitrum**: Chain ID 42161
- - **Sepolia Testnet**: Chain ID 11155111
- - И другие нужные сети
-
-3. Приватные ключи вводятся непосредственно в форме деплоя для безопасности
-
-### 2. Деплой через веб-интерфейс
-
-1. Откройте страницу: `http://localhost:5173/settings/dle-v2-deploy`
-
-2. Заполните форму:
- - **Основная информация**: Название, символ токена
- - **Юридическая информация**: Страна, ОКВЭД, адрес
- - **Партнеры**: Адреса и доли токенов
- - **Сети**: Выберите целевые блокчейн-сети
- - **Приватный ключ**: Для деплоя контрактов
-
-3. Нажмите "Развернуть DLE"
-
-### 3. Процесс деплоя
-
-Система автоматически:
-
-1. **Проверяет балансы** во всех выбранных сетях
-2. **Компилирует контракты** через Hardhat
-3. **Проверяет Factory адреса** в базе данных
-4. **Выравнивает nonce** для детерминированного деплоя
-5. **Вычисляет адрес DLE** через CREATE с выровненным nonce
-6. **Деплоит DLE** с одинаковым адресом во всех сетях
-8. **Деплоит базовые модули** (Treasury, Timelock, Reader) в каждой сети
-9. **Инициализирует модули** в DLE контракте
-10. **Верифицирует контракты** в Etherscan (опционально)
-
-### 4. Результат
-
-После успешного деплоя вы получите:
-
-- **Одинаковый адрес DLE** во всех выбранных сетях
-- **Одинаковый адрес Factory** во всех выбранных сетях
-- **Базовые модули** (Treasury, Timelock, Reader) в каждой сети
-- **Инициализированные модули** в DLE контракте
-- **ERC-20 токены управления** распределенные между партнерами
-- **Настроенный кворум** для принятия решений
-- **Поддержку мульти-чейн операций**
-
-### 5. Управление Factory адресами
-
-Система автоматически управляет Factory адресами:
-
-#### API Endpoints:
-- `GET /api/factory` - Получить все Factory адреса
-- `GET /api/factory/:chainId` - Получить Factory адрес для сети
-- `POST /api/factory` - Сохранить Factory адрес
-- `POST /api/factory/bulk` - Сохранить адреса для нескольких сетей
-- `DELETE /api/factory/:chainId` - Удалить Factory адрес
-- `POST /api/factory/check` - Проверить наличие адресов
-
-#### Автоматическое управление:
-- **Кэширование** - Factory адреса сохраняются в базе данных
-- **Переиспользование** - Существующие Factory используются повторно
-- **Валидация** - Проверка существования Factory в блокчейне
-- **Автодеплой** - Новые Factory деплоятся при необходимости
-
-### 6. Проверка одинаковости адресов
-
-Система автоматически проверяет, что все адреса одинаковые:
-
-```javascript
-// Проверка адресов DLE
-const addresses = results.filter(r => r.success).map(r => r.address);
-const uniqueAddresses = [...new Set(addresses)];
-
-if (uniqueAddresses.length === 1) {
- console.log("✅ Все адреса DLE одинаковые:", uniqueAddresses[0]);
-} else {
- throw new Error("CREATE2 не обеспечил одинаковые адреса");
-}
-```
-
-Если адреса не совпадают, это указывает на проблему с:
-- Разными Factory адресами в сетях
-- Разными salt значениями
-- Разными bytecode контрактов
-
-## Технические детали
-
-### База данных Factory адресов
-
-Система использует таблицу `factory_addresses` для хранения адресов:
-
-```sql
-CREATE TABLE factory_addresses (
- id SERIAL PRIMARY KEY,
- chain_id INTEGER NOT NULL UNIQUE,
- factory_address VARCHAR(42) NOT NULL,
- created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
- updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
-);
-```
-
-### CREATE Механизм
-
-Система использует CREATE с выровненным nonce для обеспечения одинаковых адресов:
-
-#### 1. Выравнивание nonce
-```javascript
-// Выравнивание nonce до целевого значения
-while (currentNonce < targetNonce) {
- await sendTransaction({
- to: burnAddress,
- value: 0,
- nonce: currentNonce
- });
- currentNonce++;
-}
-```
-
-#### 2. Деплой DLE
-```javascript
-// Вычисление адреса DLE через CREATE
-const predictedAddress = ethers.getCreateAddress({
- from: wallet.address,
- nonce: targetNonce
-});
-
-// Деплой DLE с предсказанным адресом
-await wallet.sendTransaction({
- data: dleInitCode,
- nonce: targetNonce
-});
-```
-
-#### Ключевые принципы:
-- **Выровненный nonce** обеспечивает одинаковые адреса во всех сетях
-- **Burn address** используется для выравнивания nonce без потери средств
-- **Проверка баланса** перед деплоем предотвращает неудачи
-- **DLE Contract** деплоится через Factory с одинаковым salt
-- **Результат**: Одинаковый адрес DLE во всех EVM-совместимых сетях
-
-### Структура DLE
-
-```solidity
-contract DLE is ERC20, ERC20Permit, ERC20Votes, ReentrancyGuard {
- // Основная информация
- DLEInfo public dleInfo;
-
- // Настройки управления
- uint256 public quorumPercentage;
-
- // Мульти-чейн поддержка
- uint256[] public supportedChainIds;
- uint256 public governanceChainId;
-
- // Система предложений
- mapping(uint256 => Proposal) public proposals;
-}
-```
-
-### Базовые модули (автоматически деплоятся)
-
-При деплое DLE автоматически развертываются и инициализируются:
-
-- **TreasuryModule** - Управление финансами, депозиты, выводы, дивиденды
-- **TimelockModule** - Задержки исполнения критических операций
-- **DLEReader** - API для чтения данных DLE
-
-### Дополнительные модули (через голосование)
-
-DLE поддерживает модульную архитектуру:
-
-- **CommunicationModule** - Внешние коммуникации
-- **BurnModule** - Сжигание токенов
-- **MintModule** - Выпуск новых токенов
-- **OracleModule** - Внешние данные
-- **CustomModule** - Пользовательские модули
-
-## Управление DLE
-
-### Создание предложений
-
-```solidity
-// Создать предложение
-uint256 proposalId = dle.createProposal(
- "Описание предложения",
- governanceChainId,
- targetChains,
- timelockHours,
- operationCalldata
-);
-```
-
-### Голосование
-
-```solidity
-// Голосовать за предложение
-dle.vote(proposalId, true); // За
-dle.vote(proposalId, false); // Против
-```
-
-### Исполнение
-
-```solidity
-// Исполнить предложение
-dle.executeProposalBySignatures(proposalId, signatures);
-```
-
-## Безопасность
-
-### Ключевые принципы
-
-1. **Только токен-холдеры** участвуют в управлении
-2. **Прямые переводы токенов заблокированы**
-3. **Все операции через кворум**
-4. **CREATE2 обеспечивает детерминистические адреса**
-5. **EIP-712 подписи для мульти-чейн исполнения**
-
-### Проверки
-
-- Валидация приватных ключей
-- Проверка балансов перед деплоем
-- Верификация CREATE2 адресов
-- Контроль кворума при голосовании
-
-## Устранение неполадок
-
-### Частые проблемы
-
-1. **Недостаточно средств**
- - Проверьте балансы во всех сетях
- - Убедитесь в правильности RPC URLs в настройках
-
-2. **Ошибки компиляции**
- - Проверьте версию Solidity (0.8.20)
- - Убедитесь в корректности импортов OpenZeppelin
-
-3. **Разные адреса в сетях**
- - Проверьте, что Factory контракты имеют одинаковые адреса
- - Проверьте CREATE2 salt для DLE
- - Убедитесь в одинаковом bytecode контрактов
- - Проверьте nonce кошелька деплоера
-
-4. **Ошибки верификации**
- - Проверьте API ключ Etherscan в форме деплоя
- - Убедитесь в корректности constructor arguments
-
-5. **RPC URL не найден**
- - Проверьте настройки RPC провайдеров в `/settings/security`
- - Убедитесь, что Chain ID указан правильно
- - Протестируйте RPC URL через кнопку "Тест" в настройках
-
-### Логи
-
-Логи деплоя доступны в:
-- Backend: `backend/logs/`
-- Hardhat: `backend/artifacts/`
-- Результаты: `backend/contracts-data/dles/`
-
-## Поддержка
-
-Для получения поддержки:
-- Email: info@hb3-accelerator.com
-- Website: https://hb3-accelerator.com
-- GitHub: https://github.com/HB3-ACCELERATOR
diff --git a/docs/DLE_MANAGEMENT_TASKS.md b/docs/DLE_MANAGEMENT_TASKS.md
deleted file mode 100644
index ed7d114..0000000
--- a/docs/DLE_MANAGEMENT_TASKS.md
+++ /dev/null
@@ -1,717 +0,0 @@
-
-
-# Детальный план задач: Управление Digital Legal Entity (DLE)
-
-## Общие принципы разработки
-
-### Архитектурные требования
-- **Single-Chain Governance**: Голосование происходит только в одной выбранной сети
-- **Кворум голосов токен‑холдеров**: Все операции требуют достижения кворума голосующей силы по снапшотам
-- **Настраиваемые таймлоки**: Инициатор устанавливает задержку для каждого предложения
-- **Cross-chain исполнение**: Решения выполняются во всех целевых сетях
-- **Без админских ролей**: Только коллективное управление через токен-холдеров
-
-### Технический стек
-- **Frontend**: Vue.js 3 + Composition API
-- **Web3**: ethers.js или web3.js
-- **Контракты**: Solidity + OpenZeppelin (ERC‑4337 опционально для кошельков/UX)
-- **Стили**: Scoped CSS с переменными
-
----
-
-## Обновления (DLE v2)
-
-- Деплой:
- - Мультисетевой деплой одной кнопкой: backend вызывает `deploy-multichain.js`.
- - Предсказанные адреса DLE отображаются автоматически (endpoint `/api/dle-v2/predict-addresses`).
- - INIT_CODE_HASH вычисляется автоматически на backend, не вводится вручную.
-- Предложения (UI):
- - Порядок секций: Базовая информация → Timelock → Governance‑сеть → Целевые сети → Тип операции и параметры → Предпросмотр.
- - Поля: `timelockHours`, `targetChains`, `governanceChainId`.
-- Аналитика:
- - Использовать новые view‑функции: `getProposalSummary`, `getProposalState`, `getProposalVotes`, `getQuorumAt`, `getVotingPowerAt`, `listSupportedChains`, `getGovernanceParams`.
-
-## 1. БЛОК "ПРЕДЛОЖЕНИЯ" (`/management/proposals`)
-
-### Задача 1.1: Создание предложений
-**Описание**: Пользователь создает предложение для выполнения операции в DLE
-
-**Что нужно сделать**:
-- [ ] Добавить форму создания предложения с полями:
- - Тип операции (управление токенами, казна, модули, настройки)
- - Описание операции (текстовое поле)
- - Выбор governance-сети (выпадающий список)
- - Выбор целевых сетей для исполнения (мультиселект)
- - Таймлок задержка в часах (числовое поле)
-- [ ] Подключить к контракту метод `createProposal(operation, targetChains, timelockDelay)`
-- [ ] Добавить валидацию: только токен-холдеры могут создавать предложения
-- [ ] Показывать предварительный расчет газа для создания предложения
-
-**Время**: 8-12 часов
-
-### Задача 1.2: Подписание предложений
-**Описание**: Токен-холдеры подписывают предложения для достижения кворума
-
-**Что нужно сделать**:
-- [ ] Отображать список активных предложений с прогрессом подписей
-- [ ] Показывать для каждого предложения:
- - Текущее количество подписей / требуемый кворум
- - Список подписавших с их балансами токенов
- - Время до истечения таймлока
-- [ ] Добавить кнопку "Подписать" для токен-холдеров
-- [ ] Подключить к контракту метод `signProposal(proposalId)`
-- [ ] Проверять баланс токенов при подписании
-- [ ] Обновлять UI в реальном времени при новых подписях
-
-**Время**: 10-14 часов
-
-### Задача 1.3: Исполнение предложений
-**Описание**: Выполнение предложений после достижения кворума и истечения таймлока
-
-**Что нужно сделать**:
-- [ ] Отображать статус предложений: "Ожидание", "Кворум достигнут", "Готово к исполнению", "Исполнено"
-- [ ] Добавить кнопку "Исполнить" для предложений готовых к исполнению
-- [ ] Подключить к контракту метод `executeProposal(proposalId)`
-- [ ] Показывать прогресс исполнения в целевых сетях
-- [ ] Обрабатывать ошибки исполнения и показывать fallback статусы
-- [ ] Добавить возможность отмены предложений до истечения таймлока
-
-**Время**: 8-12 часов
-
-### Задача 1.4: История и фильтрация
-**Описание**: Просмотр истории предложений с возможностью фильтрации
-
-**Что нужно сделать**:
-- [ ] Добавить фильтры по:
- - Статусу предложения
- - Типу операции
- - Governance-сети
- - Периоду времени
-- [ ] Реализовать поиск по описанию предложения
-- [ ] Добавить пагинацию для больших списков
-- [ ] Показывать детали каждого предложения в модальном окне
-- [ ] Добавить ссылки на блокчейн-эксплореры для транзакций
-
-**Время**: 6-8 часов
-
----
-
-## 2. БЛОК "ТОКЕНЫ DLE" (`/management/tokens`)
-
-### Задача 2.1: Информация о токенах
-**Описание**: Отображение основной информации о токенах DLE
-
-**Что нужно сделать**:
-- [ ] Показывать общий supply токенов
-- [ ] Отображать баланс текущего пользователя
-- [ ] Показывать процент кворума для голосования
-- [ ] Отображать текущую рыночную стоимость токена (если доступна)
-- [ ] Подключить к контракту методы `totalSupply()`, `balanceOf(address)`
-- [ ] Обновлять данные в реальном времени при изменениях
-
-**Время**: 4-6 часов
-
-### Задача 2.2: Передача токенов
-**Описание**: Перевод токенов между участниками через кворум
-
-**Что нужно сделать**:
-- [ ] Создать форму перевода с полями:
- - Адрес получателя
- - Количество токенов
- - Описание перевода
-- [ ] Создавать предложение для перевода токенов
-- [ ] Показывать статус предложения перевода
-- [ ] Валидировать баланс отправителя
-- [ ] Подключать к контракту через систему предложений
-
-**Время**: 6-8 часов
-
-### Задача 2.3: Распределение токенов
-**Описание**: Массовое распределение токенов новым участникам
-
-**Что нужно сделать**:
-- [ ] Создать форму распределения с возможностью добавления множественных получателей
-- [ ] Поля для каждого получателя: адрес, количество токенов
-- [ ] Кнопки "Добавить получателя" и "Удалить получателя"
-- [ ] Создавать предложение для распределения
-- [ ] Показывать общую сумму распределения
-- [ ] Валидировать общий supply и права на минтинг
-
-**Время**: 8-10 часов
-
-### Задача 2.4: Список держателей токенов
-**Описание**: Отображение всех держателей токенов с их балансами
-
-**Что нужно сделать**:
-- [ ] Получать список всех держателей токенов
-- [ ] Отображать для каждого держателя:
- - Адрес кошелька
- - Количество токенов
- - Процент от общего supply
- - Дата последней активности
-- [ ] Добавить сортировку по балансу, активности, адресу
-- [ ] Реализовать поиск по адресу
-- [ ] Показывать топ-10 держателей отдельно
-
-**Время**: 6-8 часов
-
----
-
-## 3. БЛОК "КВОРУМ" (`/management/quorum`)
-
-### Задача 3.1: Текущие настройки кворума
-**Описание**: Отображение текущих параметров кворума
-
-**Что нужно сделать**:
-- [ ] Показывать текущий процент кворума для голосования
-- [ ] Отображать минимальную задержку голосования
-- [ ] Показывать период голосования
-- [ ] Отображать порог для создания предложений
-- [ ] Подключать к контракту для получения актуальных значений
-- [ ] Показывать когда были изменены последние настройки
-
-**Время**: 4-6 часов
-
-### Задача 3.2: Изменение настроек кворума
-**Описание**: Создание предложения для изменения параметров кворума
-
-**Что нужно сделать**:
-- [ ] Создать форму изменения настроек с полями:
- - Новый процент кворума (1-100%)
- - Новая задержка голосования (в часах)
- - Новый период голосования (в днях)
- - Новый порог для предложений (в токенах)
- - Причина изменения
-- [ ] Валидировать значения (кворум не менее 51%, разумные периоды)
-- [ ] Создавать предложение для изменения настроек
-- [ ] Показывать предварительный расчет влияния изменений
-- [ ] Добавить подтверждение критических изменений
-
-**Время**: 8-10 часов
-
-### Задача 3.3: История изменений кворума
-**Описание**: Просмотр истории изменений параметров кворума
-
-**Что нужно сделать**:
-- [ ] Отображать список всех изменений кворума
-- [ ] Показывать для каждого изменения:
- - Старые и новые значения
- - Кто инициировал изменение
- - Когда было предложено и когда принято
- - Причину изменения
-- [ ] Добавить фильтрацию по периоду и типу изменений
-- [ ] Показывать статистику изменений (частота, тренды)
-
-**Время**: 6-8 часов
-
----
-
-## 4. БЛОК "МОДУЛИ DLE" (`/management/modules`)
-
-### Задача 4.1: Список установленных модулей
-**Описание**: Отображение всех установленных модулей DLE
-
-**Что нужно сделать**:
-- [ ] Получать список всех модулей из контракта
-- [ ] Отображать для каждого модуля:
- - Название и описание
- - Адрес контракта модуля
- - Версию модуля
- - Статус (активен/неактивен)
- - Дата установки
-- [ ] Показывать общую статистику модулей
-- [ ] Добавить поиск и фильтрацию по модулям
-
-**Время**: 6-8 часов
-
-### Задача 4.2: Установка новых модулей
-**Описание**: Добавление новых модулей через голосование
-
-**Что нужно сделать**:
-- [ ] Создать форму установки модуля с полями:
- - Название модуля
- - Адрес контракта модуля
- - Описание функциональности
- - Параметры инициализации
- - Причина установки
-- [ ] Валидировать адрес контракта и совместимость
-- [ ] Создавать предложение для установки модуля
-- [ ] Показывать предварительную проверку модуля
-- [ ] Добавить возможность тестирования модуля перед установкой
-
-**Время**: 10-12 часов
-
-### Задача 4.3: Управление модулями
-**Описание**: Активация, деактивация и удаление модулей
-
-**Что нужно сделать**:
-- [ ] Добавить кнопки управления для каждого модуля:
- - Активировать/деактивировать
- - Обновить версию
- - Удалить модуль
-- [ ] Создавать предложения для каждого действия
-- [ ] Показывать зависимости между модулями
-- [ ] Предупреждать о критических операциях
-- [ ] Добавить возможность отката изменений
-
-**Время**: 8-10 часов
-
-### Задача 4.4: Интерфейсы модулей
-**Описание**: Встраивание интерфейсов управления модулями
-
-**Что нужно сделать**:
-- [ ] Создать систему встраивания интерфейсов модулей
-- [ ] Каждый модуль может предоставлять свой UI
-- [ ] Безопасное взаимодействие между основным приложением и модулями
-- [ ] Единообразный стиль для всех модулей
-- [ ] Добавить документацию для разработчиков модулей
-
-**Время**: 12-16 часов
-
----
-
-## 5. БЛОК "DLE" (Интеграция с другими DLE) (`/management/dle`)
-
-### Задача 5.1: Список подключенных DLE
-**Описание**: Отображение DLE, с которыми установлена интеграция
-
-**Что нужно сделать**:
-- [ ] Показывать карточки всех подключенных DLE
-- [ ] Для каждого DLE отображать:
- - Название и описание
- - Адрес контракта
- - Количество токенов этого DLE в нашем балансе
- - Процент голосов, который мы можем использовать
- - Статус подключения
-- [ ] Добавить возможность удаления DLE из списка
-- [ ] Показывать общую статистику интеграций
-
-**Время**: 6-8 часов
-
-### Задача 5.2: Добавление новых DLE
-**Описание**: Подключение новых DLE для участия в их голосованиях
-
-**Что нужно сделать**:
-- [ ] Создать форму добавления DLE с полями:
- - Название DLE
- - Адрес контракта DLE
- - Описание и назначение
- - Причина подключения
-- [ ] Валидировать адрес и проверять существование контракта
-- [ ] Проверять баланс токенов этого DLE
-- [ ] Создавать предложение для добавления DLE
-- [ ] Показывать предварительную информацию о DLE
-
-**Время**: 8-10 часов
-
-### Задача 5.3: Участие в голосованиях других DLE
-**Описание**: Голосование в предложениях других DLE через наш кворум
-
-**Что нужно сделать**:
-- [ ] Отображать активные предложения других DLE
-- [ ] Показывать для каждого предложения:
- - Описание и тип операции
- - Наш возможный вес голоса
- - Текущий статус голосования
- - Время до истечения
-- [ ] Создавать внутренние предложения для голосования в других DLE
-- [ ] Собирать кворум подписей для внешнего голосования
-- [ ] Отправлять голос в целевое DLE после достижения кворума
-
-**Время**: 12-16 часов
-
-### Задача 5.4: Встраивание интерфейсов управления
-**Описание**: Управление другими DLE через встроенные интерфейсы
-
-**Что нужно сделать**:
-- [ ] Создать систему встраивания интерфейсов других DLE
-- [ ] Безопасное отображение внешних интерфейсов в iframe
-- [ ] Передача контекста аутентификации
-- [ ] Обработка событий и обновлений
-- [ ] Единообразный стиль и навигация
-- [ ] Добавить возможность открытия в новой вкладке
-
-**Время**: 16-20 часов
-
----
-
-## 6. БЛОК "КАЗНА" (`/management/treasury`)
-
-### Задача 6.1: Баланс казны
-**Описание**: Отображение всех активов казны DLE
-
-**Что нужно сделать**:
-- [ ] Показывать балансы всех токенов в казне:
- - Нативные токены (ETH, MATIC, BNB и т.д.)
- - ERC-20 токены
- - NFT и другие активы
-- [ ] Отображать общую стоимость в USD
-- [ ] Показывать историю изменений баланса
-- [ ] Добавить графики движения средств
-- [ ] Подключать к контракту для получения актуальных данных
-
-**Время**: 8-10 часов
-
-### Задача 6.2: Операции с казной
-**Описание**: Выполнение финансовых операций через кворум
-
-**Что нужно сделать**:
-- [ ] Создать формы для различных операций:
- - Отправка средств (нативные токены, ERC-20)
- - Получение средств
- - Обмен токенов
- - Инвестиции в DeFi протоколы
-- [ ] Создавать предложения для каждой операции
-- [ ] Валидировать балансы и права доступа
-- [ ] Показывать предварительный расчет газа и комиссий
-- [ ] Добавить подтверждение критических операций
-
-**Время**: 12-16 часов
-
-### Задача 6.3: Распределение дивидендов
-**Описание**: Выплата дивидендов токен-холдерам
-
-**Что нужно сделать**:
-- [ ] Создать форму распределения дивидендов:
- - Выбор токена для выплаты
- - Общая сумма дивидендов
- - Пропорциональное распределение по балансам
-- [ ] Показывать предварительный расчет выплат каждому держателю
-- [ ] Создавать предложение для выплаты дивидендов
-- [ ] Отслеживать статус выплат
-- [ ] Показывать историю дивидендных выплат
-
-**Время**: 10-12 часов
-
-### Задача 6.4: Бюджетирование и отчеты
-**Описание**: Планирование и контроль расходов казны
-
-**Что нужно сделать**:
-- [ ] Создать систему бюджетирования:
- - Установка лимитов расходов
- - Категоризация операций
- - Планирование расходов
-- [ ] Генерировать отчеты:
- - Месячные/квартальные отчеты
- - Анализ доходов и расходов
- - Прогнозы движения средств
-- [ ] Добавить уведомления о превышении лимитов
-- [ ] Экспорт отчетов в PDF/CSV
-
-**Время**: 12-16 часов
-
----
-
-## 7. БЛОК "АНАЛИТИКА" (`/management/analytics`)
-
-### Задача 7.1: Ключевые метрики
-**Описание**: Отображение основных показателей DLE
-
-**Что нужно сделать**:
-- [ ] Показывать ключевые метрики:
- - Общая стоимость активов (TVL)
- - Количество активных участников
- - Количество предложений за период
- - Средняя доходность
-- [ ] Добавить сравнение с предыдущими периодами
-- [ ] Показывать тренды и изменения
-- [ ] Подключать реальные данные из контрактов
-
-**Время**: 8-10 часов
-
-### Задача 7.2: Графики и визуализация
-**Описание**: Создание интерактивных графиков и диаграмм
-
-**Что нужно сделать**:
-- [ ] Интегрировать библиотеку для графиков (Chart.js, D3.js)
-- [ ] Создать графики:
- - Стоимость токенов во времени
- - Активность участников по дням/неделям
- - Распределение токенов между держателями
- - Движение средств в казне
-- [ ] Добавить интерактивность (зум, фильтры, детализация)
-- [ ] Реализовать экспорт графиков
-
-**Время**: 12-16 часов
-
-### Задача 7.3: Статистика и отчеты
-**Описание**: Детальная аналитика и отчетность
-
-**Что нужно сделать**:
-- [ ] Создать разделы статистики:
- - Топ держателей токенов
- - Самые активные участники
- - История предложений и голосований
- - Финансовая статистика
-- [ ] Добавить фильтры по периодам
-- [ ] Создать настраиваемые дашборды
-- [ ] Реализовать автоматическую генерацию отчетов
-
-**Время**: 10-14 часов
-
-### Задача 7.4: Прогнозирование и тренды
-**Описание**: Анализ трендов и прогнозирование
-
-**Что нужно сделать**:
-- [ ] Анализировать исторические данные для выявления трендов
-- [ ] Создавать прогнозы:
- - Движение стоимости токенов
- - Активность участников
- - Финансовые показатели
-- [ ] Показывать аномалии и важные события
-- [ ] Добавить уведомления о значимых изменениях
-
-**Время**: 14-18 часов
-
----
-
-## 8. БЛОК "ИСТОРИЯ" (`/management/history`)
-
-### Задача 8.1: Лог всех операций
-**Описание**: Отображение полной истории операций DLE
-
-**Что нужно сделать**:
-- [ ] Собирать и отображать все типы операций:
- - Создание и исполнение предложений
- - Операции с токенами
- - Казначейские операции
- - Изменения настроек
- - Модульные операции
-- [ ] Для каждой операции показывать:
- - Тип и описание
- - Время выполнения
- - Участники
- - Статус выполнения
- - Ссылки на транзакции
-
-**Время**: 10-12 часов
-
-### Задача 8.2: Фильтрация и поиск
-**Описание**: Удобный поиск и фильтрация истории
-
-**Что нужно сделать**:
-- [ ] Добавить фильтры по:
- - Типу операции
- - Периоду времени
- - Участникам
- - Статусу
- - Сетям
-- [ ] Реализовать полнотекстовый поиск
-- [ ] Добавить сохранение фильтров
-- [ ] Создать быстрые фильтры (сегодня, неделя, месяц)
-
-**Время**: 8-10 часов
-
-### Задача 8.3: Детали операций
-**Описание**: Подробная информация о каждой операции
-
-**Что нужно сделать**:
-- [ ] Создать модальные окна с деталями операций
-- [ ] Показывать полную информацию:
- - Параметры операции
- - Участники и их роли
- - Результат выполнения
- - Ошибки и предупреждения
-- [ ] Добавить ссылки на блокчейн-эксплореры
-- [ ] Показывать связанные операции
-
-**Время**: 8-10 часов
-
-### Задача 8.4: Экспорт и отчеты
-**Описание**: Экспорт истории в различные форматы
-
-**Что нужно сделать**:
-- [ ] Реализовать экспорт в форматы:
- - CSV для анализа в Excel
- - PDF для отчетов
- - JSON для интеграции
-- [ ] Добавить настройки экспорта (период, типы операций)
-- [ ] Создать шаблоны отчетов
-- [ ] Добавить автоматическую отправку отчетов
-
-**Время**: 6-8 часов
-
----
-
-## 9. БЛОК "НАСТРОЙКИ" (`/management/settings`)
-
-### Задача 9.1: Основные настройки DLE
-**Описание**: Управление основной информацией о DLE
-
-**Что нужно сделать**:
-- [ ] Создать форму основных настроек:
- - Название DLE
- - Символ токена
- - Описание и назначение
- - Местонахождение
- - Веб-сайт
-- [ ] Подключать к контракту для сохранения изменений
-- [ ] Валидировать данные перед сохранением
-- [ ] Показывать историю изменений
-
-**Время**: 6-8 часов
-
-### Задача 9.2: Настройки безопасности
-**Описание**: Управление параметрами безопасности
-
-**Что нужно сделать**:
-- [ ] Создать форму настроек безопасности:
- - Минимальный кворум для голосования
- - Максимальная длительность предложений
- - Порог для экстренных действий
- - Задержка таймлока по умолчанию
- - Дополнительные настройки (делегирование, KYC)
-- [ ] Добавить предупреждения о критических изменениях
-- [ ] Создавать предложения для изменения настроек
-- [ ] Показывать влияние изменений на безопасность
-
-**Время**: 10-12 часов
-
-### Задача 9.3: Настройки сети
-**Описание**: Управление сетевыми параметрами
-
-**Что нужно сделать**:
-- [ ] Создать форму настроек сети:
- - Выбор поддерживаемых сетей
- - Сеть по умолчанию для governance
- - RPC endpoints для каждой сети
- - Настройки синхронизации
-- [ ] Тестировать подключение к сетям
-- [ ] Показывать статус каждой сети
-- [ ] Добавить возможность добавления новых сетей
-
-**Время**: 8-10 часов
-
-### Задача 9.4: Резервное копирование
-**Описание**: Экспорт и импорт настроек
-
-**Что нужно сделать**:
-- [ ] Реализовать экспорт всех настроек в JSON
-- [ ] Создать импорт настроек из файла
-- [ ] Валидировать импортируемые данные
-- [ ] Добавить предварительный просмотр изменений
-- [ ] Создать автоматическое резервное копирование
-
-**Время**: 6-8 часов
-
-### Задача 9.5: Опасная зона
-**Описание**: Критические операции с DLE
-
-**Что нужно сделать**:
-- [ ] Создать раздел опасных операций:
- - Сброс настроек к значениям по умолчанию
- - Полное удаление DLE
- - Экстренная остановка операций
-- [ ] Добавить множественные подтверждения
-- [ ] Показывать последствия каждой операции
-- [ ] Создать логирование критических действий
-
-**Время**: 8-10 часов
-
----
-
-## ОБЩИЕ ЗАДАЧИ ДЛЯ ВСЕХ БЛОКОВ
-
-### Задача 0.1: Подготовка инфраструктуры
-**Описание**: Настройка базовой инфраструктуры для всех блоков
-
-**Что нужно сделать**:
-- [ ] Настроить web3-провайдеры для всех поддерживаемых сетей
-- [ ] Создать абстракции для работы с контрактами
-- [ ] Настроить обработку ошибок и уведомления
-- [ ] Создать систему кэширования данных
-- [ ] Настроить мониторинг состояния сетей
-
-**Время**: 16-20 часов
-
-### Задача 0.2: Интеграция с контрактами
-**Описание**: Подключение всех блоков к смарт-контрактам
-
-**Что нужно сделать**:
-- [ ] Создать интерфейсы для всех методов контрактов
-- [ ] Реализовать обработку событий контрактов
-- [ ] Настроить подписки на изменения состояния
-- [ ] Добавить обработку ошибок транзакций
-- [ ] Реализовать retry механизмы для неудачных транзакций
-
-**Время**: 20-24 часа
-
-### Задача 0.3: Тестирование и отладка
-**Описание**: Комплексное тестирование всех функций
-
-**Что нужно сделать**:
-- [ ] Создать unit-тесты для всех компонентов
-- [ ] Написать e2e тесты для основных сценариев
-- [ ] Протестировать работу в разных сетях
-- [ ] Провести нагрузочное тестирование
-- [ ] Исправить найденные ошибки
-
-**Время**: 24-32 часа
-
-### Задача 0.4: Оптимизация и производительность
-**Описание**: Улучшение производительности и пользовательского опыта
-
-**Что нужно сделать**:
-- [ ] Оптимизировать загрузку данных
-- [ ] Добавить lazy loading для больших списков
-- [ ] Реализовать кэширование на клиенте
-- [ ] Оптимизировать размер бандла
-- [ ] Добавить прогресс-индикаторы для длительных операций
-
-**Время**: 16-20 часов
-
----
-
-## ПРИОРИТЕТЫ РАЗРАБОТКИ
-
-### Высокий приоритет (MVP)
-1. Предложения - базовая функциональность
-2. Токены DLE - основные операции
-3. Кворум - текущие настройки
-4. Настройки - основные параметры
-
-### Средний приоритет
-1. Казна - базовые операции
-2. История - лог операций
-3. Аналитика - ключевые метрики
-4. Модули - список и управление
-
-### Низкий приоритет
-1. DLE - интеграция с другими DLE
-2. Расширенная аналитика
-3. Сложные отчеты
-4. Встраивание интерфейсов
-
----
-
-## ОЦЕНКА ВРЕМЕНИ
-
-### Общее время разработки: 280-380 часов
-
-**Разбивка по блокам:**
-- Предложения: 32-46 часов
-- Токены DLE: 24-32 часа
-- Кворум: 18-24 часа
-- Модули DLE: 36-46 часов
-- DLE (интеграция): 42-54 часа
-- Казна: 42-54 часа
-- Аналитика: 44-58 часа
-- История: 32-40 часов
-- Настройки: 38-48 часов
-- Общие задачи: 76-96 часов
-
-**Рекомендации:**
-- Начать с MVP (высокий приоритет)
-- Разрабатывать параллельно несколько блоков
-- Использовать готовые компоненты где возможно
-- Регулярно тестировать интеграцию с контрактами
\ No newline at end of file
diff --git a/docs/ENCRYPTION_GUIDE.md b/docs/ENCRYPTION_GUIDE.md
deleted file mode 100644
index c5a7ca4..0000000
--- a/docs/ENCRYPTION_GUIDE.md
+++ /dev/null
@@ -1,252 +0,0 @@
-
-
-# 🔐 Полное шифрование всех таблиц в DLE
-
-## 📋 Обзор
-
-Этот подход шифрует **ВСЕ текстовые данные** во **ВСЕХ таблицах** базы данных.
-
-## 🎯 Что шифруется
-
-### **✅ ВСЕ текстовые колонки во ВСЕХ таблицах:**
-- `text` - текстовые поля
-- `varchar` - строки переменной длины
-- `character varying` - строки переменной длины
-- `json` - JSON данные
-- `jsonb` - бинарные JSON данные
-
-### **❌ НЕ шифруются:**
-- `id` - идентификаторы
-- `created_at`, `updated_at` - временные метки
-- `integer`, `numeric`, `boolean` - числовые и логические типы
-- Колонки, уже содержащие `_encrypted` в названии
-
-## 🚀 Пошаговая инструкция
-
-### **Шаг 1: Запуск полного шифрования**
-```bash
-chmod +x encrypt-all-tables.sh
-./encrypt-all-tables.sh
-```
-
-### **Шаг 2: Проверка шифрования**
-```bash
-./decrypt-all-tables.sh
-```
-
-### **Шаг 3: Обновление кода приложения**
-
-#### **A. Использование универсального сервиса**
-```javascript
-const encryptedDataService = require('./services/encryptedDataService');
-
-// Получение данных с автоматической расшифровкой
-const users = await encryptedDataService.getData('users', { role: 'admin' });
-
-// Сохранение данных с автоматическим шифрованием
-const newUser = await encryptedDataService.saveData('users', {
- name: 'Иван Иванов',
- email: 'ivan@example.com',
- preferences: { theme: 'dark' }
-});
-
-// Обновление данных
-const updatedUser = await encryptedDataService.saveData('users',
- { name: 'Иван Петров' },
- { id: 1 }
-);
-
-// Удаление данных
-await encryptedDataService.deleteData('users', { id: 1 });
-```
-
-#### **B. Проверка статуса шифрования**
-```javascript
-const status = await encryptedDataService.getEncryptionStatus();
-console.log('Статус шифрования:', status);
-// {
-// hasEncryptionKey: true,
-// encryptedTables: [
-// { table_name: 'users', encrypted_columns: '3' },
-// { table_name: 'messages', encrypted_columns: '2' }
-// ],
-// totalEncryptedColumns: 15
-// }
-```
-
-### **Шаг 4: Обновление существующих роутов**
-
-#### **Пример обновления роута пользователей:**
-```javascript
-// Было:
-router.get('/users', async (req, res) => {
- const { rows } = await db.getQuery()('SELECT * FROM users');
- res.json(rows);
-});
-
-// Стало:
-router.get('/users', async (req, res) => {
- try {
- const users = await encryptedDataService.getData('users');
- res.json(users);
- } catch (error) {
- res.status(500).json({ error: error.message });
- }
-});
-```
-
-#### **Пример обновления роута сообщений:**
-```javascript
-// Было:
-router.post('/messages', async (req, res) => {
- const { content, user_id } = req.body;
- const { rows } = await db.getQuery()(
- 'INSERT INTO messages (content, user_id) VALUES ($1, $2) RETURNING *',
- [content, user_id]
- );
- res.json(rows[0]);
-});
-
-// Стало:
-router.post('/messages', async (req, res) => {
- try {
- const { content, user_id } = req.body;
- const message = await encryptedDataService.saveData('messages', {
- content,
- user_id
- });
- res.json(message);
- } catch (error) {
- res.status(500).json({ error: error.message });
- }
-});
-```
-
-### **Шаг 5: Тестирование**
-```bash
-# Проверить работу зашифрованных данных
-curl -X GET http://localhost:8000/api/users
-curl -X POST http://localhost:8000/api/messages -H "Content-Type: application/json" -d '{"content":"Тестовое сообщение","user_id":1}'
-
-# Проверить расшифровку
-./decrypt-all-tables.sh
-```
-
-### **Шаг 6: Удаление незашифрованных колонок**
-```bash
-# ВНИМАНИЕ: Это необратимая операция!
-./remove-unencrypted-columns.sh
-```
-
-## 🔑 Управление ключами
-
-### **Ключ шифрования**
-- **Файл**: `./ssl/keys/full_db_encryption.key`
-- **Размер**: 32 байта (base64)
-- **Алгоритм**: AES-256-CBC
-
-### **Безопасность ключа**
-```bash
-# Права доступа
-chmod 600 ./ssl/keys/full_db_encryption.key
-
-# Резервная копия
-cp ./ssl/keys/full_db_encryption.key ./ssl/keys/full_db_encryption.key.backup
-
-# Проверка целостности
-sha256sum ./ssl/keys/full_db_encryption.key
-```
-
-## 🛡️ Дополнительные меры безопасности
-
-### **1. Шифрование томов Docker**
-```yaml
-# docker-compose.yml
-volumes:
- postgres_data:
- driver: local
- driver_opts:
- type: none
- o: bind
- device: /path/to/encrypted/storage
-```
-
-### **2. SSL/TLS для PostgreSQL**
-```yaml
-# docker-compose.yml
-services:
- postgres:
- command: >
- postgres
- -c ssl=on
- -c ssl_cert_file=/etc/ssl/certs/server.crt
- -c ssl_key_file=/etc/ssl/certs/server.key
-```
-
-### **3. Шифрование переменных окружения**
-```bash
-# Для оставшихся переменных окружения
-./encrypt-env.sh
-```
-
-## 🔍 Мониторинг и аудит
-
-### **Логирование доступа к зашифрованным данным**
-```javascript
-// В сервисе добавить логирование
-console.log(`🔐 Доступ к зашифрованным данным: ${tableName} в ${new Date().toISOString()}`);
-```
-
-### **Проверка целостности**
-```bash
-# Скрипт для проверки целостности зашифрованных данных
-./verify-encryption.sh
-```
-
-## ⚠️ Важные замечания
-
-### **1. Производительность**
-- Шифрование/расшифровка добавляет задержку
-- Используйте кэширование для часто используемых данных
-- Рассмотрите индексы для зашифрованных колонок
-
-### **2. Резервное копирование**
-- **Обязательно** делайте бэкап ключа шифрования
-- **Обязательно** делайте бэкап базы данных
-- Храните ключ отдельно от данных
-
-### **3. Восстановление**
-```bash
-# Восстановление из бэкапа
-docker exec dapp-postgres psql -U dapp_user -d dapp_db < backup.sql
-
-# Восстановление ключа
-cp ./ssl/keys/full_db_encryption.key.backup ./ssl/keys/full_db_encryption.key
-```
-
-### **4. Совместимость**
-- Приложение работает с зашифрованными и незашифрованными данными
-- Fallback на незашифрованные данные при отсутствии ключа
-- Постепенная миграция существующих данных
-
-## 🎯 Результат
-
-После применения полного шифрования:
-- ✅ ВСЕ текстовые данные зашифрованы в БД
-- ✅ Ключ шифрования хранится отдельно
-- ✅ Приложение работает с зашифрованными данными
-- ✅ Fallback на незашифрованные данные при отсутствии ключа
-- ✅ Универсальный сервис для работы с данными
-- ✅ Возможность ротации ключей
-
-**Максимальная безопасность данных достигнута!** 🔒
\ No newline at end of file
diff --git a/docs/FRONTEND_ARCHITECTURE.md b/docs/FRONTEND_ARCHITECTURE.md
deleted file mode 100644
index 481c956..0000000
--- a/docs/FRONTEND_ARCHITECTURE.md
+++ /dev/null
@@ -1,122 +0,0 @@
-
-
-# Архитектура фронтенда DLE
-
-## 📁 Структура сервисов
-
-### 🎯 Принцип разделения ответственности
-
-Каждый сервис отвечает за свою область функциональности:
-
-```
-services/
-├── dleV2Service.js - Основные функции DLE (создание, чтение, управление)
-├── modulesService.js - Управление модулями DLE
-├── proposalsService.js - Управление предложениями и голосованием
-├── tokensService.js - Работа с токенами и балансами
-├── analyticsService.js - Аналитические данные и статистика
-├── multichainService.js - Мультичейн функциональность
-└── index.js - Индексный файл для удобного импорта
-```
-
-### 🔧 Использование сервисов
-
-#### Импорт отдельных сервисов:
-```javascript
-import { getDLEInfo } from '@/services/dleV2Service.js';
-import { createAddModuleProposal } from '@/services/modulesService.js';
-import { createProposal } from '@/services/proposalsService.js';
-import { getTokenBalance } from '@/services/tokensService.js';
-```
-
-#### Импорт через индексный файл:
-```javascript
-import {
- getDLEInfo,
- createAddModuleProposal,
- createProposal,
- getTokenBalance
-} from '@/services/index.js';
-```
-
-## 📄 Страницы управления DLE
-
-### 🎨 Компоненты страниц:
-
-| Страница | Файл | Используемые сервисы | Описание |
-|----------|------|---------------------|----------|
-| **Модули** | `ModulesView.vue` | `modulesService.js` | Управление модулями DLE |
-| **Предложения** | `DleProposalsView.vue` | `proposalsService.js` | Управление предложениями |
-| **Токены** | `TokensView.vue` | `tokensService.js` | Работа с токенами |
-| **Кворум** | `QuorumView.vue` | `proposalsService.js` | Настройки голосования |
-| **Аналитика** | `AnalyticsView.vue` | `analyticsService.js` | Аналитические данные |
-| **История** | `HistoryView.vue` | `dleV2Service.js` | История операций |
-| **Настройки** | `SettingsView.vue` | `dleV2Service.js` | Настройки DLE |
-| **Управление DLE** | `DleManagementView.vue` | - | Добавление DLE в список |
-
-## 🔄 Архитектурные принципы
-
-### 1. **Разделение ответственности**
-- Каждый сервис отвечает за свою область
-- Функции не дублируются между сервисами
-- Четкие границы между модулями
-
-### 2. **Единообразие API**
-- Все сервисы используют одинаковый формат ответов
-- Единообразная обработка ошибок
-- Консистентные названия функций
-
-### 3. **Простота использования**
-- Интуитивно понятные названия функций
-- Подробная документация JSDoc
-- Примеры использования
-
-### 4. **Масштабируемость**
-- Легко добавлять новые функции
-- Простое тестирование отдельных модулей
-- Возможность переиспользования
-
-## 🛠️ Утилиты
-
-### `dle-contract.js`
-Используется только для транзакций через MetaMask:
-- Создание предложений
-- Голосование
-- Исполнение предложений
-- Деактивация DLE
-
-### `utils/websocket.js`
-Для real-time обновлений:
-- Уведомления о новых предложениях
-- Обновления статуса голосования
-- Синхронизация данных
-
-## 📊 Статистика кода
-
-| Сервис | Строк | Функций | Описание |
-|--------|-------|---------|----------|
-| `dleV2Service.js` | 220 | 8 | Основные функции DLE |
-| `modulesService.js` | 298 | 5 | Управление модулями |
-| `proposalsService.js` | 264 | 12 | Управление предложениями |
-| `tokensService.js` | 72 | 3 | Работа с токенами |
-| `analyticsService.js` | 320 | 16 | Аналитические данные |
-| `multichainService.js` | 353 | 18 | Мультичейн функциональность |
-
-## 🚀 Преимущества новой архитектуры
-
-1. **✅ Читаемость** - код легко понять и поддерживать
-2. **✅ Тестируемость** - каждый сервис можно тестировать отдельно
-3. **✅ Переиспользование** - функции можно использовать в разных компонентах
-4. **✅ Масштабируемость** - легко добавлять новые функции
-5. **✅ Производительность** - загрузка только нужных модулей
-6. **✅ Поддержка** - простое исправление ошибок и добавление функций
diff --git a/docs/MODULE_ARCHITECTURE.md b/docs/MODULE_ARCHITECTURE.md
deleted file mode 100644
index b78dff0..0000000
--- a/docs/MODULE_ARCHITECTURE.md
+++ /dev/null
@@ -1,135 +0,0 @@
-
-
-# Архитектура модулей DLE
-
-## Обзор
-
-DLE использует модульную архитектуру, где каждый модуль может иметь свои правила доступа и функциональность.
-
-## Типы модулей
-
-### 1. Простые модули (Вариант 1)
-Модули сами проверяют права доступа токен-холдеров.
-
-```solidity
-contract SimpleModule {
- address public dleContract;
-
- modifier onlyDLEHolders() {
- require(IERC20(dleContract).balanceOf(msg.sender) > 0, "Must hold DLE tokens");
- _;
- }
-
- function someFunction() external onlyDLEHolders {
- // Логика функции
- }
-}
-```
-
-### 2. Сложные модули (Вариант 3)
-Модули работают через основной контракт DLE.
-
-```solidity
-contract ComplexModule {
- address public dleContract;
-
- function executeOperation(address caller, bytes calldata operation) external {
- require(msg.sender == dleContract, "Only DLE can call");
- require(IERC20(dleContract).balanceOf(caller) > 0, "Must hold tokens");
-
- // Выполняем операцию
- _executeOperation(caller, operation);
- }
-}
-```
-
-## Рекомендации по выбору
-
-### Используйте Вариант 1 для:
-- ✅ Простых операций (чтение данных)
-- ✅ Модулей с минимальной логикой
-- ✅ Быстрых операций
-
-### Используйте Вариант 3 для:
-- ✅ Сложных финансовых операций
-- ✅ Модулей с критической логикой
-- ✅ Операций, требующих аудита
-
-## Примеры модулей
-
-### TreasuryModule (Казна)
-```solidity
-contract TreasuryModule {
- address public dleContract;
- mapping(address => bool) public supportedTokens;
-
- modifier onlyDLEHolders() {
- require(IERC20(dleContract).balanceOf(msg.sender) > 0, "Must hold DLE tokens");
- _;
- }
-
- function depositToken(address token, uint256 amount) external onlyDLEHolders {
- require(supportedTokens[token], "Token not supported");
- IERC20(token).transferFrom(msg.sender, address(this), amount);
- }
-
- function withdrawToken(address token, uint256 amount) external onlyDLEHolders {
- require(supportedTokens[token], "Token not supported");
- IERC20(token).transfer(msg.sender, amount);
- }
-}
-```
-
-### GovernanceModule (Управление)
-```solidity
-contract GovernanceModule {
- address public dleContract;
-
- function executeOperation(address caller, bytes calldata operation) external {
- require(msg.sender == dleContract, "Only DLE can call");
- require(IERC20(dleContract).balanceOf(caller) > 0, "Must hold tokens");
-
- // Выполняем операцию управления
- _executeGovernanceOperation(caller, operation);
- }
-}
-```
-
-## Безопасность
-
-### Общие принципы:
-1. **Всегда проверяйте** баланс токенов DLE
-2. **Валидируйте входные данные** в модулях
-3. **Используйте ReentrancyGuard** для финансовых операций
-4. **Логируйте важные операции** через события
-
-### Аудит модулей:
-- Проверяйте права доступа
-- Тестируйте граничные случаи
-- Валидируйте входные параметры
-- Проверяйте обработку ошибок
-
-# Модульная архитектура (обновление для DLE v2)
-
-- Модули выносятся в отдельные контракты: `TreasuryModule`, `TimelockModule`, `DeactivationModule`, `CommunicationModule`.
-- Подключение/отключение модулей — строго через предложения DLE (`ModuleAdded`/`ModuleRemoved`).
-- Исполнение модульных операций инициируется основным DLE через `_executeOperation` по безопасному `operationCalldata`.
-- Денежные переводы из ядра исключены: все токено‑операции внутри `TreasuryModule`.
-- Таймлок применяется на уровне предложения: `timelockHours` хранится в `Proposal` и проверяется при исполнении.
-- Для оффчейн действий ядро эмитит событие `OffchainAction`, которое подписывает и обрабатывает бекенд/клиент.
-
-Последовательность для казначейской операции:
-1) Создание предложения с типом операции и параметрами, указание `governanceChainId`, `targetChains`, `timelockHours`.
-2) Сбор голосов в выбранной сети (снапшоты ERC20Votes).
-3) По наступлению timelock — `executeProposalBySignatures` в целевых сетях с проверкой EIP‑712 подписей и «100% или ничего».
-4) Ядро вызывает `TreasuryModule` по `abi.encodeWithSelector(...)`.
\ No newline at end of file
diff --git a/docs/MODULE_DEPLOYMENT_IMPROVEMENTS.md b/docs/MODULE_DEPLOYMENT_IMPROVEMENTS.md
deleted file mode 100644
index bfb4237..0000000
--- a/docs/MODULE_DEPLOYMENT_IMPROVEMENTS.md
+++ /dev/null
@@ -1,630 +0,0 @@
-
-
-# Улучшения системы деплоя и управления модулями DLE
-
-## Описание задачи
-
-Пользователь хочет улучшить процесс деплоя и управления модулями DLE, чтобы обеспечить автоматическую инициализацию и верификацию модулей во всех выбранных пользователем блокчейн-сетях.
-
-## Текущая ситуация
-
-### Что уже работает:
-- ✅ Деплой основного DLE контракта в 4 сетях с одинаковым адресом (через CREATE2)
-- ✅ Деплой модулей (Treasury, Timelock, Reader) в каждой сети
-- ✅ Модули инициализируются только через governance предложения
-- ✅ Верификация контрактов в каждой сети
-- ✅ Отображение модулей в виде карточек с адресами во всех сетях
-
-### Проблемы:
-- ❌ Если деплой модулей в одной сети падает, инициализация не происходит
-- ❌ Нет механизма повторной инициализации модулей
-- ❌ Нет проверки статуса инициализации перед деплоем
-- ❌ Верификация может падать из-за таймаутов блокчейн-эксплореров
-- ❌ Нет удобного интерфейса для управления модулями
-
-## Требования пользователя
-
-### 1. Workflow деплоя
-**Цель:** При заполнении формы и нажатии на кнопку "Деплой" пользователь должен получить:
-- Основной смарт-контракт DLE
-- 3 модуля (Treasury, Timelock, Reader)
-- Модули должны быть **сразу инициализированы** во всех выбранных сетях
-- Модули должны быть **сразу верифицированы** во всех выбранных сетях
-
-### 2. Отображение модулей
-**Текущее состояние:** ✅ Уже реализовано
-- Одна карточка для каждого модуля
-- В карточке показаны адреса модуля во всех сетях
-- Статус верификации для каждой сети
-- Кнопка "Настроить" для перехода к настройкам модуля
-
-### 3. Управление модулями
-**Требования:**
-- Кнопка "Настроить" должна открывать страницу с блоками для настройки модулей
-- Возможность управления модулями через веб-интерфейс
-- Отображение статуса инициализации и верификации
-
-## Реализованные улучшения
-
-### 1. Backend API Endpoints
-
-#### `/api/dle-modules/initialize-modules-all-networks`
-**Назначение:** Автоматическая инициализация всех модулей во всех поддерживаемых сетях
-
-**Параметры:**
-```json
-{
- "dleAddress": "0x...",
- "privateKey": "0x..."
-}
-```
-
-**Функциональность:**
-- Получает список поддерживаемых сетей из DLE контракта
-- Проверяет статус инициализации в каждой сети
-- Если модули не инициализированы, создает governance предложения для их добавления
-- Возвращает детальный отчет по каждой сети
-
-**Возвращаемые статусы:**
-- `success` - модули успешно инициализированы
-- `already_initialized` - модули уже инициализированы
-- `modules_not_deployed` - не все модули задеплоены
-- `error` - ошибка инициализации
-
-#### `/api/dle-modules/verify-modules-all-networks`
-**Назначение:** Автоматическая верификация всех модулей во всех поддерживаемых сетях
-
-**Параметры:**
-```json
-{
- "dleAddress": "0x...",
- "privateKey": "0x..."
-}
-```
-
-**Функциональность:**
-- Получает адреса всех модулей в каждой сети
-- Отправляет запросы на верификацию в Etherscan/блокчейн-эксплореры
-- Использует стандартный JSON input для верификации
-- Возвращает детальный отчет по каждому модулю в каждой сети
-
-**Возвращаемые статусы:**
-- `success` - модуль успешно верифицирован
-- `failed` - ошибка верификации
-- `not_deployed` - модуль не задеплоен
-- `error` - ошибка процесса верификации
-
-### 2. Frontend Service Functions
-
-#### `initializeModulesAllNetworks(dleAddress, privateKey)`
-**Назначение:** Вызов API для инициализации модулей
-
-#### `verifyModulesAllNetworks(dleAddress, privateKey)`
-**Назначение:** Вызов API для верификации модулей
-
-### 3. Улучшенный интерфейс модулей
-
-#### Обновленная карточка модуля:
-- **Основные действия:** Кнопка "Настроить" (приоритетная)
-- **Дополнительные действия:** Удалить/Активировать модуль
-- **Верификация:** Отдельные кнопки для каждой сети
-
-#### Новые стили:
-- Группировка кнопок по функциональности
-- Улучшенная компоновка элементов
-- Адаптивный дизайн для разных размеров экрана
-
-## Предлагаемый Workflow (Поэтапный подход с повторами)
-
-### Этап 1: Деплой основного DLE контракта
-```bash
-# Деплой только DLE контракта во всех выбранных сетях
-npx hardhat run scripts/deploy/deploy-dle-only.js
-```
-
-### Этап 2: Проверка успеха деплоя DLE (с повторами)
-```javascript
-POST /api/dle-modules/check-dle-deployment-status
-{
- "dleAddress": "0x...",
- "chainIds": [11155111, 17000, 421614, 84532],
- "maxRetries": 5,
- "retryDelay": 30000
-}
-```
-**Логика повторов:**
-- Если не все сети успешны → ждем 30 сек → повторяем проверку
-- Максимум 5 попыток
-- Если после 5 попыток не все сети готовы → ошибка
-
-### Этап 3: Верификация DLE контракта (с повторами)
-```javascript
-POST /api/dle-modules/verify-dle-all-networks
-{
- "dleAddress": "0x...",
- "privateKey": "0x...",
- "maxRetries": 3,
- "retryDelay": 60000
-}
-```
-**Логика повторов:**
-- Если верификация не удалась → ждем 60 сек → повторяем
-- Максимум 3 попытки
-- Etherscan может быть перегружен, поэтому больше времени между попытками
-
-### Этап 4: Деплой модуля 1 (TreasuryModule) (с повторами)
-```javascript
-POST /api/dle-modules/deploy-module-all-networks
-{
- "dleAddress": "0x...",
- "moduleType": "treasury",
- "privateKey": "0x...",
- "maxRetries": 3,
- "retryDelay": 45000
-}
-```
-**Логика повторов:**
-- Если деплой в какой-то сети упал → ждем 45 сек → повторяем только для неудачных сетей
-- Максимум 3 попытки
-- Gas price может быть высоким, поэтому больше времени между попытками
-
-### Этап 5: Проверка успеха деплоя TreasuryModule (с повторами)
-```javascript
-POST /api/dle-modules/check-module-deployment-status
-{
- "dleAddress": "0x...",
- "moduleType": "treasury",
- "chainIds": [11155111, 17000, 421614, 84532],
- "maxRetries": 5,
- "retryDelay": 30000
-}
-```
-
-### Этап 6: Верификация TreasuryModule (с повторами)
-```javascript
-POST /api/dle-modules/verify-module-all-networks
-{
- "dleAddress": "0x...",
- "moduleType": "treasury",
- "privateKey": "0x...",
- "maxRetries": 3,
- "retryDelay": 60000
-}
-```
-
-### Этап 7: Инициализация TreasuryModule (с повторами)
-```javascript
-POST /api/dle-modules/initialize-module-all-networks
-{
- "dleAddress": "0x...",
- "moduleType": "treasury",
- "privateKey": "0x...",
- "maxRetries": 3,
- "retryDelay": 30000
-}
-```
-**Логика повторов:**
-- Если инициализация упала → ждем 30 сек → повторяем
-- Максимум 3 попытки
-- Network congestion может влиять на транзакции
-
-### Этап 8: Деплой модуля 2 (TimelockModule)
-```javascript
-POST /api/dle-modules/deploy-module-all-networks
-{
- "dleAddress": "0x...",
- "moduleType": "timelock",
- "privateKey": "0x..."
-}
-```
-
-### Этап 9: Проверка успеха деплоя TimelockModule
-```javascript
-POST /api/dle-modules/check-module-deployment-status
-{
- "dleAddress": "0x...",
- "moduleType": "timelock",
- "chainIds": [11155111, 17000, 421614, 84532]
-}
-```
-
-### Этап 10: Верификация TimelockModule
-```javascript
-POST /api/dle-modules/verify-module-all-networks
-{
- "dleAddress": "0x...",
- "moduleType": "timelock",
- "privateKey": "0x..."
-}
-```
-
-### Этап 11: Инициализация TimelockModule
-```javascript
-POST /api/dle-modules/initialize-module-all-networks
-{
- "dleAddress": "0x...",
- "moduleType": "timelock",
- "privateKey": "0x..."
-}
-```
-
-### Этап 12: Деплой модуля 3 (DLEReader)
-```javascript
-POST /api/dle-modules/deploy-module-all-networks
-{
- "dleAddress": "0x...",
- "moduleType": "reader",
- "privateKey": "0x..."
-}
-```
-
-### Этап 13: Проверка успеха деплоя DLEReader
-```javascript
-POST /api/dle-modules/check-module-deployment-status
-{
- "dleAddress": "0x...",
- "moduleType": "reader",
- "chainIds": [11155111, 17000, 421614, 84532]
-}
-```
-
-### Этап 14: Верификация DLEReader
-```javascript
-POST /api/dle-modules/verify-module-all-networks
-{
- "dleAddress": "0x...",
- "moduleType": "reader",
- "privateKey": "0x..."
-}
-```
-
-### Этап 15: Инициализация DLEReader
-```javascript
-POST /api/dle-modules/initialize-module-all-networks
-{
- "dleAddress": "0x...",
- "moduleType": "reader",
- "privateKey": "0x..."
-}
-```
-
-### Этап 16: Финальная инициализация всех модулей
-```javascript
-POST /api/dle-modules/initialize-base-modules-all-networks
-{
- "dleAddress": "0x...",
- "privateKey": "0x..."
-}
-```
-
-### Этап 17: Финальная проверка и отображение
-```javascript
-POST /api/dle-modules/final-deployment-check
-{
- "dleAddress": "0x...",
- "chainIds": [11155111, 17000, 421614, 84532]
-}
-```
-**Логика финальной проверки:**
-- Проверяем, что DLE задеплоен во всех сетях
-- Проверяем, что все модули задеплоены во всех сетях
-- Проверяем, что все модули верифицированы во всех сетях
-- Проверяем, что все модули инициализированы во всех сетях
-
-**Только если ВСЕ проверки пройдены:**
-- ✅ Карточки DLE и модулей появляются в интерфейсе
-- ✅ Пользователь может управлять модулями
-- ✅ Все функции доступны
-
-**Если хотя бы одна проверка не пройдена:**
-- ❌ Карточки НЕ отображаются
-- ❌ Показывается статус "Деплой в процессе" или "Деплой не завершен"
-- ❌ Предлагается продолжить деплой или исправить ошибки
-
-## Логика отображения интерфейса
-
-### Состояния деплоя:
-
-#### 1. **Деплой не начат**
-```javascript
-// Интерфейс показывает:
-- Форму деплоя DLE
-- Кнопку "Начать деплой"
-- Нет карточек модулей
-```
-
-#### 2. **Деплой в процессе**
-```javascript
-// Интерфейс показывает:
-- Прогресс-бар с текущим этапом
-- Логи выполнения в реальном времени
-- Кнопку "Остановить деплой" (опционально)
-- Нет карточек модулей
-```
-
-#### 3. **Деплой частично завершен (ошибка)**
-```javascript
-// Интерфейс показывает:
-- Статус "Деплой не завершен"
-- Список успешных этапов
-- Список неудачных этапов с ошибками
-- Кнопки "Продолжить деплой" или "Начать заново"
-- Нет карточек модулей
-```
-
-#### 4. **Деплой полностью завершен**
-```javascript
-// Интерфейс показывает:
-- ✅ Карточки DLE и всех модулей
-- ✅ Все функции управления доступны
-- ✅ Кнопки "Настроить" для каждого модуля
-- ✅ Статус "Деплой успешно завершен"
-```
-
-### API для проверки статуса деплоя:
-```javascript
-POST /api/dle-modules/get-deployment-status
-{
- "dleAddress": "0x..."
-}
-
-// Возвращает:
-{
- "status": "completed|in_progress|failed|not_started",
- "currentStage": "deploy_dle|verify_dle|deploy_treasury|...",
- "completedStages": ["deploy_dle", "verify_dle"],
- "failedStages": [],
- "progress": 85, // процент завершения
- "canShowCards": false, // только true если status === "completed"
- "errors": [],
- "nextAction": "continue_deployment|restart_deployment|none"
-}
-```
-
-## Логика повторов
-
-### Общие принципы:
-1. **Каждый этап повторяется до успеха** или до исчерпания попыток
-2. **Разные задержки** для разных типов операций:
- - Проверки: 30 сек (быстрые операции)
- - Деплой: 45 сек (gas price может измениться)
- - Верификация: 60 сек (Etherscan может быть перегружен)
- - Инициализация: 30 сек (network congestion)
-
-3. **Умные повторы:**
- - Если операция частично успешна → повторяем только для неудачных сетей
- - Если операция полностью провалилась → повторяем для всех сетей
- - Логируем каждую попытку для диагностики
-
-4. **Критические ошибки:**
- - Если после всех попыток операция не удалась → останавливаем весь процесс
- - Показываем детальный отчет о том, что не удалось
- - Предлагаем варианты решения (повторить, пропустить, откатиться)
-
-### Пример логики повторов:
-```javascript
-async function executeWithRetries(operation, maxRetries, retryDelay) {
- for (let attempt = 1; attempt <= maxRetries; attempt++) {
- try {
- const result = await operation();
-
- // Проверяем, все ли сети успешны
- const failedNetworks = result.filter(r => r.status !== 'success');
-
- if (failedNetworks.length === 0) {
- console.log(`✅ Операция успешна с попытки ${attempt}`);
- return result;
- }
-
- if (attempt < maxRetries) {
- console.log(`⚠️ Попытка ${attempt} частично успешна. Повторяем через ${retryDelay}мс...`);
- console.log(`Неудачные сети: ${failedNetworks.map(n => n.networkName).join(', ')}`);
- await sleep(retryDelay);
- }
-
- } catch (error) {
- if (attempt < maxRetries) {
- console.log(`❌ Попытка ${attempt} провалилась: ${error.message}`);
- console.log(`Повторяем через ${retryDelay}мс...`);
- await sleep(retryDelay);
- } else {
- throw new Error(`Операция провалилась после ${maxRetries} попыток: ${error.message}`);
- }
- }
- }
-}
-```
-
-## Преимущества поэтапного подхода
-
-### 1. Максимальная надежность
-- ✅ **Проверка на каждом этапе** - если что-то пошло не так, процесс останавливается
-- ✅ **Изоляция ошибок** - проблема с одним модулем не влияет на другие
-- ✅ **Возможность восстановления** - можно продолжить с места остановки
-- ✅ **Детальная диагностика** - точно знаем, на каком этапе произошла ошибка
-- ✅ **Автоматические повторы** - временные проблемы решаются автоматически
-- ✅ **Устойчивость к сбоям** - network congestion, gas spikes, Etherscan overload
-
-### 2. Гибкость управления
-- ✅ **Выборочный деплой** - можно деплоить только нужные модули
-- ✅ **Повторные попытки** - можно повторить только неудачный этап
-- ✅ **Параллельная работа** - разные модули можно деплоить независимо
-- ✅ **Контроль качества** - верификация после каждого деплоя
-
-### 3. Улучшенная диагностика
-- ✅ **Пошаговые логи** - детальная информация о каждом этапе
-- ✅ **Статусы в реальном времени** - видно прогресс выполнения
-- ✅ **Обработка ошибок** - понятные сообщения об ошибках
-- ✅ **История операций** - можно отследить все выполненные действия
-
-### 4. Масштабируемость
-- ✅ **Легко добавить новые модули** - просто добавить новые этапы
-- ✅ **Поддержка новых сетей** - автоматически работает для всех сетей
-- ✅ **Модульная архитектура** - каждый endpoint независим
-- ✅ **Расширяемость** - легко добавить новые типы операций
-
-### 5. Безопасность
-- ✅ **Постепенное развертывание** - минимизация рисков
-- ✅ **Проверка перед выполнением** - валидация на каждом этапе
-- ✅ **Откат изменений** - можно отменить неудачные операции
-- ✅ **Аудит операций** - полная история всех действий
-
-## Пример использования поэтапного подхода
-
-### Сценарий: Деплой DLE с модулями в 4 сетях
-
-```javascript
-// 1. Деплой DLE контракта
-const dleResult = await deployDLE({
- networks: [11155111, 17000, 421614, 84532],
- privateKey: "0x...",
- params: { name: "My DLE", symbol: "MDLE" }
-});
-
-// 2. Проверка деплоя DLE
-const dleStatus = await checkDLEStatus(dleResult.address, [11155111, 17000, 421614, 84532]);
-if (!dleStatus.allDeployed) {
- throw new Error("DLE не задеплоен во всех сетях");
-}
-
-// 3. Верификация DLE
-const dleVerification = await verifyDLE(dleResult.address, "0x...");
-console.log("DLE верификация:", dleVerification);
-
-// 4. Деплой TreasuryModule
-const treasuryResult = await deployModule("treasury", dleResult.address, "0x...");
-
-// 5. Проверка деплоя TreasuryModule
-const treasuryStatus = await checkModuleStatus("treasury", dleResult.address, [11155111, 17000, 421614, 84532]);
-if (!treasuryStatus.allDeployed) {
- throw new Error("TreasuryModule не задеплоен во всех сетях");
-}
-
-// 6. Верификация TreasuryModule
-const treasuryVerification = await verifyModule("treasury", dleResult.address, "0x...");
-console.log("TreasuryModule верификация:", treasuryVerification);
-
-// 7. Инициализация TreasuryModule
-const treasuryInit = await initializeModule("treasury", dleResult.address, "0x...");
-console.log("TreasuryModule инициализация:", treasuryInit);
-
-// 8-15. Повторяем для TimelockModule и DLEReader...
-
-// 16. Создание governance предложений для добавления модулей
-const addTreasuryProposal = await createAddModuleProposal(dleResult.address, treasuryAddress, "Treasury Module");
-const addTimelockProposal = await createAddModuleProposal(dleResult.address, timelockAddress, "Timelock Module");
-const addReaderProposal = await createAddModuleProposal(dleResult.address, readerAddress, "Reader Module");
-console.log("Governance предложения созданы:", { addTreasuryProposal, addTimelockProposal, addReaderProposal });
-```
-
-### Обработка ошибок
-
-```javascript
-try {
- // Деплой модуля
- const result = await deployModule("treasury", dleAddress, privateKey);
-
- // Проверка успеха
- const status = await checkModuleStatus("treasury", dleAddress, chainIds);
-
- if (status.errors.length > 0) {
- console.log("Ошибки деплоя:", status.errors);
- // Можно повторить только для сетей с ошибками
- const retryResult = await deployModule("treasury", dleAddress, privateKey, status.errorChains);
- }
-
-} catch (error) {
- console.error("Критическая ошибка:", error);
- // Логирование и уведомление пользователя
-}
-```
-
-## Следующие шаги
-
-### 1. Реализация новых API endpoints
-- `check-dle-deployment-status` - проверка деплоя DLE
-- `check-module-deployment-status` - проверка деплоя модуля
-- `deploy-module-all-networks` - деплой одного модуля
-- `verify-dle-all-networks` - верификация DLE
-- `verify-module-all-networks` - верификация модуля
-- `initialize-module-all-networks` - инициализация модуля
-- `initialize-base-modules-all-networks` - финальная инициализация
-
-### 2. Веб-интерфейс для поэтапного деплоя
-- Мастер деплоя с пошаговым интерфейсом
-- Прогресс-бар для каждого этапа
-- Обработка ошибок и повторные попытки
-- Логи операций в реальном времени
-
-### 3. Интеграция с существующей формой деплоя
-- Добавить опцию "Поэтапный деплой"
-- Автоматическое выполнение всех этапов
-- Уведомления о статусе каждого этапа
-
-### 4. Мониторинг и логирование
-- Детальные логи всех операций
-- История деплоев и их статусов
-- Алерты при ошибках
-- Метрики производительности
-
-## Технические детали
-
-### Поддерживаемые сети:
-- Sepolia (Chain ID: 11155111)
-- Holesky (Chain ID: 17000)
-- Arbitrum Sepolia (Chain ID: 421614)
-- Base Sepolia (Chain ID: 84532)
-
-### Модули:
-- **TreasuryModule** - управление финансами
-- **TimelockModule** - задержки исполнения
-- **DLEReader** - чтение данных DLE
-
-### API Endpoints:
-
-#### Основные endpoints (уже реализованы):
-- `POST /api/dle-modules/initialize-modules-all-networks` - инициализация всех модулей
-- `POST /api/dle-modules/verify-modules-all-networks` - верификация всех модулей
-- `POST /api/dle-modules/get-all-modules` - получение списка модулей
-- `POST /api/dle-modules/get-networks-info` - информация о сетях
-
-#### Новые endpoints (требуют реализации):
-
-**Проверка статуса деплоя:**
-- `POST /api/dle-modules/check-dle-deployment-status` - проверка деплоя DLE контракта
-- `POST /api/dle-modules/check-module-deployment-status` - проверка деплоя конкретного модуля
-
-**Деплой модулей:**
-- `POST /api/dle-modules/deploy-module-all-networks` - деплой одного модуля во всех сетях
-
-**Верификация:**
-- `POST /api/dle-modules/verify-dle-all-networks` - верификация DLE контракта
-- `POST /api/dle-modules/verify-module-all-networks` - верификация одного модуля
-
-**Инициализация:**
-- `POST /api/dle-modules/initialize-module-all-networks` - инициализация одного модуля
-- `POST /api/dle-modules/initialize-base-modules-all-networks` - финальная инициализация всех модулей
-
-**Управление отображением:**
-- `POST /api/dle-modules/final-deployment-check` - финальная проверка готовности
-- `POST /api/dle-modules/get-deployment-status` - получение статуса деплоя
-
-## Заключение
-
-Реализованные улучшения обеспечивают:
-1. **Полную автоматизацию** процесса деплоя модулей
-2. **Надежность** через проверки статуса и обработку ошибок
-3. **Удобство использования** через улучшенный интерфейс
-4. **Масштабируемость** для добавления новых сетей и модулей
-
-Пользователь теперь может одним кликом развернуть полностью функциональный DLE с инициализированными и верифицированными модулями во всех выбранных сетях.
diff --git a/docs/MODULE_OPERATIONS_INTEGRATION.md b/docs/MODULE_OPERATIONS_INTEGRATION.md
deleted file mode 100644
index 71c05d9..0000000
--- a/docs/MODULE_OPERATIONS_INTEGRATION.md
+++ /dev/null
@@ -1,151 +0,0 @@
-# Интеграция динамических операций модулей в CreateProposalView
-
-## Обзор
-
-Реализована система автоматического отображения блоков с предложениями операций модулей в реальном времени на странице создания предложений (`/management/create-proposal`). После деплоя модуля карточки с операциями автоматически появляются без необходимости обновления страницы.
-
-## Архитектура решения
-
-### 1. Backend API Endpoints
-
-Добавлены новые API endpoints в `/backend/routes/dleModules.js`:
-
-- `POST /dle-modules/get-module-operations` - получение всех доступных операций модулей для DLE
-- `POST /dle-modules/get-module-specific-operations` - получение операций конкретного модуля
-- `POST /dle-modules/get-module-interface` - получение ABI и интерфейса модуля
-- `POST /dle-modules/get-module-available-functions` - получение доступных функций модуля
-- `POST /dle-modules/get-module-function-parameters` - получение параметров функции модуля
-- `POST /dle-modules/create-module-operation-proposal` - создание предложения для операции модуля
-- `POST /dle-modules/validate-module-operation` - валидация операции модуля
-
-### 2. Frontend Services
-
-Создан новый сервис `/frontend/src/services/moduleOperationsService.js` с функциями:
-
-- `getModuleOperations(dleAddress)` - получение операций модулей
-- `getModuleSpecificOperations(dleAddress, moduleType, moduleAddress, chainId)` - операции конкретного модуля
-- `createModuleOperationProposal(dleAddress, operationData)` - создание предложения
-- `getModuleInterface(moduleType, moduleAddress, chainId)` - получение интерфейса
-- `validateModuleOperation(dleAddress, operationData)` - валидация операции
-
-### 3. WebSocket Integration
-
-#### Backend (wsHub.js)
-- Добавлена функция `broadcastModulesUpdate(dleAddress, updateType, moduleData)` для отправки уведомлений об обновлениях модулей
-- Уведомления отправляются при обнаружении новых модулей в файлах деплоя
-
-#### Frontend (CreateProposalView.vue)
-- Подключение к WebSocket при монтировании компонента
-- Обработка сообщений: `modules_updated`, `module_verified`, `module_status_changed`
-- Автоматическое обновление списка операций при получении уведомлений
-
-### 4. Динамическое отображение
-
-#### Состояние компонента
-```javascript
-const moduleOperations = ref([]);
-const isLoadingModuleOperations = ref(false);
-const modulesWebSocket = ref(null);
-const isModulesWSConnected = ref(false);
-```
-
-#### Шаблон
-- Условное отображение индикатора загрузки
-- Динамическое создание блоков операций для каждого модуля
-- Анимация появления новых блоков
-
-## Поддерживаемые типы модулей и операции
-
-### 1. Treasury Module (💰)
-- **Депозит средств** - пополнение казначейства DLE
-- **Вывод средств** - вывод средств из казначейства
-- **Распределение дивидендов** - распределение дивидендов между держателями токенов
-
-### 2. Timelock Module (⏰)
-- **Установить задержку** - установить время задержки для операций
-- **Поставить операцию в очередь** - добавить операцию в очередь для выполнения
-
-### 3. Reader Module (📖)
-- **Обновить данные** - обновить информацию о DLE
-
-### 4. Hierarchical Voting Module (🗳️)
-- **Голосование во внешнем DLE** - использовать токены для голосования в другом DLE
-
-## Реальный процесс работы
-
-1. **Деплой модуля** → Backend сохраняет информацию в файлы деплоя
-2. **Обнаружение модуля** → `getDeployedModulesInfo()` читает файлы и находит новые модули
-3. **WebSocket уведомление** → `broadcastModulesUpdate()` отправляет уведомление клиентам
-4. **Обновление UI** → Frontend получает уведомление и автоматически загружает новые операции
-5. **Отображение блоков** → Новые блоки операций появляются с анимацией
-
-## Стили и UX
-
-### Визуальные особенности
-- Отдельные стили для блоков операций модулей (`.module-operation-block`)
-- Цветовая схема с зеленым акцентом для модулей
-- Теги категорий операций
-- Анимация появления (`fadeInUp`)
-- Индикатор загрузки с анимацией
-
-### Адаптивность
-- Responsive grid для блоков операций
-- Поддержка мобильных устройств
-- Адаптивные размеры и отступы
-
-## Технические детали
-
-### WebSocket Events
-```javascript
-// Подписка на обновления
-{
- type: 'subscribe',
- dleAddress: '0x...'
-}
-
-// Уведомления
-{
- type: 'modules_updated',
- dleAddress: '0x...',
- moduleData: { modulesCount: 3, moduleTypes: ['treasury', 'timelock'] },
- timestamp: 1234567890
-}
-```
-
-### Структура данных операций
-```javascript
-{
- id: 'deposit',
- name: 'Депозит средств',
- description: 'Пополнение казначейства DLE',
- icon: '💰',
- functionName: 'deposit',
- parameters: [
- { name: 'amount', type: 'uint256', label: 'Сумма', required: true }
- ],
- category: 'Финансы'
-}
-```
-
-## Будущие улучшения
-
-1. **Полные формы создания предложений** - замена alert на полноценные модальные окна
-2. **Валидация параметров** - клиентская валидация перед отправкой
-3. **Предпросмотр операций** - отображение calldata перед созданием предложения
-4. **История операций** - показ выполненных операций модулей
-5. **Расширенная фильтрация** - фильтры по типам операций и модулей
-
-## Файлы изменений
-
-### Новые файлы
-- `frontend/src/services/moduleOperationsService.js`
-- `docs/MODULE_OPERATIONS_INTEGRATION.md`
-
-### Измененные файлы
-- `frontend/src/views/smartcontracts/CreateProposalView.vue`
-- `backend/routes/dleModules.js`
-- `backend/wsHub.js`
-
-## Заключение
-
-Реализована полноценная система динамического отображения операций модулей с реальным временем обновлений через WebSocket. После деплоя модуля пользователи сразу видят доступные операции без необходимости обновления страницы, что значительно улучшает пользовательский опыт.
diff --git a/docs/RAG_TASKS.md b/docs/RAG_TASKS.md
deleted file mode 100644
index 63ae0cc..0000000
--- a/docs/RAG_TASKS.md
+++ /dev/null
@@ -1,462 +0,0 @@
-
-
-# Внедрение RAG-ассистента: поэтапный план
-
----
-
-## Особенности проекта: разнообразие клиентов, каналов и данных
-
-- **Клиенты:**
- - Различные сегменты: B2B, B2C, VIP, оптовые и розничные покупатели, корпоративные клиенты, частные лица и др.
- - Различные сценарии взаимодействия (покупка, поддержка, консультация, возврат и т.д.).
-
-- **Каналы коммуникации:**
- - Веб-чат
- - Email
- - Telegram/мессенджеры
- - Возможна интеграция с другими каналами (WhatsApp, телефон и др.)
-
-- **Типы данных:**
- - Текстовые сообщения
- - Аудио, видео, изображения (мультимодальные данные)
- - Вложения (документы, сканы, фото товаров и т.д.)
-
-- **Языки:**
- - Русский
- - Английский
- - Испанский
- - Китайский
- - Возможность расширения на другие языки
-
-- **Товары и услуги:**
- - Широкий ассортимент товаров (разные категории, бренды, характеристики)
- - Различные услуги (консультации, сервис, доставка, гарантия, возврат и др.)
- - Возможность кросс-продаж и рекомендаций
-
-- **Требования к RAG:**
- - Гибкая фильтрация знаний по сегменту клиента, языку, категории товара/услуги, каналу обращения
- - Поддержка мультиязычности и мультимодальности
- - Масштабируемость для добавления новых ассистентов, сегментов, каналов и языков
-
----
-
-## Многоагентная архитектура AI-ассистента
-
-### 🎯 Главный AI-координатор
-- **Роль:** Анализирует входящие сообщения и координирует работу специализированных агентов
-- **Функции:**
- - Определяет какие агенты нужны для обработки сообщения
- - Собирает результаты от всех агентов
- - Генерирует финальный персонализированный ответ
- - Управляет контекстом беседы
-
-### 🤖 Специализированные агенты
-
-#### 1. Агент "Персонализация пользователя"
-- **Задача:** Извлечение и управление персональными данными
-- **Функции:**
- - Извлекает имя из сообщений ("меня зовут Саша")
- - Анализирует профиль пользователя (компания, должность, предпочтения)
- - Отслеживает историю взаимодействий
- - Определяет стадию в воронке продаж
-- **Результат:** Персонализированный контекст для ответа
-
-#### 2. Агент "Анализ запроса"
-- **Задача:** Классификация и понимание сути обращения
-- **Функции:**
- - Определяет тип вопроса (техническая проблема, вопрос о цене, жалоба)
- - Анализирует эмоциональное состояние клиента
- - Выявляет скрытые потребности
- - Определяет приоритетность запроса
-- **Результат:** Структурированный анализ запроса
-
-#### 3. Агент "RAG поиск"
-- **Задача:** Поиск релевантной информации в базе знаний
-- **Функции:**
- - Векторный поиск по RAG базе
- - Фильтрация по тегам пользователя
- - Поиск похожих случаев и решений
- - Извлечение контекстной информации
-- **Результат:** Релевантные ответы и шаблоны
-
-#### 4. Агент "Контекст беседы"
-- **Задача:** Анализ истории взаимодействий
-- **Функции:**
- - Изучает предыдущие сообщения в беседе
- - Анализирует все предыдущие обращения пользователя
- - Определяет повторяющиеся темы и проблемы
- - Отслеживает прогресс в решении задач
-- **Результат:** Контекстная картина взаимодействия
-
-#### 5. Агент "Детализация"
-- **Задача:** Выяснение недостающей информации
-- **Функции:**
- - Формулирует уточняющие вопросы
- - Определяет какие детали нужны для решения
- - Адаптирует вопросы под контекст беседы
- - Отслеживает ответы на уточняющие вопросы
-- **Результат:** Структурированные уточняющие вопросы
-
-#### 6. Агент "Персонализация ответа"
-- **Задача:** Адаптация ответа под конкретного пользователя
-- **Функции:**
- - Учитывает стиль общения пользователя
- - Адаптирует тон (формальный/неформальный)
- - Использует имя и персональные данные
- - Ссылается на предыдущие взаимодействия
-- **Результат:** Персонализированный ответ
-
-#### 7. Агент "Мультиязычность"
-- **Задача:** Обработка многоязычных запросов
-- **Функции:**
- - Определяет язык входящего сообщения
- - Ищет ответы на соответствующем языке
- - Генерирует ответы на языке пользователя
- - Адаптирует культурные особенности
-- **Результат:** Локализованный ответ
-
-#### 8. Агент "Мультимодальность"
-- **Задача:** Обработка различных типов контента
-- **Функции:**
- - Анализ изображений, аудио, видео
- - Извлечение текста из медиафайлов
- - Поиск похожих медиа в базе знаний
- - Генерация мультимодальных ответов
-- **Результат:** Контекст из медиафайлов
-
-#### 9. Агент "Саммари беседы"
-- **Задача:** Создание краткого саммари истории беседы
-- **Функции:**
- - Анализирует последние 10-20 сообщений из истории
- - Создает краткое саммари через AI (вместо передачи полной истории)
- - Кэширует результат для повторного использования
- - Обновляет саммари при поступлении новых сообщений
- - Оптимизирует количество токенов в промпте
-- **Результат:** Оптимизированный контекст беседы для AI
-
-#### 10. Агент "Анализ контакта"
-- **Задача:** Извлечение и анализ данных пользователя из профиля
-- **Функции:**
- - Получает данные из профиля контакта (имя, теги, язык, роль)
- - Анализирует предпочтения и историю взаимодействий
- - Кэширует анализ для быстрого доступа
- - Обновляет при изменении профиля пользователя
- - Определяет стиль общения и приоритет
-- **Результат:** Персонализированный контекст для ответа
-
-#### 11. Агент "Кэширование бесед"
-- **Задача:** Управление кэшем бесед и контекста
-- **Функции:**
- - Кэширует саммари беседы + анализ контакта
- - Управляет TTL (Time To Live) для автоматической очистки
- - Проверяет актуальность кэша при новых сообщениях
- - Оптимизирует производительность системы
- - Предотвращает повторные вычисления
-- **Результат:** Быстрый доступ к контексту без пересчета
-
-### ⚙️ Логика работы многоагентной системы
-
-#### Шаг 1: Получение сообщения
-- Координатор получает входящее сообщение
-- Анализирует базовый контекст
-- Определяет необходимых агентов
-
-#### Шаг 2: Параллельный запуск агентов
-- Агент "Персонализация" → извлекает данные пользователя
-- Агент "Анализ запроса" → классифицирует обращение
-- Агент "RAG поиск" → ищет релевантную информацию
-- Агент "Контекст" → анализирует историю
-- Агент "Мультиязычность" → определяет язык
-- Агент "Мультимодальность" → обрабатывает медиа
-- Агент "Саммари беседы" → создает краткое саммари истории
-- Агент "Анализ контакта" → извлекает данные из профиля
-- Агент "Кэширование бесед" → проверяет и обновляет кэш
-
-#### Шаг 3: Сбор и анализ результатов
-- Координатор собирает данные от всех агентов
-- Анализирует полноту информации
-- Определяет необходимость дополнительных уточнений
-
-#### Шаг 4: Генерация ответа
-- Если информации достаточно → генерирует персонализированный ответ
-- Если нужно уточнить → запускает агента "Детализация"
-- Если требуется дополнительный контекст → запрашивает у других агентов
-
-#### Шаг 5: Сохранение контекста
-- Обновляет профиль пользователя
-- Сохраняет контекст беседы
-- Логирует использованные знания
-- Обновляет кэш саммари и анализа контакта
-- Сохраняет оптимизированный контекст для будущих запросов
-
-### 🎨 Преимущества многоагентной архитектуры
-
-1. **Модульность:** Каждый агент решает свою специализированную задачу
-2. **Масштабируемость:** Легко добавлять новых агентов
-3. **Эффективность:** Параллельная обработка разных аспектов
-4. **Гибкость:** Разные комбинации агентов для разных ситуаций
-5. **Персонализация:** Глубокое понимание каждого пользователя
-6. **Качество:** Специализированная обработка каждого аспекта
-7. **Оптимизация:** Саммари бесед снижает количество токенов
-8. **Кэширование:** Быстрый доступ к контексту без пересчета
-9. **Производительность:** Уменьшение времени ответа и нагрузки на AI
-
----
-
-## Персонализация на уровне аккаунта пользователя
-
-### 👤 Профиль пользователя
-- **Базовые данные:** Имя, компания, должность, контактная информация
-- **История взаимодействий:** Все предыдущие обращения и решения
-- **Предпочтения:** Стиль общения, технический уровень, приоритеты
-- **Статус:** Стадия в воронке продаж, статус клиента
-- **Теги:** Категории, сегменты, специализации
-
-### 📊 Контекстная картина
-- **Текущая беседа:** Сообщения в рамках одной сессии
-- **История обращений:** Все предыдущие взаимодействия
-- **Решенные проблемы:** Успешно закрытые задачи
-- **Открытые вопросы:** Незавершенные обращения
-- **Эмоциональное состояние:** Тон и настроение клиента
-
-### 🎯 Алгоритм персонализации
-
-#### 1. Анализ входящего сообщения
-- Определение типа обращения
-- Извлечение ключевой информации
-- Анализ эмоционального контекста
-
-#### 2. Загрузка профиля пользователя
-- Получение персональных данных
-- Анализ истории взаимодействий
-- Определение текущего статуса
-
-#### 3. Поиск в RAG базе
-- Фильтрация по тегам пользователя
-- Поиск релевантных решений
-- Анализ похожих случаев
-
-#### 4. Формирование контекста
-- Объединение данных профиля и истории
-- Анализ текущей ситуации
-- Определение оптимального подхода
-
-#### 5. Генерация персонализированного ответа
-- Учет персональных данных
-- Адаптация под стиль общения
-- Ссылки на предыдущие взаимодействия
-
----
-
-## Этап 1. Проектирование и подготовка инфраструктуры
-1. **Проектирование схемы хранения знаний (RAG):**
- - Описать структуру таблицы `knowledge_documents` (миграция).
- - Определить поля: id, content, language, type (текст/медиа), метаданные, дата, автор и т.д.
-2. **Подготовка backend:**
- - Создать миграцию и модель для `knowledge_documents`.
- - Подготовить базовые CRUD-эндпоинты для работы с базой знаний.
-
----
-
-## Этап 2. Интеграция векторного поиска (RAG)
-1. **Реализация векторного хранилища:**
- - Реализовать методы инициализации и поиска (`initVectorStore`, `findSimilarDocuments`) в `ai-assistant.js`.
- - Настроить хранение эмбеддингов для документов.
-2. **API для поиска знаний:**
- - Добавить эндпоинт для поиска релевантных знаний по запросу пользователя.
-
----
-
-## Этап 3. Разработка многоагентной архитектуры
-1. **Создание базовой структуры агентов:**
- - Реализовать главный AI-координатор
- - Создать базовые классы для специализированных агентов
- - Настроить систему координации между агентами
-2. **Разработка специализированных агентов:**
- - Агент "Персонализация пользователя"
- - Агент "Анализ запроса"
- - Агент "RAG поиск"
- - Агент "Контекст беседы"
- - Агент "Детализация"
- - Агент "Персонализация ответа"
- - Агент "Саммари беседы" (новый)
- - Агент "Анализ контакта" (новый)
- - Агент "Кэширование бесед" (новый)
-3. **Интеграция с существующей системой:**
- - Подключение агентов к текущему pipeline
- - Настройка логирования и мониторинга
- - Тестирование взаимодействия агентов
-4. **Реализация оптимизаций:**
- - Создание сервиса саммари бесед
- - Интеграция анализа контактов для персонализации
- - Настройка кэширования для повышения производительности
-
----
-
-## Этап 4. Интеграция RAG в pipeline ассистента
-1. **Модификация логики ответа ассистента:**
- - При получении сообщения пользователя — искать релевантные знания и включать их в prompt LLM.
- - Обеспечить мультиязычность поиска и генерации ответа.
- - Интегрировать саммари беседы вместо передачи полной истории.
- - Использовать анализ контактов для персонализации ответов.
-2. **Логирование и трассировка:**
- - Сохранять, какие знания были использованы для ответа.
- - Логировать использование саммари и кэширования.
- - Отслеживать производительность оптимизаций.
-
----
-
-## Этап 5. Интерфейс для админа
-1. **UI для управления знаниями:**
- - Добавить на фронте раздел для просмотра, добавления, редактирования и удаления знаний.
-2. **UI для модерации ответов ассистента:**
- - Кнопки "Редактировать", "Отправить", "Добавить в RAG" для сообщений и ответов.
- - Возможность быстро добавить сообщение пользователя или ответ ассистента в базу знаний.
-
----
-
-## Этап 6. Поддержка мультимодальности и мультиязычности
-1. **Обработка вложений (аудио, видео, картинки):**
- - Решить, как хранить и индексировать такие данные (например, хранить ссылки и метаданные, а не сами файлы).
-2. **Мультиязычный поиск и генерация:**
- - Проверить корректность работы эмбеддингов и LLM для разных языков.
-
----
-
-## Этап 7. Тестирование и оптимизация
-1. **Покрытие тестами ключевых сценариев (unit, интеграционные).**
-2. **Оптимизация скорости поиска и генерации.**
-3. **Тестирование производительности саммари и кэширования.**
-4. **Оптимизация использования токенов и времени ответа.**
-5. **Документация для команды.**
-
----
-
-## Бизнес-логика управления знаниями и тегами для RAG-ассистента
-
-### 1. Гибкая система тегов и связей с пользователями
-- Пользователь может создавать собственные таблицы тегов (например, "покупатель", "поставщик", "VIP-клиент" и т.д.).
-- В таблице тегов должна быть возможность добавлять ссылки (relation) на пользователей из таблицы `users`.
-- Для одного тега может быть привязано несколько пользователей (мультисвязь).
-- Для одного пользователя может быть несколько тегов.
-
-### 2. Управление знаниями (FAQ, инструкции, ответы)
-- Пользователь может создавать таблицы с вопросами и ответами (например, FAQ для определённой группы клиентов).
-- Каждая запись (вопрос-ответ) может быть связана с определённым тегом или группой тегов.
-- Возможна фильтрация и поиск знаний по тегам, языку, типу клиента и другим параметрам.
-
-### 3. Использование тегов и знаний в RAG-ассистенте
-- При обработке запроса пользователя RAG-ассистент определяет его теги (по связям в таблице тегов).
-- Для генерации ответа ассистент использует только те знания (вопросы/ответы), которые соответствуют тегам пользователя.
-- Администратор может добавлять новые теги, связывать их с пользователями, а также создавать и редактировать знания для каждой группы.
-- **Оптимизация через саммари:** Вместо передачи полной истории беседы (10 сообщений), система создает краткое саммари через AI.
-- **Персонализация через контакты:** Ассистент использует данные из профиля контакта (имя, язык, теги) для персонализации ответов.
-- **Кэширование контекста:** Саммари беседы и анализ контактов кэшируются для быстрого доступа без пересчета.
-
-### 4. UI/UX требования
-- В интерфейсе создания/редактирования пользовательских таблиц должен быть доступен тип столбца "relation" (связь с users).
-- Для ячеек типа "relation" реализовать выпадающий список с поиском по пользователям.
-- Для таблиц знаний — возможность выбора одного или нескольких тегов для каждой записи.
-
-**Пример структуры:**
-- Таблица `user_tags`: id, name, [user_id (relation, мультисвязь)]
-- Таблица `faq`: id, question, answer, [tag_id (relation, мультисвязь)]
-
-**Применение:**
-- RAG-ассистент использует связи между пользователями, тегами и знаниями для персонализации ответов и поиска релевантной информации.
-
-### 5. Безопасность и контроль
-- Только администратор может создавать и редактировать системные теги и знания.
-- Обычные пользователи могут видеть только свои теги и связанные с ними знания.
-
----
-
-## Требования к CRM-интерфейсу для работы с контактами, тегами и настройками RAG-ассистента
-
-### 1. Раздел "Контакты" в CRM
-- **Фильтры:**
- - Новые пользователи (по дате создания или статусу "новый").
- - Новые входящие сообщения (по наличию непрочитанных/неотвеченных сообщений).
- - Теги (мультиселект по тегам пользователя).
-- **Детали контакта:**
- - Просмотр истории сообщений.
- - Список тегов пользователя.
- - Добавление/удаление тегов через выпадающий список или автокомплит (создание связи в таблице user_tags).
-
-### 2. Настройки ИИ-ассистента
-- **Выбор RAG-таблиц:**
- - В настройках ассистента отображается список всех доступных RAG-таблиц.
- - Администратор выбирает (чекбоксами или мультиселектом), какие таблицы использовать для поиска ответов.
- - Для каждой выбранной таблицы отображается список тегов, которые она содержит.
-- **Связь с тегами:**
- - При генерации ответа ИИ использует только те RAG-таблицы и записи, которые соответствуют тегам пользователя.
-
-### 3. Рекомендации по интерфейсу (Vue)
-- Компоненты:
- - `ContactList.vue` — фильтры, список пользователей
- - `ContactDetails.vue` — история сообщений, теги, добавление тегов
- - `AssistantSettings.vue` — выбор RAG-таблиц
- - `RagTableSelector.vue` — список таблиц с чекбоксами
- - `TagList.vue` — просмотр тегов в выбранной таблице
-
-### 4. Схема действий администратора
-1. В разделе "Контакты" находит нового пользователя/сообщение через фильтры.
-2. В деталях контакта добавляет нужные теги пользователю.
-3. В настройках ассистента выбирает, какие RAG-таблицы использовать для поиска по тегам.
-4. ИИ-ассистент при ответе использует только релевантные RAG-таблицы и теги.
-
-### 5. Пример структуры таблиц для RAG и тегов
-- `users` — пользователи
-- `messages` — сообщения
-- `tags` — справочник тегов
-- `user_tags` — связь пользователей и тегов (user_id, tag_id)
-- `rag_tables` — таблицы знаний (например, FAQ, инструкции)
-- `rag_entries` — записи в таблицах знаний (content, rag_table_id, ...)
-- `rag_entry_tags` — связь записей знаний и тегов (rag_entry_id, tag_id)
-
----
-
-## План внедрения RAG-ассистента в CRM
-
-1. **Создать RAG-таблицы для ИИ-ассистента**
- - Таблицы для хранения знаний о компании, продуктах, услугах (например, `rag_tables`, `rag_entries`).
- - Возможность добавлять, редактировать, удалять записи через UI.
- - Каждая запись может быть связана с тегами (например, категория продукта, язык, сегмент клиента).
-
-2. **Создать таблицы с тегами для пользователей**
- - Таблица тегов (`tags`).
- - Связующая таблица `user_tags` (user_id, tag_id).
- - UI для управления тегами и их привязкой к пользователям.
-
-3. **Отредактировать страницу настройки ИИ-ассистента**
- - Добавить выбор, какие RAG-таблицы использовать для поиска.
- - Отображать список тегов, связанных с выбранными таблицами.
- - Возможность быстро подключать/отключать таблицы и теги.
-
-4. **Добавить в раздел "Контакты" фильтры (отдельные компоненты)**
- - Фильтр по новым пользователям.
- - Фильтр по новым входящим сообщениям.
- - Фильтр по тегам (мультиселект).
- - Каждый фильтр реализовать отдельным Vue-компонентом для переиспользования.
-
-5. **В "Детали контакта" добавить инлайн-кнопки**
- - Кнопки:
- - Сгенерировать (ответ с помощью ИИ)
- - Редактировать (отредактировать сгенерированный ответ)
- - Отправить (отправить ответ пользователю)
- - Добавить в RAG-таблицу (сделать сообщение или ответ частью базы знаний)
- - Кнопки должны быть доступны для каждого сообщения в истории.
-
----
-
-**Этот документ будет дополняться по мере реализации каждого этапа.**
\ No newline at end of file
diff --git a/docs/SETUP_ACCESS_LEVELS.md b/docs/SETUP_ACCESS_LEVELS.md
deleted file mode 100644
index 507f873..0000000
--- a/docs/SETUP_ACCESS_LEVELS.md
+++ /dev/null
@@ -1,105 +0,0 @@
-# Настройка расширенной системы прав доступа
-
-## Описание изменений
-
-Добавлена расширенная система прав доступа с настраиваемыми порогами:
-
-- **Read-Only (1+ токен)** - только просмотр данных
-- **Editor (2+ токен)** - просмотр + редактирование + удаление
-- **User (0 токенов)** - базовые права без изменений
-
-## Новые поля в форме добавления токенов
-
-На странице `/settings/security` в форме добавления токенов добавлены два новых поля:
-
-1. **Минимум токенов для Read-Only доступа** (по умолчанию: 1)
-2. **Минимум токенов для Editor доступа** (по умолчанию: 2)
-
-## Применение изменений
-
-### 1. Обновление базы данных
-
-Выполните SQL скрипт для добавления новых полей:
-
-```bash
-# Подключитесь к базе данных PostgreSQL
-psql -h localhost -U your_username -d your_database
-
-# Выполните миграцию
-\i backend/scripts/add_access_thresholds.sql
-```
-
-### 2. Перезапуск сервера
-
-```bash
-# В папке backend
-yarn restart
-# или
-docker-compose restart backend
-```
-
-### 3. Перезапуск frontend
-
-```bash
-# В папке frontend
-yarn dev
-```
-
-## Как использовать
-
-### Для администраторов:
-
-1. Перейдите на страницу `/settings/security`
-2. В разделе "Токены аутентификации" нажмите "Подробнее"
-3. При добавлении нового токена заполните:
- - Название токена
- - Адрес смарт-контракта
- - Сеть блокчейна
- - Минимальный баланс
- - **Минимум токенов для Read-Only доступа**
- - **Минимум токенов для Editor доступа**
-
-### Для пользователей:
-
-- Система автоматически определяет уровень доступа на основе количества токенов
-- Отображается текущий уровень доступа с визуальными индикаторами
-- UI автоматически адаптируется под уровень доступа
-
-## Примеры настроек
-
-### Стандартные настройки:
-- Read-Only: 1 токен
-- Editor: 2 токена
-
-### Строгие настройки:
-- Read-Only: 2 токена
-- Editor: 5 токенов
-
-### Либеральные настройки:
-- Read-Only: 1 токен
-- Editor: 1 токен (все пользователи с токенами могут редактировать)
-
-## Технические детали
-
-### Backend изменения:
-- `auth-service.js` - добавлена функция `getUserAccessLevel()`
-- `authTokenService.js` - поддержка новых полей
-- `tokenBalanceService.js` - возврат порогов доступа
-- `routes/settings.js` - API endpoint для новых полей
-- `routes/auth.js` - новый endpoint `/access-level/:address`
-
-### Frontend изменения:
-- `useAuth.js` - поддержка уровней доступа
-- `usePermissions.js` - новый composable для проверки прав
-- `AuthTokensSettings.vue` - форма с новыми полями
-- `SecuritySettingsView.vue` - использование новых прав доступа
-
-### Новые поля в БД:
-- `auth_tokens.readonly_threshold` - порог для Read-Only
-- `auth_tokens.editor_threshold` - порог для Editor
-
-## Обратная совместимость
-
-- Все существующие токены получают значения по умолчанию (1 и 2)
-- Старые проверки `isAdmin` продолжают работать
-- Система автоматически мигрирует существующие данные
diff --git a/docs/SMART_CONTRACTS.md b/docs/SMART_CONTRACTS.md
deleted file mode 100644
index 22937f8..0000000
--- a/docs/SMART_CONTRACTS.md
+++ /dev/null
@@ -1,558 +0,0 @@
-
-
-# Смарт Контракты Digital Legal Entity (DLE)
-
-## Основной смарт контракт DLE
-
-### DLE v2: ключевые изменения и API (актуально)
-- Безопасность: удалены уязвимые Merkle‑механизмы cross‑chain; нет внешних мостов/оракулов.
-- Голосующая сила: OpenZeppelin `ERC20Votes` (снимки `getPastVotes`, `getPastTotalSupply`).
-- Делегирование: жестко ограничено «только на себя»; третьим лицам делегировать нельзя (1 токен = 1 голос).
-- Переводы токенов: ЗАБЛОКИРОВАНЫ прямые переводы (transfer, transferFrom, approve); переводы возможны ТОЛЬКО через governance предложения.
-- Single‑Chain Governance: голосование происходит в одной выбранной сети (`governanceChainId`), время снапшота фиксируется на создании предложения и используется во всех сетях.
-- Multi‑Chain исполнение: выполнение в целевых сетях по EIP‑712 подписям холдеров, проверяется суммарная голосующая сила на зафиксированном `timepoint` (без доверия к мостам).
-- «100% или ничего»: операции считаются успешными только при готовности/успешности всех целевых сетей.
-- Модули вынесены отдельно: `Treasury`, `Timelock`, `Deactivation`, `Communication` и др. Управление только через предложения.
-- Детерминированные адреса: CREATE с выровненным nonce. Единый адрес DLE и модулей во всех выбранных сетях.
-- Аналитика: добавлены view‑функции для агрегирования и пагинации.
-
-Пример основных функций DLE v2 (интерфейс):
-```solidity
-// Создание предложения с фиксацией сети голосования, целевых сетей и таймлока
-function createProposal(
- string calldata description,
- uint256 governanceChainId,
- uint256[] calldata targetChains,
- uint64 timelockHours,
- bytes calldata operationCalldata
-) external returns (uint256 proposalId);
-
-// Голосование с использованием снапшотов ERC20Votes (учет силы на момент создания)
-function vote(uint256 proposalId, bool support) external;
-
-// Отмена инициатором при наличии достаточной голосующей силы (мягкая отмена)
-function cancelProposal(uint256 proposalId) external;
-
-// Исполнение в целевой сети по EIP-712 подписям холдеров (без мостов)
-function executeProposalBySignatures(
- uint256 proposalId,
- bytes[] calldata signatures
-) external;
-
-// Просмотровые функции (аналитика)
-function getProposalState(uint256 proposalId) external view returns (uint8);
-function getProposalVotes(uint256 proposalId) external view returns (uint256 forVotes, uint256 againstVotes);
-function getQuorumAt(uint256 timepoint) external view returns (uint256);
-function getVotingPowerAt(address account, uint256 timepoint) external view returns (uint256);
-function getProposalSummary(uint256 proposalId) external view returns (/* агрегированные поля */);
-function getGovernanceParams() external view returns (/* кворум, снапшоты, chainIds */);
-function listSupportedChains() external view returns (uint256[] memory);
-```
-
-События (ключевые):
-- `ProposalCreated`, `ProposalCancelled`, `ProposalExecuted`
-- `OffchainAction` (триггер оффчейн‑действий через события)
-- `ModuleAdded`, `ModuleRemoved`
-
-Замечания по безопасности:
-- Снапшоты голосующей силы через `ERC20Votes` исключают перелив голосов.
-- Верификация EIP‑712 подписей исключает зависимость от внешних мостов.
-- Отсутствуют админ‑роли: все изменения только предложением и кворумом.
-- Защита от повторов: `nonces` и EIP‑712 схемы подписи используются по стандарту OZ.
-```
-
-### Концепция
-**Один смарт-контракт** с ERC-20 токенами, настраиваемым кворумом и модулями. Адрес контракта одновременно выполняет функции банковского счета и контактных данных.
-
-### Архитектура
-```
-DLE.sol (Один контракт)
-├── ERC-20 токены (голосующая сила)
-├── Настраиваемый кворум (% от общего количества токенов)
-├── Система голосования (проверка баланса токенов)
-├── Голосование токен‑холдеров
-├── Модули (добавляемые через голосование)
-├── Мультичейн синхронизация
-└── Полное управление данными DLE через кворум
-```
-
-### Требования
-
-#### 1. Токен управления (ERC-20)
-- **Описание**: Стандартный ERC-20 токен для управления DLE
-- **Функции**:
- - Минтинг токенов при создании DLE
- - Распределение токенов между участниками
- - **Голосующая сила = количество токенов**
- - Проверка баланса токенов при каждой операции
- - **Прямые переводы ЗАБЛОКИРОВАНЫ** - токены служат только для голосования
- - **Переводы возможны ТОЛЬКО через governance предложения**
-
-#### 2. Настраиваемый кворум
-- **Описание**: Процент от общего количества токенов для принятия решений
-- **Функции**:
- - Настройка кворума при создании DLE
- - **Изменение кворума через голосование** ✅
- - Расчет кворума: `(totalSupply * quorumPercentage) / 100`
- - Проверка достижения кворума для каждого решения
-
-#### 3. Система голосования через токен-холдеров
-- **Описание**: Только владельцы токенов участвуют в управлении
-- **Функции**:
- - Создание предложений (любым токен-холдером)
- - Голосование пропорционально балансу токенов
- - Проверка баланса токенов при каждой подписи
- - Выполнение предложений после достижения кворума
- - **НЕТ админских ролей - только коллективное управление**
-
-#### 4. Полное управление данными DLE через кворум ✅
-- **Описание**: Все данные DLE можно изменить через систему голосования
-- **Функции**:
- - **Изменение названия DLE** через кворум
- - **Изменение символа токена** через кворум
- - **Изменение местонахождения** через кворум
- - **Изменение координат** через кворум
- - **Изменение юрисдикции** через кворум
- - **Изменение ОКТМО** через кворум
- - **Изменение КПП** через кворум
- - **Изменение кодов ОКВЭД** через кворум
- - **Изменение процента кворума** через кворум
- - **Изменение текущей цепочки** через кворум
-
-#### 5. Голосование токен‑холдеров
-- **Описание**: Критические операции подтверждаются голосованием держателей токенов
-- **Функции**:
- - Подача голосов за/против с учетом голосующей силы
- - Подсчет голосов по снапшотам `ERC20Votes`
- - Исполнение операций после достижения кворума
-
-#### 6. Казначейские функции
-- **Описание**: Управление финансами DLE через голосование
-- **Функции**:
- - Внесение токенов в казну
- - Вывод токенов из казны через голосование
- - Распределение дивидендов
- - Бюджетирование через предложения
-
-#### 7. Модульная система
-- **Описание**: Добавление новых функций через модули
-- **Функции**:
- - Добавление модулей через голосование
- - Управление модулями через голосование
- - Изоляция модулей от основного контракта
- - Обновление модулей через голосование
-
-#### 8. Коммуникационные функции
-- **Описание**: Прием сообщений и звонков
-- **Функции**:
- - Прием текстовых сообщений
- - Прием аудио/видео звонков
- - Кворум для коммуникационных действий
- - Хранение истории коммуникаций
-
-### Иерархическая система голосования DLE
-
-#### Концепция
-DLE может владеть токенами других DLE и участвовать в их голосовании через систему кворума подписей.
-
-#### Механизм работы
-1. **DLE A** владеет токенами **DLE B**
-2. **Голос DLE A** в **DLE B** прямо пропорционален количеству токенов **DLE B** на балансе **DLE A**
-3. Для участия в голосовании **DLE B** холдеры **DLE A** должны собрать **кворум голосов** внутри **DLE A**
-4. После достижения кворума подписей **DLE A** может голосовать в **DLE B** как единое целое
-
-### Новые возможности изменения данных DLE ✅
-
-#### 1. Обновление основной информации DLE
-```solidity
-function _updateDLEInfo(
- string memory _name,
- string memory _symbol,
- string memory _location,
- string memory _coordinates,
- uint256 _jurisdiction,
- uint256 _oktmo,
- string[] memory _okvedCodes,
- uint256 _kpp
-) internal
-```
-
-#### 2. Изменение процента кворума
-```solidity
-function _updateQuorumPercentage(uint256 _newQuorumPercentage) internal
-```
-
-
-#### 3. События для отслеживания изменений
-```solidity
-event DLEInfoUpdated(string name, string symbol, string location, string coordinates, uint256 jurisdiction, uint256 oktmo, string[] okvedCodes, uint256 kpp);
-event QuorumPercentageUpdated(uint256 oldQuorumPercentage, uint256 newQuorumPercentage);
-```
-
-### Процесс изменения данных DLE
-
-#### 1. Создание предложения
-- Любой токен-холдер создает предложение об изменении данных
-- Выбирает цепочку для сбора голосов
-- Указывает новые значения для изменения
-
-#### 2. Голосование
-- Токен-холдеры голосуют за/против изменения
-- Голосующая сила = количество токенов
-- Проверка баланса при каждом голосе
-
-#### 3. Исполнение
-- При достижении кворума предложение исполняется
-- Данные DLE обновляются
-- Событие эмитится для отслеживания
-
-#### 4. Синхронизация
-- Изменения синхронизируются во все поддерживаемые цепочки
-- EIP‑712 подписи холдеров обеспечивают безопасность cross-chain исполнения (без мостов)
-
-### Примеры использования
-
-#### Изменение названия DLE
-```
-1. Создание предложения: "Изменить название на 'Новое DLE'"
-2. Голосование в выбранной цепочке
-3. При кворуме: обновление названия
-4. Синхронизация во все цепочки
-```
-
-#### Изменение кворума
-```
-1. Создание предложения: "Изменить кворум с 51% на 60%"
-2. Голосование в выбранной цепочке
-3. При кворуме: обновление процента кворума
-4. Синхронизация во все цепочки
-```
-
-#### Изменение текущей цепочки
-```
-1. Создание предложения: "Изменить текущую цепочку на Polygon"
-2. Голосование в выбранной цепочке
-3. При кворуме: обновление currentChainId
-4. Синхронизация во все цепочки
-```
-
-### Безопасность
-
-#### Валидация данных
-- Проверка корректности всех входящих данных
-- Валидация адресов и числовых значений
-- Проверка поддержки цепочек перед изменением
-
-#### Защита от злоупотреблений
-- Все изменения только через кворум
-- Проверка баланса токенов при голосовании
-- EIP‑712 подписи и проверка снапшотов для cross-chain безопасности
-
-#### Аудит изменений
-- Все изменения логируются в событиях
-- Возможность отслеживания истории изменений
-- Прозрачность всех операций
-
-### Иерархическая система голосования DLE
-
-#### Концепция
-DLE может владеть токенами других DLE и участвовать в их голосовании через систему кворума подписей.
-
-#### Механизм работы
-1. **DLE A** владеет токенами **DLE B**
-2. **Голос DLE A** в **DLE B** прямо пропорционален количеству токенов **DLE B** на балансе **DLE A**
-3. Для участия в голосовании **DLE B** холдеры **DLE A** должны собрать **кворум голосов** внутри **DLE A**
-4. После достижения кворума подписей **DLE A** может голосовать в **DLE B** как единое целое
-
-#### Пример
-- **DLE A** владеет **10% токенов DLE B**
-- Кворум в **DLE B** = **51%**
-- Холдеры **DLE A** голосуют за подпись в **DLE B**
-- **DLE B** получает от **DLE A** подпись на **10% голосов**
-
-#### Технические требования
-- Система сбора голосов внутри DLE для внешнего голосования
-- Проверка прав через голосование
-- Прямо пропорциональный подсчет голосов по количеству токенов
-- Интерфейсы для взаимодействия между DLE
-
-### Межприложное взаимодействие DLE
-
-#### Концепция
-Каждое DLE имеет свое веб3 приложение с интерфейсом управления. DLE могут взаимодействовать через встраивание интерфейсов.
-
-#### Архитектура взаимодействия
-- **DLE A** (домен 1) + **Веб3 приложение A** с интерфейсом
-- **DLE B** (домен 2) + **Веб3 приложение B** с интерфейсом
-- **Голосование** происходит через блокчейн между доменами
-
-#### Вариант реализации (рекомендуемый)
-**Встраивание интерфейса DLE B в приложение DLE A**
-
-##### Преимущества:
-- **Безопасность**: Холдеры DLE A не покидают свое приложение
-- **Защита от фишинга**: Пользователи всегда в знакомой среде
-- **Контроль**: DLE A контролирует безопасность интерфейса
-- **Удобство**: Единый интерфейс для управления всеми DLE
-- **Аудит**: Все действия отслеживаются в одном месте
-
-##### Техническая реализация:
-```javascript
-// В приложении DLE A
-function DLEBManagementInterface({ dleBAddress }) {
- return (
-
-
Управление DLE B
-
-
-
-