pico-quorum

Safe{Wallet}: GS021 when a confirmation is a contract signature

The Safe web app can’t execute a transaction that a PicoQuorum key approved once there are two or more signatures. It fails with GS021 because the chip’s approval is an EIP-1271 contract signature, and the web app rebuilds every stored confirmation as a plain signature. Until this is fixed upstream, tools/quorum live exec executes instead.

Jason submits everything to Safe by hand. This folder holds the drafts and the evidence:

File	What
ISSUE.md	The issue, ready to paste: title plus body in their bug-report template. The reproduction script is inlined in a <details> block
PR.md	The pull request, ready to paste: their PR template, with the Mermaid summary they require for AI-authored PRs and the CLA line. Replace #ISSUE with the issue number
repro/	repro.mjs, the self-contained reproduction (how to run it): Anvil fork of Base Sepolia, throwaway keys, protocol-kit’s own buildSignatureBytes for both layouts. It also prints the test fixtures (--fixture)
0001-fix-keep-EIP-1271-contract-signatures-when-rebuildin.patch	The fix and its test, one commit made with git format-patch against their dev at 5717e3a. This is the pre-review version; see Status for what was submitted

Before submitting: privacy

ISSUE.md, PR.md and the patch name no personal address, Safe or transaction. The patch’s test fixture comes from throwaway keys on a local fork. Keep it that way:

• Screenshots: attach only the redacted copies in temp-safe-screenshots/redacted/ (local and gitignored). There are four from the desktop browser, and 20–23 from a mobile browser. The mobile ones are the web app on a phone, not Safe’s mobile app. They were made from macOS text recognition and checked by running it again: no address, ENS name or timestamp is left, and no identicon either. Look them over once more before uploading.
  • Submitted: one image on #8808, a tight crop of SCR-20260925-jtap-redacted.png showing only the two GS021 messages and “Cannot estimate”. It shows no Safe name, address or clock.
  • Before posting any of the others: the full desktop shots still show the Safe name (“PicoQuorum Base”), and the mobile ones show the phone’s clock in the status bar.
• No Tenderly link. The in-app simulation link is public and shows the Safe and both signatures. Checked in the issue, the PR and the commit message: none. The PR mentions the Tenderly simulation only as a feature.
• Nothing from the evidence log below. It names personal addresses and Safes, which is fine in this private repo but not upstream. The issue, PR and commit message were scanned for its addresses and tx hashes: none.
• Commit author. The patch carries Jason McPheron <jason.mcpheron@gmail.com> as author, and that shows on the PR. To use GitHub’s private address instead, run git commit --amend --reset-author after setting git config user.email <id>+jmcpheron@users.noreply.github.com. The id is in GitHub → Settings → Emails. Kept the gmail address (decided 2026-09-25).

Status

