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

# How BETH works

### The short version

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

### The system has two connected ledgers

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

The integration layer links an Ethereum 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 Ethereum.
4. The depositor verifies the network and the bridge contract address, then calls `depositETH` with the deposit account ID and the ETH amount.
5. The system detects the deposit event and waits until Ethereum finalizes the block.
6. Independent Attestor Network participants verify the eligible Ethereum deposit.
7. The approved threshold authorizes the mint workflow.
8. BETH is created for the intended Canton party.
9. The Ethereum transaction, account, attestation, Canton update, and resulting holding are reconciled.

### Transfer lifecycle

A Canton transfer does not redeem ETH. 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 an Ethereum destination address.
2. The party creates or selects a withdrawal account using current rules.
3. The application selects sufficient BETH holdings.
4. The party submits the redemption.
5. The Canton contract flow consumes the applicable BETH state.
6. The approved threshold of attestors signs the redemption, and the Ethereum bridge contract releases ETH after it verifies the signatures.
7. The application tracks completion on Ethereum and Canton.
8. The records are reconciled to one request.

### Who does what

| Role                     | Responsibility                                                                          | Boundary                                                  |
| ------------------------ | --------------------------------------------------------------------------------------- | --------------------------------------------------------- |
| BETH 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 Ethereum deposits and signs redemptions under threshold authorization | No single operator is sufficient                          |
| Ethereum bridge contract | Holds deposited ETH 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                    |
| Ethereum network         | Records deposits and redemption transactions                                            | Finality and fee behavior are external to Canton          |

### Backing and verification

BETH is intended to remain backed 1:1 by ETH. Public documentation should distinguish:

* ETH reserves visible in the Ethereum bridge contract.
* BETH 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 Ethereum 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 BETH](/beth/guides/mint-beth.md)
* [Redeem BETH](/beth/guides/redeem-beth.md)
* [Transfer and receive BETH](/beth/guides/transfer-and-receive-beth.md)
* [BETH architecture and trust boundaries](/beth/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)
* [BETH Faucet](https://cbtc-faucet.bitsafe.finance/?network=devnet\&token=cbtc)

### Next step

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