Skip to content

Protect privileged onchain operations

Chainwall checks every privileged action against rules stored onchain. It includes smart contracts, a TypeScript SDK, and a browser console for setting those rules, collecting approvals, and executing through protected accounts.

Three ways to integrate

Use the web portal for daily work. Use the SDK to build integrations. The system is synced through smart contracts.

01

Browser console

Lets teams configure users, groups, policies, accounts, contracts, tokens, interactions, timelocks, pending operations, and view execution history.

02

TypeScript SDK

Provides typed contract clients and tools for building requests, creating operation hashes, signing approvals, reading records, assembling workflows and scripts.

03

Smart contracts

Integrate directly with the Solidity contracts, supported by an advanced documentation system. Connect to Safe or Chainwall smart accounts.

Runtime checks and controlled changes work together

At execution, contracts check approved data, current rules, the exact request, allowed workflow calls, and the protected account. Separately, teams can require approval and a waiting period before selected settings change.

Chainwall product architectureThe browser console and SDK read an onchain registry. At runtime, Chainwall checks the current approval policy, exact action, workflow, and protected account. A separate, optional path can delay selected setting changes before they become active.PORTALbrowserSDKscriptsAPPROVED CATALOGOnchainregistryPOLICIES & APPROVALSPolicy rulesWAITING PERIODSConfigureddelaysEXACT REQUESTExecutionchecksALLOWED CALLSWorkflowrunnerPROTECTED ACCOUNTSProtectedaccountAPPROVED DESTINATIONProtocol contract

Scroll to explore the diagram →

Exact request

Execution checks

Chainwall gives each proposed action a fingerprint covering the calls, arguments, approval rule, value, deadline, operator, executor, and account. A changed detail produces a different request.
Chainwall product architecture. The runtime path checks the registry and current policy before execution reaches a protected account. Separately configured delays govern when selected setting changes become active.
Protection layerWhen it appliesControls
Checked during executionEvery submitted operationApproved data, current policy, exact request, workflow calls, and account path
Configured governanceOnly for selected setting changesSeparate approval, waiting periods, cancellation, and expiry
Operational assuranceDuring delivery and setupStatic console delivery, inspectable state, and predictable deployment checks

Check the exact operation again before it executes

An operator proposes an action. Approvers authorize that exact request under the current policy. An executor submits it, and Chainwall checks the call data, destination, deadline, value, operator, and account again.

RoleWhat the role does
OperatorProposes an action and may run it when the current policy permits.
ApproverAuthorizes the exact request as a member of a group required by its approval policy.
ExecutorSubmits an approved action. A request can be bound to one named executor when caller identity matters.
Interactive Chainwall operation flowA selectable operation flow. Each step explains how approved policies become an exact action that can run through a protected account.FROM APPROVED POLICY TO EXECUTIONRegister1Set rules2Defineactions3Approve4Run5

Scroll to explore the diagram →

Register

Add the people, contracts, tokens, feeds, and accounts the team has approved.
  • Connect to an existing registry or deploy one for the organization.
  • Give contracts, token records, accounts, and people stable names operators can review.
The Chainwall operation flow. Select a step to see what the team defines, approves, checks, and records.

Protect an existing Safe or use a purpose-built Chainwall smart account

Both account types reject calls that skip Chainwall's checks. Choose based on the account setup your team already uses and the integrations it needs.

For teams already using Safe

Guarded Safe

  • Safe owners and the signing threshold continue to control custody.
  • The Chainwall guard blocks unsupported account transactions.
  • The Chainwall module runs approved actions without pretending to be a normal owner transaction.
  • One-off plans can approve an exact sequence of Safe calls.

For a purpose-built Chainwall account

Purpose-built smart account (Chainwall vault)

  • The account is permanently linked to one Chainwall registry and executor.
  • Only that executor can start a call from the account.
  • It uses the same approval rules, approved contracts, and workflows as Safe mode.
  • Its address can be calculated before deployment and checked afterward.

Use the browser console or build with the SDK

The console and SDK read the same contract state. They do not keep a separate private database that can quietly change who or what is approved.

Operator console

Deploy or connect Chainwall; manage accounts, users, teams, approval rules, contracts, tokens, workflows, pending actions, delayed changes, billing, address books, and encrypted labels.

  • Can be hosted as static files
  • Reads current contract state directly
  • Guides proposals, approvals, execution, and admin changes

TypeScript SDK

Build applications, scripts, and services that read Chainwall state, prepare actions, collect approvals, and decode results across supported chains.

  • Typed requests and contract clients
  • Operation hashing and EIP-712 signing tools
  • Tools for reading records and storing encrypted pending work

Privacy, recipient delays, and billing

Encrypted operator data

An append-only KeyStore can hold encrypted labels and pending-action details. Teams can coordinate privately without letting a backend queue decide what is approved.

Delayed recipient list

A new payout recipient can be required to wait for a set period before an ETH or token transfer may use it.

Billing options

Teams can deploy with direct onchain billing. Subscription plans are also available for standard procurement, support, and deployment help.

Frequently asked questions

What Chainwall checks, how it works with existing accounts, and how teams deploy it.

Which chains and accounts does Chainwall target?

Chainwall is built for EVM-compatible networks. It supports protected Safe accounts and purpose-built Chainwall smart accounts, also called Chainwall vaults. Approvals are tied to the intended chain and account so they cannot be reused in a different setting.

Can existing Safes be used?

Yes. Teams can deploy a Safe configured for Chainwall or import an existing one. Before import, owners, signing thresholds, modules, guards, fallback handlers, contract code, and deployment source must be reviewed carefully.

Can automation use the same controls as human operators?

Yes. SDK clients, bots, workers, and internal tools use the same approved lists and rules. An action can also name the exact executor when it matters which operator or service runs it.

How is Chainwall priced?

Teams can deploy Chainwall without a subscription and pay onchain. Organizations that prefer standard procurement can request subscription pricing, deployment help, support, and assistance writing or reviewing actions and approval rules.

Map your accounts, approval rules, and recurring actions

Define the checks and waiting periods for the people, contracts, token records, accounts, and operations your team already manages.

Request access