> 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/get-started/environments-and-prerequisites.md).

# Environments and prerequisites

[BETH overview](/beth/overview.md)

### Before you start

Choose the BETH operation you need to perform before configuring an environment. Balance queries, transfers, minting, redemption, batch distribution, and UTXO management do not all share the same prerequisites.

### Choose an environment

| Environment | Use it for                                        | Before proceeding                                                                                                                 |
| ----------- | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| Development | Local development and early workflow testing      | Confirm the current participant, registry, BitSafe API, credential, and test-asset setup.                                         |
| Testnet     | Integration testing against shared infrastructure | Confirm endpoint ownership, faucet availability, reset policy, and differences from production.                                   |
| Mainnet     | Production workloads                              | Use only an Engineering-approved compatibility row, production credentials, monitoring, recovery procedures, and security review. |

Obtain current endpoints, party identifiers, and package identifiers from the maintained environment reference. Check its owner and last-verified date before use.

#### Ethereum bridge contracts

Canton Devnet and Testnet both use Ethereum Sepolia, with a separate bridge contract for each. Canton Mainnet uses Ethereum Mainnet.

| Environment | Ethereum network              | Bridge contract                              |
| ----------- | ----------------------------- | -------------------------------------------- |
| Devnet      | Sepolia (chain ID `11155111`) | `0xaAafDA111EAf5a49359e5C15B9B58DED7313f979` |
| Testnet     | Sepolia (chain ID `11155111`) | `0x5D60b6C3eC2FD5E4227AE0008BABE95Be86dD172` |
| Mainnet     | Ethereum (chain ID `1`)       | `0xb5d425d678B10949dD0f7bB0dd0427C47451D57E` |

Each address is an upgradeable proxy, so the address stays the same when the contract code is upgraded. `bitsafe-token-lib` `v0.2.0` uses these addresses, and the `ENVIRONMENT` value selects one.

### Core prerequisites

All BETH development paths require:

* Access to a supported Canton participant.
* A Canton party authorized for the intended operation.
* A supported authentication configuration and a safe method for storing credentials.
* A compatible Rust toolchain when using the current Rust library.
* A pinned `bitsafe-token-lib` release and compatible shared `canton-lib` crates.
* Network access to the required Canton and external service endpoints.
* A test plan that states the expected ledger and application result.

### Operation-specific prerequisites

| Operation                                | Additional prerequisites                                                                                                                     |
| ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| Check balances or contracts              | Ledger host, authenticated party, and compatible query interface.                                                                            |
| Send, receive, accept, reject, or cancel | Digital Asset Registry Utility components, receiver party details, required transfer context, and sufficient holdings.                       |
| Mint BETH                                | BitSafe API access, required Minter credential, compatible BETH DAR packages, account rules, and an Ethereum deposit flow.                   |
| Redeem BETH                              | BitSafe API access, required Minter credential, compatible BETH DAR packages, sufficient holdings, and a valid Ethereum destination address. |
| Batch distribution                       | Transfer prerequisites plus recipient input validation, limits, callbacks or result capture, and reconciliation.                             |
| UTXO management                          | Current holdings, approved split or consolidation policy, and a clear reason for changing the holding layout.                                |

### Install compatible components

The examples on this page use:

* `bitsafe-token` package version `0.2.0`.
* `canton-lib` dependencies pinned to `v0.11.0`.
* A Canton API client generated from Canton `3.6.1` specifications.

For deployment, use the approved compatibility matrix for the BitSafe token library, shared Canton library, Canton version, DAR packages, API behavior, and target environment.

### Configure safely

Configuration falls into four groups:

1. **Canton connection:** ledger host and party identity.
2. **Authentication:** approved identity-provider host, realm or audience, client identity, and secret-handling method.
3. **BETH network:** the `ENVIRONMENT` value (`devnet`, `testnet`, or `mainnet`). It selects the Decentralized Party, the registry, the BitSafe API, and the Ethereum bridge for the target network.
4. **Mint and redeem:** BitSafe API selection and Ethereum destination details where needed.

Never commit `.env` files, tokens, passwords, client secrets, party-specific credentials, or production addresses. Use placeholders in public examples and document how readers obtain real values through approved channels.

### Preflight checklist

* [ ] The target environment is approved for the intended test.
* [ ] The Canton participant is reachable.
* [ ] Authentication succeeds for the intended party.
* [ ] The pinned library set builds successfully.
* [ ] Required DAR packages are installed and validated.
* [ ] Registry and BitSafe services required by the operation are reachable.
* [ ] The party has the required credential and holdings.
* [ ] The expected result and rollback or recovery path are documented.
* [ ] Logs and identifiers needed for support can be collected without exposing secrets.

### Verify the setup

Start with a read-only operation such as a connection or balance check. A successful preflight should confirm:

* Authentication completed.
* The intended party was used.
* The ledger query returned a valid response.
* The application can parse the response with the pinned library set.

Continue to a state-changing operation only after the read-only check passes.

### Technical sources

* [`bitsafe-token-lib` `v0.2.0`](https://github.com/DLC-link/bitsafe-token-lib/tree/v0.2.0)
* [`bitsafe-token-lib` environment example](https://github.com/DLC-link/bitsafe-token-lib/blob/v0.2.0/.env.example)
* [BETH DAR guidance](https://github.com/DLC-link/bitsafe-token-lib/tree/v0.2.0/dars)
* [`canton-lib` `v0.11.0`](https://github.com/DLC-link/canton-lib/tree/v0.11.0)
* [BETH network values in `bitsafe-token-lib` `v0.2.0`](https://github.com/DLC-link/bitsafe-token-lib/blob/v0.2.0/src/tokens/beth/mod.rs#L39-L64)

### Related pages

* [BETH developer Quick Start](/beth/get-started/developer-quick-start.md)
* [Install and validate BETH DARs](/beth/get-started/install-and-validate-dars.md)
* [BETH authentication](/beth/get-started/authentication.md)
* [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 compatibility and release notes](/beth/concepts-and-reference/compatibility-and-release-notes.md)

### Next step

👉 **Verify your setup:** [BETH developer Quick Start](/beth/get-started/developer-quick-start.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/get-started/environments-and-prerequisites.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.