> For the complete documentation index, see [llms.txt](https://docs.reveel.id/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.reveel.id/getting-started/readme.md).

# Technical Architecture

## Overview

Reveel PayID is designed as a **modular protocol layer** that enables cross-chain stablecoin transfers through a unified, human-readable identity: `yourname(id)`.

This page provides a detailed look at how Reveel’s core systems interact to deliver seamless payments — today and in the near future.

## Modular & Composable by Design

At the heart of PayID lies a **modular architecture** designed for flexibility, scalability, and composability. Rather than a linear pipeline, Reveel is built as a **hub-and-spoke system** where each core service operates as an independent, interoperable module — all coordinated through the Reveel protocol core.

### 1. External Integrations Layer

This is the entry point for interactions with Reveel PayID. Apps, wallets, AI agents, or platforms can integrate using REST APIs.

**APIs:**

* `POST /user/create` → Register a platform user
* `GET /user/list`, `GET /user/:id` → Retrieve user data

***

### 2. PayID Resolver

The resolver converts a PayID like `alice(id)` into actionable metadata, such as:

* Registered user
* Linked wallet addresses across chains
* Custom routing rules
* Associated identities (ENS, Lens, MocaID, email)

📌**APIs:**

* `POST /payid/claim` → Claim a new PayID
* `GET /payid/search` → Look up a user by PayID
* `GET /payid/check-price` → Check on-chain PayID price before claiming

***

### 3. Routes Engine

This component parses user-defined logic and determines how incoming funds should be routed. Each route is programmable and can be based on:

* Sender (e.g., route if Bob sends)
* Source Chain
* Source Token

Each route returns:

* Destination wallet address
* Destination chain
* Preferred token

📌**APIs:**

* `POST /routes/create`
* `PUT /routes/edit-route`
* `GET /routes/get-routes`
* `DELETE /routes/delete-route`

***

### 4. Reveel Liquidity Orchestration Layer (RLOL)

**Current Status:**\
RLOL is under active development. It will power routing decisions at a higher precision and future bridge/swap execution strategies.

 **Responsibilities:**

* Parse target route and prepare transaction context
* Allow routing through supported tokens and chains
* Liquidity Aggregator Engine (LAE) for querying bridges like Connext, Hop, etc.
* Dynamic route optimization (fees, slippage, latency)
* Swap support
* Retry/fallback logic

This layer will supports the full lifecycle of a transaction, even if external liquidity execution is abstracted for now.

***

### 5. Transaction Execution Layer

After a route is resolved, the transaction is initiated and handled through the following APIs:

📌 **Cureent** **APIs:**

* `POST /transact/init-transaction` → Triggers a transaction to the target wallet as defined in the resolved route
* `POST /transact/txn-webhook` → Used by external systems to push transaction status back to Reveel
* `GET /transact/get-activity` → Retrieve transaction metadata and history for a PayID

This system may expand to include bridge routing and swap intelligence, but currently supports clean execution flows based on PayID logic.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://docs.reveel.id/getting-started/readme.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.