Attackers often target the software and admin process around a transaction, not only the signing keys. Before execution, Chainwall checks the submitted call, approved contracts, current approval rules, account, and deadline. Separately, configured waiting periods can slow selected setting changes.
Scroll to explore the diagram →
Explore connected attack surfaces, classified attack types and paths, documented incidents, and possible future failures across the onchain transaction lifecycle. The Chainwall view distinguishes checks made during execution from configured governance and operational assurance.
Runtime contract checks decide whether an operation can execute. Configured governance controls how sensitive settings change. Operational assurance reduces trust in delivery and setup without participating in every execution.
| Protection layer | Safeguard | What it does |
|---|---|---|
| Checked during execution | Approved policy stored onchain | Users, teams, approval rules, contracts, tokens, price feeds, workflows, accounts, admin permissions, and pending changes are stored in smart contracts. |
| Checked during execution | Current approval rules | Chainwall checks current team membership and approval thresholds at execution, not a saved view that may be out of date. |
| Checked during execution | Approval tied to the exact action | The operation fingerprint covers the calls, arguments, approval rule, deadline, value, operator, executor, and account where applicable. |
| Checked during execution | Only approved contracts | Reusable workflows look up contracts in the registry. If a required contract is missing, the workflow stops instead of accepting a substituted address. |
| Checked during execution | Protected account path | Managed Safes block unsupported calls, while purpose-built Chainwall smart accounts accept execution only from their assigned Chainwall executor. |
| Configured governance | Delayed permission changes | Sensitive settings can require extra approval and a waiting period. Anyone reviewing the registry can see whether a change is pending, ready, complete, canceled, or expired. |
| Operational assurance | Less trust in backend services | The static browser console builds requests locally and reads onchain records. A mutable backend is not needed to decide whether an action is allowed. |
| Operational assurance | Predictable contract addresses | Chainwall calculates component addresses before deployment and refuses to finish setup if the deployed configuration produces different addresses. |
See how Chainwall responds to misleading approvals, compromised interfaces, malicious admin changes, account bypasses, and overpowered automation.
Reject calls, operators, contracts, rules, or account paths that do not match the approved action.
Delay sensitive permission changes for separate approval and review before they become active.
Read approved catalog, policy, pending changes, approvals, and execution records directly from the chain.
Representative risks
Stolen signing authority, misleading approvals, weak recovery, provider co-signing, insider collusion
How Chainwall responds
Separate approval roles, limited admin permissions, exact action fingerprints, protected accounts, and independent operators
Representative risks
Compromised frontend, DNS, package, SDK, transaction builder, RPC, simulation, indexer, or labels
How Chainwall responds
Static delivery, local request building, contract checks, onchain settings and records, independent transaction decoding
Representative risks
Malicious approved-list changes, weaker approval rules, skipped delays, changed proxy code, excessive admin permission
How Chainwall responds
Onchain approved lists, waiting periods, separate roles, predictable deployments, visible account modules
Representative risks
Guard or module bugs, reused or stale approvals, unsafe plans, batched calls, delegated calls, token approvals and permits
How Chainwall responds
Chain and account binding, deadlines, replay protection, approved contracts, protected accounts, exact calls and named executors
Representative risks
Malicious approved code, bridges, oracles, token behavior, chain reorgs, sequencing, censorship, availability
How Chainwall responds
Chain-specific settings, price-feed checks, delayed recipients, tighter approval rules, monitoring, limits, and team review
Integration and automated tests exercise important state changes, approval rules, protected accounts, and execution checks.
A delayed admin action enters the queue without changing protected settings, and bypass attempts leave those settings unchanged.
Operation fingerprints, named executors, operator identities, one-time numbers, replay protection, and private approvals stay tied to the intended action.
Tests cover Safe guards and modules, transferred value, workflow callers, and checks against approved registry entries.
Dedicated checks cover predictable deployment addresses and the accuracy of paged onchain records.
Map the people, interfaces, permissions, accounts, and contracts involved in each action to decide which failures Chainwall should block or delay.
