> For the complete documentation index, see [llms.txt](https://docs.sectoral.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sectoral.xyz/under-the-hood/system-design.md).

# Architecture Overview

Sectoral is a confidential payments layer for people and the software working on their behalf. It runs on Robinhood Chain, and its privacy primitive comes from Sectoral's own confidential token contracts: an ERC-20 with encrypted balances in the Zether tradition. Because the EVM has nothing like this built in, the contract layer was written in-house and verified on-chain. Unlike a typical fintech, Sectoral also maintains no settlement ledger of its own. The ledger is Robinhood Chain, and Ethereum sits beneath it.

***

## Responsibilities of this layer

1. **Custody and signing.** Every account is an ERC-4337 smart account controlled by a keypair created on the client. Sectoral never receives the keys.
2. **Confidential transfers.** The token contracts encrypt amounts, and the client generates the proofs.
3. **Gas abstraction.** Each account keeps a small ETH float that tops itself up through an internal swap whenever it runs low, so users only ever think in USDG. Gas is reduced to an implementation detail.
4. **Agent policy.** The agent's client checks spend policies while signing, and the `AgentController` contract enforces them on-chain.
5. **Indexing.** An off-chain indexer consumes contract event streams and drives both the live feed and the webhook system, with no polling involved.

Anything that requires trust (who owns which funds, whether a transfer is valid) is decided by Robinhood Chain and Sectoral's on-chain contracts, and the rollup's fraud-proof settlement ultimately backs that correctness with Ethereum. Everything else, such as rendering, notifications, and indexing, is a convenience built on top. Keeping those two apart is the core of the design.

***

## Layers

```
+-------------------------------------------------+
|                 Applications                    |
|      Web . Mobile (iOS/Android) . SDK           |
+---------------------+---------------------------+
                      |
+---------------------v---------------------------+
|                  API surface                    |
|   REST + WebSocket . Agent API . Webhooks       |
+---------------------+---------------------------+
                      |
+---------------------v---------------------------+
|                 Core services                   |
|                                                 |
|  Wallet Engine   Privacy Engine   Agent Engine  |
|  (keys,          (ZK proofs,      (policies,    |
|   tx building)    client-side)     x402)        |
|                                                 |
|  Indexer (contract event streams + PostgreSQL)  |
+---------------------+---------------------------+
                      |
+---------------------v---------------------------+
|            Robinhood Chain Mainnet              |
|  Confidential Tokens . ZK Verifier . x402       |
+-------------------------------------------------+
```

***

## Trust, component by component

* **Funds:** no one has to trust Sectoral. Keys are created and stored on the device, and the servers only ever see signed transactions, never a private key.
* **Amounts:** no one has to trust Sectoral. Proof generation and decryption run on the client, and the backend only ever touches ciphertext.
* **Agents:** limits are enforced when the agent signs and again on-chain by `AgentController`, never left to Sectoral's judgment after the fact. A transaction that breaks policy never gets created.

***

## Related pages

* [Smart Contracts](/under-the-hood/contracts.md): how on-chain state is laid out
* [Security and Threat Model](/under-the-hood/threat-model.md): security at each layer


---

# 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.sectoral.xyz/under-the-hood/system-design.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.