feat!: make proposals EIP-712 by LHerskind · Pull Request #22531 · AztecProtocol/aztec-packages

LHerskind · 2026-04-14T16:46:26Z

This changes proposal-path validator signatures from eth_sign / personal_sign style payload signing to EIP-712 typed-data signing. Proposal and attestation signatures are now bound to both the L1 chainId and the rollup contract address, which closes cross-chain and cross-rollup replay for block proposals, checkpoint proposals, checkpoint attestations, and the proposer signature over packed attestations/signers.

On the Solidity side, the rollup path now computes EIP-712 digests through CoordinationSignatureLib.sol, reusing the existing Aztec Rollup domain name and version 1, and threads the verifying contract explicitly where needed. On the TypeScript side, proposal-path signing and recovery now require a { chainId, rollupAddress } signature context, validator duties sign typed data instead of raw messages, and the shared helper surface was renamed to CoordinationSignature* to match Solidity.

Tests were updated to check digest parity between TS and Solidity, sender recovery under the correct domain, failure under the wrong chainId or rollup address, and the affected contract flows that verify or invalidate checkpoint-related signatures.

Historically, it was possible to reason about replay from archives and chain history, but it was not always stupid-simple. With the EIP-712 domain binding, the replay boundary is explicit in the signature itself, so checking whether a signature targets the wrong chain or wrong rollup becomes straightforward and only depends on current L1 state.

spalladino

Looks solid. Just two things I'd want to discuss:

1- Should we drop the SignatureDomainSeparator given EIP712 includes the typehash? Feels redundant.

2- Should we explicitly include the chainid and rollup version in the proposal and attestation p2p structs so we can easily validate them, and at the same time we don't need a coordination context on any caller of getSender? If not, then at least I'd shoot for having two different structs: the current one that gets moved throughout p2p, and a "resolved" one where the sender is the computed value, which we use internally.

spalladino · 2026-04-15T13:20:07Z

        ProposePayload({archive: proposeArgs.archive, oracleInput: proposeArgs.oracleInput, headerHash: headerHash});

-      bytes32 digest = ProposeLib.digest(proposePayload);
+      bytes32 digest = ProposeLib.digest(proposePayload, address(rollup));


I was about to ask whether you needed both version of the digest method, with and without the verifying contract address.

spalladino · 2026-04-15T13:20:47Z

+  function domainSeparator(address _verifyingContract) internal view returns (bytes32) {
+    return keccak256(abi.encode(DOMAIN_TYPEHASH, NAME_HASH, VERSION_HASH, block.chainid, _verifyingContract));
+  }


Can we cache this as an immutable?

We can, but since we are using it from libraries and not where the storage are, it is a bit of a pain as the library don't have a constructor where we could do it.

spalladino · 2026-04-15T13:21:59Z

I'm pleasantly surprised the increase is so small, nice!

spalladino · 2026-04-15T13:24:16Z

+    address _verifyingContract
+  ) internal view returns (bytes32) {
+    return CoordinationSignatureLib.attestationsAndSignersDigest(
+      keccak256(abi.encode(SignatureDomainSeparator.attestationsAndSigners, _attestations, _signers)),


Do we still need the SignatureDomainSeparator if we have the 712 typehash?

Atm its mainly dispatching and then because of the SignedTxs that it was leftover, but will look at also making those EIP-712 so it is just one path.

LHerskind · 2026-04-16T12:56:51Z

Should we drop the SignatureDomainSeparator given EIP712 includes the typehash? Feels redundant.

We did not use EIP712 all over, so am looking to use it more for the SignedTxs.

2 Should we explicitly include the chainid and rollup version in the proposal and attestation p2p structs so we can easily validate them, and at the same time we don't need a coordination context on any caller of getSender? If not, then at least I'd shoot for having two different structs: the current one that gets moved throughout p2p, and a "resolved" one where the sender is the computed value, which we use internally.

I'm taking a look at it now should be able to simplify nicely together with the fix in 1.

spalladino

Looks good! Just a few nits. And sorry I took so long to re-review.

spalladino · 2026-04-22T18:16:19Z

+          expectedChainId: this.signatureContext.chainId,
+          expectedRollupAddress: this.signatureContext.rollupAddress.toString(),
+        });
+        return { result: 'reject', severity: PeerErrorSeverity.HighToleranceError };


