> ## Documentation Index > Fetch the complete documentation index at: https://thehyperstack.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Blockchain Security > Record the credentials of a group on the Hedera public ledger, so anyone can check that the record has not changed. Blockchain security is a credential group setting. When it is on, every credential you publish in the group gets a permanent record on Hedera, a public blockchain. Nobody can change or delete that record, Hyperstack included. Verifiers, such as employers, then see the record on the credential page. They can check it with **Verify credential**, or open it on a public Hedera explorer. > [!NOTE] > > Blockchain security is on the Enterprise plan. You need the **Credential issuer** or **Administrator** role to change a group. If you don't see **Security** under **More settings**, [contact us](mailto:hello@thehyperstack.com) to turn it on. ## When to turn it on Turn it on for credentials that people check carefully, for example: * Certifications that employers or regulators check. * Credentials that people use for a long time. * Programs where you want a proof that does not depend on Hyperstack alone. Credentials without blockchain security are still verifiable on their credential page and on your [verification page](/docs/tutorials/customization-and-branding/verification-page). ## Turn on blockchain security **1. Open the group** Go to **Credential Groups** and click the group. For a new group, click **Create group**. **2. Open the Security settings** Under **More settings**, click **Security**. **3. Set Blockchain security to Enabled** The row then reads **Blockchain security on**. **4. Save the group** Click **Update group**, or **Create group** for a new group. To turn it off, set **Blockchain security** to **Disabled** and save the group. New groups start with it disabled. ## What happens when you publish 1. Hyperstack signs the credential with your organization's key. 2. Hyperstack collects the credentials published in the same 30 seconds into one batch. 3. Hyperstack records one fingerprint of the batch on Hedera mainnet. The record is usually ready within a minute. If Hedera does not answer, Hyperstack tries again on its own. Only a fingerprint (a hash) goes on the blockchain. Names, email addresses, titles and other credential data do not. Blockchain security uses no extra credits. ## When you change a credential The record covers the recipient's email address, but not the name, the group or the dates. * If you change the **email** of a credential, or the recipient claims it with a different email address, Hyperstack signs it again and records it again in a new batch. Until the new record is ready, the credential page reads **Processing Transaction...** and **Verify credential** shows *Processing...*. The old record stays on Hedera. * If you change the name, the group or the dates, the record does not change. ## Existing groups and credentials You can turn on blockchain security for an existing group at any time. * Only credentials that you publish after you turn it on get a record. * Credentials that you published before do not get a record. They stay as they are. * Credentials under review get a record when you publish them. * If you turn it off, credentials that already have a record keep it. > [!WARNING] > > If your plan no longer includes blockchain security, the **Security** settings are hidden. When you then save the group, blockchain security turns off. Credentials recorded before 10 October 2026 have one record each, in an older format. They keep that record. Hyperstack does not record them again. ## What verifiers see On the credential page, the **Credential Authenticity** section shows: * **Technology**: **Hedera Hashgraph**. Credentials without blockchain security show **Hyperstack Engine**. * **Document Identity**: the credential's ID. * **Transaction Hash**: the hash of the Hedera transaction. Until the record is ready, it reads **Processing Transaction...**. * **Ledger record**: for example *Hedera Mainnet · message #196166*. Click it to open the record on HashScan, a public Hedera explorer. Credentials recorded before 10 October 2026 don't show this row. Click **Verify credential** to run the checks. With blockchain security, the list has one more step, **Verified on Blockchain**. It shows where and when the credential was recorded, for example *Recorded on Hedera Mainnet · message #196166 · 10 Oct 2026 14:12 UTC*, with a **View on HashScan** link. * If the record does not match the credential, the step reads *The ledger record does not match this credential* and the check fails. * If the Hedera ledger can't be reached, the step says *ledger unreachable right now*. This is not a failure. Try again later. > [!TIP] > > In the Studio, open a credential to see the same record in its **Verification** panel, with a **View on HashScan** link. ## Technical details for verifiers The record is on the Hedera Consensus Service: * **Network**: Hedera mainnet * **Topic**: `0.0.131862` * **Sender account**: `0.0.131578` Each batch is one message on the topic, in this format: ```json theme={null} {"v":3,"root":"<64 hex characters>","n":} ``` `root` is the Merkle root of the batch. `n` is the number of credentials in it. All credentials in a batch share the same transaction. ### Check the record yourself 1. On the credential page, note the message number in the **Ledger record** row. 2. Click the row to open the transaction on HashScan. Check the topic, the sender account and the time. 3. Or ask the public Hedera mirror node for the message: ```text theme={null} https://mainnet-public.mirrornode.hedera.com/api/v1/topics/0.0.131862/messages/ ``` The `message` field is base64. Decoded, it is the JSON above. ### What the fingerprint covers For each credential: 1. A SHA-256 hash of the credential's ID, the issuer's identity and public key, and the recipient's email address. 2. The issuer's Ed25519 signature of that hash. 3. A SHA-256 hash of the signature. This is the credential's leaf in the batch. The batch is a SHA-256 Merkle tree with RFC 6962 leaf and node prefixes. The leaves are sorted. The credential's title, the recipient's name and the dates are not part of the fingerprint. The credential page does not show the path from the credential to the batch root. **Verify credential** checks it for you: it recomputes the hash, checks the issuer's signature and the path to the root, and reads the message back from the public mirror node. Credentials recorded before 10 October 2026 have one message each. The message is the credential's own signature hash, not a batch root. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.