Stop Trusting LLMs with Calldata: Architecting a Mathematical Cage for Web3 Agents

#architecture #llm #security #web3

AI agents don’t get hacked because they are inherently malicious. They get hacked because they are structurally sloppy.

An LLM does not natively understand EIP-55 checksums, UINT256_MAX boundary limits, or the 4-byte anatomical structure of EVM calldata. It is, at its core, a text-prediction engine. It simply spits out a JSON payload that looks like a valid blockchain transaction.

If your backend architecture relies on taking raw LLM output, running a quick regex check, and firing it off to a blockchain RPC, you are playing Russian Roulette with your protocol's treasury. Hackers exploit this semantic gap by injecting malicious bytecode (like a rogue approve function) under the guise of a benign action.

In the Lirix architecture, we don't wait for the blockchain to reject a bad transaction. We eradicate hallucinations in local memory, milliseconds before a network request is even assembled.

Here is an under-the-hood look at how we engineered the Mathematical Cage (Layers 1 & 2 of the Lirix pipeline).

Layer 1: The NLP Executioner (Intent Reconciliation)

The most dangerous fallacy in the Web3 AI space is the belief that you need Natural Language Processing (NLP) to execute on-chain actions safely.

When an AI agent says, "I want to swap 100 USDC for ETH," standard frameworks try to parse the semantic meaning of the word "swap." This leaves a massive attack vector for prompt injection. A hijacked agent can easily output benign text while stealthily generating calldata that drains the wallet.

Lirix kills NLP at the execution layer. We treat the agent's stated intent as nothing more than a cryptographic security label. We then perform an atomic, byte-level reconciliation against the actual generated calldata.

If the AI declares intent="swap", Lirix completely ignores the English dictionary definition. Instead, it extracts the first 4 bytes (the Method ID / Selector) of the hex payload. That selector must strictly exist within a hardcoded, immutable whitelist of trusted signatures.

If the AI claims it is doing a "swap," but the bytecode translates to setApprovalForAll or upgradeTo, the transaction is murdered in memory.

Semantic mismatch. Instant kill.

Layer 2: The Pydantic Fortress (Schema Boundaries)

Once the intent mathematically matches the bytecode, the payload moves to Layer 2: the structural boundary.

LLMs hallucinate lower-case addresses, odd-length hex strings, and scientifically impossible integer values. To combat this, Lirix enforces a physical barrier using a heavily customized Pydantic v2 schema (_TxDraftSchema).

This is not syntactic sugar; it is a hermetic cage:

The Hex Purist: The data field must start with 0x, must possess an even length, and must successfully decode via bytes.fromhex(). Any invisible "dirty" formatting characters or zero-width spaces injected by the LLM are caught and purged.
The Overflow Guard: The transaction value is hard-clamped. It cannot be negative, and it cannot exceed UINT256_MAX.
The EIP-55 Enforcer: Every to address is mathematically validated against its Checksum. If the casing is wrong, the payload is rejected before it ever hits an RPC node.

The "Strict Mode" Singularity

In security engineering, overlapping whitelists and blacklists create dangerous edge cases. The true ruthlessness of Layer 2 is revealed when Lirix is booted in Strict Mode.

We utilize Pydantic @model_validator decorators to enforce absolute mutual exclusivity at the exact moment the configuration is instantiated. If a developer accidentally places an address in both the blacklisted_addresses and the whitelisted_addresses arrays, the system refuses to boot.

Talk is Cheap. Show the Code.

We don't trust the AI, and you shouldn't trust marketing fluff. Here is the raw Python logic that powers the L1 Selector Mapping and the L2 Strict Mode overlap protection inside Lirix.

1. The L1 Intent-to-Selector Mapping:

# The AI's semantic 'intent' is physically bound to these exact byte signatures.
SWAP_INTENT_ALLOWED_SELECTORS: Final[FrozenSet[bytes]] = frozenset(
    {
        SWAP_EXACT_TOKENS_FOR_TOKENS_SELECTOR,
        SWAP_EXACT_ETH_FOR_TOKENS_SELECTOR,
        AGGREGATE3_SELECTOR,
    }
)

INTENT_TO_ALLOWED_SELECTORS: Final[Mapping[str, FrozenSet[bytes]]] = MappingProxyType(
    {
        "swap": SWAP_INTENT_ALLOWED_SELECTORS,
        "transfer": frozenset({ERC20_TRANSFER_SELECTOR}),
    }
)

2. The L2 Strict Mode Shield:

@model_validator(mode="after")
def _guard_lists(self) -> "LirixConfig":
    if self.strict_mode:
        # Prevent contradictory security policies at instantiation
        overlap = set(self.blacklisted_addresses) & set(self.whitelisted_addresses)
        if overlap:
            raise ConfigurationGuardException(
                human_readable_reason="strict_mode forbids overlapping blacklist and whitelist."
            )
    return self

This is how you build Web3 AI. You don't build a smarter brain; you build a stronger cage. By the time a payload exits Layer 2, you are mathematically guaranteed that its semantic intent matches its binary reality, and its structure is flawlessly EVM-compliant.

What's Next?

Layers 1 and 2 protect you from a sloppy, hallucinating AI. But what happens when the AI is hijacked by a highly intelligent human hacker?

Hackers hide malicious payloads deep inside nested Multicalls and use compromised EIP-1967 Proxy contracts to mask their true destination.

In the next part of this architectural series, we will deploy the Proxy Piercing Radar (Layer 3). We will reveal how Lirix recursively unwraps DeFi transactions and physically reads EVM storage slots to rip the disguise off malicious smart contracts.

The hunt continues. Subscribe to follow the engineering journey. 🛡️

#web3 #ai #security #ethereum #developers #python #langchain #autogen #pydantic #devops