Is there a way to create different signatures with vm.sign() in tests?

[nzmpi]

I have a test, where I want to create different signatures for the same digest. If I use vm.sign(privateKey, digest) multiple times I get the same signature. Is there a way I can force it to use different k to create different signatures?

[BhariGowda]

vm.sign() uses deterministic signing (RFC 6979), so the same private key + digest always produces the same signature. There's no way to force a different k value through Foundry's cheatcode.

The solution is to use different private keys — each key produces a unique valid signature for the same digest:

uint256 privateKeyA = 0x1;
uint256 privateKeyB = 0x2;
uint256 privateKeyC = 0x3;

bytes32 digest = keccak256("some message");

(uint8 v1, bytes32 r1, bytes32 s1) = vm.sign(privateKeyA, digest);
(uint8 v2, bytes32 r2, bytes32 s2) = vm.sign(privateKeyB, digest);
(uint8 v3, bytes32 r3, bytes32 s3) = vm.sign(privateKeyC, digest);

Each signature is valid and different. You can derive the corresponding addresses with:

address signerA = vm.addr(privateKeyA);
address signerB = vm.addr(privateKeyB);
address signerC = vm.addr(privateKeyC);

This is the standard approach for testing multi-sig contracts or anything requiring multiple unique signatures over the same message.

[ECD5A]

The existing answer is right that vm.sign() is deterministic, but using another private key changes the signer, so it does not solve the case where you need different signatures from the same address over the same digest.

Foundry's vm.sign(privateKey, digest) does not expose the ECDSA nonce k. For a fixed key and digest it therefore returns the same canonical signature every time. There is no cheatcode parameter that can force a different k.

Your options depend on what the test is trying to prove:

1. Multiple signers / multisig test: use different private keys. That is the correct model.
2. Same signer, different digest: include a nonce/domain field in the signed message. This is usually the correct application design and also prevents replay.
3. Same signer + same digest + genuinely different k: generate the signature outside vm.sign() (for example a small helper invoked through FFI or a pre-generated fixture) with a signer implementation that permits randomized/non-default nonces, then pass (v, r, s) into the test.
4. ECDSA malleability test: (r, n - s) with flipped recovery parity is a second recoverable form, but it is intentionally non-canonical. OpenZeppelin ECDSA and many production verifiers reject high-s signatures, so do not use that as a normal signing strategy.

If the contract treats two encodings of the same signer/digest as two independent approvals, that is usually the bug to fix: deduplicate by recovered signer and use a per-action nonce/domain separator, not by raw signature bytes.

So: vm.sign() itself cannot be made nondeterministic; use an external test signer only when testing that edge case.

[BhariGowda]

Good additions. To summarize for anyone landing here:

• Different signers → different private keys (my original answer)
• Same signer, different digest → add a nonce/domain to the message
• Same signer, same digest, different k → FFI or pre-generated fixture
• Malleability test → (r, n-s) but expect most verifiers to reject it

And if the contract treats different raw signatures over the same
signer/digest as independent approvals that's the design bug
to fix, not the test.