VC-HB3-Accelerator/DLE
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

ваше сообщение коммита

Browse Source
This commit is contained in:
Alex
2026-02-20 14:18:08 +03:00
parent 8702a355a1
commit 24e560fc83
44 changed files with 8354 additions and 95 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
docs.en/FAQ.md Normal file
View File

@@ -0,0 +1,21 @@
**English** | [Русский](../docs.ru/FAQ.md)
# DLE — Frequently Asked Questions
## General
**Q: What is DLE?**
A: Digital Legal Entity (DLE) is a microservices platform with a web application for on-premise deployment. It includes AI agents, smart contracts, CRM, and blockchain governance. See [Platform description](application-description.md).
**Q: How do I install DLE?**
A: Use the [Setup guide](back-docs/setup-instruction.md). Quick start: Docker Compose; see root [README](../../README.md).
**Q: Where are the terms of service and licensing?**
A: [Terms of Purchase and Service](service-terms.md). Legal overview: [legal.en/README.md](../../legal.en/README.md).
**Q: How do I get support?**
A: https://hb3-accelerator.com/ | info@hb3-accelerator.com
---
*This FAQ will be expanded. For full documentation see the [docs.en](.) index and [README](../../README.md).*

188
docs.en/ai-assistant.md Normal file
View File

@@ -0,0 +1,188 @@
**English** | [Русский](../docs.ru/ai-assistant.md)
# DLE AI Agents — Building Specialized Business Agents
> **Concept:** one local model — many specialized agents. Each agent is tailored to a specific business process: its own prompt, rules, knowledge base, and interface.
## Table of Contents
1. [What and Why](#what-and-why)
2. [Architecture](#architecture)
3. [How to Create an Agent](#how-to-create-an-agent)
4. [Agent Examples](#agent-examples)
5. [Technology Stack](#technology-stack)
6. [Advantages Over Cloud Solutions](#advantages-over-cloud-solutions)
7. [Economic Impact](#economic-impact)
---
## What and Why
DLE provides **tools to create AI agents** — specialized assistants, each responsible for a distinct business process.
This is not one generic chatbot. It is a **builder** where you:
- Create an agent for a specific task (support, content, procurement, analytics)
- Set its role via system prompt
- Attach a knowledge base (RAG tables) with relevant data
- Configure behavior rules (strict, creative, hybrid)
- Bind to channels (web chat, Telegram, Email)
- Get an isolated specialist working 24/7
All agents use **one local Ollama model** on your server. They differ by system prompts, rules, and connected data. Data never leaves your server.
---
## Architecture
### Principle: One Model — Many Agents
One Ollama instance (e.g. qwen2.5:7b) serves multiple agents. Each has its own prompt, rules, RAG tables, channels, and UI. Agents are isolated and do not affect each other.
### Request Flow
User request → agent determined by channel/route → agent config (prompt, rules, RAG) → query vectorization (Ollama mxbai-embed-large) → RAG search (FAISS) → LLM response with RAG context + system prompt + history → optional cache (TTL 1 h) → response to user.
---
## How to Create an Agent
### Step 1. Basic Info
- **Name** — e.g. “Support Agent”, “Content Editor”, “AI Procurement”
- **Role** — support, content_editor, analyst, purchaser, etc.
- **Description** — what the agent is for
### Step 2. System Prompt
Defines identity and behavior. Examples:
**Support:** “You are a professional customer support assistant. Answer only from the knowledge base. If no answer — suggest contacting an operator. Do not invent prices, terms, or conditions.”
**Content editor:** “You are a professional content marketer and editor. Use company style from the knowledge base. Follow platform guidelines. Use keywords and hashtags from the base.”
### Step 3. Rules (JSON)
```json
{
"searchRagFirst": true,
"generateIfNoRag": false,
"checkUserTags": true,
"temperature": 0.3,
"maxTokens": 500
}
```
| Parameter | Effect | Support | Content | Analytics |
|-----------|--------|----------|---------|-----------|
| temperature | Creativity (0.0–1.0) | 0.3 | 0.7 | 0.2 |
| searchRagFirst | Search knowledge base first | true | true | true |
| generateIfNoRag | Generate if not in base | false | true | false |
| maxTokens | Max response length | 500 | 2000 | 1000 |
### Step 4. Knowledge Base (RAG Tables)
Attach spreadsheets the agent will search: Support → FAQ, product docs; Content → platform instructions, style, examples, keywords; Procurement → supplier base, terms, prices. Tables need columns designated as “Question for AI” and “Answer for AI” for vector indexing.
### Step 5. Channels and Interface
Channels: web chat, Telegram, Email, SMS. Route: e.g. `/content-editor`. Set which roles can access.
### Step 6. Activate
Enable the agent; it starts handling requests on the selected channels.
---
## Agent Examples
### 1. Customer Support Agent
**Task:** answer customer questions 24/7 from the knowledge base. Strict mode (only from base), temperature 0.3, RAG: FAQ, docs. Channels: web chat, Telegram, Email. If no answer → suggest operator.
### 2. Content Editor Agent
**Task:** create social posts, blog articles, emails in company style. Creative mode, temperature 0.7, RAG: platform instructions, style, examples, keywords, CTAs. Interface: `/content-editor`, Editor role.
### 3. AI Procurement Agent
**Task:** help choose suppliers and compare terms. Hybrid mode, temperature 0.5, RAG: supplier base, terms and prices. Example: “Who supplies electronics with delivery up to 3 days?” → top 3 from table with filters.
### 4. Other Possible Agents
Analyst (reports, trends), HR assistant (screening, policies), Translator (glossaries, style), Legal assistant (contracts, norms). Each = new combination of prompt, rules, and tables.
---
## Technology Stack
| Component | Technology | Purpose |
|-----------|------------|---------|
| LLM | Ollama (qwen2.5:7b or other) | Generation, dialogue |
| Embedding | mxbai-embed-large | Text vectorization |
| Vector DB | FAISS | Semantic search |
| Main DB | PostgreSQL | Agents, knowledge, history |
| Cache | Node.js Map + TTL | Fast repeat queries (< 50ms) |
| Queue | AI Queue | Priority processing |
| Encryption | AES-256 | Prompts and settings encrypted |
### RAG Search Methods
Semantic (FAISS), keyword, hybrid (e.g. 70% semantic, 30% keyword). Optional: fuzzy search, stemming, keyword extraction.
---
## Advantages Over Cloud Solutions
| | DLE (local) | ChatGPT API | Claude API |
|-|-------------|-------------|------------|
| **Cost** | $0 | ~$0.02/request | ~$0.03/request |
| **Confidentiality** | 100% on your server | Data at OpenAI | Data at Anthropic |
| **Speed (cached)** | < 50ms | 500–2000ms | 500–2000ms |
| **Offline** | Yes | No | No |
| **Business tuning** | Full: prompts, rules, RAG | Limited | Limited |
| **API limits** | None | Yes | Yes |
| **Number of agents** | Unlimited | Separate API per use | Separate API per use |
---
## Economic Impact
### API Cost Savings
| Requests/month | ChatGPT API | Claude API | DLE |
|----------------|-------------|------------|-----|
| 10,000 | $2,400/year | $3,600/year | $0 |
| 50,000 | $12,000/year | $18,000/year | $0 |
| 100,000 | $24,000/year | $36,000/year | $0 |
### Process Automation Savings
Each agent replaces routine work. Example for a mid-size company: support agent ($57,600), procurement ($64,800), HR ($57,600), content ($86,400), analyst ($144,000), partners ($43,200), training ($30,000), API savings ($24,000–36,000) → **total about $507,600–519,600/year**. DLE license: $1,000 one-time.
### 5-Year Comparison with SaaS
Typical SaaS stack (CRM, chatbot, email, AI API): ~$39,000 over 5 years. DLE: $1,000 + $0 AI + free updates 5 years → **savings about $38,000**.
---
## Additional Materials
- [Multi-agent architecture](./back-docs/multi-agent-architecture.md) — technical spec
- [AI assistant setup](./back-docs/setup-ai-assistant.md) — deployment steps
- [Tables system](./back-docs/tables-system.md) — RAG tables
- [FAQ](./FAQ.md)
---
## Support
- **Email:** info@hb3-accelerator.com
- **Chat:** https://hb3-accelerator.com
- **Docs:** [FAQ](./FAQ.md)
---
**© 2024-2025 Alexander Viktorovich Tarabanov. All rights reserved.**
**Last updated:** February 2026

195
docs.en/application-description.md Normal file
View File

@@ -0,0 +1,195 @@
**English** | [Русский](../docs.ru/application-description.md)
# Digital Legal Entity (DLE) — Platform Description
## Definition
**Digital Legal Entity (DLE)** is a microservices platform with a web application for on-premise deployment on company servers. It includes tools for configuring AI agents and a smart contract system with support for tax, accounting, banking, and other identifiers set by the regulator.
It provides management and automation of business processes, allows moving away from fragmented SaaS services with monthly subscriptions, and meets regulator requirements for data storage and processing.
---
## Table of Contents
1. [Who It's For](#who-its-for)
2. [Why DLE, Not SaaS](#why-dle-not-saas)
3. [Main Capabilities](#main-capabilities)
4. [Economic Impact](#economic-impact)
5. [Technical Details](#technical-details)
6. [Purchase Terms](#purchase-terms)
7. [Documentation](#documentation)
---
## Who It's For
DLE is for organizations that need their own IT infrastructure with transparent governance:
- Commercial organizations (LLC, JSC, sole proprietors, holdings)
- Non-profit organizations (NPOs, foundations, associations)
- Government bodies (municipalities, agencies)
- Investment and venture funds
- Startups and small business
- Cooperatives and associations
---
## Why DLE, Not SaaS
| Parameter | DLE | Typical SaaS |
|-----------|-----|--------------|
| Cost | $1,000 one-time | $200-500/month |
| Data ownership | On your server | At provider |
| Customization | Full (source code) | Limited |
| AI | Local, no limits, $0 | Cloud, paid API |
| Blockchain | Built-in | No |
| Updates | Free for 5 years | Depends on plan |
| Regulatory compliance | Full (data on-premise) | Depends on provider |
---
## Main Capabilities
### 1. AI Agents
One local Ollama model — many specialized agents. Each agent is tailored to a specific business process: its own prompt, rules, and knowledge base (RAG tables).
You create agents for company tasks: customer support, analytics, accounting, HR, marketing, procurement, and any other processes. Data never leaves your server.
More: [DLE AI Agents](./ai-assistant.md)
### 2. CRM and Contact Management
- Centralized contact database with interaction history
- Grouping by tags and categories
- Tasks and reminders
- Import/export (CSV, Excel)
- Document and template builder
### 3. Omnichannel Communications
Single interface for all channels: Telegram bot, Email, Web chat, SMS, web forms. One context per client across channels. AI auto-replies trained on your data.
### 4. Blockchain Governance and Tokenization
- Smart contracts with regulator identifier support
- Asset tokenization (real estate, IP, equity)
- Governance through token holder voting
- Multichain support (Ethereum, Polygon, BSC, Arbitrum, Optimism, Avalanche, Base)
More: [Blockchain for Business](./blockchain-for-business.md)
### 5. Groups and Team Spaces
- Customizable spaces for projects
- Granular permissions (20+ types)
- Roles: Editor, ReadOnly, User
- Integration with CRM and communications
### 6. Internal Tools
- Spreadsheets (Excel-like)
- Analytics and reporting
- Metrics monitoring
- WebSSH for server management
### 7. Security
- TLS 1.3, AES-256 encryption
- SIWE (wallet sign-in), sessions in DB
- Granular permissions (20+ types), token gating
- GDPR, CCPA, 152-FZ compliance
- All data on your server
More: [DLE Security](./security.md)
---
## Economic Impact
### 5-Year Comparison with SaaS
| Expense | SaaS stack | DLE |
|---------|------------|-----|
| CRM | $12,000 | — |
| Chatbot | $9,000 | — |
| Email campaigns | $6,000 | — |
| AI (API) | $12,000 | — |
| **Total** | **$39,000** | **$1,000** |
Savings: $38,000 over 5 years. Pay once — use indefinitely.
### Local AI vs Cloud APIs
| | DLE (local) | Cloud APIs |
|-|-------------|------------|
| Cost | $0 | ~$0.02-0.03/request |
| Confidentiality | Data on your server | Data at provider |
| Limits | None | Yes |
| Offline | Yes | No |
| Business tuning | Full (agents, RAG) | Limited |
---
## Technical Details
### Technology Stack
| Component | Technology |
|-----------|------------|
| Frontend | Vue.js 3, Vite, Element Plus |
| Backend | Node.js, Express |
| Database | PostgreSQL, pgvector |
| AI | Ollama (qwen2.5:7b), FAISS Vector Search |
| Blockchain | Ethers.js v6, Hardhat |
| Containerization | Docker Compose |
### Minimum Requirements
| Parameter | Value |
|-----------|-------|
| CPU | 4 cores |
| RAM | 12 GB (app + AI + Vector Search) |
| Storage | 100 GB SSD |
| OS | Ubuntu 20.04+, Debian 11+, CentOS 8+ (any Linux with Docker) |
### Deployment
One-command installation via Docker Compose. More: [Setup Guide](./back-docs/setup-instruction.md)
---
## Purchase Terms
| Package | Price | Tokens | Votes |
|---------|-------|--------|-------|
| Standard | $1,000 USDT (one-time) | 1 | 1 |
| Premium | $10,000 USDT (one-time) | 10 | 10 |
Perpetual license, full source code, free updates 5 years, technical support, governance tokens on blockchain, ready document pack for regulator.
More: [Terms of Purchase and Service](./service-terms.md)
---
## Documentation
**Product:**
- [AI Agents](./ai-assistant.md) — architecture, agent examples, setup
- [Blockchain for Business](./blockchain-for-business.md) — asset tokenization, use cases
- [Security](./security.md) — multi-layer protection, compliance
- [Terms of Service](./service-terms.md) — licensing, support, warranties
- [FAQ](./FAQ.md) — frequently asked questions
**General:**
- [Main page](../README.md)
- [Legal documentation](../legal.en/README.md)
---
**Contacts:** info@hb3-accelerator.com · https://hb3-accelerator.com · [GitHub](https://github.com/VC-HB3-Accelerator)
**© 2024-2025 Alexander Viktorovich Tarabanov. All rights reserved.**
**Last updated:** 2026-02-19

109
docs.en/back-docs/MULTICHAIN_GOVERNANCE_TOKEN_TRANSFER.md Normal file
View File

@@ -0,0 +1,109 @@
**English** | [Русский](../../docs.ru/back-docs/MULTICHAIN_GOVERNANCE_TOKEN_TRANSFER.md)
# DLE Multichain Governance Token Transfer
## Overview
The DLE multichain governance system lets token holders create proposals to transfer tokens from their wallet to another address (or treasury) through voting in every network where the DLE contract is deployed. Each network has its own quorum; proposals are coordinated and shown as a single card.
## Architecture
- One DLE can be deployed on several chains (e.g. Sepolia, Arbitrum Sepolia, Base Sepolia).
- Each DLE contract per chain runs independently.
- Proposals are created, voted on, and executed **per chain**.
- Proposal IDs are **unique per chain** (e.g. ID=1 on Sepolia and ID=1 on Arbitrum Sepolia are different).
Proposals with the same description and initiator are **grouped** into one card showing status and voting in all chains.
---
## Process: Token transfer
### Stage 1: Create proposal
1. User fills form: description, recipient address, amount (tokens), voting duration, connected wallet (sender).
2. System determines all networks with deployed DLE.
3. **Sequential creation per chain:** switch MetaMask to each network (1 s delay), call DLE `createProposal(...)`, get proposal ID for that chain, delay 3 s (5 s Base Sepolia) after tx. Retry on RPC errors (e.g. up to 3 with exponential backoff).
4. User signs **one transaction per chain** in MetaMask.
**Contract:** `createProposal(description, duration, operation, targetChains, timelockDelay)`.
**Operation:** `_transferTokens(sender, recipient, amount)` — **signature `_transferTokens(address,address,uint256)`**. All three parameters required. **Sender** must be initiator (from `signer.getAddress()` when creating in **that** chain). **Amount** must be in wei: `ethers.parseUnits(amount.toString(), 18)`.
**Encoding (ethers.js):** use Interface with `_transferTokens(address,address,uint256)` and encode sender (from signer for current chain), recipient, amountInWei. **Critical:** encode operation **inside** the loop over chains so sender is correct per chain.
**Result:** N proposals (one per chain), each with its own ID; UI shows one card with status per chain.
---
### Stage 2: Voting
1. User sees one card with all chains.
2. Chooses vote For or Against.
3. **Sequential voting:** for each active chain (state active, not executed/canceled): switch network, 1 s delay, **check token balance in that chain** (if none, skip with warning), call `vote(proposalId, support)` with **that chain’s proposal ID**, delay after tx.
4. One MetaMask signature per active chain.
**Contract:** `vote(proposalId, support)`. Use per-chain proposal ID. Quorum is per chain. Balance checked per chain; if no tokens in a chain, skip voting there.
---
### Stage 3: Execute proposal
**Condition:** Proposal can be executed only when it is **ReadyForExecution** (and quorum reached) **in every** chain where it is active.
1. System checks readiness in all chains.
2. **Sequential execution:** for each ready chain: switch network, 1 s delay, call `executeProposal(proposalId)` with **that chain’s ID**, delay after tx.
3. One signature per ready chain.
**Contract:** `executeProposal(proposalId)`. Operation `_transferTokens(sender, recipient, amount)`: sender = initiator (checked), recipient and amount from proposal. Tokens are transferred from initiator’s wallet.
---
## Cancel proposal
Only initiator can cancel, while proposal is active. **Sequential cancel** in all active chains (switch network, delay, `cancelProposal(proposalId, reason)`), one signature per chain.
---
## Important details
1. **Proposal IDs:** Each chain has its own counter. Same numeric ID on different chains = different proposals. UI stores per-chain IDs and uses them for vote/execute/cancel.
2. **Grouping:** Key `${description}_${initiator}`. One card = one logical proposal across chains.
3. **Quorum:** Independent per chain. Execution requires quorum **in all** chains.
4. **Sequential operations:** Create, vote, execute, cancel are done **one chain at a time** (no `Promise.all`) because MetaMask works with one network at a time.
5. **Errors:** Retry on retryable RPC errors; if one chain fails, continue others and report. On vote, skip chains where user has no balance (with warning).
6. **Security:** Sender must equal initiator on execute; balance checked per chain; state and data validated before each call.
7. **Token source:** Tokens are transferred **from the initiator’s wallet**, not from the contract balance.
---
## UI (summary)
Card: description, initiator, list of chains (name, status, proposal ID, For/Against, quorum), actions: Vote For/Against (if active), Execute (if ready in all), Cancel (if initiator). Statuses: Active, Ready for execution, Executed, Canceled, Expired.
---
## Contract functions (reference)
- `createProposal(description, duration, operation, targetChains, timelockDelay)` → proposalId
- `vote(proposalId, support)`
- `executeProposal(proposalId)`
- `cancelProposal(proposalId, reason)`
- `_transferTokens(sender, recipient, amount)` (internal)
---
## Encoding and implementation notes
- **Correct:** Encode `_transferTokens(sender, recipient, amountInWei)` **inside** the chain loop with `sender = await signer.getAddress()` for that chain. Use `ethers.parseUnits(amount.toString(), 18)`.
- **Wrong:** Encode once before loop; use `_transferTokens(address,uint256)`; omit sender; wrong parameter order in `createProposal`.
- **Wrong:** Use `Promise.all` for execute/vote across chains (MetaMask cannot handle multiple networks in parallel).
All critical encoding and multichain flow issues in the codebase are documented as fixed; implementation follows this spec and the contract.
---
## Conclusion
Multichain governance for DLE provides decentralized token transfer decisions with per-chain quorums and a single UI for managing proposals across all deployed networks.
**Important:** All critical bugs in operation encoding have been fixed; code matches the documentation and contract.

82
docs.en/back-docs/TASK_REQUIREMENTS.md Normal file
View File

@@ -0,0 +1,82 @@
**English** | [Русский](../../docs.ru/back-docs/TASK_REQUIREMENTS.md)
# Task: Multichain Governance System for DLE
## Status
- ✅ Transfer proposal form works
- ✅ Proposals created in all DLE chains
- ✅ Voting in each chain separately
- ✅ Quorum per chain
- ✅ Personal transfer from proposal initiator
- ✅ Proposals grouped by description + initiator
- ✅ Server coordination with cryptographic proofs
- ✅ No hardcoded chains — deployedNetworks from API
## Context
DLE (Digital Legal Entity) is a decentralized legal entity with contracts in multiple blockchain networks. The task is to implement token governance via multichain governance: token holders can transfer tokens through voting with quorum.
## Architecture
- **Frontend:** Vue.js with Web3
- **Backend:** Node.js for coordination and API
- **Smart contracts:** DLE contracts in each supported network
- **Database:** PostgreSQL for metadata
- **WebSocket:** Real-time sync across networks
## Supported networks
- Ethereum Sepolia (chainId: 11155111)
- Arbitrum Sepolia (chainId: 421614)
- Base Sepolia (chainId: 84532)
## Functional requirements
### 1. Transfer tokens proposal form
**URL:** `/management/transfer-tokens?address=<DLE_ADDRESS>`
**Fields:** Recipient address (required), Amount (tokens, required), Description (optional), Voting duration (days, required).
### 2. Proposal creation
1. Get `deployedNetworks` from API `/dle-v2`
2. Create proposals in all DLE networks (sequentially with MetaMask; one proposal per chain)
3. Encode operation: `_transferTokens(sender, recipient, amount)` — sender = initiator
### 3. Voting
1. Voting is per chain
2. Quorum per chain: `(forVotes / totalSupply) >= quorumPercentage`
3. Vote weight = voter’s token balance
### 4. Execution
1. Each contract checks its local quorum
2. Backend aggregates quorum results and can sign global status
3. Execution with global quorum proof or per-chain execution
## Technical spec (summary)
- **Proposal:** id, description, forVotes, againstVotes, executed, canceled, deadline, initiator, operation, targetChains, snapshotTimepoint, hasVoted
- **_transferTokens(sender, recipient, amount)** internal; emits TokensTransferredByGovernance
- **Backend:** QuorumCoordinator (collect results, generate global proof)
- **API:** GET /dle-v2, POST create/vote/execute proposal endpoints
- **Frontend:** TransferTokensFormView (validation, encode operation, create in all chains), DleProposalsView (grouped list, status per chain, vote/execute)
## Security
On-chain checks (balance, deadlines, quorum), cryptographic proofs for global quorum, validation, graceful degradation if a chain is down.
## Testing
Acceptance: form works; proposals in all chains; voting per chain; quorum per chain; transfer from initiator; server coordination; grouping; error handling. Cases: create in multichain; vote when one chain down; execute with global quorum; execute with partial quorum (must fail); sufficient/insufficient initiator balance.
## Deployment
Backend with RPC to all networks, DB, SSL, monitoring. Env: RPC URLs, DATABASE_URL, SERVER_PRIVATE_KEY for signing.
---
Fully functional multichain governance for DLE tokens is implemented, with decentralized decisions and optional trusted-server coordination with cryptographic proofs.

165
docs.en/back-docs/blockchain-integration-technical.md Normal file
View File

@@ -0,0 +1,165 @@
**English** | [Русский](../../docs.ru/back-docs/blockchain-integration-technical.md)
# Digital Legal Entity (DLE) Blockchain Integration
## Table of Contents
1. [Introduction](#introduction)
2. [Smart Contract Architecture](#smart-contract-architecture)
3. [DLE Core Contract](#dle-core-contract)
4. [Module System](#module-system)
5. [Multichain Architecture](#multichain-architecture)
6. [Voting (Governance) System](#voting-governance-system)
7. [Smart Contract Deployment](#smart-contract-deployment)
8. [Wallet Authentication](#wallet-authentication)
9. [Frontend Integration](#frontend-integration)
10. [Security](#security)
11. [Practical Examples](#practical-examples)
---
## Introduction
Digital Legal Entity (DLE) uses blockchain for **tokenized governance** (similar to a blockchain-based joint-stock company) and **transparent decision-making** via smart contracts.
### Why Blockchain in DLE?
1. **Governance like a joint-stock company** — decisions by token holders through on-chain voting
2. **Transparency** — all votes and operations recorded on blockchain
3. **Censorship resistance** — smart contract enforces token holder rights
4. **Immutability** — decision history cannot be altered
5. **Multichain support** — operation across multiple chains
### DLE Governance Model
| Aspect | Implementation |
|--------|----------------|
| **Voting** | Token holders (as shareholders) |
| **Quorum** | 51%+ of tokens to pass decisions |
| **Asset distribution** | Via voting (as in JSC) |
| **Parameter changes** | Via token holder voting |
| **Application code** | Proprietary (author) |
| **Updates** | Author develops; token holders vote on priorities |
### Supported Blockchains
DLE works with **EVM-compatible** networks: Ethereum (mainnet & testnets), Polygon, Arbitrum, BSC, Base, and others.
---
## Smart Contract Architecture
DLE ecosystem: **DLE Core Contract** (ERC20Votes, tokens, proposals, multichain) ↔ **Modules** (HierarchicalVotingModule, TreasuryModule, TimelockModule) ↔ **DLEReader** (batch reads, RPC optimization).
Standards: OpenZeppelin ERC20, ERC20Votes, ERC20Permit, ReentrancyGuard, ECDSA.
---
## DLE Core Contract
File: `backend/contracts/DLE.sol`
Structures: **DLEInfo** (name, symbol, location, coordinates, jurisdiction, okvedCodes, kpp, creationTimestamp, isActive), **Proposal** (id, description, forVotes, againstVotes, executed, canceled, deadline, initiator, operation, governanceChainId, targetChains, snapshotTimepoint, hasVoted).
### Main Features
- **Governance tokens (ERC20):** 1 token = 1 vote; transfers disabled (only via governance); EIP-712 for meta-transactions.
- **Voting (ERC20Votes):** snapshots (flash-loan protection), votes from past block, optional delegation.
- **Multichain:** same address across chains (deterministic deploy); voting on one chain; execution on target chains.
- **Modules:** mapping(bytes32 => address) modules, activeModules; add/remove only via voting.
### Operations Available via Voting
_addModule, _removeModule, _addSupportedChain, _removeSupportedChain, _transferTokens, _updateDLEInfo, _updateQuorumPercentage, _updateVotingDurations.
---
## Module System
### 1. HierarchicalVotingModule
DLE can hold tokens of other DLEs and vote in them. Functions: addExternalDLE, createProposalInExternalDLE, voteInExternalDLE.
### 2. TreasuryModule
Treasury and asset management. transferTokens(token, recipient, amount) only callable by DLE contract. getTokenBalance(token).
### 3. TimelockModule
Delayed execution (timelock), cancel before execution. scheduleProposal(proposalId, operation, delay), executeTimelockProposal(operationHash).
### 4. DLEReader
Batch read: getDLEFullInfo(dleAddress), getAllProposals(dleAddress).
---
## Multichain Architecture
Deterministic deploy: same address on all chains. Voting on one chain (governance chain); execution on target chains via executeWithSignatures(proposalId, operationHash, signers, signatures).
---
## Voting (Governance) System
**createProposal(description, duration, operation, chainId, targetChains, initiator)** — returns proposalId.
**vote(proposalId, support)** — true = For, false = Against.
**execute(proposalId)** — when deadline passed, quorum reached, For > Against, not executed.
**Quorum:** quorumPercentage of totalSupply; change only via voting.
---
## Smart Contract Deployment
**Script:** `backend/scripts/deploy/deploy-multichain.js` — multichain deploy, deterministic address, verification, retry, nonce management. Run: `yarn deploy:multichain`.
**Modules:** `backend/scripts/deploy/deploy-modules.js` — `yarn deploy:modules`. Config in DB (settings: supported_chain_ids, rpc_providers, dle_config). Verification via Etherscan API; supported: Etherscan, Polygonscan, Arbiscan, BSCScan, Basescan.
---
## Wallet Authentication
**SIWE (Sign-In with Ethereum):** request nonce → sign message in wallet → POST signature → backend verifies signature and token balance → session created. getUserAccessLevel(address) from contract balance and thresholds (editor, readonly).
---
## Frontend Integration
Connect wallet (MetaMask/WalletConnect), sign SIWE message, authenticateWithWallet. getDLEContract, createProposal, voteOnProposal, getProposal. Vue component example for proposal card and vote buttons.
---
## Security
See [DLE Security](../security.md). Summary: ReentrancyGuard, transfers disabled, vote snapshots, EIP-712, parameter validation, custom errors.
---
## Practical Examples
See [Blockchain for Business](../blockchain-for-business.md). Technical scenarios: multichain deploy, adding modules, hierarchical voting, treasury management.
---
## Conclusion
Blockchain in DLE provides: governance like a JSC, full transparency, multichain support, modular design, OpenZeppelin-based security.
### Resources
- [Main README](../../README.md)
- [FAQ](../FAQ.md)
- [Setup](./setup-instruction.md)
- [Terms](../service-terms.md)
- [Legal](../../legal.en/README.md)
**Contacts:** https://hb3-accelerator.com/ | info@hb3-accelerator.com | https://github.com/VC-HB3-Accelerator
---
**© 2024-2025 Alexander Viktorovich Tarabanov. All rights reserved.**
**Last updated:** October 2025

118
docs.en/back-docs/multi-agent-architecture.md Normal file
View File

@@ -0,0 +1,118 @@
**English** | [Русский](../../docs.ru/back-docs/multi-agent-architecture.md)
# Multi-Agent AI Architecture in DLE
> **Concept:** Separate specialized agents for different tasks, using one local Ollama model with different system prompts, rules, and interfaces.
---
## Table of Contents
1. [Architecture concept](#architecture-concept)
2. [Agent types](#agent-types)
3. [System architecture](#system-architecture)
4. [Agent configuration](#agent-configuration)
5. [Agent interfaces](#agent-interfaces)
6. [Knowledge base](#knowledge-base)
7. [Agent workflow](#agent-workflow)
---
## Architecture concept
### Principles
1. **One model, many agents** — all use one Ollama instance (e.g. qwen2.5:7b); differentiation by prompts and rules.
2. **Isolation** — each agent has its own prompt, rules, RAG tables, channels, route, permissions.
3. **Task specialization** — support (user Q&A), content editor (posts, articles), others (analyst, translator, procurement).
4. **Separate interfaces** — each agent has its own UI and access path.
---
## Agent types
### 1. Support agent
**Role:** Answer user messages. Uses RAG (FAQ, docs), strict mode (minimal generation), system prompt “professional support assistant”. Interface: chat (web, Telegram, email). Knowledge: FAQ, product docs, client knowledge base.
### 2. Content editor agent
**Role:** Create content on request. RAG: platform instructions, company style, examples. Creative mode. System prompt “content marketer and editor”. Interface: `/content-editor` page. Knowledge: platform instructions, style, examples, keywords, CTAs.
### 3. Other possible agents
Analyst (reports, trends), Translator (localization), Procurement (suppliers, terms).
---
## System architecture
Single Ollama model → multiple agents (Support, Content editor, Others), each with own prompt, rules, RAG, interface.
**Storage:** table `ai_agents` — id, name, role, description, system_prompt_encrypted, rules_id, selected_rag_tables, enabled_channels, interface_route, permissions_required, is_active. Links to `ai_assistant_rules` and RAG tables.
---
## Agent configuration
Steps: (1) Basic info — name, role, description. (2) System prompt. (3) Rules (from or new). (4) RAG tables. (5) Interface — route, permissions, channels. (6) Activate and test.
Example: Support — strict (temperature 0.3, searchRagFirst, no generateIfNoRag), FAQ + docs, chat. Content editor — creative (0.7, generateIfNoRag), instructions + style + examples, `/content-editor`, web only.
---
## Agent interfaces
**Support:** embedded in main chat (HomeView); auto on message; expand/collapse; history.
**Content editor:** page `/content-editor` — request field, content type, platform, generate → edit → save/export, history. Editor role only.
---
## Knowledge base
Support: FAQ, Documentation, Client knowledge base. Content editor: Platform instructions, Company style, Content examples, Keywords, CTAs. RAG search → context → LLM; each agent only sees its own tables.
---
## Agent workflow
**Support:** message → RAG search (FAQ, docs) → if found use it, else suggest operator → send reply.
**Content editor:** request + type + platform → RAG (instructions, style, examples, keywords) → generate content → show in UI → edit/save/export.
---
## Advantages
Specialization, flexibility, isolation, scalability (one model, many agents), clear responsibility.
---
## Comparison: single vs multiple agents
| | Single agent | Multiple agents |
|--|--------------|-----------------|
| Specialization | General, less precise | Per-task, more precise |
| Configuration | One set for all | Per task |
| Knowledge base | Shared | Isolated per agent |
| Interface | One | Per agent |
| Flexibility | Harder to adapt | Easy to add agents |
---
## Next steps
1. Create `ai_agents` table
2. Agent management service
3. Adapt AI Assistant for multiple agents
4. Content editor UI
5. Support agent (adapt existing)
6. Content editor knowledge base
7. Test both agents
---
**© 2024-2025 Alexander Viktorovich Tarabanov. All rights reserved.**
**Last updated:** January 2026

132
docs.en/back-docs/setup-ai-assistant.md Normal file
View File

@@ -0,0 +1,132 @@
**English** | [Русский](../../docs.ru/back-docs/setup-ai-assistant.md)
# AI Assistant Setup with Vector Search
## Full guide to launching the intelligent assistant
This document describes the step-by-step setup of the AI assistant for business tasks using spreadsheets and vector search.
---
## What you will have after setup
✅ Working AI assistant with local model (Ollama)
✅ Knowledge base for customer answers (FAQ)
✅ Supplier and procurement automation
✅ Staff training system
✅ Vector search over your data
✅ Significant time and cost savings
> 💡 **Economics:** See [DLE AI Agents](../ai-assistant.md) for architecture, examples, and savings.
---
## Time required
- **Quick setup:** 20–30 minutes (basic FAQ)
- **Full setup:** 1–2 hours (all features)
---
## Step 1: Install and run Ollama
1. **Settings** → **Integrations** → **Ollama** → **Details**
2. Check status: “Ollama is running” or “Ollama API not responding”
3. If not running: `docker-compose up -d ollama` or `ollama serve`
4. **Install model:** e.g. qwen2.5:7b (recommended), llama2:7b, mistral:7b
5. **Install embedding model:** mxbai-embed-large:latest (recommended) or nomic-embed-text:latest
> ⚠️ Embedding model is required for RAG (vector search).
---
## Step 2: Create knowledge base (spreadsheets)
### 2.1 FAQ table
1. **Tables** → **+ Create table**
2. Name: e.g. “FAQ – Frequently asked questions”, description for AI
3. **Add columns:**
- **Question** — type Text, **purpose: Question for AI** (required for RAG)
- **Answer** — type Text, **purpose: Answer for AI**
- **Product** (optional) — Multiselect, purpose: Product filter
- **Tags** (optional) — Multiselect, purpose: User tags
- **Priority** (optional) — Number, purpose: Priority
### 2.2 Fill with sample Q&A
Add rows: e.g. “How to pay?” / “We accept card, PayPal, bank transfer…”; “Delivery time?” / “3–5 business days…”; “Return policy?” / “Within 14 days…”. Minimum ~20–30 questions recommended.
### 2.3 Enable as AI source
In table settings enable **“Use as source for AI”** and save. Table is then indexed for vector search.
---
## Step 3: AI provider (Ollama) settings
1. **Settings** → **Integrations** → **Ollama**
2. Base URL: Docker `http://ollama:11434`, local `http://localhost:11434`
3. **LLM model:** e.g. qwen2.5:7b
4. **Embedding model:** mxbai-embed-large:latest
Save.
---
## Step 4: AI Assistant settings
1. **Settings** → **Integrations** → **AI Assistant** → **Details**
2. **System prompt** — e.g. “You are a professional support assistant. Answer from the knowledge base. If not found, suggest contacting an operator. Always end with ‘How else can I help?’”
3. **Models:** select same LLM and embedding as above
4. **Selected RAG tables:** choose your FAQ table
5. **Rules (JSON):** e.g. `searchRagFirst: true`, `generateIfNoRag: true`, `temperature: 0.7`, `maxTokens: 500`
6. **RAG search:** e.g. Hybrid, max results 5, relevance threshold 0.1; optional keyword extraction, fuzzy search, stemming
Save.
---
## Step 5: Test
1. **RAG tester** (on assistant settings page): choose table, ask e.g. “How to pay?” → check answer and score (good: about -300 to 0).
2. **Web chat:** open main page, ask e.g. “What is the delivery cost?” — answer should come from your FAQ.
3. Try questions inside and outside the knowledge base; test with typos (fuzzy search).
---
## Step 6 (optional): Extra tables and channels
- **Suppliers table:** columns for company, category, contact, email, phone, prices, payment terms, delivery, rating. Enable as AI source; add prompt instructions for “TOP-3 suppliers” style answers.
- **Staff knowledge base:** questions/answers by category (Sales, HR, IT). Same RAG setup.
- **Telegram:** create bot via @BotFather, add token and username in Settings → Integrations → Telegram; link to AI assistant.
- **Email:** IMAP/SMTP in Settings; for Gmail use app password. Link to AI assistant.
---
## Step 7: Monitoring and tuning
- **Status:** Settings → AI Assistant → Monitoring: Backend, Postgres, Ollama, Vector Search should be green.
- **RAG quality:** Score -300…0 = good; >300 = not found. Improve by adding variants of questions and adjusting relevance threshold.
- **Speed:** Smaller model or fewer RAG results if responses are slow.
---
## Troubleshooting
- **Ollama not responding:** `docker-compose restart ollama`, check logs.
- **Wrong answers:** Check RAG score; add more questions; lower relevance threshold; ensure column purposes “Question for AI” and “Answer for AI”.
- **Vector search error:** Install embedding model; on table page use “Rebuild index”; ensure table is enabled as AI source.
- **Wrong language:** Add “Always answer in English” (or desired language) to system prompt; choose suitable model (e.g. qwen2.5:7b for multilingual).
---
## Technical reference (developers)
- **DB:** ai_providers_settings, ai_assistant_settings, ai_assistant_rules (encrypted fields, RAG tables, rules JSON).
- **API:** GET/PUT settings per provider and assistant; rules CRUD; Ollama status, models, install.
- **Flow:** Message → UnifiedMessageProcessor → language check → dedup → load settings and rules → RAG search → generate LLM response → return. Security: AES-256 for sensitive fields; admin-only for settings.
---
**© 2024-2025 Alexander Viktorovich Tarabanov. All rights reserved.**
Version: 1.0.0 | Date: October 25, 2025

157
docs.en/back-docs/setup-instruction.md Normal file
View File

@@ -0,0 +1,157 @@
<!--
Copyright (c) 2024-2025 Alexander Viktorovich Tarabanov
All rights reserved.
This software is proprietary and confidential.
Unauthorized copying, modification, or distribution is prohibited.
For licensing inquiries: info@hb3-accelerator.com
Website: https://hb3-accelerator.com
GitHub: https://github.com/VC-HB3-Accelerator
-->
**English** | [Русский](../../docs.ru/back-docs/setup-instruction.md)
# Digital Legal Entity — Application Setup Guide
## Full system initialization
This document describes the full process of preparing the application for use with blockchain, smart contracts, and the access control system.
---
## Step 1: Install software
1. Clone the project repository to your machine
2. Run the application via Docker Compose or locally as per your setup
3. Open the web app in a browser: `http://localhost:9000` (production) or `http://localhost:5173` (dev)
---
## Step 2: Connect crypto wallet
1. Ensure a browser wallet is installed (MetaMask, WalletConnect, or similar)
2. Create or import an account that holds governance tokens
3. In the web app click **"Connect wallet"**
4. Choose wallet type and confirm connection
5. After success you will see your account address in the top corner
---
## Step 3: Add RPC providers (Security → RPC providers)
1. Go to **Settings** → **Security** tab
2. Find **"RPC providers"**
3. Click **"Add"**
4. For each blockchain network fill in:
- **Network name** (e.g. Ethereum, Polygon, BSC)
- **RPC URL** (e.g. `https://eth-mainnet.g.alchemy.com/v2/YOUR-API-KEY`)
- **Chain ID**
5. Click **"Save"** for each provider
6. The system will verify the connection
> ⚠️ **Important:** Obtain API keys from providers (Alchemy, Infura, QuickNode, etc.) before adding
---
## Step 4: Multichain smart contract deployment
1. Go to **Settings** → **Blockchain** tab
2. Fill in the form
3. Click **"Start deployment"**
---
## Step 5: Complete deployment and save contract address
1. Wait for deployment to finish (typically 30–120 seconds)
2. After success the **"Contract management"** page opens
3. **Copy the deployed contract address** (e.g. `0x742d35Cc6634C0532925a3b844Bc...`)
---
## Step 6: Configure authentication via smart contract
1. Return to **Settings** → **Authentication** tab
2. In **"Smart contract address"** paste the address from step 5
3. Set access thresholds:
- **Minimum tokens for editing** (e.g. 100)
- **Minimum tokens for viewing** (e.g. 1)
---
## Step 7: AI and database configuration
1. Go to **Settings** → **AI** tab
2. Open **"Database"** subsection
3. Change default passwords
4. Click **"Generate new encryption key"**
- The system creates a cryptographic key
- **Store the key securely** (needed for data recovery)
---
## Step 8: Internet access (optional)
If you need external access to the web app:
1. Go to **Settings** → **Server** tab
2. Select **WEB SSH** or another suitable service
3. Fill in the form to migrate the local app to a host with public IP and domain
4. Click **"Publish"**
5. Wait for migration to complete
> ℹ️ Requires a registered domain and DNS access
---
## Step 9: Legal documents for personal data
### 9.1 Company legal information
1. Go to **CRM** → **Content**
2. Open the **"Company legal information"** form
3. Fill in: full name, short name, legal form, legal address, actual address, Tax ID/OGRN/KPP, contacts, DPO responsible person, applicable jurisdiction (GDPR, CCPA, etc.)
4. Click **"Save"**
### 9.2 Document templates
1. In **Content** go to **"Templates"**
2. Select templates: Privacy Policy, User Agreement, Consent to data processing, Cookie policy
3. For each: **Preview**, edit if needed, then **Publish for public** / **Publish for internal** / **Print** (PDF)
4. Confirm; documents are added to the app
> ⚠️ Consult a lawyer before publishing to ensure legal compliance
---
## Application ready
After these steps the application is fully configured.
**Next:**
- AI assistant setup: see `setup-ai-assistant.md`
- Smart contract management: see `manage-smart-contracts.md`
---
## Security tips
✓ Store contract addresses and encryption keys securely
✓ Use strong DB passwords
✓ Back up configuration regularly
✓ Never share wallet private keys
✓ Use HTTPS in production
---
## Documentation
- [AI Agents](../ai-assistant.md)
- [Blockchain for Business](../blockchain-for-business.md)
- [Security](../security.md)
- [Blockchain technical docs](./blockchain-integration-technical.md)
- [FAQ](../FAQ.md)
- [Application description](../application-description.md)
**Support:** https://hb3-accelerator.com/ | info@hb3-accelerator.com

68
docs.en/back-docs/system-messages-management.md Normal file
View File

@@ -0,0 +1,68 @@
**English** | [Русский](../../docs.ru/back-docs/system-messages-management.md)
# Technical Specification: System Messages Management
## 1. Goal and context
- Manage display of system messages on the home page (`/`, `HomeView.vue`) and provide an admin UI for creating and moderating them in Content (`/content`, `ContentListView.vue`).
- System messages support statuses “draft” and “published”, are stored in the database, and exposed via REST API.
## 2. Current state
- Home is built by `HomeView.vue` with assistant chat (`ChatInterface.vue`); system messages are those with `message.role === 'system'` (`Message.vue`).
- Content (`ContentListView.vue`) has cards: Create page, Templates, Published, Settings, Internal. No entity or API for system messages yet; `pagesService.js` only handles pages (`/pages`).
## 3. User scenarios
- **View on home (/):** Published system messages loaded into assistant chat as collapsible cards with clickable title. On click: expand to show full text **or** send a prepared AI assistant reply (content stored with message, chosen by `reply_type`). Messages visually marked as system; optional “read” state in localStorage.
- **Content section:** New card “System messages” with “Details” → `/content/system-messages/table` (user table, no separate dashboard). Table: rows per message, checkboxes for bulk: publish, unpublish, move to draft, delete. Row “Details” → view/edit form.
- **Create/Edit:** Routes `/content/system-messages/create`, `/content/system-messages/:id/edit`. Form: title, summary, main content (Markdown/HTML), reply type (`inline` | `assistant_reply`), assistant reply content (when `assistant_reply`), severity (info/warning/danger), publish_at, expire_at, visible to guests. Buttons: Save as draft, Publish; on edit: Update, Unpublish, Delete. Validation: title and main content (or assistant reply when applicable) required; expire_at ≥ publish_at.
## 4. UI requirements
- In `ContentListView.vue` add “System messages” card to `management-blocks`.
- Table page: BaseLayout, scoped styles; sort, filter by status, search by title; header and row checkboxes; action bar when selection exists; “Create message” opens create form.
- Form: rich text (at least Markdown), preview, character/word count; reply type switch with conditional “Assistant reply” field; severity presets (icon/color).
## 5. Routing and components
- Routes: `/content/system-messages/table` → SystemMessagesTableView; `/content/system-messages/create` → SystemMessageCreateView; `/content/system-messages/:id` → SystemMessageDetailsView; `/content/system-messages/:id/edit` → SystemMessageEditView.
- Components under `src/views/content/system-messages/` and shared in `src/components/system-messages/`.
- Service: `src/services/systemMessagesService.js`.
## 6. API and data
- **Table** `system_messages`: id (uuid), title, summary, content, reply_type (inline | assistant_reply), assistant_reply_content, severity (info | warning | danger), status (draft | published), visible_for (all | authenticated | guests), publish_at, expire_at, created_at, updated_at, created_by, updated_by, slug.
- **REST:** GET /system-messages (pagination, filters), GET /system-messages/published (public, by date/audience), GET /system-messages/:id (editors), POST, PATCH, DELETE; optional POST publish/unpublish.
- Auth and permission (e.g. MANAGE_LEGAL_DOCS) on protected endpoints. New migration, validation (e.g. Joi), logging (winston).
## 7. Frontend logic
- **HomeView:** On load, fetch published messages (by audience) via `systemMessagesService.getPublished({ includeExpired: false })`; cache; on expand either show content (inline) or trigger sending assistant_reply_content; optional “read” in localStorage.
- **ContentListView:** Add “System messages” card.
- List: pagination, sort by date, status badges.
- Form: client-side validation; on publish redirect to list; on draft save stay with notification.
## 8. Security and access
- Create/edit for roles with PERMISSIONS.MANAGE_LEGAL_DOCS.
- GET /system-messages/published: filter by status=published, publish_at ≤ now, expire_at > now (or null), visible_for by guest/auth.
- In chat response hide created_by, updated_by, internal fields. CSRF, CORS, rate-limit as in existing routes.
## 9. Testing
- Backend: CRUD tests in tests/system-messages/*.test.js (Mocha); filters and role access; migration rollback/apply.
- Frontend: unit tests for form and list if present; E2E: draft → publish → visible on home.
- Regression: existing content list and assistant chat still work; `yarn lint`, `yarn test`.
## 10. Integration and DevOps
- Update docker-compose if needed (e.g. migrations on startup). Document new env vars in README and setup-instruction. Optional seed script for test messages.
## 11. Open points
- Audit history (system_messages_history)? Multi-language? WebSocket event for new messages (wsHub)?
## 12. Deliverables
Backend: routes, controllers, service, migration. Frontend: pages, service, updated routes, HomeView, ContentListView. Docs: README, application-description or tables-system if schemas change, this spec.

188
docs.en/back-docs/tables-system.md Normal file
View File

@@ -0,0 +1,188 @@
**English** | [Русский](../../docs.ru/back-docs/tables-system.md)
# DLE Spreadsheet (Tables) System
> **Internal working document**
---
## Table of Contents
1. [System overview](#system-overview)
2. [Database architecture](#database-architecture)
3. [Field types](#field-types)
4. [Features](#features)
5. [Table relations](#table-relations)
6. [AI (RAG) integration](#ai-rag-integration)
7. [API reference](#api-reference)
8. [Examples](#examples)
9. [Security](#security)
---
## System overview
### What it is
The tables system in DLE is a **full database with a GUI** — similar to **Notion Database** or **Airtable** — built into the app.
### Features
- 6 field types (text, number, relation, lookup, multiselect, multiselect-relation)
- Relations between tables (1:1, 1:N, N:N)
- Lookup and data rollup
- Filtering and sorting
- Real-time updates (WebSocket)
- AI integration (RAG search)
- AES-256 encryption for data
- Placeholders for API access
- Cascade delete, bulk operations
### vs Excel/Sheets
| | Excel/Sheets | DLE Tables |
|-|--------------|------------|
| Data typing | Weak | Strict (6 types) |
| Relations | No | Yes (relation, lookup) |
| AI search | No | Yes (RAG, vector) |
| Real-time | Partial | Full (WebSocket) |
| Encryption | No | AES-256 |
| API | Limited | Full REST |
---
## Database architecture
### Main tables (PostgreSQL)
- **user_tables:** id, name_encrypted, description_encrypted, is_rag_source_id, created_at, updated_at
- **user_columns:** id, table_id, name_encrypted, type_encrypted, placeholder_encrypted, placeholder, options (JSONB), order, created_at, updated_at
- **user_rows:** id, table_id, order, created_at, updated_at
- **user_cell_values:** id, row_id, column_id, value_encrypted, created_at, updated_at, UNIQUE(row_id, column_id)
- **user_table_relations:** id, from_row_id, column_id, to_table_id, to_row_id, created_at, updated_at
Cascade: delete table → columns, rows, cell values, relations. Indexes on relation columns for performance.
---
## Field types
1. **Text** — plain text
2. **Number** — numeric
3. **Multiselect** — multiple choices from a list (options.choices)
4. **Multiselect-relation** — multiple rows from another table (options: relatedTableId, relatedColumnId); stored in user_table_relations
5. **Relation** — single row in another table (1:1 or N:1); one row in user_table_relations
6. **Lookup** — value pulled from related table (options: relatedTableId, relatedColumnId, lookupColumnId)
---
## Features
### CRUD
- **Create table:** POST /tables (name, description, isRagSourceId); name/description encrypted
- **Add column:** POST /tables/:id/columns (name, type, order, purpose, options)
- **Add row:** POST /tables/:id/rows (auto index for RAG if applicable)
- **Save cell:** POST /tables/cell (row_id, column_id, value); upsert; update vector store
- **Delete row:** DELETE /tables/row/:rowId (rebuild vector store)
- **Delete column:** DELETE /tables/column/:columnId (cascade relations and cell values)
- **Delete table:** DELETE /tables/:id (admin; cascade all)
### Filtering
- GET /tables/:id/rows?product=… — by product
- ?tags=… — by user tags
- ?relation_&lt;columnId&gt;=&lt;to_row_ids&gt; — by relation
- ?multiselect_&lt;columnId&gt;=… — by multiselect
### Placeholders
Auto-generated from column name (transliteration, uniqueness). Used for API: GET /tables/:id/data?fields=placeholder1,placeholder2.
### Order
PATCH /tables/:id/rows/order with array of { rowId, order }.
### WebSocket
Events: table-update, table-relations-update, tags-update. Frontend subscribes and reloads when needed.
### Bulk
Select rows (checkboxes); bulk delete or other actions; after delete, vector store rebuilt as needed.
---
## Table relations
- **N:1 (Relation):** one column links to one row in another table (e.g. Task → Project).
- **N:N (Multiselect-relation):** multiple links (e.g. Contacts → Tags).
- **Lookup:** show a field from the related row (e.g. Order → Product → Product.price).
API: GET/POST/DELETE on /tables/:tableId/row/:rowId/relations (column_id, to_table_id, to_row_id or to_row_ids for multiselect).
---
## AI (RAG) integration
- Tables (or selected tables) can be **RAG sources**. Columns with **purpose** “question” and “answer” are used for vector indexing.
- On row create/update: rows with question/answer are upserted into vector store (FAISS). On row delete: rebuild for that table.
- **Rebuild index:** POST /tables/:id/rebuild-index (admin). Reads question/answer columns and rebuilds vector index.
- **RAG flow:** User asks → vector search in table(s) → top_k results with score and metadata (answer, product, userTags, priority) → LLM gets context and generates reply. Filter by product/tags in metadata if needed.
---
## API reference (summary)
- **Tables:** GET/POST /tables, GET/PATCH/DELETE /tables/:id
- **Columns:** POST /tables/:id/columns, PATCH/DELETE /tables/column/:columnId
- **Rows:** POST /tables/:id/rows, DELETE /tables/row/:rowId, PATCH /tables/:id/rows/order
- **Cell:** POST /tables/cell (upsert)
- **Filtered rows:** GET /tables/:id/rows?…
- **RAG:** POST /tables/:id/rebuild-index
- **Relations:** GET/POST/DELETE …/row/:rowId/relations
- **Placeholders:** GET /tables/:id/placeholders, GET /tables/placeholders/all
---
## Examples
### FAQ for AI
Create table with columns: Question (purpose: question), Answer (purpose: answer), Product (multiselect, purpose: product), Tags (multiselect, purpose: userTags). Add rows; enable as RAG source. AI will search by question and return answer; filter by product/tags.
### CRM
Tables: Companies (name, website, industry), Contacts (name, email, company relation, company website lookup). Relation from Contact to Company; lookup “company website” from Company via relation.
### Tasks
Tables: Projects (name, status), Tasks (name, project relation, priority, status). Filter tasks by project: GET .../rows?relation_&lt;projectColumnId&gt;=&lt;projectRowId&gt;.
---
## Security
- **Encryption:** AES-256 for name_encrypted, description_encrypted, value_encrypted, placeholder_encrypted. placeholder and options can be plain for indexing/performance.
- **Access:** View for authenticated users; edit for users with edit rights; delete and rebuild-index for admins (e.g. userAccessLevel.hasAccess). Token balance checked for access level.
- **SQL:** Parameterized queries only. Validate types, existence, uniqueness (e.g. placeholder). Cascade deletes to avoid orphaned data. Optional rate limiting on tables routes.
---
## Performance
- Parallel queries for table meta, columns, rows, cell values where possible. Indexes on user_table_relations. UNIQUE(row_id, column_id) for fast upsert. WebSocket instead of polling. Optional server-side cache for frequent GET /tables/:id.
Typical: GET /tables 50–100 ms, GET /tables/:id 150–300 ms, POST cell 100–200 ms, rebuild-index 1–5 s. Tables up to ~10k rows fine; larger may need pagination/lazy load.
---
## Limits and future
Current: no server-side pagination, no formulas, no grouping, no change history, limited server-side sort. Possible: pagination, sort params, formula fields, audit table, export/import, table templates.
---
**© 2024-2025 Alexander Viktorovich Tarabanov. All rights reserved.**
Version: 1.0.0 | Date: October 25, 2025 | Status: Internal

231
docs.en/blockchain-for-business.md Normal file
View File

@@ -0,0 +1,231 @@
**English** | [Русский](../docs.ru/blockchain-for-business.md)
# Blockchain Integration for Business: Solving Real Problems
## Table of Contents
1. [Introduction: Why Business Needs Blockchain](#introduction-why-business-needs-blockchain)
2. [Smart Contract as Universal Identifier](#smart-contract-as-universal-identifier)
3. [Asset Tokenization](#asset-tokenization)
4. [Solving Governance Problems](#solving-governance-problems)
5. [Financial Operations Without Banks](#financial-operations-without-banks)
6. [Transparency and Trust](#transparency-and-trust)
7. [Automation and Cost Reduction](#automation-and-cost-reduction)
8. [Practical Use Cases](#practical-use-cases)
9. [Economic Impact](#economic-impact)
---
## Introduction: Why Business Needs Blockchain
### Traditional Business Problems
| Problem | Consequences | Costs |
|---------|--------------|-------|
| Multiple bank accounts | Complex accounting, fees | 2-5% of turnover |
| Bureaucracy | Slow decisions, paperwork | 20-30% of time |
| Opaque governance | Shareholder conflicts, corruption | Up to 40% of value |
| Illiquid assets | Cannot quickly sell/divide | Lost opportunities |
| Geographic restrictions | Difficulties with international partners | Missed profit |
| Slow transactions | 3-7 days for bank transfers | Capital freeze |
### Solution: Digital Legal Entity on Blockchain
DLE turns a company into a **digital organization** with blockchain identity:
- One smart contract address = full company identification
- Any assets tokenized and easily manageable
- Transparent governance through voting
- Instant financial operations without intermediaries
- Global availability 24/7
---
## Smart Contract as Universal Identifier
### Concept: One Address for Everything
In traditional business, a company has many identifiers: Tax ID/EIN, bank accounts (local currency, USD, EUR), email, phone, legal address, multiple accounting systems.
**With DLE:** one smart contract address (e.g. `0x742d35Cc6634C0532925a3b844Bc9377F91cAB6C`) replaces everything: tax identifier, bank account (multi-currency), email/phone for communications, legal identity, asset accounting system.
### Key Benefits
- **Tax identifier:** one address in all countries; link to Tax ID/EIN/VAT stored in contract; instant verification, impossible to forge.
- **Bank account:** address accepts USDT, USDC, ETH, any ERC20; fees 50-100x lower; transactions in 30 seconds; 24/7 operation.
- **Communications:** contract address = message address; cryptographic signatures; omnichannel integration (blockchain, Telegram, email, web).
---
## Asset Tokenization
**Tokenization** — turning any asset into a digital token on blockchain: fast buy/sell, fractional ownership, exchange, value tracking, instant transfer worldwide.
### Asset Types
| Asset | Traditional problem | DLE solution |
|-------|---------------------|--------------|
| Real estate | Illiquidity, 3-6% fees, cannot divide | Tokens = shares; sale in 30 sec; 0.1% fee; auto rent distribution |
| Shares and equity | IPO expensive and slow; LLC shares illiquid | “IPO” in 1 day; $100-1,000 instead of $500,000+; auto dividend payouts |
| IP (patents, music) | Complex licensing, opaque royalties | Tokens = revenue shares; automatic royalties; secondary market |
| Goods and inventory | “Dead” capital in warehouse | Tokens = shares in goods; liquidity; hedging |
| Jewellery, art | High entry barrier | Fractional ownership from $20; liquidity; transparent custody |
### Treasury Model
Company assets are placed in the Treasury Module of the smart contract. Token holders own shares proportionally to tokens. Asset income is distributed automatically.
---
## Solving Governance Problems
### Traditional Issues
- **Opacity:** closed meetings, no record of decisions, votes unverifiable.
- **Slowness:** from proposal to registration — 3 months.
- **High costs:** $31,500-161,000/year (accountant, lawyer, notary, registry, audit).
- **Corruption:** conflicts of interest hard to track.
### DLE Solution
- Every proposal (Proposal) is public: ID, description, initiator, For/Against votes, date, result.
- Voting 1-7 days instead of 3 months; automatic execution in 30 seconds.
- Costs: $200-2,000/year (gas, RPC, hosting) instead of $31,500-161,000.
- Conflicts of interest detected automatically (ownership transparency).
### Hierarchical Governance
DLE can hold tokens of other DLEs (holding). Parent company votes in subsidiaries automatically; consolidated governance; transparent structure; auto dividends bottom-up.
---
## Financial Operations Without Banks
### Comparison
| Parameter | Bank | DLE (crypto) |
|-----------|------|---------------|
| Transfer time | 3-7 days | 30 sec - 5 min |
| Fee | $25-50 + 2-5% conversion | $0.10-5 |
| Operating hours | Mon-Fri, 9:00-18:00 | 24/7/365 |
| Freezes | Possible | Not possible |
**Example:** $100,000 transfer to China — traditionally $3,080 in fees + 5 days; with DLE (USDT) — $2 + 30 seconds.
### DLE Capabilities
- **Multi-currency treasury:** one address holds USDT, USDC, EURC, ETH, BTC, tokenized assets.
- **Auto payouts:** dividends and salaries — one transaction, everyone receives in 30 seconds.
- **Global payments:** no geographic limits (subject to local laws and taxes).
---
## Transparency and Trust
Blockchain is the source of truth. Every token holder sees in real time: treasury assets, liabilities, operation history. Impossible to hide expenses, withdraw funds secretly, or fake balance.
Every decision is recorded forever: initiator, votes, owners, status. History cannot be rewritten. Ownership transparency allows automatic detection of conflicts of interest.
DLE reputation: immutable operation history, partner ratings, public metrics, verified assets.
---
## Automation and Cost Reduction
### Removing Intermediaries
Traditional transaction: 7-12% fees + 3-7 days. Blockchain: $0.10-5, 30 seconds. Savings on $1M turnover: $69,500-119,500 (99%).
### Process Automation
| Process | Before | After |
|---------|--------|-------|
| Decision-making | 55-85 days, $2,000-10,000 | 1-7 days, $2-5 |
| Dividend payout | 10-17 days, $500-2,000 | 30 sec, $5-20 |
| Audit and reporting | $13,000-90,000/year | $0 (blockchain = continuous audit) |
| Escrow | $500-2,000 | Smart contract $5 |
| Multisig | Notary $100-500 | $2-10 |
---
## Practical Use Cases
### Case 1: Startup Raising Investment
**Situation:** tech startup seeking $500,000.
**Traditional:** 10-19 months; lawyers $20,000-50,000, valuers $5,000-10,000, registration $2,000-5,000. Total: $27,000-65,000.
**With DLE:** create DLE in 1 day; issue 10M tokens (70% founders, 30% investors); list on DEX in 3 days; deploy $100, listing $500. Total: 4 days + $600.
**Result:** 90x faster, 45-100x cheaper, access to global investors, instant liquidity.
### Case 2: Real Estate Fund
**Situation:** fund owns $10M office building, needs funds for new project.
**Traditional:** bank loan 12-18%, setup 2-3 months, valuation+lawyers $50,000; or sale 6-18 months, fee 3-5% ($300,000-500,000); or REIT $50,000-200,000, 6-12 months.
**With DLE:** tokenization in 1 day (10M tokens at $1); sell 30% in 2 weeks → $3M; rent $100,000/month auto-distributed (70% fund, 30% holders); cost $1,000.
**Result:** $3M in 2 weeks, asset retained (70%), passive income continues, cost $1,000 vs $50,000-200,000.
---
## Economic Impact
### Summary Table (business with $1M/year turnover, 10 employees, 5 shareholders)
| Item | Traditional | With DLE | Savings |
|------|-------------|----------|---------|
| Bank fees | $26,950/year | $1,200/year | $25,750 (96%) |
| Corporate governance | $54,000/year | $12,000/year | $42,000 (78%) |
| Raising investment (1 deal) | $50,000 | $600 | $49,400 (99%) |
| **Total direct savings** | | | **$117,150/year** |
| Additional profit from speed | — | ~$1,000,000 | Missed opportunities |
**ROI:** 1,117% on DLE adoption. Payback: < 1 month.
### Comparison with Competitors
| Solution | Cost/year | Fees | Speed | Transparency |
|----------|-----------|------|-------|--------------|
| Traditional business | $54,000+ | 3-7% | 3-7 days | Low |
| SaaS solutions | $12,000-60,000 | 2-5% | 1-3 days | Medium |
| DLE on blockchain | $1,200-3,000 | 0.01-0.5% | 30 sec | Full |
---
## Conclusion
Digital Legal Entity addresses fundamental business problems:
1. **Financial freedom:** operations without banks, instant transfers, 99% fee savings.
2. **Universal identity:** one address = all identifiers, cryptographic protection.
3. **Tokenization:** any asset liquid, fractional ownership from $1, global market 24/7.
4. **Transparent governance:** every shareholder sees everything, auto-execution, protection from corruption.
5. **Automation:** smart contracts instead of lawyers, 90-99% time and money savings.
**For a business with $1M/year turnover:** savings $117,000/year; additional profit ~$1,000,000; ROI 1,117%; payback < 1 month.
### Get Started
1. [Read the FAQ](../FAQ.md) — answers to common questions
2. [Install DLE](./back-docs/setup-instruction.md) — step-by-step guide
3. [Configure blockchain](./back-docs/blockchain-integration-technical.md) — technical documentation
4. [Get support](https://hb3-accelerator.com/) — we can help!
---
## Additional Resources
- [FAQ](../FAQ.md)
- [Installation](./back-docs/setup-instruction.md)
- [Blockchain technical documentation](./back-docs/blockchain-integration-technical.md)
- [Terms of Service](./service-terms.md)
- **Support:** https://hb3-accelerator.com/ | info@hb3-accelerator.com
---
**© 2024-2026 Alexander Viktorovich Tarabanov. All rights reserved.**
**Last updated:** February 2026

193
docs.en/security.md Normal file
View File

@@ -0,0 +1,193 @@
**English** | [Русский](../docs.ru/security.md)
# Digital Legal Entity (DLE) Security
## Table of Contents
1. [Introduction](#introduction)
2. [Security Model](#security-model)
3. [Token-Based Access Control](#token-based-access-control)
4. [Smart Contract Security](#smart-contract-security)
5. [Wallet Compromise Protection](#wallet-compromise-protection)
6. [Web Application Security](#web-application-security)
7. [Module Management](#module-management)
8. [Audit and Monitoring](#audit-and-monitoring)
9. [Security Recommendations](#security-recommendations)
10. [Attack Scenarios and Mitigation](#attack-scenarios-and-mitigation)
---
## Introduction
Digital Legal Entity (DLE) is built with **security at every layer**:
- Access control via blockchain tokens
- Smart contract protection from compromise
- Tokens cannot be stolen even if wallet is compromised
- Governance only through voting with quorum
### Key Security Principles
1. **Secure by default** — all actions denied until explicitly allowed
2. **Least privilege** — each entity gets only required rights
3. **Transparency** — all actions recorded on blockchain
4. **Immutability** — history cannot be forged
5. **Collective control** — critical operations only through voting
---
## Security Model
### Security Architecture
```
┌─────────────────────────────────────────────────────────────┐
│ DLE Protection Layers │
├─────────────────────────────────────────────────────────────┤
│ │
│ Layer 1: Blockchain (Immutable Base) │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ • DLE smart contract (audited, immutable) │ │
│ │ • Governance tokens (ERC20Votes) │ │
│ │ • Full operation history on blockchain │ │
│ │ • Rules cannot change without voting │ │
│ └───────────────────────────────────────────────────────┘ │
│ ↑ │
│ Layer 2: Web Application (Backend) │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ • Real-time token checks │ │
│ │ • Wallet authentication (SIWE) │ │
│ │ • Data encryption (AES-256) │ │
│ │ • Rate limiting and DDoS protection │ │
│ └───────────────────────────────────────────────────────┘ │
│ ↑ │
│ Layer 3: Frontend (Vue.js) │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ • Wallet connection │ │
│ │ • Transaction signing │ │
│ │ • XSS protection (DOMPurify) │ │
│ │ • CSRF tokens │ │
│ └───────────────────────────────────────────────────────┘ │
│ ↑ │
│ Layer 4: User │
│ ┌───────────────────────────────────────────────────────┐ │
│ │ • Wallet private key (MetaMask, WalletConnect) │ │
│ │ • Confirmation for each operation │ │
│ └───────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
```
### Threat Model
| Threat | Risk level | Mitigation |
|--------|------------|------------|
| **Wallet compromise** | Medium | Tokens cannot be transferred without voting |
| **Web app compromise** | Low | All rights checked on blockchain, governance via blockchain explorers |
| **Smart contract compromise** | Low | Audit, OpenZeppelin, immutability |
| **DDoS** | Medium | Rate limiting, CDN, backup servers |
| **Phishing** | High | User education, domain verification |
| **Insider threat** | Low | All actions through voting |
### Critical: Web Application Is Only an Interface
**Key DLE architecture point:**
The web app (frontend + backend) provides **convenience**. It may be compromised or unavailable — **but business assets remain protected**. Real control and assets are on the blockchain; you can manage via Etherscan/Polygonscan etc. and deploy a new frontend connected to the same contracts.
**If the web app is compromised:** assets stay on chain, contracts keep working, tokens cannot be stolen, governance is possible via blockchain explorers, and a new frontend can be deployed.
---
## Token-Based Access Control
**Without tokens, access to the application is NOT possible.**
Access flow: user connects wallet → backend checks token balance in smart contract → if no tokens → access denied; if tokens exist → access granted (level depends on amount).
### Access Levels
| Token balance | Access level | Rights |
|---------------|--------------|--------|
| **0 tokens** | ❌ No access | "No access" page only |
| **1+ tokens** | ✅ ReadOnly | View data |
| **100+ tokens** | ✅ Editor | Edit, create |
| **Any amount** | 🗳️ Voting | 1 token = 1 vote |
Token checks run on every request; balance is read from the contract. If tokens are transferred away, access is lost immediately; if received, access is granted. The check cannot be bypassed.
---
## Smart Contract Security
**CRITICAL:** Governance tokens **cannot** be transferred by normal means. `transfer`, `approve`, and `transferFrom` are disabled and revert. Tokens can only be moved through governance (voting with quorum). Transfers use snapshots for voting power to prevent flash-loan attacks. All parameters are validated; custom errors save gas.
---
## Wallet Compromise Protection
If an attacker obtains a private key: they cannot send tokens (transfer disabled), sell on DEX (approve disabled), or use transferFrom. They could only create a proposal to transfer tokens to themselves — which requires other token holders to vote and reach quorum, so it will usually fail.
Protections: Timelock (delayed execution so others can react), multisig for critical ops, and cold/hardware wallets for large holders.
---
## Web Application Security
- **SIWE (Sign-In with Ethereum):** nonce generated and stored encrypted; signature verified; private key never leaves wallet.
- **Data encryption:** AES-256 for wallet addresses, nonces, session data, private messages.
- **Rate limiting** on API and stricter limits on auth.
- **CSRF** and **XSS** (DOMPurify) protection.
- **Helmet.js** for secure headers.
- **Clean logs:** sensitive data (addresses, nonces) redacted.
---
## Module Management
Only the DLE smart contract can call module functions (`onlyDLE` modifier). Owner, backend, or attacker cannot call modules directly. Adding/removing modules is only through voting.
---
## Audit and Monitoring
All actions are recorded in contract events (ProposalCreated, ProposalVoted, ProposalExecuted, ModuleAdded, TokensTransferred). Backend subscribes to events and can alert token holders. Critical events can trigger email/Telegram and logging.
---
## Security Recommendations
**For token holders:** Use hardware wallet; store seed phrase safely; enable notifications; review every proposal; split tokens (hot 10–20%, cold 80–90%).
**For admins:** Regular updates; daily DB backups; log monitoring; encryption key rotation; firewall (only 80/443 if needed).
**For developers:** Audit contracts (Slither, Mythril); run tests and coverage; code review; `yarn audit` for dependencies.
---
## Attack Scenarios and Mitigation
**Phishing:** Backend validates domain in SIWE; frontend can warn if hostname is wrong. Users should check URL and use bookmarks.
**Backend compromise:** Token checks are on-chain; balances and rules cannot be changed by backend. Users can verify on Etherscan and manage via explorers.
**51% attack:** Timelock gives time to react; other holders can vote against or take legal action.
**Social engineering:** Frontend shows what is being signed; support never asks to sign messages. Users should never sign on request from “support”.
---
## Conclusion
DLE provides multi-layer protection: blockchain (tokens not stealable), audited contracts, quorum voting, timelock, backend checks, frontend hardening, and monitoring. Access is token-gated; tokens are protected even if wallet or web app is compromised; governance can continue via blockchain explorers.
### Next Steps
1. [Technical documentation](./back-docs/blockchain-integration-technical.md)
2. [Secure setup](./back-docs/setup-instruction.md)
3. [FAQ](../FAQ.md)
4. [Support](https://hb3-accelerator.com/)
---
**© 2024-2025 Alexander Viktorovich Tarabanov. All rights reserved.**
**Last updated:** October 2025

343
docs.en/service-terms.md Normal file
View File

@@ -0,0 +1,343 @@
**English** | [Русский](../docs.ru/service-terms.md)
# Digital Legal Entity — Terms of Purchase and Service
## Table of Contents
1. [Licensing Model](#1-licensing-model)
2. [Pricing](#2-pricing)
3. [Voting System](#3-voting-system)
4. [Updates and Maintenance](#4-updates-and-maintenance)
5. [Technical Support and Training](#5-technical-support-and-training)
6. [Refunds and Warranties](#6-refunds-and-warranties)
7. [Liability](#7-liability)
8. [Terms of Use](#8-terms-of-use)
9. [Security and Privacy](#9-security-and-privacy)
10. [Governance Smart Contract](#10-governance-smart-contract)
11. [Payment and Sellers](#11-payment-and-sellers)
12. [Changes to Terms](#12-changes-to-terms)
13. [Contacts](#13-contacts)
**Legal documents:** [legal.en/README.md](../legal.en/README.md) — license, copyright, attribution requirements.
---
## 1. Licensing Model
### 1.1. Core Principles
| Parameter | Value |
|-----------|-------|
| License type | Perpetual |
| Term | Unlimited |
| Updates | Free for 5 years for token holders |
| Revocation | License cannot be revoked by the company |
### 1.2. License and Tokens
Each DLE license is tied to a **governance token on the blockchain**. The token confirms the right to use the platform and grants a vote in product development.
| Parameter | 1 token | 10 tokens |
|-----------|---------|-----------|
| Number of licenses | 1 | 1 |
| Lines of business | 1 | 1 |
| Votes in voting | 1 | 10 |
| Service terms | Same | Same |
**Voting:** 1 token = 1 vote. Decisions are made by majority (51%+) via smart contract on the blockchain.
### 1.3. Line of Business
- One license — one line of business.
- Separate licenses required for multiple lines of business.
---
## 2. Pricing
### 2.1. Licenses
| Package | Price | Tokens | Votes |
|---------|-------|--------|-------|
| Standard | $1,000 USDT (one-time) | 1 | 1 |
| Premium | $10,000 USDT (one-time) | 10 | 10 |
All prices are **excluding taxes**. Taxes are the buyer’s responsibility (VAT, Sales Tax, Income Tax, etc. as per jurisdiction).
### 2.2. What’s Included in Both Licenses
- Perpetual right to use the platform
- Full source code and documentation
- Free updates for 5 years (for token holders)
- Technical support (SLA by issue priority)
- Governance tokens on the blockchain
- Vote in product development
- Access to online training sessions
- Ready document pack for the regulator
The only difference between packages is the number of tokens and thus votes.
### 2.3. Payment Methods
- **Cryptocurrency (USDT)** — directly or via authorized partners
- **Bank transfer** — in local currency via authorized dealers
- **Credit cards** — via partners’ payment systems
All transfer, conversion, and payment processing fees are borne by the buyer.
### 2.4. Purchase Process
1. Choose seller (authorized dealer or author directly)
2. Agree price in USDT or local currency equivalent
3. Receive payment details
4. Send payment
5. Confirmation and payment document
6. Receive token and platform access
---
## 3. Voting System
### 3.1. Process
1. **Proposal** — community proposes a new feature
2. **Registration** — vote is created in the smart contract on the blockchain
3. **Voting** — each token = 1 vote, For or Against
4. **Decision** — with 51%+ For, the feature is taken into development
### 3.2. Frequency
- Voting is open continuously (asynchronous)
- Quarterly review of results
- Development by priority (vote count)
### 3.3. Voting Portal
**URL:** https://hb3-accelerator.com/
Available: create proposals, vote, view results, track development status, voting history.
**Requirements:** wallet with tokens (MetaMask, WalletConnect, etc.).
---
## 4. Updates and Maintenance
### 4.1. Free Updates (5 Years)
For all license token holders from the token transfer date recorded on the blockchain:
- Bug fixes
- Performance improvements
- New features (approved by voting)
- Security updates
**Frequency:**
| Type | Frequency |
|------|------------|
| Security patches | As soon as found |
| Regular updates | Weekly (Wednesdays) |
| Major features | Per voting results |
### 4.2. Update Platform
**URL:** https://hb3-accelerator.com/
License holders can: download all versions, read release notes, get new version notifications, read migration documentation.
**Access requirement:** license token on wallet at request time.
---
## 5. Technical Support and Training
All license holders get access to support and training via the portal: https://hb3-accelerator.com/
Detailed support terms, training, online sessions, and platform setup are in the [accelerator program](https://github.com/VC-HB3-Accelerator/.github/blob/main/Версия%20на%20русском/accelerator-program.md).
---
## 6. Refunds and Warranties
### 6.1. General
License is perpetual — standard refund is not provided.
### 6.2. 70% Refund Program
**70% of the license price** may be refunded within **5 years** of purchase if all of the following are met:
1. More than **51% negative votes** in token holder voting
2. Complaints concern **lack of update releases**
3. Voting is conducted **via smart contract on the blockchain**
4. Request is submitted **within 5 years** of the license date
**Process:** request at hb3-accelerator.com → confirmation on smart contract → 70% refund within 30 days.
### 6.3. Payment Dispute
Within 30 days of payment — in case of calculation error, double payment, or other justified reasons.
---
## 7. Liability
### 7.1. Author’s Warranties
- License is perpetual (right to use not limited in time)
- Updates and basic maintenance free for 5 years
- Core functionality remains available
- Vote in product development
### 7.2. Not Guaranteed
- Specific new features (depend on voting)
- Specific release schedule
- Support when modifying source code
- Performance beyond recommended limits
### 7.3. Limitation of Author’s Liability
Author is not liable for: lost profit, indirect damages, data loss, business interruption, reputational harm, fines, or sanctions.
**Maximum liability:** not more than the license fee paid. Only direct damages from direct breach of contract are covered.
### 7.4. User Responsibility
User is responsible for: data backup, use in accordance with the license, protecting wallet private keys, compliance with applicable law, timely application updates.
---
## 8. Terms of Use
### Allowed
- Use for managing own business
- Deployment on own infrastructure
- Data backup
- Local configuration changes
- Voting on product development
- Transfer of license to heirs
### Prohibited
- Resale or sublicensing
- Using one license for more than one line of business
- Reverse engineering and source code modification
- Removal of copyright and license notices
- Sharing between independent organizations
- Educational use without permission
- Deploying SaaS based on the platform
---
## 9. Security and Privacy
| Mechanism | Description |
|-----------|-------------|
| TLS 1.3 | All connections encrypted |
| AES-256 | Critical data encrypted at rest |
| Key management | User controls encryption keys |
| GDPR | Compliance (with DPA) |
More: [DLE Security](./security.md)
---
## 10. Governance Smart Contract
### 10.1. Architecture
DLE uses an on-chain smart contract for licenses and voting:
- **ERC20** — each license is represented by governance tokens (1 or 10)
- **ERC20Votes** — built-in voting
- **ERC20Permit** — signatures for gasless transfers
- **Multichain** — voting supported across multiple networks
### 10.2. Voting via Smart Contract
**Creating proposals:** token holders only. Voting duration: 1 hour to 30 days.
**Process:** proposal → voting (1 token = 1 vote) → quorum 51%+ → execution.
**Execution:** via direct call on the voting chain or via signatures on other chains.
### 10.3. Contract Security
- ReentrancyGuard
- Tokens transfer only through governance
- Vote snapshots vs flash-loans
- EIP-712 signatures for contract wallets
- All parameters validated before execution
### 10.4. License Transfer
License = tokens tied to wallet address. Transfer = moving tokens to a new address through governance. New owner automatically gets voting rights.
---
## 11. Payment and Sellers
### 11.1. Authorized Sellers
Licenses are sold **only through companies** with official written authorization from the author.
**Seller requirements:** legal entity, signed contract, listed on hb3-accelerator.com, compliance with licensing terms.
### 11.2. Seller for Russian Federation
**LLC "ERAYTI"**
- OGRN: 1222600014383
- INN: 2636220809
- Address: 355007, Stavropol Krai, Stavropol, ul. Burmistrova, 65B, premises 2
- Contacts: 18900@эрайти.рф, +7 (968) 269-92-64
### 11.3. Direct Purchase from Author
- Email: info@hb3-accelerator.com
- Website: https://hb3-accelerator.com
- GitHub: https://github.com/VC-HB3-Accelerator
---
## 12. Changes to Terms
### For New Licenses
- Terms may change for new purchases
- 60 days’ notice before changes take effect
- Applies only to licenses purchased after the change date
### For Existing Licenses
- Your license terms **do not change** after purchase
- Fixed rights apply perpetually
- Backward compatibility is maintained
---
## 13. Contacts
- **Support portal:** https://hb3-accelerator.com/
- **Email:** info@hb3-accelerator.com
- **GitHub:** https://github.com/VC-HB3-Accelerator/DLE
- **Legal status:** Proprietary software (see [LICENSE](../LICENSE))
- **Legal documentation:** [legal.en/README.md](../legal.en/README.md)
---
## Additional Documentation
- [Platform description](./application-description.md)
- [AI Agents](./ai-assistant.md) — specialized agent system
- [Blockchain for Business](./blockchain-for-business.md) — digital asset registration and business use cases
- [DLE Security](./security.md) — multi-layer protection
- [FAQ](./FAQ.md) — frequently asked questions
---
**© 2024-2025 Alexander Viktorovich Tarabanov. All rights reserved.**
**Last updated:** February 2026