- Participate - Witness-network mailing lists

Staging log-list request - edge.bluefox.ai/transparency/reliance/v1 (BlueFox Edge receipt transparency log)
by Ethan Holien 18 Sep '26

18 Sep '26

Hello, We would like to request that our transparency log be added to the STAGING log list. Origin line: edge.bluefox.ai/transparency/reliance/v1 Public key (vkey): edge.bluefox.ai/transparency/reliance/v1+dde62350+ATjbXC50KK3XMDTkI4H79Q+TshwWsnwhJ3wDuw3ZvFzO (key type 0x01, Ed25519; the key name is the origin line) add-checkpoint rate: 24 per day (one checkpoint every 3600 s) Log list: staging Contact: Ethan Holien, CEO, ethan(a)bluefoxedge.ai About the log: BlueFox Edge (bluefoxedge.ai) issues signed receipts for brand-verification results consumed by AI agents; every receipt is included in a C2SP-style tlog whose checkpoints are published at https://api.bluefoxedge.ai/v1/transparency/checkpoint. What we ask of independent cosigners, stated in advance, is published at https://www.bluefoxedge.ai/docs/cosigner-bar. Thank you for running the network. Ethan

2 2

Participation request: Apertrue Witness device register log (staging)
by James Henry Newton 16 Sep '26

16 Sep '26

Hello Witness Network maintainers, We would like to request that the transparency log behind Apertrue Witness be added to the staging list. Operator: Apertrue Origin: apertrue.photo/witness/production Public key (Ed25519 vkey, key name is the origin): apertrue.photo/witness/production+03cfa386+AVHItNDu7TwYuYl5pxDxmCKbwaz+zwxcOBk+YRbn6fuD Checkpoint URL: https://witness.apertrue.photo/v1/tlog/checkpoint Keys: https://witness.apertrue.photo/v1/tlog/keys Add-checkpoint rate: at most 24 per day (hourly), usually fewer Log list: staging (log-list-10qps-4klogs) Contact: jamie(a)apertrue.photo Expected lifetime: long-running Purpose: Apertrue Witness verifies that a person on a video call is using an enrolled camera. The log records every change to our register of enrolled camera devices, so that the verification pages and receipts people rely on can check a device's enrolment against an independently witnessed history. It is small (16 entries today) and grows only when the register changes. Checkpoints follow c2sp.org/tlog-checkpoint and submissions follow c2sp.org/tlog-witness. We have tested against our own witness so far, and plan to require a quorum of independent cosignatures in our verification page and app before launch. Please let us know if you need anything else or would prefer a different list or rate. Kind regards, Jamie Newton Apertrue

2 2

Log submission: log.frem.sh (C2SP tlog-tiles)
by Søren Hartvig Jensen 16 Sep '26

16 Sep '26

Hello, I would like to add a log to the witness-network lists. Operator: fremverk ApS (Denmark) Origin: log.frem.sh Vkey: log.frem.sh+4e9c5de6+AcfzmSNWSmxIklo06ELrJzqR8VNCsdV3Sz9pFqL+5lH+ Checkpoint: https://log.frem.sh/checkpoint Tiles: https://log.frem.sh/tile/... Formats: c2sp.org/tlog-tiles, c2sp.org/tlog-checkpoint Current size: 457 (grows a few leaves per day) Add-checkpoint: ~4 per day (ceiling 96/day) Requested list: staging - happy to be placed wherever you think appropriate Contact: Soren Hartvig Jensen <info(a)fremverk.com>, +45 91886000 The log records SLSA provenance attestations for software we build. Each leaf is the SHA-256 of a DSSE envelope, so the log is publicly verifiable without revealing which repository produced an entry. On the submission rate: our publisher runs every fifteen minutes but returns early when the tree has not advanced, before contacting any witness. The tree has grown 3.8 leaves per day over the last 119 days, so in practice witnesses would see roughly four add-checkpoint requests a day rather than ninety-six. Two things that may be relevant to you: - Our client-side verifier already implements both cosignature types -- Ed25519 (0x04) and ML-DSA-44 (0x06), including the subtree/v1 cosigned-message construction. If ML-DSA-44 support is a gating concern for the production tier, we are ready for it today and happy to be a test consumer. - Verification happens entirely on the caller's machine. Our CLI recomputes every hash locally and never asks our server for a verdict. With thanks, Med venlig hilsen / best regards Søren Hartvig Jensen CEO, Co-founder & Enterprise Cloud Architect [signatureImage] shj(a)fremverk.com<mailto:shj@fremverk.com> | +45 6022 8378<tel:+4560228378> www.fremverk.com<https://www.fremverk.com/> | LinkedIn<https://linkedin.com/in/sorenhartvigjensen>

