# Protocol Architecture

## Current Architecture

<figure><img src="/files/1yGJuBXklhLlejnQaO5Z" alt=""><figcaption></figcaption></figure>

## Component

### Identity Verification Service

* Purpose:&#x20;
  * Manages KYC (Know Your Customer) and KYB (Know Your Business) verifications for users accessing the system.
* Responsibilities:
  * Verifies user identity to enable access to restricted actions or data.
  * Interacts with Access Control to ensure only verified users can perform certain transactions.
* Interaction:
  * Provides identity verification status to the Access Control module, allowing or restricting user access based on their KYC/KYB status.

### Access Control

* Purpose:&#x20;
  * Manages user permissions based on verification status.
* Responsibilities:
  * Ensures that only authorized users can interact with certain smart contracts.
  * Works with the Identity Verification Service to validate user permissions.
* Interaction:
  * Queries the Identity Verification Service to verify user permission before granting access to specific functionalities within the smart contracts.

### dApp (Decentralized Application)

* Purpose:&#x20;
  * The user-facing interface that enables users to interact with the blockchain and perform various operations.
* Responsibilities:
  * &#x20;Connects to users’ wallets or ledgers, allowing them to perform transactions and view their portfolios.
  * Sends transaction requests to the backend and communicates directly with smart contracts.
* Interaction:
  * Connects to Wallet/Ledger to allow users to initiate transactions.
  * Retrieves portfolio data from the Backend and sends transactions to Smart Contracts.

### Wallet/Ledger

• Purpose: Acts as the digital wallet where users store their private keys and sign transactions.

• Responsibilities:

• Authenticates users within the dApp.

• Enables users to initiate transactions by connecting their wallets.

• Interaction:

• Directly connects to the dApp, allowing users to perform actions based on their wallet balances and permissions.

### Backend

* Purpose:&#x20;
  * The server-side component responsible for handling business logic, data processing, and API integrations.
* Responsibilities:
  * Reads user portfolio data and provides it to the dApp.
  * Communicates with the RPC Node to query the status of various smart contracts.
* Interaction:
  * Retrieves data from RPC Node and WebSocket to support real-time updates.
  * Supplies the dApp with data, such as portfolio information, and relays transaction statuses.

### RPC Node

* Purpose:&#x20;
  * Provides access to the Ethereum (or other blockchain) network, allowing the backend and other components to interact with smart contracts.
* Responsibilities:
  * Facilitates querying of blockchain data, such as transaction status and smart contract interactions.
* Interaction:
  * Communicates with Smart Contracts and the Backend to fetch and relay data.
  * Works with WebSocket for real-time events monitoring.

### WebSocket

* Purpose:&#x20;
  * Enables real-time communication, pushing event updates from the blockchain to other components.
* Responsibilities:
  * Listens to blockchain events and relays them to the Backend and other modules.
  * Provides real-time updates on transactions and smart contract changes.
* Interaction:
  * Communicates with Smart Contracts to capture events and sends them to the Backend.

### Smart Contracts

* Purpose:&#x20;
  * The core contracts that reside on the blockchain, containing the logic for handling transactions, verifying permissions, and storing data.
* Responsibilities:
  * Executes business logic on the blockchain, including financial transactions and access verification.
  * Maintains the integrity of data related to transactions and user interactions.
* Interaction:
  * Processes transactions initiated by the dApp and responds with success or error messages.
  * Emits events that are captured by WebSocket for real-time processing.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://svim.gitbook.io/technical-documents/protocol-architecture.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.