> 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/guides/redeem-chype.md).

# Redeem CHYPE

[CHYPE overview](/chype/readme.md) · [CHYPE environments and prerequisites](/chype/get-started/environments-and-prerequisites.md)

### Outcome

Create or select a withdrawal account, redeem CHYPE, and verify delivery of HYPE to the intended HyperEVM address.

### Before you start

* Complete the CHYPE environment preflight.
* Confirm the party holds enough CHYPE for the intended test.
* [Install and validate the DAR packages](/chype/get-started/install-and-validate-dars.md) required for redemption.
* Confirm the required Minter credential.
* Configure the approved BitSafe API.
* Obtain a valid HyperEVM destination address for the selected network. The address must accept native HYPE.
* Understand the approved minimums, limits, fees, and recovery path.

### 1. Validate the HyperEVM destination

Before creating a withdrawal account:

* Confirm the destination address format and HyperEVM network.
* Confirm that the address can receive native HYPE. A contract address that rejects HYPE makes the redemption fail.
* Confirm ownership or authorization under the organization’s controls.
* Use a second-person or system control for production destinations where required.

The account owner can change the destination address after account creation. A change does not affect a redemption that is already in progress.

A wrong-network or wrong-recipient destination may be irreversible.

### 2. Retrieve current withdrawal rules

Retrieve the current account rules from the BitSafe API of the selected environment:

```http
GET /chype/v1/account-contract-rules
```

Use the `wa_rules` entry for withdrawal accounts. Confirm that the response matches the selected environment, current DAR set, and intended operation.

### 3. Create or select a withdrawal account

Create a withdrawal account using the authenticated party, approved credential, current rules, and verified HyperEVM destination. If reusing an existing account, confirm its destination and current status before selecting it.

A withdrawal account allows one withdrawal at a time. A second redemption from the same account fails until the first one is processed.

Created deposit and withdrawal accounts stay on the ledger until someone closes them. Do not create duplicate accounts as an automatic retry strategy.

CHYPE rejects the zero address, HyperEVM system addresses, and CHYPE bridge proxies as withdrawal destinations. The library checks the destination during account creation and again before burning holdings. A burn cannot be undone.

### 4. Select CHYPE holdings

Query current CHYPE holdings and select sufficient inputs to cover the requested redemption according to the approved holding-selection policy.

Before submission:

* Confirm the total selected amount.
* Confirm the requested withdrawal amount.
* Check applicable limits.
* Preserve enough information for reconciliation.
* Avoid using holdings involved in another pending operation.

### 5. Submit the withdrawal

Submit the redemption through the supported CHYPE interface. Use a unique request or command identifier where available and retain the resulting Canton update or contract identifiers securely.

{% hint style="info" %}
Do not retry blindly after a timeout. First determine whether the original command committed, failed, or remains pending.
{% endhint %}

### 6. Monitor the lifecycle

Monitor the authoritative states for:

* Withdrawal submitted.
* CHYPE burned or otherwise consumed by the approved contract flow.
* Withdrawal account pending balance updated.
* HyperEVM redemption transaction submitted.
* HyperEVM block finalized.
* Completed, failed, cancelled, or escalated.

### 7. Verify and reconcile

A successful redemption should show:

1. The intended CHYPE amount no longer appears in the party’s available holdings.
2. The withdrawal account reflects the approved state transition.
3. HYPE is delivered to the verified destination.
4. The Canton and HyperEVM records reconcile to one redemption request.

The HYPE arrives as an internal transfer from the bridge contract. The outer HyperEVM transaction shows zero HYPE value. Check the bridge `Withdraw` event or the internal transfers of the transaction.

### Source example

The example requires `DESTINATION_HYPE_ADDRESS`. It reads `WITHDRAW_AMOUNT`, which defaults to `0.25` CHYPE.

```bash
cargo run --example chype_credentials
cargo run --example chype_redeem_flow
```

### Troubleshooting

| Symptom                                | Check                                                                                  | Safe next action                                                      |
| -------------------------------------- | -------------------------------------------------------------------------------------- | --------------------------------------------------------------------- |
| Destination rejected                   | Network, format, rule set, and account state                                           | Stop; do not substitute an address without repeating validation.      |
| Insufficient selectable holdings       | Available balance, pending operations, UTXO layout, and limits                         | Reconcile holdings before consolidating or splitting.                 |
| Second redemption fails                | Whether the account has a redemption in progress                                       | Wait until the first redemption is processed.                         |
| Submission times out                   | Canton update status and withdrawal-account state                                      | Determine commitment before retrying.                                 |
| CHYPE decreases but HYPE is pending    | Withdrawal state, bridge pause state and limits, HyperEVM finality, and service health | Follow the approved pending-withdrawal escalation path.               |
| HYPE arrives with an unexpected amount | Requested amount, approved fees, bridge `Withdraw` event, and reconciliation record    | Escalate; do not make an offsetting transaction automatically.        |
| Destination does not accept HYPE       | Whether the destination is a contract that rejects HYPE                                | Escalate with sanitized account, transaction, and update identifiers. |

### Technical sources

* [Redeem flow example](https://github.com/DLC-link/bitsafe-token-lib/blob/v0.4.1/examples/chype/redeem_flow.rs)
* [Examples guide](https://github.com/DLC-link/bitsafe-token-lib/blob/v0.4.1/examples/README.md)
* [HyperEVM bridge contract](https://github.com/DLC-link/evm-asset-bridge)

### Related pages

* [Install and validate CHYPE DARs](/chype/get-started/install-and-validate-dars.md)
* [CHYPE authentication](/chype/get-started/authentication.md)
* [CHYPE batch transfers and UTXO management](/chype/guides/batch-transfers-and-management.md)
* [CHYPE errors, retries, and troubleshooting](/chype/concepts-and-reference/errors-retries-and-troubleshooting.md)
* [CHYPE compatibility and release notes](/chype/concepts-and-reference/compatibility-and-release-notes.md)

### Next step

👉 **Prepare for failures safely:** [CHYPE errors, retries, and troubleshooting](/chype/concepts-and-reference/errors-retries-and-troubleshooting.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/guides/redeem-chype.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.