> 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-model.md). # Security model The assumptions Bloxchain's design rests on, the boundaries between what is trusted and what is not, the threats it addresses, and what this page does not cover. {% hint style="info" %} **Status.** The Protocol core is audited by Nethermind (NM\_0828), core framework scope. Custom extensions and your own configuration are not covered by that audit. The Platform runs on Sepolia today. Ethereum mainnet is coming soon. See [Audit status](/security/audit-status.md). {% endhint %} ## Design assumptions * **The chain enforces, clients orchestrate.** Policy lives in the smart account contract. The Platform and the SDK build and submit transactions; neither is trusted for authorization and neither can bypass a denial. * **Separation of duties.** Every account has three protected roles set at deploy: **Owner**, **Broadcaster** (1 to 3 addresses) and **Recovery**, all distinct addresses. Custom roles split day-to-day work further. * **Explicit actions only.** An account performs only registered **actions**, only for roles with the right per-step permission and a granted **gate**, and only to destinations on an **allowlist**. Anything unset is denied by default (**Flow incomplete**). * **Two authorisation shapes.** Delayed release separates request and approval in time (the time lock). Signed approval and One signature separate the signer from the submitter (the Broadcaster). One key alone cannot both decide and execute unless policy deliberately allows it. * **Immutable official deployments.** Accounts from the official factory are EIP-1167 clones fixed to a template published at tagged releases. Upgradeable proxies exist only if you build them. See [Immutable vs upgradeable](/developers/deployment.md#immutable-vs-upgradeable). * **Non-custodial by architecture.** Users hold their keys. Bloxchain never holds a key and cannot move funds, approve requests or recover a lost key. * **Local-first inventory.** The account list and custom networks live in the user's browser (**This device**) unless the user joins a paid organization with a shared list (**Cloud**). Bloxchain keeps no copy of local data; the backup file is the only copy. * **Optional relay.** The **Bloxchain broadcaster** is a sign-in-gated convenience that submits signed payloads. It is not a security control and is not promised in every environment; any wallet holding the Broadcaster role can submit instead. * **Operator hygiene.** Keys live in hardware wallets or secret stores, and operators check **My access** to know which wallet they are using. We assume nothing about legal or tax treatment, RPC availability, or protection against social engineering. ## Trust boundaries
Trust boundaries between the smart account on chain, wallets, the Platform, the SDK and off-chain services

Authorization is decided on chain. Everything off chain prepares, displays or relays.

| Trusted for authorization | Not trusted for authorization | | ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | The smart account contract and its stored policy | The Platform (bloxchain.app) front end and hosted services | | Wallet signatures, including EIP-712 signed payloads | SDK client code and your own services | | On-chain role, gate and allowlist state | Off-chain indexes, notifications, reference prices, the Approvals list itself | | | Signed files in transit (`.bloxmeta.json`): valid until expiry or use, so treat them like a signed cheque | The Platform holds only orchestration state: account names and marks (never on chain), custom networks, stored signed payloads awaiting submission and, for signed-in users, notification preferences. None of it can grant a permission. ## Threat model ### Assets at risk | Asset | Impact if compromised | | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | Owner key | Policy and ownership changes, approval of delayed requests. Ownership transfer is itself time-locked, which gives Recovery a window to act. | | Broadcaster key | Submission of any valid signed payload it receives, and gas spending. It cannot approve or request by itself. | | Recovery key | Can take ownership. Cannot spend or change policy until it does. | | Custom role signer | Whatever steps that role holds on whatever actions, within allowlists. | | Signed file | Anyone who can submit can broadcast it until it expires or is used. | | Proxy admin key (custom upgradeable deploys only) | Implementation swap. Not applicable to official immutable clones. | | This device's browser storage | Loss of the account list and stored payloads, not of the contract. Restore from backup or re-import by address. | ### On-chain mitigations Against external attackers, malicious insiders, compromised operators, faulty integrators and a malicious front end, the contract provides: | Threat | Mitigation | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Unauthorised action | Per-step role permissions, gates, and protected roles enforced in the contract | | Value sent to the wrong place | Allowlists for recipients, payees and contract targets, checked before any external call | | Rushed or mistaken transfer | Time lock on delayed release; cancel during the wait | | Meta-transaction replay | EIP-712 domain bound to the account, per-signer sequential nonces, deadlines, handler binding | | Reentrancy | Checks-effects-interactions ordering. External code runs at two points: the transition to executing, and the attached-payment settlement that follows it. The record moves to a payment status before that second call, so it cannot be re-entered | | Malicious front end | Wallets show what they sign; policy denies anything outside the rules regardless of what the UI displayed | | Upgrade hijack | Not possible on official immutable clones; on custom proxies, your proxy admin controls apply | Organizational security (phishing, key ceremonies, monitoring) is yours to run. See [Security best practices](/security/security-best-practices.md). ## What reviewers should examine Role and gate assignment paths; time lock enforcement on the delayed path and its deliberate absence on signed paths; meta-transaction verification (digest, nonce, deadline, handler binding); allowlist checks before every external call; attached-payment rollback; and, for custom proxies only, initializer atomicity and storage layout. Reading order and repository links: [Security](/security/security.md#reading-order-for-a-security-review). ## What this page does not cover Your organization's operational security and key management, audits of custom extensions beyond the Protocol baseline, legal or regulatory classification of your use case, and economic or MEV risks on public networks. ## Incident response
Incident response flow: contain, rotate, review

Contain first (cancel pending requests, remove roles), then rotate keys, then review History.

Operator procedure: [Recovery and incidents](/platform-guide/recovery.md). Protocol issues: [Report a vulnerability](/security/report-vulnerabilities.md). ## Related * [Known limitations](/security/audit-status/known-limitations.md) * [How governed operations work](/introduction/how-it-works.md) * [Technical overview](https://github.com/PracticalParticle/Bloxchain-Protocol/blob/99beac2d6e6d7567c23b25cecaf6f4053f31c987/TECHNICAL_OVERVIEW.md) and [SECURITY.md](https://github.com/PracticalParticle/Bloxchain-Protocol/blob/99beac2d6e6d7567c23b25cecaf6f4053f31c987/SECURITY.md) at the pinned commit --- # 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-model.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.