Security overview

How Bloxchain keeps policy on chain, what has been audited, where the limits are, and how to report a problem.

The one-paragraph version

A Bloxchain smart account enforces its own rules. Requests wait, collect approvals and execute according to roles, gates and allowlists stored in the contract. The Bloxchain Platform orchestrates those steps in a browser; the SDK does the same from code; neither can override a denial on chain. Integration surfaces compares what each client can and cannot do. 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. Bloxchain never holds a key.

Pages in this section

Page	Read it for
Security model	Assumptions, trust boundaries, threat model, what is out of scope
Audit status	The Nethermind audit, its scope, and what each surface's status means for you
Known limitations	Honest boundaries of the Protocol, the Platform and this documentation
Security best practices	Operator practices: keys, time lock, allowlists, backups, signed files, drills
Report a vulnerability	Private disclosure contact, what to include, bounty scope
Disclaimers	Non-custodial statement, data handling, legal notices

Reading order for a security review

If you are assessing Bloxchain before deploying or integrating, read in this order.

1. How governed operations work: the lifecycle, execution paths, roles, gates and allowlists as users see them.
2. Security model: the assumptions the design rests on and the boundaries between what is trusted and what is not.
3. Audit status and Known limitations: what has been reviewed, and what has not.
4. Protocol internals, synced from the repository: State machine engine, Meta-transactions, Core contract graph, Contract reference, Protocol best practices.
5. The code itself, at the pinned commit: Bloxchain-Protocol. Run npm run test:foundry on the revision you review.
6. Before any real value: Production readiness and Security best practices.

Two adjacent pages belong in the same review: Design roles and permissions for the role model an assessor will want to see, and Recovery and incidents for the response plan behind a lost owner key or a compromised signer.

Findings go to Report a vulnerability, not to public issues.