IPTF
concept L2 I2I + I2U

L2 Privacy Evaluation Framework

Give institutions a vendor-neutral, sourced methodology for comparing privacy-preserving L2 solutions across performance and cost, privacy and Data Availability, and security and governance. The framework defines a common workload so that self-reported metrics can be placed next to independent benchmarks on the same axes.

I2I
Between institutions the framework is used by procurement, risk, and ops teams to weigh counterparty-aligned criteria such as force-inclusion SLAs, compliance features, and DA trust assumptions. Both sides can cross-review the filled table.
I2U
For user-facing deployments the framework surfaces asymmetries that matter to end users: client proving cost, availability of forced exits without operator cooperation, and whether disclosure can be compelled unilaterally by the operator.
Works best when
Multiple privacy L2s must be compared for an institutional deployment decision.
Throughput, security, and censorship resistance have to be placed side by side across heterogeneous architectures.
A consistent, sourced methodology is needed so that procurement and risk teams can review the same evidence.
Avoid when
The L2 under review has no privacy features; use a general L2 scorecard instead.
A single vendor is already chosen and only vendor docs need verification.
Intent

Give institutions a vendor-neutral, sourced methodology for comparing privacy-preserving L2 solutions across performance and cost, privacy and Data Availability, and security and governance. The framework defines a common workload so that self-reported metrics can be placed next to independent benchmarks on the same axes.

Note: this card is an evaluation framework, not a reusable privacy primitive. pattern-privacy-l2s is the actual L2 pattern; this one documents how to compare privacy L2s. Candidate for relocation to approaches/ or a methodology section in a follow-up.

Components
  • Self-reported metric sheets collected from each L2 team, with a source link per cell.
  • Independent benchmarks and risk reviews used to cross-check the self-reported values.
  • A standardized workload (Simple Value Transfer) that fixes what a transaction means across heterogeneous architectures.
  • A disclosure convention that records what each metric measures, what is excluded, and whether a value is Pending or N/A.
Protocol
1
[evaluator] Adopt Simple Value Transfer as the baseline workload.
2
[evaluator] Request each L2 team to fill the three evaluation tables (performance, privacy and DA, security and governance).
3
[evaluator] Require a source link for every claim (benchmark run, docs page, or paper).
4
[evaluator] Mark `Pending` where data is missing and `N/A` where the metric does not apply to that architecture.
5
[evaluator] Produce the comparative view; highlight trade-offs that matter for the target use case.
6
[evaluator] Re-run the exercise on hard forks, client updates, or when a new benchmark is published.
Guarantees & threat model

Guarantees:

  • Consistent comparison criteria across heterogeneous L2 architectures.
  • Separation of self-reported metrics from independently verified metrics.
  • Clear visibility into what each system hides and from whom.
  • Traceable claims: every metric requires a source.

Threat model:

  • Self-reported metrics may be optimistic; the source link is what anchors them.
  • Some systems do not map cleanly to every row; the N/A marker is load-bearing.
  • Criteria drift over time; periodic re-evaluation is required.
Trade-offs
  • The exercise is labor-intensive; automation via a benchmark pipeline helps.
  • Architectural heterogeneity makes equal-weight scoring misleading; use the tables as input to a weighted decision, not an output score.
  • Frozen snapshots age quickly; timestamp every filled table and link back to source commits where possible.
Post-quantum
low risk
Vector: The framework itself is a methodology, not a cryptographic primitive. One of its rows (PQ Security) flags HNDL exposure in the evaluated systems.
Mitigation: Encourage each system to report post-quantum readiness in its row, and re-evaluate as systems migrate proof systems.
Example

An OTC settlement team filters the table for cryptographic privacy, requires viewing keys for audit support, compares client proving cost against trust assumptions, and reviews censorship-resistance SLAs before choosing between an AppChain SDK and a public privacy L2.

Open-source implementations
L2Beat open dataset and risk methodology used as a baseline for independently verified metrics
TypeScript