[daniil-dovgal]

Description

High level implementation overview

Second milestone of the TS SDK quorum stack, stacked on #2255 (E1).

• Foundation: feat(wallets): read quorum signer entries (quorum foundation 1/3) #2214, feat(wallets): quorum rules and quorum API errors (quorum foundation 2/3) #2215, feat(wallets): acting-signer seam, held signers and quorum API errors at call sites (quorum foundation 3/4) #2233 and feat(wallets): approval collection and poll outcome for quorum approvals (quorum foundation 4/4) #2225 add the quorum types, rules, signer seams and approval polling. feat(wallets): a quorum acting signer returns the created transaction unsigned, as prepareOnly does (quorum foundation 5/5) #2268 makes a creating call whose signer is a quorum return { transactionId } unsigned, as with prepareOnly: true.
• E1 (feat(wallets): approve as a quorum member (EVM + Stellar quorum E1) #2255): a client approves as a quorum member on EVM and Stellar, approve returns without a hash while other members must still sign, and useSigner accepts a key that is only a member.

Before this PR, creating calls always sent the active key as the request's signer. A member-only key therefore got the API's SIGNER_IS_QUORUM_MEMBER, and signMessage / signTypedData had no way to name a quorum.

This PR implements EDD 007 §7 "Role" and "A quorum forces prepareOnly" for creating calls:

• A key that is only a member acts as its quorum; a key in several quorums throws QuorumSelectionAmbiguousError.
• A request made as a quorum, named or inferred, is created unsigned and returned as with prepareOnly: true. Members sign it later with approve.
• signMessage / signTypedData take a signer option, like send.

Other keys behave as before, and make no extra request.

await wallet.useSigner(alice); // Alice is only a member of `treasury`
const { transactionId } = await wallet.send(to, "usdc", "1000", { prepareOnly: true }); // created as `treasury`, unsigned
await wallet.approve({ transactionId }); // Alice signs her member entry (E1)
await evmWallet.signMessage({ message, options: { prepareOnly: true, signer: treasury.locator } }); // ERC-1271 as the quorum

Details

• wallets/wallet.ts resolveSignerParams (the feat(wallets): acting-signer seam, held signers and quorum API errors at call sites (quorum foundation 3/4) #2233 seam, now async): an explicit signer is sent as given. Otherwise the active key is sent, unless useSigner selected it as a member-only key (matched by locator). For such a key it reads the wallet's config with one getWallet call and runs feat(wallets): quorum rules and quorum API errors (quorum foundation 2/3) #2215's resolveActingRole (recovery and delegated quorums): the key's quorum, the ambiguous error before any request, or the key itself when it has since become a registered signer (on the request's chain, which signTypedData may set) or recovery method, or left its quorum. A failed read, or one with no usable config, throws WalletNotAvailableError. Only member-only keys pay for the read.
• Each public creating method resolves the signer once and passes it to feat(wallets): a quorum acting signer returns the created transaction unsigned, as prepareOnly does (quorum foundation 5/5) #2268's isPrepareOnly. So send, sendTransaction (every chain), signMessage and signTypedData return early for an inferred quorum too, and the role is read once per call.
• useSigner remembers that locator only for a member key; any other selection clears it. Keys swapped in by device recovery or withRecoverySigner don't match it. Chain wallets (EVMWallet.from, …) carry the locator through the constructor.
• wallets/evm.ts / wallets/types.ts: SignatureInputOptions gains optional signer?: SignerOption. A quorum locator requests an ERC-1271 signature as that quorum and returns { signatureId } with signature undefined.
• Stellar upgrade / migrate are unchanged: without an explicit signer they send none, and the server uses the admin signer.

Accepted:

• For an email or phone member key in several quorums, the ambiguity error comes after preAuthIfNeeded, so an OTP can run first. preAuth can swap the active key, so the role is resolved for the key that actually signs.
• The static result type follows prepareOnly, not the signer (EDD "Type honesty"): pass prepareOnly: true when a quorum may act.
• On a multichain EVM wallet, a delegated quorum installed only on another chain still counts toward ambiguity: the config doesn't say where a quorum is installed.

Next Steps

E3 (#2261): signer changes approved by a quorum. The four signer-change calls take signer (sent as approver) and return early when it is a quorum, and useRecoveryMethod accepts a member of a recovery quorum.

Test plan

• Tests first. Red baselines: 18 failed, 84 passed (first commit); 3 failed, 30 passed (signature calls as a quorum). The transaction rows were green after merging feat(wallets): approve as a quorum member (EVM + Stellar quorum E1) #2255: the inferred quorum reaches isPrepareOnly.
• Suites:
  • wallets/wallet.quorum-acting-role.test.ts (41 tests): send, EVM and Stellar sendTransaction, signMessage and signTypedData act as a delegated or recovery quorum and return unsigned, with and without prepareOnly; one wallet read per call; registration on signTypedData's chain; the member key signs later through approve; ambiguity, explicit signer, membership changed after useSigner, address case, failed or config-less reads, an uninstalled quorum; no read for other keys on every chain; Stellar upgrade unchanged.
  • wallets/wallet.signer-params.test.ts: the EVM signature calls join feat(wallets): acting-signer seam, held signers and quorum API errors at call sites (quorum foundation 3/4) #2233's explicit-signer rows.
  • wallets/wallet.quorum-member-signer.test.ts, utils/recovery.test.ts.
• Mutation checks (marker clear, signers() read, cached recovery, exact-case match, first delegated quorum only, a second role read before the early return): each fails its rows.
• Run: cd packages/wallets && pnpm exec vitest run src/wallets src/quorum src/utils src/chains src/signers → 1196 passed. tsc on src/ is clean, the changed test files type-check with a test tsconfig, and biome reports no errors.
• Fresh-context review: three rounds for the first part, three for this one; every finding fixed (one read per call, Stellar coverage, the role on signTypedData's chain).

Package updates

• @crossmint/wallets-sdk: minor (.changeset/quorum-act-as-quorum.md).

[changeset-bot]

🦋 Changeset detected

Latest commit: 2840a07

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 10 packages

Name	Type
@crossmint/wallets-sdk	Minor
@crossmint/wallets-quickstart-devkit	Patch
@crossmint/wallets-playground-react	Patch
@crossmint/client-sdk-react-base	Patch
@crossmint/client-sdk-react-native-ui	Patch
@crossmint/client-sdk-react-ui	Patch
@crossmint/integration-tests	Patch
@crossmint/wallets-playground-expo	Patch
@crossmint/auth-ssr-nextjs-demo	Patch
@crossmint/client-sdk-nextjs-starter	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[greptile-apps]

Confidence Score: 4/5

[Medium impact] The change affects request creation for member-only keys across wallet chains and EVM signatures.

Fix the cross-chain registration check before merging so member-only keys reliably act as their quorum.

_{Reviews (1) · Last reviewed commit: "Merge remote-tracking branch 'origin/dan..." · Reviewed by Greptile}