I built a ZK + BLS-based customs clearance prototype on L2 — looking for feedback on the on-chain verification architecture.

The problem:

Single-authority customs approval is a rational bribery target. One official, one decision, predictable cost. The incentive structure is broken by design.

Game theory layer:

UBLP changes the incentive structure before any cryptography kicks in:
- 2/3 committee threshold required (Byzantine fault tolerant)
- Committee members have conflicting interests by design
- Any anomalous signing pattern is visible on-chain

Corrupting the system is no longer a cost-benefit calculation — it becomes a coordination problem that defeats itself.

On-chain verification:

L2 smart contract verifies two independent proofs at settlement:

1. BLS12-381 aggregate signature — 2/3 committee threshold
2. SP1 Groth16 ZK proof — document validity + holder privacy

Neither alone is sufficient for settlement. The contract independently verifies both before writing the immutable record.

L2 → Ethereum mainnet anchoring:

Settlement records are written to L2. L2 periodically commits
a batch proof to Ethereum mainnet — inheriting Ethereum's
security guarantees without paying mainnet gas per document.

Each customs clearance is ultimately anchored to Ethereum's
consensus. Tampering with a settled record requires breaking
both the L2 and Ethereum mainnet — economically infeasible.

This is the finality layer: L2 handles throughput,
Ethereum handles trust.

ZK circuit (SP1 zkVM):

Private inputs (never leave the circuit):
- ministry_signature — P-256 ECDSA, 64 byte
- holder_signature — P-256 ECDSA, 64 byte
- holder_pub_key_raw — uncompressed SEC1, 65 byte
- document_hash — SHA256("ublp-doc-v1:" + canonicalJson), 32 byte
- ministry_pub_key_raw — uncompressed SEC1, 65 byte
- document_id_hash — 32 byte

Public outputs (verified on L2):
- document_hash — document fingerprint
- ministry_pub_key_hash — ministry key commitment
- document_id_hash — replay protection
- holder_pub_key_hash — holder identity proof without identity exposure

Architecture:

- Ministry signs document (EC P-256 ECDSA) → issues Verifiable Credential
- Agent generates ZK proof via SP1 zkVM (Groth16/PLONK)
- Independent committee verifies ZK proof, then BLS12-381 threshold signs (2/3)
- L2 smart contract verifies both → immutable settlement

Open questions I'd love feedback on:

1. Is verifying both BLS + ZK on L2 the right approach, or should BLS verification move inside the ZK circuit?
2. BLS 2/3 threshold — right model for this trust setup?
3. Agent-first flow: committee never sees raw document, only the ZK proof — any attack vectors I'm missing?
4. Domain-separated document hash `SHA256("ublp-doc-v1:" + canonicalJson)` — idiomatic for this use case?
5. Security model — if you spot any attack vectors, trust assumption violations, or cryptographic weaknesses I haven't considered, please flag them. This is a prototype and I'd rather find the holes here than later.

This is a prototype — mock ZK in dev mode, real SP1 in prod mode.

GitHub: github.com/ekacin/UBLP