> 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/concepts-and-reference/attestor-network-and-ethereum-signing.md). # Attestor Network and Ethereum signing [BETH architecture and trust boundaries](/beth/concepts-and-reference/architecture-and-trust-boundaries.md) ### Attestor Network The Attestor Network is the set of independent institutional operators that verify eligible Ethereum events and sign redemptions for BETH custody workflows. Operator membership and signing policy can change, so check the maintained security reference for current operating details. ### How attestors sign a redemption Each attestor holds its own Ethereum signing key. For a redemption, each attestor signs a typed EIP-712 message. The message names the redemption, the destination address, the amount, and a deadline. The Ethereum bridge contract releases ETH only when it receives valid signatures from at least the threshold number of different attestors. The contract checks each signer against its list of attestors. No shared key or key share exists. The security benefit comes from the signature check in the contract, not from a special transaction type. ### What threshold signing does not do Threshold signing does not by itself: * Verify that a deposit or redemption request is valid. * Decide which redemption should be signed. * Protect a compromised operator application from approving bad input. * Guarantee service availability. * Replace monitoring, policy, access control, or incident response. ### Workflow boundary 1. The system identifies an eligible Ethereum deposit or redemption event. 2. Operators independently receive the approved signing context. 3. Each participant applies the current verification and authorization policy. 4. The required threshold of attestors signs the redemption. 5. An attestor submits the signatures to the Ethereum bridge contract, which checks them and releases ETH. 6. The redemption result proceeds through the workflow. ### Key lifecycle Each attestor generates, stores, backs up, and rotates its own Ethereum key. The bridge contract holds the list of attestor addresses. Adding, removing, or replacing an attestor is a role change on the contract. It does not need a key ceremony or a new contract. ### Availability and failure The network can continue only while enough eligible participants and required services are available under the active policy. One unavailable operator does not necessarily stop the network. Check the current service reference for applicable availability targets. ### Operator trust boundary Each operator must protect its infrastructure, credentials, signing key, software supply chain, and verification process. Independent operation reduces unilateral control. It does not remove the need to evaluate correlated failures or common software dependencies. ### Related pages * [BETH architecture and trust boundaries](/beth/concepts-and-reference/architecture-and-trust-boundaries.md) * [BETH Proof of Reserve](/beth/concepts-and-reference/proof-of-reserve.md) * [BETH security](/beth/concepts-and-reference/security.md) ### Next step 👉 **Review the complete control model:** [BETH security](/beth/concepts-and-reference/security.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/concepts-and-reference/attestor-network-and-ethereum-signing.md?ask=&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.