Add a Second Device or Co-Signer

1. Additional devices that each act on their own. Add the user’s laptop passkey alongside their phone passkey. Either device can sign a transfer. This is what most consumer apps want.
2. Co-signing where multiple signers must approve. Require two signatures (or three of four, etc.) before any transfer goes through. This is what agent treasuries, shared wallets, and high-value accounts want.

​

When to use which

1. Agent treasuries — an automated agent spends up to $X/day on its own, anything bigger requires a co-sign from the user’s passkey. 2-of-2 above the threshold, 1-of-2 below.
2. AI-API service accounts — a service account shares custody with a human operator. Routine API spend doesn’t prompt; settlement transfers do.
3. Co-signed org treasuries — Chipi credits balance is N-of-M with key roles distributed across finance + ops + the founder.

​

Compared to single-owner

[V2_SNIP12_PREFIX, owner_id, kind_tag, ...payload]

[
  V2_THRESHOLD_PREFIX,
  num_owner_sigs,   // count of frames that follow (at least 2)
  frame_1_len, owner_id_1, kind_tag_1, ...payload_1,
  frame_2_len, owner_id_2, kind_tag_2, ...payload_2,
  ...
]

​

Owner kinds within a threshold

• An EOA on MetaMask (EIP191_SECP256K1) co-signs with a passkey (WEBAUTHN_P256)
• A Phantom / Solana wallet (ED25519) co-signs with a STARK key held server-side
• A JWT_ES256 service account co-signs with a STARK key held server-side
• A Starknet wallet the user already has, such as Bramble (STARK_SNIP12), co-signs with a passkey. Bramble signs with wallet_signTypedData and buildStarkSnip12Envelope wraps its signature into an inner envelope. See Trusted wallets
• A guardian (role: "GUARDIAN") does NOT count toward the threshold for normal transactions — guardians only initiate recovery, never co-sign

​

Configuring N and M

• propose_add_owner → execute_add_owner after 48h
• propose_remove_owner → execute_remove_owner after 24h
• propose_set_threshold → execute_set_threshold after 48h (above 1 only on V8.5+)
• propose_add_verifier_class → execute_add_verifier_class after 48h, for a signer kind the wallet doesn’t verify yet

​

SDK status

import {
  buildThresholdEnvelope,
  buildStarkEnvelope,
  buildEip191EnvelopeFromSignature,
  type Eip191Pubkey,
} from "@chipi-stack/backend";

declare const serverStarkKey: string;
declare const oeHash: bigint; // computeOeHash(outsideExecution, walletAddress, chainId)
declare const metaMaskPersonalSig: string; // personal_sign over the 32-byte hash
declare const metaMaskPubkey: Eip191Pubkey; // { x, y }: uncompressed secp256k1 key, 32 BE bytes each

// Two owners co-sign the same OE. Each envelope carries its owner's index.
const innerStark = buildStarkEnvelope({
  privateKey: serverStarkKey,
  messageHash: oeHash,
  ownerIndex: 0n,
});
const innerEip191 = buildEip191EnvelopeFromSignature({
  signatureHex: metaMaskPersonalSig,
  pubkey: metaMaskPubkey,
  ownerIndex: 1n,
});

const envelope = buildThresholdEnvelope({
  innerEnvelopes: [innerStark, innerEip191],
});
// Feed `envelope` into the same execute_from_outside_v2 calldata path
// you'd use for a single-owner OE.

​

External wallets that don’t expose a key (MetaMask, Phantom, Bramble)

import {
  buildEd25519EnvelopeFromSignature,
  ed25519SignedBytes,
} from "@chipi-stack/backend";

// 1. Connect Phantom and read its 32-byte Ed25519 pubkey.
await window.solana.connect();
const publicKey = window.solana.publicKey.toBytes();

// 2. Sign the EXACT bytes the verifier expects (not the raw hash).
const msg = ed25519SignedBytes(oeHash);
const { signature } = await window.solana.signMessage(msg); // 64-byte R‖s

// 3. Wrap into an inner envelope (async — initializes Garaga on first call).
const innerEd25519 = await buildEd25519EnvelopeFromSignature({
  signature,
  publicKey,
  messageHash: oeHash,
});
// `innerEd25519` slots into `buildThresholdEnvelope({ innerEnvelopes: [...] })`
// exactly like the EIP-191 envelope above.

​

Gas

​

Threshold + recovery together

• Day-to-day operations require N-of-M signatures
• Lost-key recovery still works because a guardian can initiate initiate_recovery even if N-1 owners have lost their keys
• Any one owner can still stop a recovery with cancel_recovery naming itself, even below the threshold

​

Related

• Passkey reference — what each owner can be on the browser side
• Recovery — add/remove owners + guardian recovery
• Migration — getting from CHIPI v29 to SHHH first