Inside Bloxchain: Technical Architecture of EngineBlox and Multi-Phase Workflows

Why Another Security Framework? The Design Targets

Bloxchain Protocol was built to meet requirements we kept hearing from protocol engineers, infra teams, and auditors:

• Deterministic workflows – operations should follow a well‑defined state machine, not ad‑hoc if‑else chains.
• Configurable without redeploy – roles and limits should be adjustable without rewriting core contracts.
• Composable – security primitives should be reusable across different applications and accounts.
• Observable – every phase transition should emit structured events suitable for monitoring and forensics.

EngineBlox is the part of Bloxchain that turns those requirements into code.

EngineBlox at a Glance

At a high level, EngineBlox consists of:

• A base state machine contract that encodes phases and transitions.
• Role and policy layers that gate which transitions are allowed.
• Storage models for per‑operation and per‑account metadata.
• Integration points for meta‑transactions and off‑chain relayers.

Each “operation” (e.g., “withdraw X tokens to address Y”) is represented as an instance in this state machine, moving through states such as:

• Requested → TimeLocked → ReadyForApproval → Approved → Executed → Completed / Cancelled

The exact naming and granularity can change per template, but the pattern is consistent: no direct jump from “requested” to “executed”.

State Machines in Solidity (Without Losing Your Mind)

EngineBlox uses a straightforward implementation strategy to keep audits tractable:

• States are represented as small enums or uint8 flags.
• Valid transitions are centralized in internal functions that enforce:
  • Current state
  • Caller role
  • Time‑based conditions
  • Policy hooks (limits, whitelists, etc.)
• Each transition emits an event with:
  • Operation ID
  • Old and new states
  • Caller and relevant metadata

This makes it easy for auditors (and your internal security team) to:

• Enumerate all reachable states and transitions
• Verify that there is no path that bypasses approvals or time‑locks
• Trace any operation’s full lifecycle from logs alone

Roles, Policies, and Configuration

On top of the state machine, Bloxchain exposes a role and policy layer:

• Roles (e.g., proposer, approver, executor, recovery) are stored as mappings or role structs.
• Policies (e.g., value limits, asset allowlists, strategy IDs) are typically expressed as config structs.

Key design choices:

• Most configuration is stored on-chain but separate from the core logic, allowing upgrades or rotations without redeploying the entire engine.
• Policy checks are implemented as pure or view functions wherever possible, to keep reasoning and testing simple.
• Hooks exist for strategy‑specific logic (e.g., different limits per portfolio or per asset).

From an integrator’s perspective, you are working with:

• A small, well‑defined API for creating and managing operations.
• Events that surface exactly where an operation is in the workflow.
• Optional extensions for custom checks and strategy logic.

Meta-Transactions and Relayers

Bloxchain is designed to work naturally with meta‑transactions:

• End‑users or internal tools sign an operation payload.
• A relayer or execution service broadcasts that payload to the network and pays gas.
• The contracts verify:
  • The signature(s) are valid
  • The operation is in the right state to proceed
  • The caller is an authorized executor, if relevant

This has several benefits:

• You can run execution infrastructure in hardened environments.
• Asset‑holding accounts do not need to hold native gas balances.
• You can centralize monitoring, rate limiting, and anomaly detection around a small number of relayers.

From a security standpoint, relayers become constrained operators, not super‑users. They can only execute what the state machine and policies already allow.

Example: Treasury Withdrawal Flow

Let’s walk a concrete example that many teams implement first.

Goal: Implement a high‑value treasury withdrawal workflow where:

• Strategy leads can request withdrawals.
• Risk or governance must approve.
• A relayer executes on-chain after a time‑lock.

In an EngineBlox‑based template, you might see:

1. requestWithdrawal(operationParams)

   • Valid only for ROLE_PROPOSER.
   • Creates an operation with state Requested.
   • Emits WithdrawalRequested(id, params, proposer).

2. startTimeLock(id) (often implied by request)

   • Moves state to TimeLocked.
   • Records unlockTimestamp based on policy.

3. approveWithdrawal(id)

   • Valid only for ROLE_APPROVER and after unlockTimestamp.
   • Moves state to Approved.
   • Emits WithdrawalApproved(id, approver).

4. executeWithdrawal(id)

   • Valid only for ROLE_EXECUTOR or an authorized relayer.
   • Checks limits and destination policies one last time.
   • Executes token transfers.
   • Moves state to Executed / Completed.
   • Emits WithdrawalExecuted(id, executor).

At no point can a single compromised proposer or relayer skip directly to execution.

Observability and Tooling

The event model in Bloxchain is designed to be machine‑friendly:

• Each event includes stable identifiers, states, and roles.
• You can build:
  • Dashboards of pending, approved, and executed operations.
  • Alerts for suspicious sequences (e.g., too many cancellations, repeated high‑value attempts).
  • Forensic tooling for post‑incident analysis.

Because the logic is open source, you can also:

• Simulate state transitions off‑chain to test policies.
• Write invariant tests (e.g., “funds can never move without at least N hours between request and execution”).
• Integrate with formal‑verification tools where appropriate.

Working with Bloxchain as a Developer

If you are integrating Bloxchain into your stack, you will typically:

1. Deploy core contracts on a testnet (e.g., Sepolia) using reference configurations.
2. Write small adapters or strategy contracts that plug into EngineBlox hooks.
3. Use the TypeScript SDK to:
   • Construct and sign meta‑transactions.
   • Query operation state and history.
   • Subscribe to events for dashboards and approvals.
4. Automate low‑risk flows with bots that operate within strict, on‑chain policy guardrails.

The repository includes examples and templates that cover common cases like treasuries, strategy accounts, and admin operations.

Status and Caveats

As of early 2026:

• Bloxchain Protocol is open source (MPL‑2.0) and focused on testnet deployments.
• Audits, internal reviews, and formal methods are strongly recommended for any production‑bound use.
• EngineBlox is designed to be composable, so you should feel comfortable:
  • Forking and extending templates.
  • Contributing improvements back to the ecosystem.

If you are a protocol engineer, infra lead, or security researcher interested in multi‑phase architectures, we encourage you to explore the Bloxchain Protocol repository, review the state‑machine patterns, and experiment with your own workflows on testnet.

For deeper collaboration, including joint design sessions or co‑authoring security patterns, reach out to the Particle CS team or follow our research updates on X.