Problem
AtomicWriteBatch + commit_batch assumes a single signer produces the complete ixn event in one call. For multi-sig identities (kt > 1), the ixn event requires multiple signatures before it can be appended to the KEL. The current atomic write pattern cannot accommodate this because:
try_stage_anchor calls sign_ixn with a single signer — it produces one signaturecommit_batch writes everything in one commit — there's no way to add a second signature to an already-staged event- The
AtomicWriteBatch has no concept of "partially signed, awaiting co-signer"
Current state
AtomicWriteBatch stages AtomicWriteOp::AppendEvent { prefix, event } — the event is finaltry_stage_anchor signs with one key and stages the ixn- No partial-signature or signature-collection flow exists for ixn events
- Multi-sig identities can do inception and rotation (those have separate flows) but ixn anchoring is single-signer only
Impact
Low for now — no multi-sig identities exist in production. But if/when threshold multi-sig lands, device link/revoke operations would fail for multi-sig controllers because the atomic write path can't collect the required number of signatures.
Possible approaches
-
Signature collection before staging: Collect all required signatures via the witness/co-signer protocol, then stage the fully-signed event in the batch. The batch remains single-commit.
-
Two-phase commit: Stage the event with one signature, commit it as "pending", then amend the commit when the second signature arrives. Requires a "pending events" concept in the KEL storage.
-
Externalize signing from batching: try_stage_anchor returns the unsigned event + SAID. The caller collects signatures externally, then stages the fully-signed event. This separates the signing concern from the batching concern.
Files
crates/auths-id/src/keri/anchor.rs — try_stage_anchorcrates/auths-id/src/storage/registry/backend.rs — AtomicWriteBatch, commit_batch
Problem
AtomicWriteBatch+commit_batchassumes a single signer produces the complete ixn event in one call. For multi-sig identities (kt > 1), the ixn event requires multiple signatures before it can be appended to the KEL. The current atomic write pattern cannot accommodate this because:try_stage_anchorcallssign_ixnwith a single signer — it produces one signaturecommit_batchwrites everything in one commit — there's no way to add a second signature to an already-staged eventAtomicWriteBatchhas no concept of "partially signed, awaiting co-signer"Current state
AtomicWriteBatchstagesAtomicWriteOp::AppendEvent { prefix, event }— the event is finaltry_stage_anchorsigns with one key and stages the ixnImpact
Low for now — no multi-sig identities exist in production. But if/when threshold multi-sig lands, device link/revoke operations would fail for multi-sig controllers because the atomic write path can't collect the required number of signatures.
Possible approaches
Signature collection before staging: Collect all required signatures via the witness/co-signer protocol, then stage the fully-signed event in the batch. The batch remains single-commit.
Two-phase commit: Stage the event with one signature, commit it as "pending", then amend the commit when the second signature arrives. Requires a "pending events" concept in the KEL storage.
Externalize signing from batching:
try_stage_anchorreturns the unsigned event + SAID. The caller collects signatures externally, then stages the fully-signed event. This separates the signing concern from the batching concern.Files
crates/auths-id/src/keri/anchor.rs—try_stage_anchorcrates/auths-id/src/storage/registry/backend.rs—AtomicWriteBatch,commit_batch