v14.17.0: SHHH V8.5, and Bramble as co-owner or guardian

​

TL;DR: does this affect me?

​

SHHH V8.5

• createWallet (TS and Python) computes the address with V8.5 and now names that class in prepare-creation. If the API answers with any other class it stops with Not deploying, so a wallet can’t land at an address the SDK didn’t compute. The API keeps V8.4 as its default for older SDKs, which name no class.
• Existing wallets don’t move. V8.x has no upgrade path, and a V8.4 wallet at threshold 1 (every V8.4 wallet on mainnet) is not affected. getWalletTypeFromClassHash still returns SHHH for V8.4.
• N-of-M only on V8.5. Chipi’s API refuses propose_set_threshold / execute_set_threshold above 1 for wallets on older classes (422 SHHH_THRESHOLD_UNSUPPORTED). A V8.4 treasury’s requiredApprovals are enforced by Chipi’s backend only; to get the on-chain N-of-M, move it to a V8.5 wallet. See Co-signing.
• Same API otherwise. V8.5 has the same constructor, storage layout and ABI as V8.4: every builder, hook and envelope works unchanged.
• Migrating CHIPI wallets to SHHH (migrateChipiWalletToShhh) still upgrades them to V8.4, the class Chipi’s migration names.

​

Trusted wallets (@chipi-stack/backend, chipi-react, nextjs)

• starkSnip12ApprovalTypedData, resolveStarkSnip12Signer, starkSnip12PubkeyFelts, buildStarkSnip12Envelope, verifyStarkSnip12Approval, parseStarknetWalletSignature.
• sdk.executeWithExternalSigner and useExternalSignerExecute: run calls approved by the external wallet, relayed gaslessly. Lower level: prepareExternalOwnerExecution / submitExternalOwnerExecution.
• Governance: buildProposeAddVerifierClassCall / buildExecuteAddVerifierClassCall (a wallet must register a kind before it can have an owner of that kind), isShhhVerifierDeclared.
• Reads: readShhhOwners, readVerifierClass, readPendingRecovery, parseOpProposedEvents (op ids come from the propose transaction’s events).
• executeShhhWithStarkKey: sign as a STARK owner other than owner 0, such as the key a guardian recovery added.

const txHash = await sdk.executeWithExternalSigner({
  params: {
    walletAddress: chipiWallet.publicKey,
    ownerIndex: brambleOwnerId,
    calls,
    signTypedData: async (typedData) =>
      (await bramble.request({ type: "wallet_signTypedData", params: typedData })) as string[],
  },
  bearerToken,
});

​

Connect with Chipi 0.5.0 (@chipi-stack/starknet-connector)

​

Connect with Chipi wallet object (@chipi-stack/chipi-react)

​

Fixes

• Threshold envelopes (@chipi-stack/backend, Python SDK): buildThresholdEnvelope kept each owner’s V2_SNIP12 tag inside the envelope, and the wallet contract rejected every such envelope with THRESH: bad owner_id. It now emits each frame as [owner_id, kind_tag, ...payload], the shape the contract verifies. useThresholdSign gets the fix through it; you still pass the per-kind builders’ envelopes.
• Argent signatures: the paymaster adapter (sendSponsored()) and core’s x402 client read ["1", "0", publicKey, r, s] as r = 1, s = 0. Both now take r and s from the end, and refuse shapes they don’t know.
• Sign in with Starknet accepts the domain chainId as SN_MAIN or its felt.

​

Docs fixes

• Guardian recovery: recovery adds an owner (it never replaces one), cancel_recovery takes the cancelling owner’s id, guardians cannot cancel, and every execute_* call is permissionless. Adding an owner of a new kind needs the verifier class first.
• Sign in with Starknet: Bramble end to end, every failure reason, and the wallet error codes.
• When passkeys fail, threshold, multi-owner governance and the core signer pages: corrected against the code.

​

Related

• Trusted wallets
• Sign in with Starknet
• Connect with Chipi