How governed operations work

Every change to a Bloxchain smart account follows one governed lifecycle: a request is posted, it waits, an approver reviews it, the contract executes it, and the result is recorded on-chain. Signing is not the final decision. Rules apply from request through settlement.

The governed lifecycle

Step	What happens	Where you see it
Request	A signer whose role may request an action posts the request. Nothing moves yet.	New request, then the request appears in Approvals
Wait	For a delayed request, the account's time lock runs. While it runs the request can be cancelled but not approved.	Approvals, State column shows Blocked with the remaining time
Review & approve	An approver checks the decoded request and approves or cancels it.	Approve request dialog
Execute	The contract checks permissions and allowlists again, then runs the action.	Status Executing, then Executed
Record	The outcome (executed, cancelled or failed) is written on-chain and listed for the life of the account.	History

The on-chain record behind every request. Each status change is a contract state transition.

The same lifecycle as the Platform shows it inside a request.

Three execution paths

An action may enable up to three ways of moving through the lifecycle. Which paths exist, and who may take each step, is set per action under Policies → Actions.

Path	Tab label	What happens	Typical use
Delayed release	Delayed	The request is posted on-chain with your wallet. The time lock runs. An approver approves (or cancels) on-chain, and the action executes.	Large transfers, ownership changes, anything you want a chance to cancel
Signed approval	Signed	The request is posted on-chain. The approver signs an approval or cancellation off-chain. A broadcaster submits it and the action executes.	Approvers who should not pay gas or who approve from another device
One signature	One sign	The requester signs request and approval in one signature. A broadcaster submits and executes. No wait.	Routine, pre-authorised operations

In the compose screen this collapses to a two-way toggle. Wallet posts the request on-chain (the delayed path). Sign produces a signed meta-transaction that you, a permitted role or a broadcaster submits before it expires (the default expiry is shown, for example Meta-tx expires in 1h). A meta-transaction is a signed message that someone else can submit on your behalf; the contract verifies the signature, not the submitter. If you are signed in, the optional Bloxchain broadcaster checkbox submits it for you where that relay is available.

The time lock is enforced on the delayed path only. An approval that arrives as a signed meta-transaction is not held by the time lock; the signer's role permission and the allowlists still apply.

Who does what

Separation of duties: three protected roles, three addresses.

Role	Set	What it may do
Owner	At deploy; changeable through a time-locked transfer	Controls the account, approves delayed requests, configures roles, actions and allowlists
Broadcaster	One address at deploy; up to three in total, the rest added afterwards under Policies → Security	Submits signed meta-transactions and pays the gas for them
Recovery	At deploy	Can take ownership in an emergency (a time-locked ownership transfer)

These are protocol security roles. Use a different address for each. Beyond them, the owner creates custom roles (a name and a maximum number of wallets) and adds signers, the addresses that hold one or more roles. A signer's roles decide which steps of which actions that address may perform. Check your own from My access inside an account.

Policies

Actions are registered functions the account can perform. The Actions page lists each one by its on-chain operation name in upper case, with the function signature underneath: NATIVE_TRANSFER (__bloxchain_native_transfer__()), ERC20_TRANSFER (transfer(address,uint256)), and administration operations such as CONTROLLER_CONFIG_BATCH (executeGuardConfigBatch((uint8,bytes)[])). A new account has these registered at deploy; you add your own functions, such as mint(address,uint256), with Add action.

Each action carries permissions per step across three phases: Request, Approval and Execute. For every execution path you assign which role may perform each step. The editor is Manage permissions.

The governance flow of one action: which role may take each step on each path.

Gates are role-scoped on-chain authorizations that let a granted action run. A role needs both the permission on the action and the gate. Gates are permanent for that role; deleting a custom role clears its gates, and system-role gates stay on.

Allowlists restrict destinations: Recipients for native transfers, Payees for attached payments, and Allowed contracts (with the functions they may be called with) for contract calls. An empty list allows nothing.

The time lock is the minimum wait before a delayed request can be approved. It must be greater than zero and applies to every delayed request on the account, including ownership transfer.

Two labels worth knowing

Flow incomplete appears on an action whose permissions or allowlist are not configured. The account denies that action by default until they are. The action drawer lists what is missing under Related setup.

Vault is a freshly deployed account with no spending capability. It has an owner, a recovery address, broadcasters and a time lock, and it can receive assets. The transfer actions are registered, but no role is permitted to use them and every allowlist is empty, so nothing can move. It is a finished, locked state, not an error.

Statuses you see

The Platform shows friendly labels. Underneath, the contract stores one of a few statuses.

You see	On-chain status	Meaning
New, Awaiting Approval, Awaiting Your Approval	PENDING	Request posted; time lock running or waiting for an approver
Ready to Execute, Ready to Submit Cancellation	PENDING	Time lock complete, or a signed cancellation is ready
Approved, Submitting	PENDING	A signed approval exists on this device but has not been submitted yet
Executing, Pending Confirmation	EXECUTING	Approval submitted; the action is running
Executed, Confirmed	COMPLETED	Done and recorded
Cancelled	CANCELLED	Cancelled before execution
Failed	FAILED	The action ran and reverted; the failure is recorded
Expired	PENDING (request)	A signed payload passed its expiry. Sign again or cancel the request

In Approvals the State column summarises this as Blocked (time lock running), Ready, Cancel with time left, or Expired. History filters settled items by Executed, Cancelled and Failed.

Related

• Your first governed request
• Actions and Manage permissions
• Glossary