Lero Network Whitepaper

Lero Network presents a groundbreaking cryptographic verification protocol that enables the generation of verifiable proofs from real-world data sources without revealing the underlying sensitive information. By combining Three-Party TLS (3P-TLS), Multi-Party Computation (MPC), and Zero-Knowledge Proofs (ZKP), Lero creates a trustless bridge between centralized data sources and decentralized applications.

The protocol addresses a fundamental challenge in Web3: the need to verify claims about off-chain data without compromising user privacy or requiring trusted intermediaries. Traditional oracle solutions rely on API access and data source cooperation, limiting their applicability. Lero's approach requires no API integration or server-side changes, enabling verification of any HTTPS-based data source.

Key innovations include:

• -Universal Data Source Compatibility: Verify any web-accessible data without API access or server modifications
• -Privacy-First Design: User data never leaves the local environment in raw form
• -Decentralized Verification: No single point of trust or failure in the verification process
• -On-Chain Integration: Proofs can be stored as zkSBTs or shared privately with specific addresses

2.1 The Problem of Private Data Verification

The blockchain ecosystem has matured significantly over the past decade, yet a fundamental limitation persists: the inability to reliably verify claims about off-chain data while preserving user privacy. This constraint manifests across numerous critical applications:

• -DeFi Lending: Protocols cannot assess borrower creditworthiness without accessing sensitive financial data
• -Identity Verification: KYC processes require exposing personal documents to centralized entities
• -Reputation Systems: Web2 credentials cannot be ported to Web3 without revealing underlying data
• -Healthcare: Medical records verification requires trusted intermediaries

2.2 Limitations of Existing Solutions

Current approaches to bridging off-chain data with blockchain applications suffer from several fundamental limitations:

2.3 The Lero Approach

Lero Network addresses these limitations through a novel combination of cryptographic techniques that enable verification without trust assumptions on data sources or intermediaries:

The protocol operates by extending the standard TLS handshake into a three-party process, where MPC nodes participate in key generation without gaining access to the actual data being transmitted. This approach ensures:

1. 1.Data authenticity is cryptographically guaranteed by the original TLS certificate
2. 2.Users maintain complete control over their raw data
3. 3.Verification occurs without any party having complete access to session keys
4. 4.Zero-knowledge proofs enable selective disclosure of verified claims

3.1 Three-Party TLS (3P-TLS)

At the core of Lero Network lies the 3P-TLS protocol, an extension of the standard TLS 1.3 handshake that introduces MPC nodes as cryptographic witnesses without compromising the security properties of the original protocol.

3.1.1 Handshake Process

The 3P-TLS handshake proceeds through the following phases:

3.2 MPC Network Architecture

The MPC network consists of distributed nodes that collectively perform verification tasks without any single node having access to complete session information.

3.3 Proof Generation Pipeline

Once data authenticity is established through 3P-TLS, users generate zero-knowledge proofs locally using the verified data and MPC attestations.

4.1 Hybrid Zero-Knowledge Proof System

Lero Network employs a Hybrid ZK architecture that combines the strengths of different zero-knowledge proof systems to optimize for both prover efficiency and verifier cost.

4.2 Multi-Party Computation Protocol

The MPC protocol ensures that no single party can access complete session keys while maintaining the ability to collectively verify data authenticity.

4.3 zkSBT Implementation

Zero-knowledge Soulbound Tokens (zkSBTs) serve as the on-chain representation of verified proofs, enabling persistent and composable verification claims.

// zkSBT Structure
struct zkSBT {
    bytes32 schemaId;      // Verification schema identifier
    bytes32 proofHash;     // Hash of ZK proof
    uint256 timestamp;     // Verification timestamp
    bytes   encryptedData; // Optional encrypted metadata
    address issuer;        // MPC network attestation
}

5.1 Node Architecture

The Lero Network operates through a distributed network of nodes with specialized roles, ensuring decentralization while maintaining high performance.

5.2 Consensus Mechanism

Lero employs a modified Proof-of-Stake consensus optimized for the unique requirements of verification workloads.

• -Delegated Proof-of-Stake: Token holders delegate to validators, distributing security responsibility
• -VRF-Based Selection: Task node assignment uses verifiable random functions for fairness
• -Slashing Conditions: Malicious behavior results in stake reduction and network ejection

6.1 Schema System

Lero's schema system defines how data is extracted, validated, and converted into verifiable claims. Schemas are created by developers and reviewed for security before deployment.

// Example Schema Definition
{
  "schemaId": "twitter-follower-verification",
  "version": "1.0.0",
  "dataSource": {
    "type": "https",
    "domain": "twitter.com",
    "path": "/*/followers"
  },
  "selectors": [
    {
      "name": "followerCount",
      "type": "number",
      "xpath": "//span[@data-testid='followerCount']"
    }
  ],
  "proofTypes": ["gt", "lt", "eq", "range"]
}

6.2 Supported Data Sources

The protocol supports any HTTPS-based data source. Pre-built schemas are available for common platforms:

7.1 $LERO Token Utility

The $LERO token serves as the native utility token of the network, enabling economic coordination between participants.

7.2 Token Distribution

Lero Network enables a wide range of applications that were previously impossible or required trusted intermediaries.

9.1 Threat Model

The protocol is designed to be secure under the following threat model:

9.2 Audit Status