> For the complete documentation index, see [llms.txt](https://docs.bitsafe.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bitsafe.finance/chype/concepts-and-reference/architecture-and-trust-boundaries.md).

# Architecture and trust boundaries

[How CHYPE works](/chype/how-chype-works.md)

### Architecture at a glance

CHYPE connects HYPE custody in the HyperEVM bridge contract and event verification with private Canton contract workflows. This page owns the component map and trust boundaries. Lifecycle steps belong in [How CHYPE works](/chype/how-chype-works.md); control requirements belong in [CHYPE security](/chype/concepts-and-reference/security.md).

### Component map

<table data-search="false"><thead><tr><th>Component</th><th>Responsibility</th><th>Primary boundary</th></tr></thead><tbody><tr><td>HyperEVM bridge contract</td><td>Receive eligible deposits and release approved redemptions</td><td>Contract logic, signature threshold, limits, upgrade governance, and HyperEVM finality</td></tr><tr><td>Attestor Network</td><td>Verify eligible events and participate in threshold authorization</td><td>Independent operation, policy, and signing keys</td></tr><tr><td>CHYPE workflow services</td><td>Associate accounts and events, coordinate workflows, and reconcile state</td><td>Authentication, availability, and correct state handling</td></tr><tr><td>Canton participants and parties</td><td>Host parties, contracts, and authorized commands</td><td>Canton identity, rights, topology, and privacy</td></tr><tr><td>CHYPE Daml packages</td><td>Define holdings, transfers, accounts, credentials, and administrative behavior</td><td>Approved package versions and contract authorization</td></tr><tr><td>Client libraries and applications</td><td>Expose supported workflows and submit authorized requests</td><td>Pinned releases, credentials, validation, and retries</td></tr><tr><td>Proof of Reserve and reconciliation</td><td>Provide scoped evidence about reserves and system state</td><td>Completeness, freshness, source integrity, and stated limitations</td></tr></tbody></table>

### Trust boundaries

#### HYPE custody

The HyperEVM bridge contract holds the underlying HYPE. The contract releases HYPE only when it verifies signatures from a threshold of independent Attestor Network operators. Each operator signs with its own HyperEVM key. The threshold is configurable, and the operator set can change.

Safe multisig wallets hold the admin roles of the bridge contract. These roles can change the attestor set and the signature threshold, upgrade the contract through a timelock, set deposit and withdrawal limits, and pause the bridge.

#### Attestor Network

Event verification and signing authorization are separate responsibilities. No single operator should be presented as sufficient to authorize a custody action. The detailed signing model belongs in [CHYPE Attestor Network](/chype/concepts-and-reference/attestor-network-and-hyperevm-signing.md).

#### Canton

Canton records CHYPE contract state and applies authorization through parties, participant rights, package logic, and topology. Configurable sub-transaction privacy limits contract visibility to entitled parties; it does not hide HyperEVM transactions.

#### Integration services

Clients authenticate separately to Canton and approved CHYPE services. They must validate networks, parties, addresses, package compatibility, and authoritative state before retrying an ambiguous request.

#### Evidence

Proof of Reserve demonstrates only the evidence and observation scope documented on [CHYPE Proof of Reserve](/chype/concepts-and-reference/proof-of-reserve.md). It does not prove every application, custody, operational, or redemption property.

### Architecture limits

This architecture does not by itself guarantee instant HyperEVM confirmation, every external service’s availability, correct integrator configuration, protection from an authorized request containing the wrong destination, or complete coverage by one evidence source.

### Technical sources

* [BitSafe token library](https://github.com/DLC-link/bitsafe-token-lib)
* [Shared Canton library](https://github.com/DLC-link/canton-lib)
* [HyperEVM bridge](https://github.com/DLC-link/evm-asset-bridge)

### Related pages

* [CHYPE token standard and contract model](/chype/concepts-and-reference/token-standard-and-contract-model.md)
* [CHYPE Attestor Network](/chype/concepts-and-reference/attestor-network-and-hyperevm-signing.md)
* [CHYPE Proof of Reserve](/chype/concepts-and-reference/proof-of-reserve.md)
* [CHYPE security](/chype/concepts-and-reference/security.md)

### Next step

👉 **Review the control model:** [CHYPE security](/chype/concepts-and-reference/security.md).


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.bitsafe.finance/chype/concepts-and-reference/architecture-and-trust-boundaries.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.