NEBRA

• Name: NEBRA
• URL: https://nebra.one/
• Category: zero-knowledge proof aggregation / verification-cost infrastructure / proof-settlement middleware
• Summary: Keep projects/nebra on the technical surface NEBRA calls Universal Proof Aggregation (UPA): a protocol for batching and recursively aggregating proofs so applications can settle proof validity on Ethereum and other EVM chains at much lower cost. The docs, protocol specification, transparency page, deployment registry, and GitHub repos make this a concrete proof-settlement middleware note with an opinionated security model: onchain registration and proof indexing, an offchain aggregator/prover layer, audited contracts and circuits, and app-facing integration tooling. For the named operator boundary around the permissioned aggregator, verification-service endpoint issuance, and production deployment shell, use nebra.
• What it does:
  • Builds UPA, a protocol that lets applications register verification keys, submit proofs, and later verify aggregated proof results onchain instead of verifying every proof individually
  • Uses recursive SNARK-based aggregation to compress many application proofs into a single proof that can be checked by an onchain verifier contract
  • Supports multiple Groth16 proof implementations today and publishes SDKs, templates, deployment addresses, and integration guides for developers
  • Offers both censorship-resistant onchain submission flows and newer offchain-submission flows with different cost/liveness tradeoffs
  • Publishes unusually detailed security and transparency material covering audits, protocol specs, deployment verification, and the current role of the permissioned aggregator
• Key claims:
  • The official docs say NEBRA UPA is a universal proof aggregation protocol that can batch proofs from different circuits and different proof sources, not just one app-specific circuit family
  • The docs claim applications can lower proof-verification cost by roughly 5x+ in the general introduction, and the gas-cost pages model savings of roughly 80–85% per proof under current batching assumptions
  • The security docs say the current offchain aggregator is permissioned and operated by NEBRA, but emphasize that it is not trusted for proof validity because correctness is enforced by the aggregation circuits and onchain verifier
  • The protocol docs describe forced-inclusion / censorship-resistance mechanics for onchain submissions, with penalties if valid queued proofs are skipped
  • The public deployment registry shows live verifier deployments across Ethereum mainnet plus newer Base and World Chain surfaces, which is a stronger production signal than a research-only zk project usually provides
• Whitepaper: Official technical papers exist. NEBRA’s docs link to the Universal Proof Aggregation ePrint, and the open-source repo publishes a protocol specification PDF; both were saved locally alongside the primary-source snapshot. See ../whitepapers/nebra-primary-sources-2026-04-27.md and ../whitepapers/nebra-upa-eprint-2023-869.pdf, plus the local protocol specification at ../whitepapers/nebra-upa-protocol-spec-v1.2.0.pdf. For the newly separated entity-layer source packet, see ../whitepapers/nebra-company-primary-sources-2026-08-13.md.
• Sources:
  • https://nebra.one/
  • https://docs.nebra.one/
  • https://docs.nebra.one/introduction/what-is-nebra-upa.md
  • https://docs.nebra.one/security-and-transparency.md
  • https://docs.nebra.one/upa-protocol-specification.md
  • https://docs.nebra.one/developer-guide/gas-costs-on-l1s.md
  • https://docs.nebra.one/developer-guide/deployments.md
  • https://github.com/NebraZKP
  • https://raw.githubusercontent.com/NebraZKP/upa/main/README.md
  • https://eprint.iacr.org/2023/869.pdf

Internal linkages

• Company / operator boundary: nebra.
• Useful proving-stack comparisons: sp1, risc-zero, and succinct-labs.

Protocol / company boundary

• Keep projects/nebra on the proof-aggregation mechanism itself: recursive aggregation, verification-cost compression, onchain proof indexing, forced inclusion, and verifier deployment surfaces.
• Use nebra when the sharper question is who operates the current permissioned off-chain aggregator, who grants verification-service endpoints, and who publishes the canonical docs / deployment shell teams inherit first.
• That split matters because UPA can reduce trust in the aggregator for correctness while still depending on a named company for service access, rollout, and practical liveness.

Control surface

• Practical leverage at the project layer sits in proof-system support, batching and settlement economics, onchain ordering and censorship-resistance mechanics, verifier deployment footprint, and how easy it is to integrate different proof sources.

• Keep the company layer visible too: nebra is where the current operator boundary becomes easier to analyze.

• Last reviewed: 2026-08-13 UTC