Security beyond the key.
A private key proves who authorized a request. We build the controls that decide what that request is allowed to do — before it executes on-chain.
Six questions before an operation runs.
A signature answers the first two. The rest are an organization’s policy — and without operation-level controls, those answers live in a UI, a backend or a manual procedure.
| Before an operation executes | Signature only | With our controls |
|---|---|---|
| The key is authorized for the account | ||
| The request wasn’t altered after signing | ||
| This participant’s role allows this operation | – | |
| The target is one the account permits | – | |
| Required approvals or waiting periods are met | – | |
| Changes to the rules follow a controlled path | – |
Each control applies where it is configured and enforced on the account.
Between the key and the chain.
We don’t replace wallets, custody or monitoring. Bloxchain is the layer in between — it governs what an operation may do, how the rules change, and the record it leaves.
BloxchainProgrammable governance for secure execution
- AuthorizationWho may request, approve, cancel or execute.
- PolicyPermitted targets, approvals and waiting periods.
- GovernanceHow owners, roles and rules change — including recovery.
- ExecutionOperations run only once their checks pass.
- RecordOn-chain, from request to result.
AlongsideMonitoring stays with your tools — our on-chain records and waiting periods give them something to act on.
How an operation is decided.
Every request is checked against the account’s configuration before it executes. There are three possible outcomes.
Intent
A person, an application or an AI agent asks for an operation.
Controls
The account checks the role, the target and any conditions it’s configured with.
Outcome
- ProceedExecutes and is recorded
- PendingWaits for an approval or a delay
- RejectedNothing executes
Three ideas, explained in depth.
Start with how a request is checked, then who sets the rules, then where those rules are kept.
Pre-execution security
What an account checks before an operation runs — and why a refused request moves nothing.
Read the page →Programmable governance
Roles, approvals, waiting periods and destinations — including how the rules themselves change.
Read the page →Smart-account architecture
Ownership, roles and execution rules on one account — so policy travels with it.
Read the page →What controls can and can’t do.
Governance controls can limit or condition operations when they are configured and enforced correctly. They do not guarantee that a compromised key has no consequences, prevent every malicious action, or replace secure key management, monitoring and operational controls.