Protect protocol admin actions through limited adapters

Keep the protocol focused on its core job. Small adapter contracts expose only the admin calls you intend to allow, while Chainwall checks who may use them, which contracts they depend on, what approval is required, and whether a delay has passed.

Request access See a tested market listing

Route protocol admin calls through limited adapters

Keep core protocol logic separate from approval and admin tooling. Core contracts accept calls from a few limited entry points. Chainwall checks whether the action and caller meet the current rules.

Empty parliamentary chamber arranged around a central floor — Photo: Neon Wang / Unsplash

Governance adapter

Market listings, oracle rotations, and supply-cap changes accept calls only from a small contract built for those actions and reached through an approved workflow.

Mechanical locking bars and dial on a historic bank vault — Photo: David Trinks / Unsplash

Treasury adapter

Fee sweeps use a limited adapter and look up the approved recipient in the registry instead of accepting an arbitrary address.

Red motor stop button on an industrial control panel — Photo: Hans Westbeek / Unsplash

Emergency permission

Emergency pause checks whether the caller currently holds one specific onchain permission, so the role can change without hard-coding a permanent admin address.

Give approved contracts stable names

Give important dependencies a stable name in the registry: governance and treasury accounts, workflow runners, tokens, price feeds, and adapters. Changing the address behind a name becomes a visible, reviewable admin action.

Approved registry names* sample registry names from a fictitious protocol

01northstar/dao-safe
02northstar/treasury-safe
03northstar/miniscript
04northstar/weth
05northstar/oracle-main
06cap.northstar.pause

Choose an approved workflow or an exact call plan

Choose the simplest method that fits the action instead of giving every admin task one broad transaction path.

Reusable workflow for routine actions

Use a MiniScript workflow to list markets, rotate oracles, set caps, and run other recurring actions. It looks up approved contracts and dependencies when the action executes.

Review the action once and reuse it
Look up approved contracts by stable name
Add onchain checks for conditions that can change

Exact plan for a one-off action

Approve the precise calls for a fee sweep, treasury migration, position unwind, or reward transfer. The plan can also name the only executor allowed to run it.

Exact calls and value under one approved fingerprint
Approval stays tied to the intended account and chain
Name the executor when caller identity matters

List markets after token and price-feed approval

In the test, an operator proposes a WETH market and an approver in the risk group authorizes it. The listing still fails because the catalog has no approved token record containing WETH and its registered price feed.

Scroll to explore the diagram →

Rejected

Token check blocks it

Execution fails because the catalog does not yet contain an approved token record with the registered price feed.

Three tests cover the key checks

These tests use the real Chainwall contracts for approved policy, execution, workflows, account protection, approval rules, and delayed changes—not a mocked dashboard.

TEST 01

Guarded Safe

Guarded account bypass test

A Safe protected by Chainwall rejects a direct proposal call that tries to skip the approved execution path.

TEST 02

Market-listing checks

Token + feed approval test

A listing approved by two groups stays blocked until a separate write adds the token record with its registered price feed after operations and risk approval and a one-day wait.

TEST 03

Named plan executor

Executor binding test

Another approved operator cannot run the treasury plan; only the executor named in the approval can complete the sweep.

Apply this pattern to your protocol

01
Put configurators, proxy admins, oracle admins, pause guardians, and rewards controllers behind Chainwall-protected accounts or limited adapters.
02
Give important tokens, price feeds, routers, rate models, treasuries, and adapters stable names in the registry.
03
Keep the protocol integration small: look up one approved address, check one permission, or trust one limited adapter.
04
Use reusable workflows for routine actions and exact plans for one-off actions.
05
Require stronger approval and real waiting periods when contracts, tokens, feeds, workflows, modules, or permissions change.
06
Name the executor when the identity of the final caller matters.
07
Protect the managed account so Safe owners and signers cannot bypass the reviewed path.
08
Monitor changes and waiting queues independently from the interface used to submit them.

Frequently asked questions

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

Does a protocol need to import Chainwall internals?

No. Keep the contract interface small: trust a limited adapter, look up an approved address, or check one dedicated permission. The protocol does not need to know how Chainwall implements approvals, waiting periods, or workflows.

Why use an adapter instead of making the Safe the protocol admin?

A limited adapter exposes only the admin actions intended for that path. The Safe continues to hold funds and approvals, while Chainwall checks which adapter call, arguments, contracts, and approval rules are allowed.

Why are token metadata and a price feed separate from the contract address?

Approving a contract address does not prove that the contract was reviewed as a token or has an approved price feed. A market-listing workflow can require both facts before it executes.

Limit who can run each protocol admin action

Identify the admin calls, contracts, approval rules, waiting periods, and accounts that should sit behind a small Chainwall adapter or dedicated permission.

Request access