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.
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.
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
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 organization members, watched addresses and per-organization notification preferences. None of it can grant a permission.
Threat model
Assets at risk
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:
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.
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.
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
Operator procedure: Recovery and incidents. Protocol issues: Report a vulnerability.
Related
Technical overview and SECURITY.md at the pinned commit
Last updated
Was this helpful?