[Idea/Draft] Protocol-Level Smart Contract Invariant Protection via Pre-Mempool Validation (Security Manifests)

EIPs EIPs networking
1

Abstract

This is a draft conceptualization meant to initialize a discussion on what I believe is a necessary evolution for EVM security. The goal is to introduce a standardized “Security Manifest” for smart contracts, coupled with a specialized mempool admission policy.

To be clear: this is a general idea. I am putting this forward to start the conversation, not to present a finalized specification. However, the premise is direct: we might need an infrastructure-layer gatekeeper that prevents zero-day exploits by enforcing intended contract behavior before execution.

Motivation

Currently, smart contract security relies entirely on execution-time logic (bounded by gas and block limits) or off-chain monitoring (often too late). Recent proposals like EIP-7906 (Transaction Assertions) are excellent, but they are user-side protections (e.g. slippage/state-diff limits). They do not protect the smart contract itself from an attacker.

I want to hit the obvious roadblocks first so we can move past them: I know L1 nodes cannot natively run non-deterministic AI or heavy heuristics without breaking consensus. Therefore, this proposal does not suggest putting AI inside Geth/Reth. Instead, it proposes a network-level standard to bridge off-chain threat analysis with on-chain mempool admission.

Proposed Architecture (High-Level)

  1. The Manifest Standard: Contracts expose a standardized URI detailing normal parameters, state boundaries, and restricted modifications.

  2. The Pre-Mempool Routing: Transactions targeting protected contracts are gossiped to a specialized builder network or pre-mempool.

  3. Heuristic / AI Validation: Nodes within this specialized network run advanced non-deterministic checks (AI/ML threat modeling) against the transaction payload using the contract’s manifest.

  4. Standard Mempool Admission: If deemed safe, the transaction is wrapped with a cryptographic proof (e.g., zkML) or a committee signature. The L1 node simply verifies this lightweight proof/signature before accepting it. Gas costs for verification are paid by the sender.

How the Manifest Should Look (Draft Concept)

The manifest should be an immutable document (on-chain or hosted on IPFS/Arweave to avoid content modiification without notice) referenced or accesible on-chain via a standardized function, such as securityManifestURI().

  • Format: A standardized JSON or YAML schema.

  • Content: It should act as an extension of the ABI, defining strict pre- and post-conditions. It would outline:

    • Acceptable input ranges (e.g., “Function X should never receive a uint256 larger than Y”).

    • State invariants (e.g., “The sum of all balances must strictly equal totalSupply”).

    • Behavioral anomalies (e.g., “A single transaction should not drain more than 10% of the TVL”).

  • Language: Ideally, it maps closely to existing invariant-testing syntax (like Halmos or Foundry’s forge test invariant structures) so developers can easily translate their local test constraints into a live network firewall.

Addressing the Elephant in the Room (Trade-offs & Attack Vectors)

I want to pre-emptively address the trade-offs, because I am aware that adding a security layer inherently adds a new attack vector.

  1. Non-Retroactive: This specification cannot and should not be retroactive. You cannot arbitrarily attach a manifest to an existing, non-upgradeable contract to change its behavior. This must be an opt-in standard for new deployments or specific upgrade paths.

  2. The “Malicious Admin” Vector: The typical question is: “What happens if an admin updates the manifest maliciously to censor users or brick the contract?” The answer is: The exact same thing that happens if an admin maliciously updates an ERC-1967 proxy implementation. Yes, it requires trust in the upgrade keys. This is simply a new flavor of the exact same trade-off we already accept with proxies.

  3. Auditability: Because a malicious manifest could cause false positives (or intentional denial of service), the manifest is code. It must be audited exactly like the Solidity smart contract it protects.

Used maliciously, it’s a censorship tool. Used correctly, the win is staggering: developers would no longer need to rely purely on flawless formal verification or fear unpredictable edge-case attacks, because the infrastructure itself refuses to route transactions that violate the contract’s fundamental physics.

Open Questions for the Community

  • Mempool Gossip Rules: Should this be handled by a new EIP-2718 transaction type that requires a generic “validity proof” field, or handled entirely out-of-protocol by MEV-Boost builders?

  • L2 First? While the ultimate goal is EVM-wide infrastructure, would it make more sense to standardize this specifically for L2 Sequencer implementations first (similar to how Zircuit approaches sequencer-level quarantine)?

I look forward to the community’s brutal honesty and constructive ideas to refine this conceptualization.

1 Like