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

# CCTP Express Architecture

CCTP Express adopts a Hub-and-Spoke architecture, it can be broken down into a 3-layered system: a request for quote mechanism to obtain users' bridging intent, enabling a filler network to claim and fill those orders, and lastly a settlement layer periodically repay fillers through CCTP and utilizing attestation service from Iris.

CCTP Express aligns with the industry standards, the `CrossChainOrder` struct follows [ERC-7683 standard](https://www.erc7683.org/).

Below is a diagram of the architecture of CCTP Express:

<figure><img src="https://131966688-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFaA5rrAIiExQEcVyNvp7%2Fuploads%2F3Lwj1qj5HXGkqvKorVsf%2FScreenshot%202024-08-28%20at%204.27.46%E2%80%AFPM.png?alt=media&amp;token=33723b8d-e614-4344-b3ba-29c8f7dc742d" alt=""><figcaption></figcaption></figure>

**Order initiation**

1. User signs an off-chain message defining the parameters of an order.
2. The order is disseminated to Fillers. The Filler calls `initiate` on the source chain SpokePool. A `CrossChainOrder` will be created and the user's funds are transferred to the `SpokePool` for escrow.
3. The `SpokePool` on source chain submits a `Deposit` message to Circle's off-chain attestation service, Iris, for attestation and subsequently a `DepositAttestation` will be generated.

**Filler Network Fills Order**

4. Fillers calls `fillOrder` on the destination `SpokePool` with their own assets which are then transferred to the user from the `SpokePool`.
5. The `SpokePool`on destination chain submits a `Fill` message to Iris and a `FillAttestation` will be generated.

**Settlement**

6. A permissionless Datadaemon retrieves the `DepositAttestation` and `FillAttestation` from Iris and relay to the `Hub Pool` on the Settlement Chain.&#x20;
7. Periodically, a permissionless Datadaemon calls `repayFunds` and `rebalanceFunds` at the `Hub Pool`, which would collect all the attestations and perform the following steps:
   1. Iterate through a list of attestations, a valid filled order is supported by both Deposit and Fill attestation.
   2. Determine the aggregate settlement sum from all valid fills for each filler.
   3. If there is sufficient fund on `SpokePool` to repay filler, a `repayFunds` message in the form of merkle root hash is sent to Iris.&#x20;
   4. For the remaining outstanding payment, the `Hub Pool` will send a `rebalanceFunds` message in the form of merkle root hash to Iris, which indicates how much a SpokePool with surplus funds would send to another pool in deficit to fulfill the need for repayment.
8. Once the `repayFunds` and `rebalanceFunds` messages got attested by Iris, they are sent to respective SpokePools. Datamaemon will call `repayFunds` and `rebalanceFunds` on SpokePools with merkle root hash and their respective transaction details. Accordingly, funds would be repaid to fillers and sent to other SpokePools to ensure sufficient funds for handling repayments.&#x20;
9. Repay funds to fillers from the SpokePool on destination chain, and rebalance funds across `SpokePools` on difference chains via CCTP.

**Cctp Fill Settlement**

10. In case of order initiated by Fillers not being filled, the Datadaemon can call `cctpFill` and mark the order status on destination chain `SpokePool` to `RequestCctpFill` and block any filler from filling it. At the same time, the `SpokePool` will emit a `CctpFill`message to Iris for attestation.
11. The `CctpFillAttestation` will be used to replace the `FillAttestation` mentioned in 5. and allow the user fund to be transferred via the CCTP route.