Sign off on exactly what runs.

Each approval is tied to one specific request — given on-chain after a wait, or signed from any device. If the request changes, it needs a new approval.

Map an approval workflow How pre-execution checks work

Where control breaks today

A “yes” in chat doesn’t stop anything.

Most teams already require approval for sensitive changes — upgrades, large transfers, new permissions. The gap is that the approval isn’t connected to the transaction it was meant to allow.

Approval by message

A “yes” in chat or a ticket isn’t connected to the transaction, so nothing shows which request it allowed.

Approvers read a summary

A message describes the change. What actually executes can differ from what was read.

A yes that can be reused

An approval with no reference or expiry can be stretched to cover something that has changed since.

Approvers tied to a desk

Approving often means being at the right machine, with gas in the right wallet — so approvals wait, or get handed to someone else informally.

In practice

Approve from any device.

The security lead approves an upgrade by signature — from their own wallet, on another device.

What you set up

The approval paths each action allows
Who may request, approve and cancel
A broadcaster for signed approvals
The upgrade function on the allowed list

Approve from another device, step by step (opens in a new tab)

Engineering
requests

Lead signs
on any device

Upgrade
runs

Request
edited

Needs a new
approval

Illustrative

The approach

Two ways to approve, one set of rules.

For each kind of operation, you choose which ways are allowed and who may use them.

Approve on-chain, after a wait

The request waits out the account’s waiting period. Anyone watching the queue has time to cancel a bad one first.

Or sign off from anywhere

The approver signs off‑chain — no gas, any device — and a broadcaster or another role you configure submits it. Signed approvals are not held by the waiting period.

Cancel before it runs

Anyone allowed to cancel can stop a waiting request — on-chain, or with a signed cancellation from any device.

Bound to one request

An approval applies to one specific request. If the request changes, it needs a new approval.

Before you sign off

What the account enforces — and what it can’t.

An approval is only as good as the review behind it. We separate what the technology enforces from what your team still owns.

Enforced by the account

Who may request, approve and cancel — on each approval path you allow
The waiting period on approvals given on-chain
Signer, request and expiry checks on signed approvals
An on-chain record of each step

Your responsibility

Actually reviewing what you approve
Keeping signed approvals private until they’re submitted
Off-chain checks, such as testing new code before you approve it
Key management for every approver

Start with one approval you rely on.

We’ll map who should request it, who should approve it, and how they’ll sign.

Talk to us Bloxchain Platform