DOCUMENTATION

Lero Network
Documentation

Everything you need to integrate and build with the Lero Network verification protocol.

GETTING STARTED

Welcome to Lero Network

Lero Network is a cryptographic verification protocol that enables applications to verify claims about real-world data without accessing the underlying information. This documentation provides comprehensive guidance on integrating Lero into your applications.

New to Lero?

Start with the Core Concepts section to understand how the protocol works before diving into implementation.

For Users

Learn how to generate proofs and verify your data using LeroGate.

User Guide

For Developers

Integrate Lero verification into your dApp with our SDK.

Developer Guide

Installation

1Install the SDK

npm install @lero/sdk

Or using yarn: yarn add @lero/sdk

2Get Your App ID

Register your application on the Lero Dashboard to receive your unique App ID.

Go to Dashboard

3Initialize the Client

import { LeroClient } from '@lero/sdk'

const client = new LeroClient({
  appId: 'your-app-id',
  environment: 'production', // or 'testnet'
  network: 'ethereum' // supported: ethereum, polygon, arbitrum
})

Quick Start

Here's a complete example of generating and verifying a proof that a user has more than 1000 Twitter followers:

import { LeroClient } from '@lero/sdk'

// Initialize client
const client = new LeroClient({
  appId: 'your-app-id',
  environment: 'production'
})

// Generate proof
async function verifyFollowers() {
  try {
    // Request user to verify their Twitter account
    const proof = await client.generateProof({
      schemaId: 'twitter-follower-count',
      claim: {
        type: 'gt', // greater than
        value: 1000
      }
    })

    if (proof.isValid) {
      console.log('Proof generated successfully!')
      console.log('Proof hash:', proof.hash)
      
      // Optionally mint as zkSBT
      const txHash = await client.mintZkSBT(proof)
      console.log('zkSBT minted:', txHash)
    }
  } catch (error) {
    console.error('Verification failed:', error)
  }
}

LeroGate Extension Required

Users must have the LeroGate browser extension installed to generate proofs. The SDK will prompt them to install it if not detected.

Core Concepts

Schemas

Schemas define what data can be verified and how. Each schema specifies a data source, extraction rules, and available proof types. Lero maintains a registry of pre-approved schemas for common use cases.

// Example: Twitter follower schema
{
  "schemaId": "twitter-follower-count",
  "dataSource": "twitter.com",
  "extractionPath": "//span[@data-testid='followerCount']",
  "dataType": "number",
  "proofTypes": ["eq", "gt", "lt", "range"]
}

Proofs

A proof is a cryptographic attestation that a specific claim about data is true, without revealing the underlying data. Proofs can make different types of claims:

eq

Value equals exactly

gt / lt

Value greater/less than

range

Value within range

membership

Value in allowed set

zkSBTs (Zero-Knowledge Soulbound Tokens)

zkSBTs are non-transferable tokens that represent verified proofs on-chain. They enable persistent, composable verification that other smart contracts can query.

How It Works

Lero Network combines three core technologies to enable privacy-preserving verification of any HTTPS-based data source:

01

3P-TLS (Three-Party TLS)

An enhanced TLS protocol that introduces MPC nodes into the standard handshake process. This enables secure data verification without API access or data source authorization.

User ←→ Data Source ←→ MPC Nodes (witness only, no data access)
02

MPC Network

Randomly selected task nodes supervise the 3-party handshake, obtaining a portion of the MAC key to ensure data integrity while maintaining complete user privacy.

  • - No single node can access complete data
  • - Byzantine fault tolerant (2/3 honest majority)
  • - Cryptographic commitment to data authenticity
03

Zero-Knowledge Proofs

Users generate ZKPs locally using TLS response data and MPC attestations. Proofs can be stored on-chain as zkSBTs or shared privately.

TLS Data + MPC Attestation → Local ZK Prover → Verifiable Proof

3P-TLS Protocol

The 3P-TLS (Three-Party TLS) protocol extends standard TLS 1.3 to enable cryptographic verification without compromising the security guarantees of the original protocol.

