> For the complete documentation index, see [llms.txt](https://svim.gitbook.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://svim.gitbook.io/technical-documents/architecture-design.md).

# Architecture Design

This design diagram shows how Swimmer Finance application is put together: a user-facing dApp, a conventional backend, blockchain infrastructure, and an on-chain smart contract, with authentication sitting in front so only verified users can act. Data and actions move between these pieces through APIs, wallet signatures, RPC calls, live events, and on-chain transactions. The sections below walk through each part of that flow.

<figure><img src="https://2323604957-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FU8jqoajHXx9Dj24zWzZw%2Fuploads%2FH0L4zxPUzsbaQix4550E%2FArchitecture2.jpg?alt=media&amp;token=8ae85e90-0d27-4e06-9eb1-448c017c1a18" alt=""><figcaption></figcaption></figure>

#### Identity Verification Service

The Identity Verification Service is the authentication layer that confirms a user is who they claim to be before they can use the application. It can include traditional account verification such as sending a one-time password (OTP) to email or phone, two-step / two-factor verification, password or social-login checks, and similar identity proofs. In this Web3 setup it also covers crypto-native authentication: connecting a wallet and asking the user to sign a message so the application can prove they control that address without taking custody of their keys. Once any of these checks succeed, the service passes the authenticated identity downward to Access Control so permissions can be granted.

#### Access Control&#xD;

Access Control receives the outcome from the Identity Verification Service and decides what the verified user is allowed to do. It acts as a gatekeeper that can grant or deny permissions, often by updating on-chain allow-lists, roles, or other authorization data that the Smart Contract later consults.

#### Backend&#xD;

The Backend is a conventional server-side application that sits between the user-facing dApp and the rest of the system. It exposes an API that the dApp calls, orchestrates business logic, talks to the RPC Node and WebSocket connections, and can store off-chain data or perform operations that should not live entirely on the blockchain.\
\
**RPC Node**
\
The RPC Node is the application’s window onto the blockchain. The Backend (and sometimes the dApp) sends read and write requests through it—querying contract state, submitting transactions, or fetching block data. It is the standard JSON-RPC interface most Ethereum-compatible chains expose.<br>

#### WebSocket&#xD;

The WebSocket component provides a live, two-way connection so the Backend can receive real-time events emitted by the Smart Contract instead of constantly polling. When the contract fires an event (a transfer, a state change, a new listing, etc.), the WebSocket pushes that information immediately so the Backend and dApp can update their views without delay.dApp
\
The dApp is the user-facing web or mobile application. Users interact with it in the browser; it talks to the Backend over an API, asks the User/Wallet to sign transactions, and displays data that ultimately comes from the Smart Contract. It is the layer that ties the off-chain and on-chain worlds together for the end user.

#### User/Wallet&#xD;

The User/Wallet represents the person using the application together with the wallet software (browser extension, mobile wallet, hardware device, etc.) that holds their private keys. The dApp asks this component to “Connect Wallet,” after which the user can approve and sign transactions that will be sent to the Smart Contract.

#### Smart Contract&#xD;

The Smart Contract is the on-chain program that holds the application’s core logic and state. The dApp sends signed transactions to it, the Backend queries it through the RPC Node, and it emits events that travel back through the WebSocket. Access Control can also write authorization rules into it so that only verified users can call privileged functions.