Alex
9fc4c62052
Root README files removed from Docs; navigation now points to the org profile page. Co-authored-by: Cursor <cursoragent@cursor.com>
5.3 KiB
Proposal for Cooperation within a Regulatory Sandbox
Navigation: ← Contents · Sandbox description · Roles and current status
From: VC HB3 Accelerator
To: Competent authority for digital-asset regulation
Subject: Deployment of blockchain infrastructure with participant identification in the jurisdiction
1. Background
FATF recommendations (Travel Rule, 2023 update), the EU MiCA Regulation (effective 30.12.2024), and the practice of VARA (UAE) and SEC/CFTC (USA) set a common requirement: digital-asset operations must be tied to identified parties.
According to the World Bank and SSRN, as of January 2025 there are 199 regulatory sandboxes in 92 countries. 70% of them focus on blockchain and fintech. Yet most jurisdictions lack the basic infrastructure needed to meet those requirements:
- no blockchain registries linked to national legal-entity identifiers;
- no monitoring tools (blockchain scanners) for supervisory authorities;
- no venues for controlled testing of blockchain solutions with real businesses;
- no data-exchange protocols between registries of different jurisdictions.
2. Essence of the proposal
VC HB3 Accelerator proposes to deploy blockchain infrastructure with support for national identifiers in the jurisdiction within a regulatory sandbox.
The fund undertakes:
- registering a presence in an IT hub / special economic zone;
- integrating national identifiers (tax, accounting, banking, registration) into the operating system;
- deploying a blockchain registry and scanner on servers located in the jurisdiction;
- attracting participants (entrepreneurs, contractors, investors) through the accelerator program.
What is required from the regulator: a grant to open the presence and provision of national identifier lists for integration.
3. Operating system
The solution is based on the Digital Legal Entity (DLE) operating system: a personal OS template for a legal entity, local (on-premises) deployment. Product: README.md.
Key components:
Smart contracts with identifiers. At registration, a company binds regulator-set identifiers to the smart contract: tax (INN, EIN, TIN), accounting (OKVED, NAICS, NACE), banking (BIK, SWIFT, IBAN), registration (OGRN, Company Number, ABN). All subsequent on-chain operations are tied to an identified party.
Blockchain registry (EVM-compatible). A registry of transactions and smart contracts for the jurisdiction. Deployed on local servers; data does not leave the territory.
Blockchain scanner. An operations monitoring tool: search by transactions, addresses, company identifiers. Access for the supervisory authority.
AI agents. A local language model (no cloud requests). Automation of analytics and reporting.
The OS source code is open — independent audit is possible.
4. Implementation order
| Stage | Content | Term |
|---|---|---|
| 1. Preparation | Agree grant terms. Register the fund presence. Obtain identifier lists. | 1–3 months |
| 2. Integration | Embed identifiers into the OS. Deploy registry and scanner. Deploy the first smart contract (fund presence). | 1–2 months |
| 3. Acceleration | Enroll participants. Companies register on the accelerator platform and deploy smart contracts with identifiers. The supervisory authority gets scanner access. | from 3 months |
| 4. Operation | Infrastructure support. Expand participants and activity types. Connect to registries of other jurisdictions. | ongoing |
Total time to a working infrastructure with first participants: 5–8 months.
5. Outcomes for the regulator
After implementation, the supervisory authority receives:
- Participant identification — every party working with digital assets in the jurisdiction is tied to national identifiers via a smart contract.
- Monitoring tools — a blockchain scanner with real-time access to the operations registry.
- A living sandbox — a venue with real companies (accelerator participants), not an empty test environment.
- Cross-jurisdiction compatibility — a multichain architecture can link the registry to similar registries in other jurisdictions.
- Independence from external vendors — infrastructure on local servers, open code, data under the regulator’s jurisdiction.
6. Data security
| Requirement | Implementation |
|---|---|
| Data localization | On-premises deployment; data does not leave the jurisdiction |
| Encryption | TLS 1.3 (transport), AES-256 (storage) |
| AI component | Local model, no data transfer to third parties |
| Audit | Open source code, reviewable by the supervisory authority |
| Compliance | GDPR, adaptation to local data-protection requirements |
7. Contact information
| Organization | VC HB3 Accelerator |
| info@hb3-accelerator.com | |
| Website | https://hb3-accelerator.com |
Additional materials available on request:
Accelerator program · 5-year roadmap · Market analysis · Business model
Date: 2026-07-17