> For the complete documentation index, see [llms.txt](https://docs.bloxchain.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bloxchain.app/security/security-best-practices.md). # Security best practices Operator habits that keep a governed account safe: how you hold keys, set the time lock, shape allowlists, back up this device, handle signed files and rehearse recovery. **Where:** inside an account → **Policies** and **On-chain access**; **Settings → Backup** Role design is covered in [Design roles and permissions](/guides/roles-and-permissions.md) and the pre-launch checklist in [Production readiness](/developers/deployment/production-readiness.md). This page does not repeat them; it covers what you do day to day. {% hint style="warning" %} **Testnet only during alpha.** The Platform is **Alpha · Testnet · Local-first** on Sepolia. Practise every habit below with test funds. {% endhint %} ## Keep the three protected keys apart **Owner**, **Recovery** and **Broadcaster** must be different addresses at deploy, and should stay that way in practice too. * **Owner** on a hardware wallet used only for approvals and policy changes. * **Recovery** on a cold wallet or with a trusted party, stored somewhere the owner key is not. Set it: **Overview** shows **Recovery not set** until you do. * **Broadcaster** on a wallet or service that only submits. It pays gas and cannot approve anything by itself. Never use any of these as a day-to-day requester. Create a custom role for that. See [Security](/platform-guide/policies/security.md). ## Choose the time lock for the humans who watch The time lock is how long a delayed request must wait before anyone can approve it, and therefore how long you have to notice and **Cancel** a bad one. * Personal accounts: hours are usually enough to catch a mistaken transfer. * Treasury accounts: a day or more, so a reviewer in another time zone can see it. * Remember that **Signed approval** and **One signature** do not wait. If you enable them, the signing keys need the protection the time lock would otherwise give. Change it under **Policies → Security → Change time lock**. Ownership transfers always wait the full time lock. ## Keep allowlists short and reviewed * Add only the recipients, payees and contract targets you use now. An empty list allows nothing; that is the safe state. * When a counterparty changes, remove the old entry the same day you add the new one. * For contract targets, allow only the functions you call. See [Allowlists](/platform-guide/policies/allowlists.md). ## Grant gates to narrow roles A gate cannot be turned off for a role once granted. Grant gates to small, purpose-built roles so that removing a person or a capability later means removing a role, not rebuilding the account. See [Gates](/platform-guide/policies/gates.md). ## Back up this device Your account list, names, custom networks and stored signed payloads live in this browser. Bloxchain keeps no copy. * Export from **Settings → Backup → Export JSON** after every change to your list or networks. * Store the file where you store other sensitive documents. It contains addresses and stored signed payloads, not keys. * Test a **Merge** restore in a second browser once, so you know the file works. See [Backup and restore](/platform-guide/settings/backup.md). ## Treat signed files like signed cheques A `.bloxmeta.json` file is valid for anyone who can submit it, until it expires or is used. * Share it only over a channel you would use for a signed cheque. Never paste it into a public place or a URL. * Keep the default expiry short unless you have a reason not to. * After the payload is submitted, **Delete** the stored copy from **Approvals → Approved** on every device that held it. * If a file leaks, act before its deadline: submit a harmless meta-transaction to consume the signer's nonce, or remove the signer's role. See [Signed files](/platform-guide/operate/signed-files.md). ## Check your own access before you act Open **My access** with the wallet you plan to use. It lists what that wallet can do at each phase and which path. If it says "This wallet is not assigned to any role yet", stop and ask an admin rather than trying other wallets. See [My access](/platform-guide/operate/my-access.md). ## Watch the queue and the record * Review **Approvals** regularly. Anything in **Blocked** or **Ready** that you do not recognise should be cancelled and investigated. * Review **History** after every batch of operations and compare it with your own records. Signed-in users can turn on alerts under **Settings → Notifications**. ## Rehearse recovery on testnet Once a quarter, and whenever a key holder changes, run the recovery drill on a disposable Sepolia account: connect the Recovery wallet, transfer ownership, wait out the time lock, approve, confirm in **My access**. Write down who holds Recovery and when they may use it. Procedure: [Recovery and incidents](/platform-guide/recovery.md). ## Related * [Known limitations](/security/audit-status/known-limitations.md) * [Protocol best practices](/protocol-reference/getting-started/best-practices.md) * [Report a vulnerability](/security/report-vulnerabilities.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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.bloxchain.app/security/security-best-practices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.