2 2

Participation request — notbefore.net/log (staging list)
by Bill Dailey, MD, MSEng, MSMI 16 Sep '26

16 Sep '26

Hello, I'd like to add a transparency log to the staging list. Details per https://www.google.com/url?q=https://witness-network.org/participate&source… : Origin line https://www.google.com/url?q=http://notbefore.net/log&source=gmail&ust=1789… Public key (vkey, Ed25519, key type 0x01; key name = origin line) https://www.google.com/url?q=http://notbefore.net/log%2B8b627e7f%2BAfPQekre… Log-list entry, in your log-list-format terms vkey https://www.google.com/url?q=http://notbefore.net/log%2B8b627e7f%2BAfPQekre… qpd 60 contact docdailey(a)gmail.com add-checkpoint rate Two requests per hour in steady state — one per published record (a commit at :01 and a reveal at :06 past each hour) — plus rare back-fills. Requesting qpd 60 to leave headroom; typical days will use about 48. List staging. This is a real, running log with real usage; we're happy to dogfood. Contact docdailey(a)gmail.com · https://www.google.com/url?q=https://notbefore.net/&source=gmail&ust=178932… · https://www.google.com/url?q=https://github.com/docdailey/qrng-beacon-log&s… What the log is An hourly commit-then-reveal randomness beacon ("NotBefore"): a 32-byte value is committed before a named drand quicknet round exists and revealed after it, so a consumer can check that the value was fixed before the round and not selected after. Each commit carries two RFC 3161 timestamps; every record is additionally anchored in Rekor and OpenTimestamps. The Merkle tree is RFC 6962 over every published record; checkpoints follow https://www.google.com/url?q=http://c2sp.org/tlog-checkpoint&source=gmail&u… and are signed in the same commit as the record they cover. The current checkpoint is served at https://www.google.com/url?q=https://notbefore.net/checkpoint&source=gmail&… and history at https://www.google.com/url?q=https://notbefore.net/checkpoints/NNNNNN&sourc…; the same files are in the GitHub repository above. Tree size is ~52 today, growing by ~17,500 entries per year. Origin and key are permanent by policy; a key rotation would be announced in the repository and the origin would not change. Implementation notes The log speaks https://www.google.com/url?q=http://c2sp.org/tlog-witness@v1.0.0&source=gma… (add-checkpoint with old size + consistency proof; 409 handling) and appends cosignatures per https://www.google.com/url?q=http://c2sp.org/tlog-cosignature@v1.0.1&source…. We have been exercising the client hourly against a witness we run ourselves, and have implemented the RFC 6962 vectors, signed-note and cosignature key-ID derivations as tests ( https://www.google.com/url?q=https://github.com/docdailey/qrng-beacon-log/b…, `selftest`). If anything in our checkpoints or requests is non-conformant, I'd be grateful to hear it — this is our first participation in the network. Once approved, we will configure the staging witnesses' add-checkpoint endpoints and keys from the witness tables and start submitting on the next published record. Thank you, Doc docdailey(a)gmail.com https://www.google.com/url?q=https://notbefore.net/&source=gmail&ust=178932…