Protocol Flow

1

Session Initiation

User initiates verification through LeroGate. The extension requests task node assignment from the network.

2

Node Selection

VRF-based selection chooses 3-5 task nodes from the active pool. Nodes are selected based on stake weight and historical performance.

3

Distributed Key Generation

During TLS handshake, MPC nodes participate in distributed key generation. Each node receives a share of the MAC key.

4

Data Request

User's browser makes a standard HTTPS request to the data source. TLS encryption protects data from MPC nodes.

5

Attestation Generation

MPC nodes use their key shares to generate attestations proving the response came from the claimed data source.

Security Note

MPC nodes never see decrypted user data. They only verify that the TLS response is authentic through distributed MAC verification.

MPC Network

The Multi-Party Computation network is the distributed infrastructure that enables trustless verification.

Task Nodes

Execute verification tasks and generate attestations.

  • Minimum stake: 1,000 LERO
  • Hardware requirements: 4 vCPU, 8GB RAM
  • 99.9% uptime requirement

Validator Nodes

Secure consensus and manage network state.

  • Minimum stake: 10,000 LERO
  • Maximum 100 active validators
  • Slashing for misbehavior

Running a Node

# Install Lero node software
curl -sSL https://get.lero.network | sh

# Initialize node
lero-node init --type task

# Configure stake
lero-node stake --amount 1000

# Start node
lero-node start

Zero-Knowledge Proofs

Lero uses a Hybrid ZK system combining VOLE-ZK for efficient prover computation and zk-SNARKs for succinct on-chain verification.

LOCAL PROVER

VOLE-ZK

Optimized for prover efficiency with linear complexity.

  • - O(n) prover time
  • - Low memory footprint
  • - Runs in browser
ON-CHAIN VERIFIER

zk-SNARKs

Constant-size proofs for efficient on-chain verification.

  • - ~200 byte proofs
  • - O(1) verification
  • - ~200k gas on Ethereum

Proof Structure

interface LeroProof {
  schemaId: bytes32;      // Schema being proven against
  claimType: string;      // eq, gt, lt, range, membership
  proofData: bytes;       // Serialized ZK proof
  mpcAttestation: bytes;  // MPC node signatures
  timestamp: uint256;     // Proof generation time
  nullifier: bytes32;     // Prevents double-use if needed
}

LeroGate SDK

The LeroGate SDK provides a complete toolkit for integrating Lero Network verification into your applications. It includes both client-side and server-side components.

Client SDK

Browser-based SDK for generating proofs and interacting with LeroGate extension.

View Reference

Server SDK

Node.js SDK for verifying proofs and managing schemas server-side.

View Reference

Client SDK Reference

LeroClient

The main client class for browser-based applications.

constructor(config)

Initialize a new Lero client instance.

const client = new LeroClient({
  appId: string,           // Your application ID
  environment: 'production' | 'testnet',
  network: 'ethereum' | 'polygon' | 'arbitrum',
  onExtensionMissing?: () => void  // Callback when extension not found
})

generateProof(options)

Request the user to generate a proof for a specific claim.

const proof = await client.generateProof({
  schemaId: string,        // Schema identifier
  claim: {
    type: 'eq' | 'gt' | 'lt' | 'range' | 'membership',
    value: number | string | [number, number] | string[]
  },
  options?: {
    timeout?: number,      // Request timeout in ms
    silent?: boolean       // Skip user confirmation
  }
})

// Returns: LeroProof object

mintZkSBT(proof)

Mint a zkSBT representing the verified proof.

const txHash = await client.mintZkSBT(proof, {
  recipient?: address,     // Default: connected wallet
  metadata?: {
    name?: string,
    description?: string
  }
})

// Returns: Transaction hash

verifyProof(proof)

Verify a proof's validity client-side.

const isValid = await client.verifyProof(proof)

// Returns: boolean

Server SDK Reference

LeroServer

Server-side SDK for Node.js applications.

constructor(config)

Initialize the server SDK with your API key.

import { LeroServer } from '@lero/sdk/server'

