Westwyrd
Metrics
Verifiable system-level metrics derived from deterministic event streams. All reported data is computed from on-chain events and cryptographically verifiable system outputs — no sampling, estimation, or statistical inference is applied to core protocol metrics. What is reported is what occurred.
The metrics infrastructure is designed around a fundamental principle: every reported metric must be independently verifiable against the protocol's on-chain event log. This is not a policy commitment — it is an architectural constraint. Each metric is computed as a deterministic function of on-chain events, and the computation logic is published as open-source code that any observer can execute against their own archive node to reproduce the reported values.
Verification latency — the time required to verify a single Groth16 proof on-chain — is bounded by the computational complexity of the bilinear pairing check, which is constant regardless of circuit size. In the current deployment on Ethereum, this verification consumes approximately 230,000 gas and executes in under 100 milliseconds. This constant-time property is a fundamental feature of the Groth16 proof system and provides predictable gas costs for institutional planning purposes.
The proof rejection rate metric tracks the fraction of submitted proofs that are rejected by the on-chain verifier. In a correctly functioning system, this rate should be exactly zero — all proofs are generated by the authorized proving pipeline, which produces only valid proofs by construction. A non-zero rejection rate would indicate either a malfunction in the proving pipeline, an attempted proof forgery, or a discrepancy between the circuit used for proving and the verification key embedded in the on-chain verifier.
Cross-domain latency is governed by the consensus finality guarantees of each settlement layer. L3 state roots are committed to L1 with every L3 epoch, producing an effective state propagation latency of approximately 12 seconds under normal network conditions. Proof generation runs in a parallel pipeline 2–4 minutes behind the execution frontier, ensuring full ZK coverage of all committed state without blocking execution throughput.
Bridge withdrawal times differ substantially between the optimistic and ZK-attested paths. The optimistic path requires a 7-day challenge window during which any honest observer can submit a fraud proof if the proposed state root is incorrect. The ZK-attested path bypasses the challenge window entirely, reducing withdrawal time to the L1 finality window of approximately 12 minutes (two PoS epochs) — a critical advantage for institutional settlement operations requiring predictable settlement finality.
The forced-inclusion mechanism provides a censorship-resistant escape path. If the L3 sequencer fails to include a valid transaction within approximately 3 minutes (14 L1 blocks), the user can submit the transaction directly to L1 for forced inclusion. This bound is enforced by the L3 sequencer contract and cannot be overridden by the sequencer operator.
UTXO integrity and fragmentation analysis provides structural validation of unspent transaction outputs within the protocol's asset tracking system. The analysis computes the fragmentation index — the ratio of UTXO count to total value — which serves as a proxy for the operational efficiency of the settlement system. High fragmentation indicates excessive granularity in previous settlement operations, which increases proving costs as each UTXO consumed in a state transition adds approximately 300 R1CS constraints to the circuit.
Circuit compilation efficiency metrics track the constraint count and proving time for each circuit version. The constraint count is the primary determinant of proving cost: the Groth16 proving algorithm has O(n log n) time complexity in the number of R1CS constraints. The current settlement circuit contains 10,924 constraints, producing proving times of approximately 3.2 seconds on an Apple M4 Max SoC with 128GB unified memory.
Statistical analysis of system randomness and output distribution provides assurance that the protocol's cryptographic operations maintain their security properties in practice. The entropy metrics monitor proof components, hash outputs, and signature values for statistical anomalies that could indicate a degradation in the quality of the underlying randomness sources used for ZK blinding factors.
Metrics are computed from immutable on-chain events — retroactive modification is impossible without controlling >66% of Ethereum validators. Computation logic is open-source and deterministically reproducible. No manual data curation, selection bias, or survivorship bias — all events are included regardless of outcome.
Each metric is defined as a pure function of the protocol's on-chain event log. Function definitions include event types consumed, aggregation logic applied, and output format. Changes to metric computation logic are versioned alongside smart contract code, enabling observers to re-compute historical metrics under updated definitions.
Internal consistency checks ensure related metrics remain consistent with each other — total settlement volume must match the sum of individual settlement events, and proof verification count must match ProofVerified events emitted by the verifier contract. Inconsistencies trigger automated security alerts.