Suggested change

return { result: 'reject', severity: PeerErrorSeverity.HighToleranceError };

return { result: 'reject', severity: PeerErrorSeverity.LowToleranceError };

spalladino · 2026-04-22T18:16:33Z

+          expectedChainId: this.signatureContext.chainId,
+          expectedRollupAddress: this.signatureContext.rollupAddress.toString(),
+        });
+        return { result: 'reject', severity: PeerErrorSeverity.HighToleranceError };


spalladino · 2026-04-22T18:18:16Z

+
+  constructor(
+    public attestations: CommitteeAttestation[],
+    public readonly signatureContext: CoordinationSignatureContext = EMPTY_COORDINATION_SIGNATURE_CONTEXT,


Does it break too many things if we remove the default? I'm worried we forget to wire it in in a legitimate code path.

spalladino · 2026-04-22T18:42:43Z

-    | undefined;
+  readonly primaryType: CoordinationSignatureType = 'BlockProposal';
+
+  private cachedSender: EthAddress | undefined | null = null;


Nit: I'd default to undefined for initial value, and null if no value is recoverable, or even a null-object

spalladino · 2026-04-22T19:13:53Z

By the way, do you want to move this to merge-train/spartan?

LHerskind added the ci-draft Run CI on draft PRs. label Apr 14, 2026

LHerskind force-pushed the lh/tmnt-520-make-it-stupid-simple-to-check-cross-chain-replay-for branch 5 times, most recently from a8ec1a0 to fb34548 Compare April 15, 2026 07:11

LHerskind marked this pull request as ready for review April 15, 2026 08:58

LHerskind requested review from Maddiaa0 and just-mitch as code owners April 15, 2026 08:58

LHerskind force-pushed the lh/tmnt-520-make-it-stupid-simple-to-check-cross-chain-replay-for branch 2 times, most recently from 5a02d69 to cfe2a60 Compare April 15, 2026 12:50

spalladino reviewed Apr 15, 2026

View reviewed changes

LHerskind force-pushed the lh/tmnt-520-make-it-stupid-simple-to-check-cross-chain-replay-for branch 3 times, most recently from 7003b54 to 7256238 Compare April 16, 2026 18:21

spalladino approved these changes Apr 22, 2026

View reviewed changes

LHerskind force-pushed the lh/tmnt-520-make-it-stupid-simple-to-check-cross-chain-replay-for branch from 7256238 to 41f782d Compare April 28, 2026 11:55

LHerskind changed the base branch from next to merge-train/spartan April 28, 2026 11:55

LHerskind added 3 commits April 28, 2026 13:57

feat!: make proposals EIP-712

01e4a67

chore: EIP-712 all the things

02029ee

fix: Address proposal signature review comments

63e0b5c

LHerskind force-pushed the lh/tmnt-520-make-it-stupid-simple-to-check-cross-chain-replay-for branch from 41f782d to 63e0b5c Compare April 28, 2026 11:59

spalladino merged commit 625f9f2 into merge-train/spartan Apr 28, 2026
12 checks passed

spalladino deleted the lh/tmnt-520-make-it-stupid-simple-to-check-cross-chain-replay-for branch April 28, 2026 12:32

AztecBot mentioned this pull request Apr 28, 2026

feat: merge-train/spartan #22814

Merged

	return { result: 'reject', severity: PeerErrorSeverity.HighToleranceError };
	return { result: 'reject', severity: PeerErrorSeverity.LowToleranceError };

Conversation

LHerskind commented Apr 14, 2026

Uh oh!

spalladino left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LHerskind commented Apr 16, 2026

Uh oh!

spalladino left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

spalladino commented Apr 22, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants