> 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/how-chype-works.md).

# How CHYPE works

### The short version

CHYPE represents HYPE on Canton Network. A mint starts with HYPE deposited to the HyperEVM bridge contract. The system verifies the deposit and creates the corresponding CHYPE for the intended Canton party. A redemption consumes CHYPE and releases HYPE to the destination address of the party's withdrawal account. Transfers between Canton parties use Canton contracts and do not move the underlying HYPE for each transfer.

### The system has two connected ledgers

* **HyperEVM:** holds the HYPE that backs CHYPE in the bridge contract and records deposits and redemption transactions.
* **Canton Network:** records CHYPE holdings, transfers, account workflows, and the parties authorized to act.

The integration layer links a HyperEVM event to its corresponding Canton workflow. It must prevent duplicate processing and preserve enough identifiers for reconciliation.

### Mint lifecycle

1. The Canton party obtains the required credential and current deposit-account rules.
2. The party creates a deposit account.
3. The deposit account ID identifies the account on HyperEVM.
4. The depositor verifies the network and the bridge contract address, then calls `depositETH` with the deposit account ID and the HYPE amount.
5. The system detects the deposit event and waits until HyperEVM finalizes the block.
6. Independent Attestor Network participants verify the eligible HyperEVM deposit.
7. The approved threshold authorizes the mint workflow.
8. CHYPE is created for the intended Canton party.
9. The HyperEVM transaction, account, attestation, Canton update, and resulting holding are reconciled.

### Transfer lifecycle

A Canton transfer does not redeem HYPE. The sender creates a transfer offer for a receiver. The receiver inspects and accepts the intended offer unless an approved preapproval flow applies. Canton archives or updates the relevant contracts and creates the receiver’s new holding state.

### Redemption lifecycle

1. The party validates a HyperEVM destination address.
2. The party creates or selects a withdrawal account using current rules.
3. The application selects sufficient CHYPE holdings.
4. The party submits the redemption.
5. The Canton contract flow consumes the applicable CHYPE state.
6. The approved threshold of attestors signs the redemption, and the HyperEVM bridge contract releases HYPE after it verifies the signatures.
7. The application tracks completion on HyperEVM and Canton.
8. The records are reconciled to one request.

### Who does what

| Role                     | Responsibility                                                                          | Boundary                                                  |
| ------------------------ | --------------------------------------------------------------------------------------- | --------------------------------------------------------- |
| CHYPE holder             | Owns Canton holdings and initiates supported actions                                    | Can act only with the party’s authorization               |
| BitSafe services         | Coordinate account and integration workflows                                            | Cannot be described as able to move reserves unilaterally |
| Attestor Network         | Verifies eligible HyperEVM deposits and signs redemptions under threshold authorization | No single operator is sufficient                          |
| HyperEVM bridge contract | Holds deposited HYPE and releases it against a threshold of attestor signatures         | Enforces its own limits and can be paused                 |
| Canton participant       | Hosts the party and submits or observes authorized Canton actions                       | Visibility follows Canton entitlements                    |
| HyperEVM network         | Records deposits and redemption transactions                                            | Finality and fee behavior are external to Canton          |

### Backing and verification

CHYPE is intended to remain backed 1:1 by HYPE. Public documentation should distinguish:

* HYPE reserves visible in the HyperEVM bridge contract.
* CHYPE supply and contract state visible to entitled Canton parties.
* Proof of Reserve evidence and its exact coverage.
* Operational reconciliation performed by the system.

### Failure boundaries

A workflow can pause because of HyperEVM finality delays, bridge limits or a paused bridge, service availability, Canton connectivity, authentication, incompatible packages, insufficient approvals, or an ambiguous prior submission. Clients must query authoritative state before retrying.

### Related guides

* [Mint CHYPE](/chype/guides/mint-chype.md)
* [Redeem CHYPE](/chype/guides/redeem-chype.md)
* [Transfer and receive CHYPE](/chype/guides/transfer-and-receive-chype.md)
* [CHYPE architecture and trust boundaries](/chype/concepts-and-reference/architecture-and-trust-boundaries.md)

### Technical sources

* [`bitsafe-token-lib` repository](https://github.com/DLC-link/bitsafe-token-lib)
* [`canton-lib` repository](https://github.com/DLC-link/canton-lib)
* [`evm-asset-bridge` repository](https://github.com/DLC-link/evm-asset-bridge)

### Next step

👉 **Choose an operation:** [Choose a CHYPE path](/chype/choose-a-chype-path.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/how-chype-works.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.