• Issue opened on safe-global/safe-wallet-monorepo: #8808
• Fork jmcpheron/safe-wallet-monorepo, branch fix/contract-signatures-existing-tx from dev at 004b061
• Patch applied, with “Fixes #8808” added to the commit message: commit 07a9717
• Full install; the utils, web and mobile tests, type-check and lint pass on the fork (details under “What’s been verified so far” below)
• CLA read (https://safe.global/cla). The page is a 404, and it’s the same link the CLA workflows in other safe-global repos use. The PR’s CLA line says so rather than confirming agreement; a maintainer may ask about it.
• PR opened from the fork: #8809, 2026-09-25

What was submitted differs from these drafts. The versions on GitHub are the reference:

• The commit:
  • toSafeSignature’s doc comment and the test file’s header are cut to one line each, since their AGENTS.md asks for one-line comments
  • one call-site test per app (web ts-sender.test.ts, mobile create.test.ts), each failing without the fix
  • Fixes #8808, and a Co-Authored-By: Claude trailer
• The issue: the re-run block is noted, the fix paragraph updated, #1952 added under Related, and one screenshot attached.
• The PR:
  • #8808 filled in, and the call-site tests described
  • two blast-radius bullets: validateTxSignatures now skips contract signatures, and gas estimation and Tenderly get the corrected bytes
  • risks updated, and the CLA note

Waiting on:

• A maintainer to approve CI. All 16 workflows were action_required when the PR opened, as expected for a first-time contributor.
• Review.

Working on the fork

# after forking on GitHub
git clone https://github.com/jmcpheron/safe-wallet-monorepo.git && cd safe-wallet-monorepo
git remote add upstream https://github.com/safe-global/safe-wallet-monorepo.git
git fetch upstream
git checkout -b fix/contract-signatures-existing-tx upstream/dev

# the fix, as a commit with its original message and authorship
git am ../pico-quorum/docs/upstream/safe-wallet-gs021/0001-fix-keep-EIP-1271-contract-signatures-when-rebuildin.patch
# once the issue exists, add its number:
git commit --amend      # add a line "Fixes #NNNN" above "Refs #3673"

corepack enable && yarn install
yarn workspace @safe-global/utils test src/utils/__tests__/safeTransaction.test.ts
yarn workspace @safe-global/web test src/services/tx/tx-sender
yarn workspace @safe-global/utils type-check && yarn workspace @safe-global/web type-check && yarn workspace @safe-global/mobile type-check
yarn workspace @safe-global/utils lint && yarn workspace @safe-global/web lint
yarn prettier

git push -u origin fix/contract-signatures-existing-tx
# open the PR from the fork's branch into safe-global:dev, with PR.md as the description

If git am doesn’t apply cleanly because dev has moved on, git am --3way usually does. The change is small, so it can also be redone by hand: the helper and its test, plus two call sites.

Review, 2026-09-25. A review of the drafts led to:

• narrowing the claim to a threshold of 2 or more (with a 1-of-2 control that works)
• keeping observed results, code analysis and untested scope apart
• a self-contained reproduction
• exact mobile scope
• the parser’s rule stated and tested: it reads the encoded offset, requires it past the static part, and requires the data to run exactly to the end
• tests for both signer orders, multiple contract signatures, unchanged eth_sign and v = 1, and malformed input
• the wording fixes

All adopted. The Safe.sol link now points at the GS021 check itself (L306-L316); the suggested range stopped short of it.

What’s been verified so far:

• On a private fork of Base Sepolia: the fixture Safe (throwaway keys) reverts with GS021 in the web app’s layout and executes in the fixed one.
• On a fresh fork with repro/repro.mjs:
  • a 2-of-2 (EOA, contract) and a 3-of-3 (contract, EOA, contract) revert with GS021 in the current layout, and execute in the fixed one: ExecutionSuccess, the recipient paid, and the logged bytes equal the fixed layout
  • a 1-of-2 control works both ways
• Locally, on a focused install: the 11 unit tests pass in a node environment, and Prettier is clean.
• On the fork, with a full install (2026-09-25):
  • utils: all 81 suites (1467 tests) pass in the default jsdom environment, including the 11 new ones. Lint, type-check (TS 7) and Prettier are clean.
  • mobile: verify --changed passes: type-check, lint, Prettier and the 364 related tests.
  • web: type-check, lint and Prettier pass, and so do the tx, speed-up, queued-simulation and confirm-tx suites (113 tests). verify:changed runs 7039 related tests: 3 timed out in two spaces/Policies form suites that don’t touch this code, and both suites pass on their own (34/34).
  • Call-site tests: both fail with the call-site change reverted, and pass with it.
• repro/repro.mjs was re-run at block 47307399 with the same results. A second run on the same fork is identical, and --fixture matches the committed test data byte for byte.

How we know

• What GS021 means. In Safe’s checkNSignatures it is “the contract signature’s offset points inside the static part”: s < requiredSignatures * 65.
• Where the web app goes wrong. Its createExistingTx adds each confirmation with staticPart: () => data, dynamicPart: () => '', isContractSignature: false.
  • A contract owner’s confirmation comes back from the service as {owner}{offset = 65}{00}{length}{data}, so it is concatenated whole, with its offset still at 65.
  • Mobile has the same code in addSignaturesToTx.
• Safe already knows. In #3673, reported for a nested Safe owner, a maintainer wrote in Aug 2024: “the bug is likely here: create.ts … The dynamic part is always set to '' which is wrong for nested Safe signatures.” It was closed as “not planned” in Feb 2026, with no fix.
• Safe’s own SDK can already do it. protocol-kit’s EthSafeSignature(signer, data, true) plus buildSignatureBytes lay contract signatures out correctly (offsets past all the static parts). The web app just never marks them as contract signatures.

Evidence log (private: names personal addresses, don’t paste upstream)

Add to this as it comes in: date, chain, what was seen, links.

2026-09-25, Base Sepolia

• The Safe. 0xEDEDC0063B23A309f4cAdA5e1225Ef21D8A30a43: Safe 1.5.0 L2, 2-of-3.
  • Owners: MetaMask 0x61D2…637F, the Pico’s SafeWebAuthnSignerProxy 0x2843…5E53, and later 0x1289…f2DA.
• The confirmations were accepted. Every contract-signature confirmation POSTed to api.safe.global/tx-service/basesep got 201: the emulator’s on #0, the Pico’s on #1–#3.
• The web app failed. Execute on #1 and #3 showed “Simulation failed”, “Cannot estimate”, GS021. There’s a screenshot of #3; the in-app simulation’s “View” link is still to capture.
• Reproduced for #3. Simulating execTransaction at block 47276343, the block before it executed:
  • Safe{Wallet}’s bytes (stored signatures sorted by signer and concatenated, 450 bytes): GS021.
  • protocol-kit’s layout with the contract signature marked: OK, byte for byte what executed in 0xb8ee9c98….
• Executed another way. tools/quorum live exec, which lays the signatures out the same way as protocol-kit, executed #0–#3. #1 and #2 are the Pico’s approvals.

2026-09-25, Base mainnet

• The Safe. 0xDebDE58b3ed0867d19285f6C8B0d81AdBC326Da9: Safe 1.5.0 L2, 2-of-3.
  • Owners: MetaMask 0x61D2…637F, the Pico’s SafeWebAuthnSignerProxy 0x2843…5E53 (deployed on Base in 0xe5e8ad92…), and 0xb78e…AdBD8.
• Two confirmations, both accepted. #0 (safeTxHash 0x4c1e4f18…cef63ad6) sends 0.000001 ETH:
  • 0xb78e… confirmed with an EOA signature (65 bytes).
  • The Pico posted its contract signature itself: api.safe.global/tx-service/base stored it as CONTRACT_SIGNATURE, 385 bytes.
• Reproduced again, simulating execTransaction at block 51784275, with #0 pending:
  • Safe{Wallet}’s layout (450 bytes, contract signature offset 65): GS021.
  • The fixed layout (450 bytes, offset 130): OK.
• The web app on mainnet showed “Simulation failed” in Safe Shield and “Cannot estimate”, then This transaction will most likely fail… GS021. Clicking Execute gave Could not submit the transaction. Error code GS021.
  • Four screenshots, before, during and after, are in temp-safe-screenshots/ (local only), with redacted copies in redacted/.
  • Tenderly simulation (public link, private use only): https://dashboard.tenderly.co/public/safe/safe-apps/simulator/7afa3560-c7f6-44df-a583-f2b1e560fe46
• Still to capture: the app version and the execution tx.

2026-09-25, a private fork of Base Sepolia: the public fixture

• The Safe. Throwaway keys: EOA 0x27d0D792…A43E and passkey signer 0x4D5Df238…5E91, which own a fresh 2-of-2 Safe 1.5.0 at 0x28EB931d…7A71 on an Anvil fork (block 47295478). None of it is on a public chain.
• The result. The web app’s layout (450 bytes) reverts with GS021. The fixed layout (450 bytes) executes (ExecutionSuccess), and the SafeMultiSigTransaction event logs exactly those bytes. That is the patch’s test fixture.