const server = new LeroServer({
  apiKey: process.env.LERO_API_KEY,
  environment: 'production'
})

verifyProof(proofData)

Verify a proof server-side with full validation.

const result = await server.verifyProof(proofData)

// Returns:
{
  isValid: boolean,
  schemaId: string,
  claim: object,
  timestamp: number,
  mpcNodeCount: number
}

getZkSBT(address, schemaId)

Check if an address holds a zkSBT for a specific schema.

const sbt = await server.getZkSBT(
  '0x1234...', 
  'twitter-follower-count'
)

// Returns: zkSBT data or null

Creating Schemas

Schemas define what data can be verified and how it should be extracted from the source. Creating custom schemas requires approval to prevent malicious use.

Schema Structure

{
  "schemaId": "unique-schema-identifier",
  "name": "Human Readable Name",
  "description": "What this schema verifies",
  "version": "1.0.0",
  
  "dataSource": {
    "type": "https",
    "domain": "example.com",
    "pathPattern": "/user/*/profile",
    "requiredAuth": true
  },
  
  "selectors": [
    {
      "name": "fieldName",
      "type": "number" | "string" | "boolean" | "date",
      "extraction": {
        "method": "xpath" | "jsonpath" | "regex",
        "pattern": "//div[@class='value']"
      },
      "validation": {
        "required": true,
        "min": 0,
        "max": 1000000
      }
    }
  ],
  
  "proofTypes": ["eq", "gt", "lt", "range", "membership"],
  
  "security": {
    "antiReplay": true,
    "maxAge": 3600
  }
}

Submitting for Review

// Using the CLI
lero schema submit ./my-schema.json

// Using the SDK
await server.submitSchema({
  schema: mySchema,
  contact: 'developer@example.com'
})

Supported Data Sources

Lero can verify any HTTPS data source. These are pre-built schemas available for immediate use:

Social Media

  • - Twitter/X: Followers, Following, Account Age
  • - GitHub: Contributions, Repositories, Stars
  • - LinkedIn: Connections, Experience
  • - Discord: Server Membership, Roles

Financial

  • - Binance: Trading Volume, Balance Range
  • - Coinbase: Verification Level, Holdings
  • - Bank Statements: Income Range, Account Age
  • - Credit Reports: Score Range

Identity

  • - Government IDs: Age, Nationality
  • - Educational: Degrees, Certifications
  • - Professional: Licenses, Memberships
  • - Healthcare: Insurance, Vaccinations

Web3

  • - NFT Ownership (with privacy)
  • - DAO Membership
  • - Protocol Participation
  • - On-chain History

Security Model

Lero's security is built on cryptographic guarantees rather than trust assumptions.

Data Privacy

User data is encrypted end-to-end. MPC nodes only see encrypted traffic and verify MAC authenticity without decryption capability.

Data Authenticity

Verification is tied to the original TLS certificate. Data cannot be forged without compromising the source's private key.

Proof Integrity

ZK proofs are mathematically sound. False proofs cannot be generated without the underlying verified data.

Network Security

Byzantine fault tolerant with 2/3 honest majority assumption. Economic incentives align node behavior with protocol security.

Audited by Leading Firms

Trail of Bits, OpenZeppelin, and Veridise have completed comprehensive audits of the protocol.

FAQ

Do data sources need to integrate with Lero?

No. Lero works with any HTTPS data source without requiring API access or server-side changes. Verification happens through the standard TLS connection.

Can MPC nodes see my data?

No. MPC nodes participate in key generation but never have access to decrypted data. They verify authenticity through distributed MAC computation only.

How long does proof generation take?

Typical proof generation takes 5-15 seconds depending on the schema complexity and network conditions. The user sees a simple verification flow in their browser.

What chains are supported?

Currently Ethereum, Polygon, and Arbitrum. Additional chains are being added based on community demand.

What happens if a data source changes their website?

Schemas may need updates when data source structure changes. The schema registry maintains versioning, and affected schemas are flagged for review.

Need Help?

If you have questions or need assistance with your integration, our team is here to help.