> 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/developers/deployment/production-readiness.md). # Production readiness One checklist for the Protocol, the SDK and the Bloxchain Platform before an account holds value you cannot afford to lose. **You need:** a Sepolia account you have already configured and operated ## Where things stand | Surface | Status today | | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Bloxchain Protocol** (contracts, SDK) | Core framework audited (Nethermind NM\_0828). Official deployments on the 15 supported networks. | | **Bloxchain Platform** (bloxchain.app) | **Alpha · Local-first.** Same 15 networks. Free on this device; sign in if you have early access, otherwise join the waitlist; organizations available as paid plans. Alpha is not a certification for material value. | | **Your extensions** | Custom contracts, custom factories and proxies are outside the audit scope. Review them separately. | Enforcement is always on chain. The Platform and the SDK are clients; neither can loosen a rule stored in the account. Audit scope and reports: [Audit status](/security/audit-status.md). ## Checklist ### 1. Versions and deployment * [ ] Accounts come from a tagged Protocol release or the official factory, not an unreviewed fork. * [ ] `@bloxchain/sdk` and `@bloxchain/contracts` are pinned to the same release. See [Releases and compatibility](/resources/releases.md). * [ ] The account address and chain are verified on a block explorer. * [ ] You know whether each account is an immutable clone or a custom proxy. See [Immutable vs upgradeable](/developers/deployment.md#immutable-vs-upgradeable). ### 2. Policy on chain * [ ] Every function your team will call is registered as an **action**. See [Actions](/platform-guide/policies/actions.md). * [ ] **Roles** exist for each duty, **signers** are assigned, and per-step permissions are set with **Manage permissions**. No action shows **Flow incomplete**. See [Roles](/platform-guide/access/roles.md) and [Manage permissions](/platform-guide/policies/manage-permissions.md). * [ ] Every granted role has its **gate**. Remember gates are permanent for that role. See [Gates](/platform-guide/policies/gates.md). * [ ] **Allowlists** (recipients, payees, allowed contracts) contain only what is needed. An empty list allows nothing. See [Allowlists](/platform-guide/policies/allowlists.md). * [ ] **Owner**, **Recovery** and **Broadcaster** addresses are distinct, documented offline, and none is used as a day-to-day operator key. The **time lock** gives a human time to notice and cancel. See [Security](/platform-guide/policies/security.md). * [ ] Separation of duties holds: no single wallet can request and approve a critical action unless you decided that on purpose. See [Design roles and permissions](/guides/roles-and-permissions.md). ### 3. Platform workspace * [ ] The connected wallet is on the same network as the account. See [Connect a wallet](/platform-guide/connect-wallet.md). * [ ] The account list on **this device** is exported from **Settings → Backup**, and everyone who operates knows Bloxchain keeps no copy. See [Backup and restore](/platform-guide/settings/backup.md). * [ ] If you use an organization, checkout is complete (**Organization active**, not **Checkout required**) and member addresses are current. See [Organizations and billing](/platform-guide/settings/organizations-and-billing.md). * [ ] Operators have practised **New request**, **Approvals** and **History**. See [Operate an account](/platform-guide/operate.md). * [ ] You know how signed files move between devices and who may submit them. The optional Bloxchain broadcaster relay needs sign-in and is not promised in every environment; a wallet with the Broadcaster role can always submit. See [Signed files](/platform-guide/operate/signed-files.md). ### 4. Rehearsed on testnet * [ ] Each execution path your policy enables (Delayed release, Signed approval, One signature) has run end to end on Sepolia. * [ ] A cancel during the time lock has been tested. * [ ] Revert reasons for a denied request are understood. See [Troubleshooting](/resources/troubleshooting.md). ### 5. Security and legal * [ ] [Security model](/security/security-model.md) and [Known limitations](/security/audit-status/known-limitations.md) read. * [ ] Custom contract code reviewed separately from the Protocol audit. * [ ] Legal and compliance review done for your jurisdiction. See [Disclaimers](/security/audit-status/security-disclaimers.md). * [ ] The team knows how to [report a vulnerability](/security/report-vulnerabilities.md) privately. ## Recovery planning Write this down before you need it. The operator-side procedure is in [Recovery and incidents](/platform-guide/recovery.md); these are the integration points. * Record which addresses hold **Owner**, **Broadcaster** and **Recovery** for each account, and where those keys are stored. * The SDK's account address is the **smart account**, not your business-logic contract. Document both, and which actions and allowlist entries connect them. * Record whether each account is an **immutable clone** or a **custom upgradeable proxy**, and who holds any proxy admin key. * Plan a **migration**: for immutable accounts, new logic means a new account, a policy rebuild, governed asset moves and updated allowlists and integrators. See [Recovery and incidents → Limits](/platform-guide/recovery.md#limits). * Know how to invalidate a leaked signature: consume the signer's nonce, rotate the signer off its role, or wait for the deadline. See [Meta-transactions](/protocol-reference/api-reference/meta-transactions.md). * Rehearse the recovery path on a disposable Sepolia account, and repeat it whenever key holders change. ## When something goes wrong * Operators: [Troubleshooting](/resources/troubleshooting.md) and the in-app **Help** page. * Security issues: [Report a vulnerability](/security/report-vulnerabilities.md). * Everything else: [Support and community](/resources/support.md). ## Related * [Deploy the Protocol](/developers/deployment.md) * [Audit status](/security/audit-status.md) * [Security best practices](/security/security-best-practices.md) * [Roadmap](/resources/roadmap.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.bloxchain.app/developers/deployment/production-readiness.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.