Particle CS Launch app (opens in a new tab)

The controls, in your own contracts.

Bloxchain Protocol is an open-source (MPL-2.0) set of smart-contract controls for EVM applications — example contracts are licensed separately. You integrate them into the functions that matter — so roles, permissions and execution conditions are checked where the operation runs.

create-account.ts
import { BasicFactory } from '@bloxchain/sdk';

// An account with its protected roles and a waiting period
const factory = new BasicFactory(
  publicClient, walletClient, factoryAddress, chain, gasLimit,
);
const minted = await factory.cloneBlox({
  initialOwner: owner,
  broadcaster,
  recovery,
  timeLockPeriodSec: 86_400n, // 1 day
}, { from: owner });

const account = factory.cloneAddressFromReceipt(await minted.wait());
$ npm install @bloxchain/sdk @bloxchain/contracts viem
Adapted from the Bloxchain Protocol README · github.com/PracticalParticle/Bloxchain-Protocol
Why it’s open

A control layer you can read.

Your app knows who signed. The Protocol decides what happens next — and you can verify exactly how.

Security you can read

A control layer you can’t inspect is a promise. The contracts, the tests and the audit report are public, so you can verify the enforcement rather than take our word for it.

No dependency on us

The policy lives in your own contracts. If you never use our Platform — or stop using it — the rules still hold.

Take only what you need

Use one component — ownership, roles or guarded execution — in your own contracts, without adopting the whole account.

Don’t rebuild the same logic

Roles, approvals and conditions are needed by many applications. Reuse a reviewed implementation instead of writing your own.

What you can build

Start from the shape closest to your case.

Use the building blocks you need, and leave the rest.

A governed account

Roles, approvals and limits in one account.

A vault

Assets behind an owner and a waiting period.

A token or tokenized asset

Supply changes go through approval.

Payments that wait

Each payment waits, then is approved or cancelled.

Rules over an existing setup

Keep your multisig; limit what it may call.

Architecture

Three components, one shared engine.

A governed account combines ownership and recovery, roles and permissions, and guarded execution — over a shared state and operation lifecycle. You can adopt the whole account or only the parts you need.

Adopting it

Start fresh, or add to what you run.

Deploy a new governed account, or put controls in front of contracts you already use. Either way, begin with one important function and test an allowed, a denied and a governed request.

New account

Start from a governed account

Deploy an account with the components you need and define its roles and operations from the start.

  1. Choose the components
  2. Define roles and governed operations
  3. Deploy and test the lifecycle
Existing contracts

Put controls in front of what you run

Add execution rules in front of a contract or multisig you already use, without migrating everything.

  1. Identify the security boundary
  2. Integrate the relevant controls
  3. Test failure conditions, then expand

Deploying an account. The official CreateX path deploys a standard account on the 15-network catalog (deployment integrity verified). An experimental toolkit is also available on Sepolia for testing.

Official factory and Sepolia toolkit (opens in a new tab)
Resources

Everything is published.

Security boundaries

What’s been reviewed.

Independent auditNethermind (NM_0828)Scope: core protocol contracts (contracts/core/). BasicFactory and BasicAccount are not in NM_0828.Scope →
DeploymentsCatalog verifiedThe official CreateX catalog was checked across all 15 listed networks against the published contracts release.How →
Your codeNeeds its own reviewCustom extensions and anything you build on top aren’t covered by our audit.Trust →

Start with one important function.

Integrate one control, test the allowed, denied and governed cases, and inspect the result on-chain.