Domain separation only works if the executing contract checks it

The specification puts a chain identifier in the domain separator precisely so a signature for one chain cannot be replayed on another. That protection is only real if the contract verifies the value at execution rather than trusting one it cached.

Part of Digital asset custody

What the domain separator does

Typed structured data signing hashes a domain object alongside the message. The domain typically contains the contract name, a version, a chain identifier and the verifying contract's address.

Including all four means a signature is valid only for that message, to that contract, on that chain. Change any element and the hash changes and the signature fails.

The optimisation that breaks it

Computing the separator involves several hashes, which costs gas. A common optimisation computes it once in the constructor and stores it.

// Common pattern — computed once, stored
constructor() {
    DOMAIN_SEPARATOR = keccak256(abi.encode(
        TYPE_HASH, nameHash, versionHash,
        block.chainid,          // captured at deployment
        address(this)
    ));
}

// At execution, the stored value is used.
// If block.chainid has changed since deployment,
// the separator no longer reflects the current chain.

On a chain that never forks and where the contract exists at only one address, this is harmless and saves gas on every call. Neither condition is guaranteed.

Two situations where it matters

The second is more common than it sounds. Deterministic deployment patterns are used deliberately to place contracts at matching addresses across chains, which is convenient and removes the address element's distinguishing power.

With the address matching and the chain identifier cached, two of the four domain elements no longer separate anything.

The fix

// Cache, but verify the cache is still valid
function _domainSeparator() internal view returns (bytes32) {
    if (block.chainid == _cachedChainId
        && address(this) == _cachedThis) {
        return _cachedSeparator;
    }
    return _buildSeparator();     // recompute
}

This keeps the gas saving in the common case and recomputes when the assumption no longer holds. Widely used library implementations do exactly this, which is an argument for using them rather than hand-rolling the pattern.

Why review misses it

Three reasons, and they compound.

1. The code looks right. The chain identifier is present in the computation. A reviewer scanning for its presence finds it.
2. It cannot be tested locally. Reproducing it needs a chain identifier change, which does not happen in normal test environments.
3. The pattern is widespread. Seeing it in many codebases suggests it is correct rather than that it is a common error.

What to check

• Is the domain separator cached, and if so is the cache validated against the current chain identifier and address?
• Are signatures bound to a nonce, and is that nonce consumed on use?
• Is there an expiry, so a signature does not remain valid indefinitely?
• Does the same contract exist at the same address on other chains?
• Does the verification path check the recovered signer against an expected value, or accept any valid signature?

The last one catches an unrelated but more damaging error that appears in the same code region, which is a reason to review the whole signature verification path rather than only the separator.

The broader lesson

A separator is only separating if it is computed from current reality at the moment of verification. Caching any security-relevant value turns it into an assumption, and assumptions need to be checked rather than trusted.

The same pattern appears well outside smart contracts: cached permission decisions, cached tenant identifiers, cached environment flags. Each is a gas optimisation of a different kind, with the same failure mode.

Why review misses it

Three reasons, and they compound. The chain identifier is visibly present in the computation, so a reviewer scanning for it finds it. The condition cannot be reproduced in a normal test environment, because chain identifiers do not change there. And the pattern appears in many codebases, which reads as confirmation rather than as a common error.

Deterministic deployment patterns are used deliberately to place contracts at matching addresses across chains, which is convenient and removes the address element's distinguishing power. Combined with a cached chain identifier, half the separator stops working.

Objections and honest limits

“Caching is a legitimate gas optimisation.” It is, and the fix keeps it. Cache, but validate the cache against the current chain id and address, and recompute when they differ. Widely used library implementations already do exactly this.

“Our chain will never fork.” Possibly. The second failure mode does not need a fork — only identical bytecode at the same address on another chain, which is a deployment convenience rather than an event.

// Cache, but verify the cache is still valid
function _domainSeparator() internal view returns (bytes32) {
    if (block.chainid == _cachedChainId
        && address(this) == _cachedThis) {
        return _cachedSeparator;
    }
    return _buildSeparator();     // recompute
}

Reviewing a signature verification path

1. Is the separator cached, and is the cache validated? Against both the current chain id and the current address.
2. Is the signature bound to a nonce, and is the nonce consumed? A replay inside the same chain is the more common bug.
3. Is there an expiry? A signature valid indefinitely defeats any timelock above it.
4. Does the same bytecode exist at the same address elsewhere? Deterministic deployment removes the address element.
5. Is the recovered signer checked against an expected value? Or does the code accept any structurally valid signature? This one is more damaging and lives in the same function.

Terms used here

Domain separator

A hash over the contract name, version, chain identifier and verifying contract address, included in an EIP-712 signature so it is valid only in that context.

Deterministic deployment

Deploying a contract to a predictable address, often identical across chains, so integrations can hard-code it.

Replay

Presenting a valid signature in a context it was not intended for — another chain, another contract, or a second time.

Frequently asked questions

What does the domain separator protect against? Replay across contracts, versions and chains. A signature is valid only for the message, contract and chain the separator encodes.

Why is caching it a problem? The cached value reflects the chain identifier at deployment. If the chain forks, or identical bytecode exists elsewhere at the same address, the separator stops distinguishing.

Why do reviewers miss it? The chain identifier is visibly present in the computation, the condition cannot be reproduced in normal test environments, and the pattern appears in many codebases.

What is the fix? Validate the cache against the current chain identifier and address, recomputing when they differ. Widely used library implementations already do this.

Sources and further reading

• EIP-712 — Typed structured data hashing and signing
• EIP-155 — Simple replay attack protection
• Published security research on domain separator caching in deployed contracts.
• Reference library implementations of typed data signing.