182 lines
11 KiB
Markdown
182 lines
11 KiB
Markdown
# Presentation: EPR and Digital Regulatory Sandbox on the DLE Operating System (VC HB3 Accelerator)
|
||
|
||
**Language:** [Русский](../../ru/presentations/fns-epr-dle-hb3-deck.md) | [English](fns-epr-dle-hb3-deck.md)
|
||
|
||
## Slide 1. Client: FNS. Goal: launch EPR
|
||
**To:** Federal Tax Service of Russia / competent authority
|
||
**From:** OOO ERAYTI
|
||
**Topic:** Deployment of a *digital regulatory sandbox* and Experimental Legal Regime (EPR) based on the first pilot company project of VC HB3 Accelerator, which uses the **Digital Legal Entity (DLE)** operating system to organize commercial activity with digital-sandbox participants
|
||
**Goal:** create a controlled environment where the FNS gets monitoring, and sandbox participants work through scenarios under clear rules.
|
||
|
||
---
|
||
|
||
## Slide 2. Problem statement (why this matters for the FNS)
|
||
- New technologies require oversight of operations tied to legally significant identifiers (organizations, addresses, activity codes, etc.)
|
||
- Business finds it hard to test innovations without risk of violations: *legal and technological predictability* is needed
|
||
- The regulator needs a venue: not “in a vacuum,” but with real participants and observable processes
|
||
|
||
---
|
||
|
||
## Slide 3. What EPR is (in the project’s logic)
|
||
**EPR = experimental regime**, where:
|
||
- consequences for core activity are predictable
|
||
- risks are limited by control within set rules
|
||
- technologies are tested on live cases under supervision
|
||
|
||
In our approach, EPR is implemented through a *digital regulatory sandbox* on the DLE infrastructure of the first pilot company project of VC HB3 Accelerator.
|
||
|
||
---
|
||
|
||
## Slide 4. What we deploy under EPR
|
||
|
||
**The Digital Legal Entity digital sandbox within the experimental legal regime is organized as an industrial contour of local deployment and oversight:**
|
||
- the contributor deploys the Digital Legal Entity OS in the jurisdiction contour; in the Russian Federation the contributor is Limited Liability Company “ERAYTI” (authorized license seller in the Russian Federation)
|
||
- VC HB3 Accelerator uses the Digital Legal Entity OS to organize commercial activity with sandbox participants and run the accelerator program
|
||
- sandbox participants deploy their own Digital Legal Entity OS instances and deploy their own smart contracts with governance tokens; smart-contract addresses are submitted to VC HB3 Accelerator to configure access rights to service and resources of VC HB3 Accelerator on the Digital Legal Entity OS
|
||
- integration of identifiers and tagging rules is performed based on lists provided by the regulator and fixed in the pilot regulation
|
||
- the supervisory authority monitors operations via a blockchain scanner in the sandbox contour
|
||
|
||
---
|
||
|
||
## Slide 5. Participants and roles (ecosystem model)
|
||
1. **Federal Tax Service (supervisory authority)**
|
||
- approves and provides identifier lists and tagging rules for the pilot (within the experimental legal regime)
|
||
- receives monitoring of operations in the sandbox contour via a blockchain scanner
|
||
2. **VC HB3 Accelerator (first pilot company project)**
|
||
- uses the Digital Legal Entity OS to organize commercial activity with sandbox participants
|
||
- runs the accelerator program for participants and defines interaction rules in the pilot
|
||
- receives from participants addresses of smart contracts with governance tokens to configure access rights to service and resources of VC HB3 Accelerator on the Digital Legal Entity OS
|
||
3. **Contributor (local operator in the jurisdiction)**
|
||
- deploys the Digital Legal Entity OS in the jurisdiction contour and onboards participants
|
||
- acts as an authorized license seller in the relevant territory under a contractual model with the rights holder
|
||
- in the Russian Federation the contributor is Limited Liability Company “ERAYTI”
|
||
4. **Sandbox participants (customer companies and contractor companies)**
|
||
- deploy their own Digital Legal Entity OS instances and deploy their own smart contracts with governance tokens
|
||
- participate in commercial pilot scenarios in accordance with the sandbox regulation
|
||
|
||
---
|
||
|
||
## Slide 6. How DLE links the “smart contract” and identification
|
||
- The Digital Legal Entity OS supports smart contracts with identifiers set by the regulator
|
||
- For a specific pilot, identifier lists and tagging rules provided by the regulator are fixed in the sandbox regulation and implemented in configuration and smart contracts
|
||
- Governance tokens are used as a governance and access-control mechanism (token-gating) within participants’ OS instances
|
||
- Resident status is recorded in DLE at the level of organization identification and the smart contract
|
||
- **Immutability** of records and traceability of operations create a supervisory contour for the FNS
|
||
|
||
---
|
||
|
||
## Slide 7. Technology architecture (components)
|
||
Deployed on servers inside the jurisdiction:
|
||
- **Blockchain registry (EVM-compatible)** — recording of operations and smart contracts
|
||
- **Smart contracts with identifier support**
|
||
- **Blockchain scanner** — monitoring tool (by transactions/addresses/identifiers)
|
||
- **User wallet**
|
||
|
||
---
|
||
|
||
## Slide 8. What the FNS gets from the pilot
|
||
1. **Participant identification** via a smart contract bound to national identifiers
|
||
2. **Monitoring tools**: blockchain scanner with real-time access to the operations registry
|
||
3. **Working sandbox**: first pilot company project of VC HB3 Accelerator using the OS to organize commercial activity with sandbox participants
|
||
4. **Cross-jurisdiction compatibility** (reuse of architecture / connection to similar registries)
|
||
5. **Independence from external vendors**: on-prem, open code, independent audit possible
|
||
6. **Measurable supervisory effect** (within agreed KPIs): lower share of manual reconciliations, higher data quality, shorter time to analyze cases
|
||
|
||
---
|
||
|
||
## Slide 9. Security and data-compliance requirements
|
||
- **Data localization**: on-premises deployment
|
||
- **Encryption**: TLS 1.3 (channel), AES-256 (storage)
|
||
- **Audit**: open source code and review by the supervisory authority
|
||
|
||
---
|
||
|
||
## Slide 10. Implementation order
|
||
Stage 1. Preparation
|
||
- agree the experimental legal regime and pilot regulation
|
||
- define identifier lists and tagging rules provided by the regulator
|
||
- form the pilot participant set and commercial-activity scenarios
|
||
|
||
Stage 2. Integration
|
||
- the contributor (in the Russian Federation — Limited Liability Company “ERAYTI”) deploys the Digital Legal Entity OS in the jurisdiction contour
|
||
- integrate identifier lists and tagging rules into the sandbox contour per the pilot regulation
|
||
- deploy the blockchain registry and blockchain scanner for supervisory monitoring of operations
|
||
|
||
Stage 3. Acceleration
|
||
- participants install the Digital Legal Entity OS and deploy their own contours (on-premises)
|
||
- participants deploy their own smart contracts with governance tokens and submit addresses to VC HB3 Accelerator to configure access rights to service and resources
|
||
- the supervisory authority gets access to the blockchain scanner under pilot rules
|
||
|
||
Stage 4. Operation
|
||
- support / expand participants / connect new case groups
|
||
|
||
---
|
||
|
||
## Slide 11. What we ask of the FNS (precise request)
|
||
1. **Agreement of the experimental legal regime and pilot regulation** (scenarios, participant set, limitations, and oversight procedure)
|
||
2. **Provision of identifier lists and tagging rules** needed for integration into the Digital Legal Entity sandbox contour
|
||
3. **Connect FNS representatives to monitoring** (blockchain scanner and access to the operations registry under pilot rules)
|
||
4. **Joint agreement of pilot KPIs** (metrics fixed at the start):
|
||
- share of processes where identification/control are performed automatically via smart contract
|
||
- reduction of manual reconciliations and “data gaps”
|
||
- speed of obtaining analytical slices of resident operations
|
||
- data quality (completeness/correctness of identifiers and bindings)
|
||
|
||
---
|
||
|
||
## Slide 12. Why business becomes a resident (participant benefits)
|
||
A resident gets:
|
||
- digital regulatory sandbox participant status recorded in DLE based on a license token
|
||
- ability to install the Digital Legal Entity OS from the repository and deploy their own contour (on-premises)
|
||
- deployment of smart contracts with governance tokens to manage teams and access within the OS
|
||
- access to the VC HB3 Accelerator program and to OS service and resources under pilot rules (based on participants’ smart-contract addresses)
|
||
- a **controlled testing regime** within agreed pilot rules
|
||
- a path to **investment offers** upon reaching planned metrics
|
||
- for supervisory representatives: **monitoring and analytics** of operations via blockchain scanner within the pilot
|
||
|
||
---
|
||
|
||
## Slide 13. Participation format: “cohorts by activity type”
|
||
- Cohorts by activity type: launch scenarios in selected directions (70+ groups)
|
||
- first pilot company project of VC HB3 Accelerator — which uses the OS to organize commercial activity with sandbox participants
|
||
- Sandbox participants: organizations — supervisory representatives, companies — contractors, and companies — customers
|
||
|
||
---
|
||
|
||
## Slide 14. Next step: agree a PoC
|
||
We propose an initial working session to:
|
||
- define the pilot subject and KPIs for the FNS
|
||
- agree identifier lists for integration
|
||
- choose the on-premises deployment territory and contributor (local operator) for the pilot
|
||
|
||
Then — launch Stage 1 (preparation) and the implementation plan.
|
||
|
||
---
|
||
|
||
## Slide 15. Transition to the industrial contour after receiving regulator tagging
|
||
After receiving smart-contract tagging from the regulator:
|
||
- contributors create an industrial smart contract with governance tokens and regulator tagging (for the relevant jurisdiction)
|
||
- holders of contributor demonstration tokens vote to select the jurisdiction for the first pilot company project of VC HB3 Accelerator
|
||
- in the selected jurisdiction, a smart contract with local regulator tagging is deployed and the industrial contour is launched
|
||
|
||
---
|
||
|
||
## Slide 16. Rights and economics model of a network of local operating systems
|
||
- the author-developer transfers rights to the fund (VC HB3 Accelerator) under a contractual model
|
||
- license tokens are distributed through regional contributor operating systems and sold for local regulator stablecoins of the relevant jurisdiction
|
||
- contributors transfer governance tokens of their OS smart contracts with profit into the VC HB3 Accelerator treasury
|
||
- result: a fund managing a network of local operating systems under individual regulators (jurisdictions), with common principles of oversight and scaling
|
||
|
||
---
|
||
|
||
## Slide 17. Legal status of the DLE OS and rights in the RF
|
||
- The source code of the `Digital Legal Entity (DLE)` operating system is protected by copyright.
|
||
- Use of the OS within the pilot is under a licensing model and the author’s terms.
|
||
- `OOO “ERAYTI”` received from the author official written authorization to configure and sell the OS in the Russian Federation.
|
||
- For the FNS this means: infrastructure is built on a legal basis, and all residents receive access under agreed terms.
|
||
|
||
---
|
||
|
||
## Slide 18. Note
|
||
Materials are provided for informational purposes and are not legal advice or an offer to deal. Legally significant actions require agreements and legal analysis within the pilot.
|