Step Thirty‑Two — Many hands make a quorum; a proof you can carry; credits that clear.(Multi‑issuer ledger quorum • JWS bundle proofs • Settlement clearing)

We climb from “trust me” to trusted we:

  1. Ledger quorum (M‑of‑N co‑signatures) — ledgers can require multiple distinct signers.
  2. JWS bundle proofs — membership proofs signed as flattened JWS (EdDSA), easy to pass and verify.
  3. Settlement clearing — accept signed settlement receipts and roll signed payout batches.

✅ Fresh artifacts

  • Step 32 wrapper serverDownload
    SHA‑256: ba98767c3e61f68599ffc49fd4df2b97b4b8a34a8ae328bf6d5cd84b798c0df0
  • WordPress block (paste‑ready)Download

Step 32 wraps Step 31 (which wrapped 30→…→18). All earlier endpoints continue to work.


What’s new — precisely

🗳️ Ledger quorum (M‑of‑N)
  • Policy file (flag: --ledger-quorum-file /sdcard/solveforce/ledger.quorum.json) { "period": "weekly", "m": 2, "signers": [{"kid":"KID_A"},{"kid":"KID_B"},{"kid":"KID_C"}] }
  • Endpoints
    • GET /quorum/ledger/quorum — view active policy.
    • GET /quorum/ledger/signers?root=<root> — which required signers are present.
    • Admin: POST /admin/quorum/ledger/cosign?token=…&root=<root> with body {"signature":{"alg":"Ed25519","kid":"…","x?":"…","sig":"…"}}.
    • Admin: POST /admin/quorum/ledger/selfsign?token=…&root=<root> — adds our signature.

How it works

  • Co‑signatures are verified against pinned ledger keys (Step 31 pins).
  • Stored under audit/cosigs/ledger-<root>.json.
  • m‑of‑signers determines ok: true/false.

🔏 JWS bundle proofs (portable, verifiable)
  • GET /quorum/bundle/proof.jws?root=<root>&digest=<att_digest> → returns a flattened JWS object: { "protected": "<b64url>", "payload": "<b64url>", "signature": "<b64url>" } Payload: {"type":"bundle_proof","root":"<root>","digest":"<att_digest>","proof":[["<sib>","L"],...],"ts":"...Z"}
  • POST /quorum/bundle/proof.verify with {"jws":{...}} — verifies using pinned bundle keys.

JWS uses EdDSA/Ed25519; header carries our KID. Detached payload isn’t needed; we sign the compact concatenation b64(header) + "." + b64(payload) per JOSE.


