DID.COMMSDOCS

Governance Layer

The Arcform Governance Layer extends the sovereign messaging infrastructure into a control plane for decentralized identity governance. It enables M-of-N threshold signing, typed governance signals, conditional XRPL anchoring, and a stable migration path toward real zero-knowledge proof verification.

Governance Signals

Every envelope carries a signal_type that declares its governance intent. Legacy messages default to message. Control plane operations use proposal, vote, attestation, or instruction.

message

Standard encrypted DIDComm envelope. Default for all legacy traffic.

proposal

Governance proposal submitted to a signer set for threshold approval.

vote

A signer's response to a proposal. Counted toward M-of-N quorum.

attestation

Cryptographic attestation anchored to the audit spine. Immutable once delivered.

instruction

Operational directive from a governance authority. Triggers downstream actions.

Multi-Sig DID Governance

Organizational DIDs are governed by the SignerSet entity — a versioned record of authorised signers, their roles, and the required quorum threshold. Identity verdict resolution now checks whether the sender was an authorised signer in the active signer set at send-time. Unauthorised signers receive a degraded verdict.

// SignerSet schema

signer_set_id — Unique identifier, referenced by KeyLineage

did — The organizational DID this set governs

threshold — M in M-of-N (minimum signers for quorum)

signers — JSON array of { api_key_id, did, role, added_at, removed_at }

effective_at — When this configuration became active

superseded_at — When replaced by a newer version (null = current)

status — active | superseded | revoked

// KeyLineage event types

rotation — Standard key rotation (single signer)

compromise — Key compromised, emergency rotation

manual_revocation — Administrative key revocation

threshold_change — Quorum adjustment, signer addition/removal

// Identity verdict — signer set resolution

1. Find signer_set_id from KeyLineage records

2. Resolve the SignerSet active at anchored_at timestamp

3. Check sender_key_id is in the active signers list

4. Authorised → identity proceeds normally

5. Unauthorised → verdict = 'unauthorised_signer' → degraded

Signer set versioning is immutable: when the quorum changes, a new SignerSet record is created and the previous one is marked superseded. This preserves the full governance history for historical verification.

Conditional XRPL Anchoring

XRPL anchoring is now conditional rather than assumed. The anchor_status field on EnvelopeLog tracks the full lifecycle: pending → signed → anchored, or skipped/failed. Legacy envelopes default to anchored.

pending

XRPL transaction queued, awaiting wallet signature.

signed

Payload submitted to Xaman, awaiting ledger confirmation.

anchored

Transaction confirmed on XRPL. Default for legacy envelopes.

failed

Anchoring attempt failed. Delivery is still valid.

skipped

No wallet available. Envelope delivered without ledger anchor.

ZKP Migration Path

The zkp_type field on Attribute records defines which proof system is used for verification. The API surface remains stable across all types.

simulated

ACTIVE

Hash comparison. Current v1 default.

zk_snark

RESERVED

Succinct proofs. Future implementation.

zk_stark

RESERVED

Transparent proofs. Future implementation.

Attributes with non-simulated zkp_type values currently return a graceful proof_invalid verdict with a descriptive reason, ensuring forward compatibility without breaking existing integrations.

Combined Verdict Tiers

Every verification produces a combined verdict from three independent layers: Integrity (EnvelopeLog), Identity (APIKey + KeyLineage), and Attestation (Attribute + Delegation). No layer modifies another.

verified

Integrity valid + identity ok at send-time. Full trust.

partial

Integrity valid but identity ambiguous or missing. Audit spine intact.

degraded

Integrity valid but key was revoked/rotated before send-time. Content intact, sender compromised.

orphaned

Bubble record exists but no audit spine found. Data integrity inconsistency.

unverified

No records at all for this envelope hash.

Sovereign Hard Rules

Key Isolation

No client-side key access. Ever.

All Ed25519 signing keys and X25519 encryption keys are generated, encrypted, and stored within Arcform's sovereign infrastructure. Developers interact with api_key_id aliases — never raw key material.

Cryptographic Authority

Arcform signs. Arcform encrypts. Arcform routes.

For every DIDComm action, Arcform — not the developer — is the cryptographic actor of record. This means Arcform carries the compliance burden for key custody, signing integrity, and encryption correctness.

Immutable Privacy

Strip & Seal is always on. No toggles. No opt-out.

Metadata stripping and payload sealing are architectural invariants. Every envelope has its routing metadata stripped before delivery. Envelope logs record hashes, byte counts, and latency — never payload content.

Audit Immutability

Every action is logged with a cryptographic checksum.

All identity activations, envelope deliveries, key revocations, and webhook registrations are recorded in an immutable audit log. Each entry includes a checksum, severity level, and actor role.

Industrial-Scale Caching

Boundary 1

Full Verdict Cache

Terminal envelopes (delivered/failed) with deterministic identity verdicts are cached permanently. Zero I/O on repeat verification.

Boundary 2

Identity Verdict Cache

sender_key_id + anchored_at combos produce deterministic results. Eliminates APIKey + KeyLineage queries on repeat checks.

Boundary 3

Batch Parallelisation

Batch requests (up to 50) run in parallel chunks of 10. 5–10x throughput improvement over sequential execution.

Boundary 4

Signer Set Cache

Superseded signer set configurations are cached. Active sets are resolved fresh to ensure quorum changes propagate immediately.

Boundary 5

Delegation Chain Cache

Valid delegation chains are cached with minute-level temporal bucketing. Eliminates N+1 database walks on 5-hop chains.

Governance Validation — 33/33 Tests Passing

14/14

Identity Verdict

Includes threshold_change + signer set resolution

13/13

Attribute Verdict

Includes zkp_type routing & delegation caching

6/6

Tide Isolation

Zero verdict impact from external metadata