10 KiB
English | Русский
Digital Legal Entity (DLE) Security
Table of Contents
- Introduction
- Security Model
- Token-Based Access Control
- Smart Contract Security
- Wallet Compromise Protection
- Web Application Security
- Module Management
- Audit and Monitoring
- Security Recommendations
- 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
- Secure by default — all actions denied until explicitly allowed
- Least privilege — each entity gets only required rights
- Transparency — all actions recorded on blockchain
- Immutability — history cannot be forged
- 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
© 2024-2026 Alexander Viktorovich Tarabanov. All rights reserved.
Last updated: February 2026