> 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/guides/mint-beth.md).

# Mint BETH

[BETH overview](/beth/overview.md) · [BETH environments and prerequisites](/beth/get-started/environments-and-prerequisites.md)

### Outcome

Create a BETH deposit account, select its deposit account ID, deposit ETH to the Ethereum bridge, and verify that the corresponding BETH becomes available to the intended Canton party.

### Before you start

* Complete the BETH environment preflight.
* Use a supported Canton participant and authenticated party.
* [Install and validate the BETH DAR packages](/beth/get-started/install-and-validate-dars.md) required for minting.
* Confirm that the party has the required Minter credential.
* Confirm that the BitSafe API of the selected environment is reachable.
* Use a pinned `bitsafe-token-lib` release and compatible shared Canton libraries.
* Confirm the approved Ethereum network and the bridge contract address. For Devnet and Testnet, get Sepolia ETH from a Sepolia faucet.
* Use an Ethereum account that can call a contract and that holds ETH for the deposit and for gas.

Minting has additional prerequisites beyond ordinary BETH transfers. Do not begin from the Send BETH setup alone.

### 1. Confirm the Minter credential

Use the credential example or the approved application interface to:

1. Check whether the party already holds the required credential.
2. Find an eligible pending credential offer if none exists.
3. Accept only the intended offer through the approved flow.
4. Record the resulting credential contract identifier securely for the current operation.

Do not copy a real credential contract identifier into documentation or support tickets.

### 2. Retrieve current account rules

Retrieve the deposit and withdrawal account rules from the BitSafe API of the selected environment:

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

The response holds `da_rules` for deposit accounts and `wa_rules` for withdrawal accounts. Each rule has a `template_id`, a `contract_id`, and a `created_event_blob`.

Verify that:

* The response belongs to the selected environment.
* The package and template references match the approved DAR set.
* The returned rules are current for the intended party and operation.

Treat rules as runtime data. Do not hard-code them into a long-lived integration.

### 3. Create a deposit account

Create a deposit account using:

* The authenticated Canton party.
* The approved Minter credential.
* The current deposit-account rules.
* A unique command or request identifier where the interface supports one.

Verify that the resulting account is owned by the intended party before continuing.

### 4. Select the deposit account ID

BETH doesn't have a separate deposit address for each account. Instead, every deposit goes to the one Ethereum bridge contract of the environment. The deposit account ID tells the attestors which account to credit.

Select the deposit account ID:

* If the deposit account has an `id` value, use that value.
* Otherwise, use the contract ID of the deposit account.

The ID stays the same when a completed deposit recreates the account contract. Use the same ID for every deposit to the account. Do not replace it with the newest contract ID.

{% hint style="warning" %}
A deposit with the wrong deposit account ID does not mint BETH, and the ETH can become stuck in the bridge. Pay extra attention to the ID before sending a deposit. If a finalized deposit does not mint BETH, contact support with the transaction hash and the ID. Do not send a second deposit.
{% endhint %}

Before depositing ETH:

* Confirm the Ethereum network and chain ID.
* Confirm the bridge contract address for the selected environment.
* Confirm the ID belongs to the expected deposit account.
* Record the account and ID association in the integration’s reconciliation data.

### 5. Deposit ETH

Call `depositETH(bytes depositAccountId)` on the bridge contract. Pass the deposit account ID as UTF-8 bytes, and send the approved test amount as the transaction value. Use the transaction hash to monitor Ethereum finality.

The amount must be a whole multiple of `100000000` wei (`0.0000000001` ETH), because BETH has 10 decimal places. The bridge rejects any other amount. The bridge also rejects a plain ETH transfer, so a deposit must call `depositETH`. The amount must also be within the deposit account's own limits. `beth::mint::deposit_call` checks these limits.

{% hint style="info" %}
Check the bridge's current `depositLimits()` and `paused()` state before sending. Check the current environment and compatibility reference for fees, timing, and timeout behavior. Do not rely on historical values.
{% endhint %}

### 6. Monitor the mint lifecycle

Track the deposit account and BETH state until the approved completion condition is met. Monitor:

* `Deposit` event emitted by the bridge contract.
* Ethereum block finalized.
* Verification or attestation state.
* Mint submitted on Canton.
* BETH holding created for the intended party.
* Terminal failure or escalation state.

### 7. Verify the result

A successful mint should be verified in two places:

1. The deposit workflow shows the approved completed state.
2. The intended Canton party’s BETH balance or holdings increase by the expected amount.

Reconcile the Ethereum transaction, deposit account, mint result, Canton update, and resulting holdings without exposing secrets.

### Source example

The repository includes a guided example:

```bash
cargo run --example beth_credentials
cargo run --example beth_mint_flow
```

The `beth_mint_flow` example does not send ETH. It prints the `depositETH` transaction, which you sign and send with your own Ethereum wallet.

Use these commands only with the reviewed source tag and an approved environment. Link to the source for exhaustive implementation details rather than duplicating the full code.

### Troubleshooting

| Symptom                             | Check                                                                                       | Safe next action                                                        |
| ----------------------------------- | ------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| No eligible credential              | Party, environment, registrar, and pending offers                                           | Stop and use the approved credential-request path.                      |
| Account rules unavailable           | BitSafe API, authentication, environment, and service status                                | Do not reuse cached rules unless the support policy permits it.         |
| Deposit account creation fails      | DAR compatibility, credential, party rights, rule identifiers, and Canton response          | Capture sanitized identifiers and the version set.                      |
| Deposit transaction fails           | Bridge pause state, deposit limits, amount unit, and `depositETH` call data                 | Correct the input before another attempt.                               |
| ETH deposit is not detected         | Chain ID, bridge contract address, deposit account ID, transaction hash, and finality state | Do not send a second deposit until the first transaction is reconciled. |
| Deposit is final but BETH is absent | Deposit account ID, verification state, mint status, Canton update, and target party        | Escalate with sanitized account, transaction, and update identifiers.   |

### Technical sources

* [Mint flow example](https://github.com/DLC-link/bitsafe-token-lib/blob/v0.2.0/examples/beth/mint_flow.rs)
* [Credential example](https://github.com/DLC-link/bitsafe-token-lib/blob/v0.2.0/examples/beth/credentials.rs)
* [Examples guide](https://github.com/DLC-link/bitsafe-token-lib/blob/v0.2.0/examples/README.md)
* [BETH DAR guidance](https://github.com/DLC-link/bitsafe-token-lib/tree/v0.2.0/dars)
* [Ethereum bridge contract](https://github.com/DLC-link/evm-asset-bridge)

### Related pages

* [Install and validate BETH DARs](/beth/get-started/install-and-validate-dars.md)
* [BETH authentication](/beth/get-started/authentication.md)
* [BETH errors, retries, and troubleshooting](/beth/concepts-and-reference/errors-retries-and-troubleshooting.md)
* [BETH compatibility and release notes](/beth/concepts-and-reference/compatibility-and-release-notes.md)

### Next step

👉 **Prepare for failures safely:** [BETH errors, retries, and troubleshooting](/beth/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/beth/guides/mint-beth.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.