Arkheionx is built as a deterministic execution firewall for Safe treasuries. I designed it to withstand hostile transaction construction, compromised signer behavior, malicious module paths, unsafe Safe self-mutation, calldata ambiguity, adapter tampering, and governance latency abuse. The core assumption is simple: humans can approve bad transactions, but the EVM does not have to execute them. Arkheionx enforces policy at the transaction boundary and treats every calldata payload as hostile until it satisfies the active policy and its registered adapter checks.

I built Arkheionx to defend against the following classes of failure:

• Compromised Safe signers attempting to remove or replace the guard.
• Compromised Safe signers attempting to mutate owner sets or signer thresholds.
• Malicious or compromised modules attempting to bypass transaction-guard enforcement.
• Unsafe Safe self-calls, including guard mutation, module mutation, module guard mutation, fallback handler mutation, and owner mutation.
• Delegatecall execution through the Safe transaction path or module path.
• Unlimited ERC20 approvals under strict policy.
• Native value transfer attempts when native value movement is blocked.
• Gas refund abuse through gas-token refunds, custom refund receivers, inflated gas parameters, or refund-drain patterns.
• Unknown targets and unknown selectors under strict allowlist policy.
• Malformed calldata attempting to exploit ABI decoding assumptions.
• Adapter replacement, adapter codehash mismatch, and adapter quarantine bypass.
• Policy mutation during transaction execution.
• Reentrancy into active guard lifecycle state.
• Stale snapshot leakage after failed or successful execution hooks.

The immutable enforcement layer is composed of ArkheionxGuard and ArkheionxModuleGuard. These contracts enforce the transaction lifecycle and module lifecycle directly through Safe-compatible guard hooks. They do not depend on upgradeable proxy logic. I intentionally keep the core firewall small, deterministic, and resistant to governance mutation.

The mutable control layer is composed of PolicyRegistry and AdapterRegistry. Policy updates and adapter registrations are queued and executed through explicit timelocks. Adapter logic is stateless and bound to codehashes. A quarantined adapter is removed from active routing without replacing core guard logic. This design lets me add coverage for new risk surfaces without turning the enforcement layer into an upgradeable admin key disguised as security architecture.

The recovery layer is delayed by design. Emergency recovery exists to authorize exact recovery payloads after a delay, not to create an omnipotent backdoor. Freeze paths are allowed to stop risk quickly. Relaxation paths must wait. This is intentional: removing danger can be immediate; reducing protection must be delayed.

The current invariant suite models adversarial Safe execution through real guard lifecycle calls. The suite tracks violations through ghost counters and asserts that every critical bypass counter remains exactly zero. The current campaign survived 512,000+ adversarial calls without a single ghost violation.

The tested attack classes include:

• Guard removal.
• Module guard removal.
• Fallback handler mutation.
• Module enable and disable attempts.
• Owner addition, removal, swap, and threshold mutation.
• Unlimited ERC20 approval.
• Native value drain.
• Delegatecall execution.
• Gas-token refund abuse.
• Custom refund receiver abuse.
• Massive native gas refund abuse.
• Unknown call execution.
• Zero-target execution.
• Malformed ERC20 calldata.

Do not send me philosophical PDFs or theoretical vulnerabilities. Submit a deterministic Foundry trace that breaks one of my invariants. Code is the only truth.

A valid report must include:

• The exact commit hash tested.
• The exact Foundry command used.
• A minimal reproduction test or invariant handler mutation.
• The expected invariant.
• The observed violation.
• The exploit path through contract functions and calldata.
• The smallest patch that preserves the existing security model.

I do not treat vague claims, informal reasoning, speculative attack narratives, or screenshots as security findings. If the issue is real, it can be expressed as executable Solidity, a failing invariant, or a reproducible fork trace.

Send security findings privately before public disclosure. Do not exploit live deployments, do not touch funds, do not grief governance or registries, and do not test against production Safes without explicit permission. A finding that causes live harm is not research; it is an attack wearing a lab coat.