2 1

Participation Request: Android Binary Transparency Tessera Logs
by Billy Lau 10 Sep '26

10 Sep '26

Hello maintainers of the Witness Network, The Android Binary Transparency team at Google would like to submit our two new Tessera-backed transparency logs to the Public Witness Network for synchronous checkpoint co-signing. Below are the registration details for both logs: 1. Google Product Application Transparency Log (as detailed in https://developers.google.com/android/binary_transparency/google1p/log_deta… ) Origin line: android.transparency.goog/google1p/apk/2026/1 Public Key (vkey format, Ed25519 / type 0x01): android.transparency.goog/google1p/apk/2026/1+fc654374+ATr9NQE0gvOtVfj5cCStUzdlflEp3oZoNHD8pImzPj5O Public Key (PEM Format): -----BEGIN PUBLIC KEY----- MCowBQYDK2VwAyEAOv01ATSC861V+PlwJK1TN2V+USnehmg0cPykibM+Pk4= -----END PUBLIC KEY----- Checkpoint URL: https://gstatic.com/android/binary_transparency/google1p/apk/2026/02/checkp… Tile Base URL: https://gstatic.com/android/binary_transparency/google1p/apk/2026/02/tile/ Log List: staging (with intent to transition to production when available) Add-checkpoint rate: At most once every 30 seconds (~2 requests/min, < 0.1 QPS) 2. Android Mainline Modules Transparency Log (as detailed in https://developers.google.com/android/binary_transparency/mainline_modules/… ) Origin line: android.transparency.goog/mainline/modules/2026/1 Public Key (vkey format, Ed25519 / type 0x01): android.transparency.goog/mainline/modules/2026/1+1a8e4064+AfwnHm59rNQTJICchMd7a2W5PQa7nC5h2gTEfq3fhCEI Public Key (PEM Format): -----BEGIN PUBLIC KEY----- MCowBQYDK2VwAyEA/Ccebn2s1BMkgJyEx3trZbk9BrucLmHaBMR+rd+EIQg= -----END PUBLIC KEY----- Checkpoint URL: https://gstatic.com/android/binary_transparency/mainline/2026/02/checkpoint Tile Base URL: https://gstatic.com/android/binary_transparency/mainline/2026/02/tile/ Log List: staging (with intent to transition to production when available) Add-checkpoint rate: At most once every 30 seconds (~2 requests/min, < 0.1 QPS) *Contact Information* Technical POC: Billy Lau (billylau(a)google.com) Project documentation: https://developers.google.com/android/binary_transparency/overview *Operational & Architecture Details* Implementation: Both logs are built on Tessera and adhere to the C2SP tlog-tiles specification (with height of 8). Witness Interaction Policy: - requests to witness /add-checkpoint endpoints are dispatched on a fixed 30-second interval by our backend publisher loop (internal rate-limiting prevents burst or traffic amplification). - outbound HTTP requests are identified by User-Agent: Google-Android-Binary-Transparency/1.0 (<log_origin_string>) - we operate in greedy collection mode with a 10second timeout, but with fail-open semantics. Temporary witness unresponsiveness or network delays will not block log ingestion or publication. Please let me know if any additional information or adjustments are needed, and what are the next steps required. Thank you, Billy Lau Android Binary Transparency Team

2 1

Markovian Protocol witness: testing -> staging
by Markovian Protocol 09 Sep '26

09 Sep '26

Hello, We operate the Markovian Protocol witness, listed in the testing table since July 29, so about six weeks (about page: https://witness.markovianprotocol.com/about) We'd like to be considered for the staging tier. We would configure testing/log-list.1 plus both staging lists (log-list-10qps-4klogs.1 and log-list-100qps-40klogs.1), refresh hourly, and keep the never-remove semantics we already follow. Capacity, measured August 2 on an isolated instance of the same witness build on the same host, loaded with a 40,000-entry known-logs table: 10, 25, 50, and 100 requests per second sustained for 45 seconds each, zero errors across 12,800 valid signed checkpoints with real consistency proofs; median latency 5-6 ms and p99 under 10 ms at every sustained rate; an unthrottled burst averaged 315 requests per second, also error-free. The known-logs table size had no measurable effect on latency. Operations, stated plainly: single operator, single host (Hetzner, Helsinki), SQLite state with an off-host backup, Cloudflare fronting the public endpoint, C2SP refusal rules (404/403/409/422) enforced. The cloudflared process fronting the endpoint has been up since 2026-08-31, 8 days, and reports 222,129 proxied requests with zero request errors. That counter resets when the process restarts, so it is 8 days of evidence, not six weeks -- we are not claiming an unbroken record behind it. If there's anything else you'd like to see first, tell us and we'll do it. Markovian Protocol hello(a)markovianprotocol.com

2 1

Participation request: MCP Verify archive log (staging)
by contact 04 Sep '26

04 Sep '26

Hello Witness Network maintainers, I would like to add a log to the witness network. Origin line: mcpverify.ai/archive/v1 Public key: mcpverify.ai/archive/v1+f5d9c8d0+AZ0GwtwS941FiviqZwM4j/UKN/YiUO3rZawJimXMIfMc Checkpoint URL: https://mcpverify.ai/proof/checkpoint.txt Public key URL: https://mcpverify.ai/proof/log.pub Add-checkpoint rate: at most 24 per day, and in practice far less. Log list: staging/log-list-10qps-4klogs.1 Operator: MCPVerify Labs Contact: contact(a)mcpverify.ai Expected lifetime: indefinite; the origin line is frozen and the archive is append-only by design. Purpose. The log is the append-only record behind MCP Verify, an archive of Model Context Protocol server reliability measurements. It commits one leaf per daily snapshot, in insertion order, as an RFC 6962 tree. Checkpoints are C2SP tlog-checkpoint format, signed with Ed25519 under signed-note type byte 0x01. The key name is the same string as the origin line, so the log-list entry can omit its `origin` line. Rate. Snapshots are captured daily and unattended, but checkpoints are signed by a human, at most about once a week. The figure above is a ceiling rather than an expected rate: it allows for a second signing in a day, the documented zero-size bootstrap request alongside the real submission, one retry, and headroom for a manual debugging session. Steady-state load is a couple of requests a week. What has been exercised. I have run the tlog-witness protocol end to end against a witness of my own before writing to you: a real signed checkpoint of this log was submitted, cosigned, and the cosignature verified per tlog-cosignature. Each documented response condition was exercised individually, including the zero-size bootstrap and its 409 reply. No third-party witness has been contacted and none has cosigned this log. I would like the staging list rather than testing: this is a real log with real usage and I am happy to dogfood staging. Happy to adjust the rate, or to take a different list, if either would suit the network better. Thank you, MCPVerify Labs

1 0

Re: Participation request: Thelemail key transparency log (staging)
by Rasmus Dahlberg 01 Sep '26

01 Sep '26

Great thanks for the request -- you've now been added to the 10qps staging list: https://staging.witness-network.org/log-list-10qps-4klogs.1 -Rasmus On Fri, Aug 28, 2026 at 09:36:57AM +0000, Vladislav Gorokhov wrote: > Hey Rasmus, > > We'd rather lower it to once every 10 seconds, so 8640 qpd. Please put us in the 10qps list. That should be enough. > > Thank you. > Vlad > > On Fri, 28 Aug 2026 at 08:11, Rasmus Dahlberg <rgdd(a)glasklarteknik.se> wrote: > > Hey, thanks for submitting this requests! If you need to allocate 1 qps > > (84600 qpd) I would suggest that we put you in the 100qps list. > > > > https://staging.witness-network.org/log-list-100qps-40klogs.1 > > > > Does this sound good, or would you rather lower the qpd? Note: if you > > exceed the declared qpd, witnesses may rate limit, block, and similar. > > > > -Rasmus > > > > On Fri, Aug 28, 2026 at 02:54:49AM +0000, Vladislav Gorokhov via Participate wrote: > > > Hello Witness Network maintainers, > > > > > > We would like to enroll Thelemail’s key-transparency log in the Witness Network staging environment. > > > > > > Operator: Thelemail > > > > > > Origin: > > > > > > thelemail.com/keys > > > > > > Log public key (Ed25519 vkey): > > > > > > thelemail.com/keys+76ead63c+ASduViYkPgYHzuTuDnuTdEkjR/DIprnavuFA3vom4YZT > > > > > > Checkpoint URL: > > > > > > https://tlog.thelemail.com/checkpoint > > > > > > Add-checkpoint rate: > > > > > > At most one request per second per witness. In practice, the rate should be significantly lower while the log receives few updates. > > > > > > Requested log list: > > > > > > staging/log-list-10qps-4klogs.1 > > > > > > Contact: > > > > > > security(a)thel.email > > > > > > Purpose: > > > > > > This is a long-lived transparency log used by Thelemail’s encrypted email service. It records privacy-preserving, VRF-addressed statements binding Thelemail addresses to their public encryption and signing keys. > > > > > > The log is already serving real users, although current traffic and log growth are small. We are happy to dogfood the staging Witness Network while production is unavailable. > > > > > > Public information: > > > > > > https://thelemail.com/keys > > > > > > Current checkpoint: > > > > > > https://tlog.thelemail.com/checkpoint > > > > > > Open-source log implementation: > > > > > > https://github.com/thelemail/keylog > > > > > > The log uses Tessera and C2SP-compatible checkpoints and proofs. > > > > > > Please let us know if you need additional information or would prefer a different staging log list or request rate. > > > > > > Best, > > > Vlad > > > Thelemail > > > > > _______________________________________________ > > > Participate mailing list -- participate(a)lists.witness-network.org > > > To unsubscribe send an email to participate-leave(a)lists.witness-network.org > > > >

1 0

Request to add Enigm Key Transparency Log to the staging list
by Enigm Security Team 01 Sep '26

01 Sep '26

Hello Witness Network maintainers, We would like to request the inclusion of Enigm's Key Transparency Log in the Witness Network staging list. List: staging Origin: keys.enigm.dev/v1 Public log URL: https://keys.enigm.dev/v1 Public key (C2SP vkey): keys.enigm.dev/v1+06c61fb2+AcBPl120wgVJe9QWPfa8Pazv3kG99wFcZvr316Msrab6 Expected add-checkpoint rate: at most one checkpoint every two minutes, approximately 720 checkpoints per day (0.0083 requests per second). Contact: security(a)enigm.io Organization: Enigm Expected lifetime: long-running Purpose: Enigm uses an append-only key transparency log to allow clients to verify changes to users' public encryption keys and detect inconsistent views. We want the staging log to be independently witnessed before activating the corresponding production infrastructure. The integration follows the C2SP transparency-log witness protocol. We plan to configure a 2-of-3 witness quorum during preproduction testing. Please let us know if you require any additional technical information or changes to the submitted configuration. Kind regards, -- Enigm Security Team security(a)enigm.io - enigm.io

2 1

participation question for an autonomous-agent action log
by tony 01 Sep '26

01 Sep '26

Hello Witness Network maintainers, I’m building Fulcrum, control and evidence infrastructure for autonomous-agent actions. Its transparency log produces signed tree heads and currently uses only Fulcrum-operated witnesses, so I’m looking for an independent operating path without claiming one already exists. Would a log recording allowed and stopped agent actions be in scope for a participation request, and if so, which interoperability details should I verify before submitting one? I’ve read the network’s experimental/work-in-progress notice and participation guidelines. I’m not asking you to operate anything through this note; I’m asking whether the log fits the participation process. Tony

2 3