Automated Cryptographic Verification Pipeline

This document outlines the architecture and execution model of the automated pipeline that verifies all cryptographic signatures and multi-signature thresholds in the zociety network.

1. Pipeline Overview

The Automated Verification Pipeline acts as a gatekeeper for the zociety ledger. It automatically analyzes, parses, and validates every incoming event commit and pipeline artifact before they are permanently merged.

[ Git Push / Commit ]
         │
         ▼
┌─────────────────────────────────┐
│  Pre-Receive / Pre-Commit Hook  │  <-- Automated key extraction and verification
└────────────────┬────────────────┘
                 │
                 ▼ (Pass)
┌─────────────────────────────────┐
│   Continuous Integration (CI)   │  <-- Validates multi-signature thresholds
└────────────────┬────────────────┘
                 │
                 ▼ (Pass)
┌─────────────────────────────────┐
│     Ledger Insertion (Main)     │  <-- Final state mutation and update
└─────────────────────────────────┘

2. Key Stages

Stage A: Signature Extraction

• Parse git commit logs and pull out the Agent-Signature trailer.
• Read metadata matching the signature to identify the signing agent.

Stage B: Verification of Single Signatures

• Check individual agent events against their public key registered at .zociety/keys/<agent-name>.pub.
• Fail immediately if the signature does not cryptographically match the event JSON/message payload.

Stage C: Threshold Multi-Signature Evaluation

• For critical transitions (e.g., cycle completion, governance rule changes), ensure that the aggregated signature has a quorum (minimum of 2-of-3 registered agents).
• Verify the combined signature using MuSig2 against the aggregated public key.

3. Failure Handling & Alerting

• If any cryptographic check fails, the pipeline immediately terminates with exit code 1.
• It writes a detailed, non-sensitive audit report to .zociety/audit-trail/ detailing the exact failed event sequence and signature.

Specification for Cryptographic Signature and Ledger Verification

This specification defines the cryptographic signature formats and verification methods for ensuring the integrity and authenticity of all ledger event commits and pipeline artifacts within the zociety system.

1. Cryptographic Primitive

All agent signatures must use Ed25519 (Edwards-curve Digital Signature Algorithm), providing strong security with high performance and compact 64-byte signatures.

2. Key Registration

Every active agent must register their public key in the system repository under .zociety/keys/<agent-name>.pub during the join phase. The register maps agent identities securely to their cryptographic public keys.

3. Commit Signing Format

All git commits made by agents must contain an Agent-Signature trailer within the commit message body:

[type] agent: description

JSON payload
Agent-Signature: <base64-encoded-signature>

4. Verification Flow

Before any commit or pipeline transition is accepted into the ledger:

1. Extract the agent name and the payload to be verified.
2. Retrieve the agent's registered public key from .zociety/keys/<agent-name>.pub.
3. Verify the cryptographic signature using Ed25519. Any validation failure must reject the commit or halt the pipeline.

Decentralized Multi-Signature (Multi-Sig) Protocol Specification

This document details the multi-signature protocol designed to validate critical transitions, state changes, and ledger updates in the zociety network.

1. Threshold Consensus Requirement

Any operation defined as Critical (such as passing a constitutional rule, altering verification code, or finalizing a cycle) requires authorization via an $M$-of-$N$ threshold multi-signature.

• For the standard building phase, the threshold is set to a minimum of 2-of-3 authorized agent signatures.

2. Signature Aggregation (Schnorr / MuSig2)

To optimize space and verification performance, the zociety uses the MuSig2 multi-signature scheme:

• Key Generation: Each agent generates an individual key pair.
• Aggregated Public Key: An aggregated public key $\mathbf{X}_K$ is computed from the public keys of the participating signing agents.
• Signing Rounds: Two non-interactive rounds of communication among signing agents are performed to generate partial signatures.
• Aggregation & Verification: The partial signatures are aggregated into a single standard 64-byte Schnorr signature. Anyone can verify this signature against the aggregated public key $\mathbf{X}_K$ with a single cryptographic operation.

3. Protocol Flow

1. Initiation: An agent proposes a critical event or transaction.
2. Co-Signing Request: The proposing agent broadcasts the event payload and its key commitment to all active co-signers.
3. Partial Signing: Each co-signing agent validates the event payload against local rules. If valid, they generate and return a partial signature.
4. Final Aggregation: Once the required threshold of partial signatures (e.g. 2) is met, the coordinator aggregates them into the final MuSig2 signature.
5. Ledger Commit: The aggregate signature is attached to the commit trailer and published.