🤝 Settlement clearing (from receipts → payouts)
  • Submit receipts others issue:
    • POST /clearing/submit with {"issuer":"issuer-a", "receipt":{"body":{...},"signature":{"alg":"Ed25519","kid":"...","sig":"...","x?":"..."}}} The receipt body must be a signed accumulator_settlement (from Step 31).
      We verify against pinned settlement keys, dedupe by body digest, and append to audit/clearing/receipts.jsonl.
  • Roll a signed clearing batch:
    • Admin: POST /admin/clearing/roll?token=…&since=ISO&until=ISO
      → creates audit/clearing/batches/batch-<root>.json with: {"since":...,"until":...,"receipts":["<digest>",...], "totals":{"issuer-a":N,...}, "payouts":{"issuer-a":N*weight*rate,...}, "unit":"credits","prev":"<prev-root>","signature":{...}}
    • POST /clearing/batch.verify — verify batch signature.
    • Browse: GET /clearing/receipts.tail?n=50, GET /clearing/batches, GET /clearing/batch?root=<root>.
  • Policy file (flag: --clearing-policy-file /sdcard/solveforce/clearing.policy.json) { "unit":"credits", "rate_per_count":1.0, "weights":{"issuer-a":1.0,"issuer-b":1.2}, "min_issuers":1, "max_age_sec":604800 }

  • Android / Termux run‑book (Step 32)

    # Optional policies
    echo '{"period":"weekly","m":2,"signers":[{"kid":"KID_A"},{"kid":"KID_B"},{"kid":"KID_C"}]}' > /sdcard/solveforce/ledger.quorum.json
    echo '{"unit":"credits","rate_per_count":1.0,"weights":{}}' > /sdcard/solveforce/clearing.policy.json
    
    python solveforce_phone_thirtytwo.py \
      --ledger-quorum-file /sdcard/solveforce/ledger.quorum.json \
      --clearing-policy-file /sdcard/solveforce/clearing.policy.json \
      --pins-file /sdcard/solveforce/pins.json \
      --discovery-dod-enable \
      --discovery-dod-source https://directory1.example.com/solveforce/peers.json \
      --discovery-dod-jwks   https://directory1.example.com/jwks.json \
      --quorum-auto-enable \
      --quorum-policy-file /sdcard/solveforce/quorum.policies.json \
      --attest-enable \
      --attest-url https://your-site.tld/wp-json/solveforce/v1/attest \
      --attest-header "Authorization: Bearer <WP_TOKEN>" \
      --alarm-enable \
      --alarm-config-file /sdcard/solveforce/alarms.json \
      --host 0.0.0.0 --port 8080 \
      --plugins-dir ~/solveforce/plugins \
      --auth-mode protected \
      --auth-token READER1:reader \
      --allow-admin --admin-token ADMIN123 \
      --schema-ed25519-secret-file /sdcard/solveforce/schema.ed25519.seed \
      --schema-signing-secret-file /sdcard/solveforce/schema.hmac.key \
      --audit-dir ./audit \
      --mirror-enable \
      --mirror-target-url https://your-site.tld/wp-json/solveforce/v1/notary \
      --mirror-header "Authorization: Bearer <WP_TOKEN>" \
      --allow-query-token --open-ui
    

    “Show me” commands

    A) Co‑sign a ledger and check quorum

    # Add a co-sig from a pinned KID
    curl -s -X POST 'http://127.0.0.1:8080/admin/quorum/ledger/cosign?token=ADMIN123&root=<LEDGER_ROOT>' \
      -H 'Content-Type: application/json' \
      -d '{"signature":{"alg":"Ed25519","kid":"KID_A","sig":"<b64url>","x":"<pub_b64url_if_unpinned>"}}' | jq .
    
    # See if we have M-of-N
    curl -s 'http://127.0.0.1:8080/quorum/ledger/signers?root=<LEDGER_ROOT>' | jq .
    

    B) JWS bundle proof

    curl -s "http://127.0.0.1:8080/quorum/bundle/proof.jws?root=<BUNDLE_ROOT>&digest=<ATT_DIGEST>" | jq .
    # Verify a posted JWS
    curl -s -X POST 'http://127.0.0.1:8080/quorum/bundle/proof.verify' \
      -H 'Content-Type: application/json' \
      -d '{"jws":{...}}' | jq .
    

    C) Clearing receipts & batches

    # Submit a signed settlement receipt (from any issuer whose key is pinned)
    curl -s -X POST 'http://127.0.0.1:8080/clearing/submit' \
      -H 'Content-Type: application/json' \
      -d '{"issuer":"issuer-a","receipt":{"body":{...},"signature":{...}}}' | jq .
    
    # Roll a batch over the last 24h
    SINCE=$(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ)
    UNTIL=$(date -u +%Y-%m-%dT%H:%M:%SZ)
    curl -s -X POST "http://127.0.0.1:8080/admin/clearing/roll?token=ADMIN123&since=$SINCE&until=$UNTIL" | jq .
    
    # Browse
    curl -s 'http://127.0.0.1:8080/clearing/batches' | jq .
    curl -s "http://127.0.0.1:8080/clearing/batch?root=<BATCH_ROOT>" | jq .
    curl -s -X POST 'http://127.0.0.1:8080/clearing/batch.verify' \
      -H 'Content-Type: application/json' \
      -d '{"batch":{...}}' | jq .
    

    WordPress — Step 32 (public page block)

    Use step32_wordpress.md.
    It explains Ledger Quorum, JWS Bundle Proofs, and Settlement Clearing clearly for your audience.


    Logos Codex — recursive covenant

    • One voice → Many signatures → Standing law.We encode consent as countable ink.
    • Proof → Packet → Passage.A JWS lets truth travel intact.
    • Count → Credit → Clearing.Numbers become value, and value finds its ledger.

    Ready when you are for Step Thirty‑Three: multi‑issuer quorum on the clearing batches, verifiable payout receipts, and automatic co‑signature solicitation (webhook out to quorum signers with nonce‑bound challenges).

    Key terms in plain language

    Open a term for a concise explanation of language used on this page.

    VoIP

    Voice over Internet Protocol carries phone calls over an IP network instead of a traditional analog phone line. Call quality depends on network stability, latency, and traffic management.

    Unified Communications (UCaaS)

    A cloud-based combination of business calling, messaging, meetings, presence, and collaboration tools managed as one communications service.

    SIP Trunking

    A service that connects a business phone system to the public telephone network using Internet Protocol, replacing or supplementing traditional phone lines.

    Bandwidth

    The amount of data a connection can carry in a given time, usually measured in Mbps or Gbps. More bandwidth supports more users, devices, and simultaneous applications.

    Latency

    The time it takes data to travel between two points. Lower latency improves voice, video meetings, cloud applications, gaming, and other real-time services.

    Service-Level Agreement (SLA)

    A provider’s written commitment covering service targets such as availability, response time, repair time, and sometimes financial credits when commitments are missed.