NEP-100: Ethos Credibility Integration

Abstract

This NEP integrates the Ethos credibility protocol into Netrun's trust infrastructure. The proposal establishes a standardized framework for querying onchain reputation data, defines credibility thresholds for protocol operations, and implements oracle programs that bridge Ethos scores to Netrun on Solana. Integration enables participants to evaluate counterparty reliability before engaging in cross-chain transactions, with credibility scores influencing bridge operator selection, liquidity pool matching, and governance weight calculations.

Motivation

Netrun's cross-chain architecture requires participants to interact with bridge operators, liquidity providers, and validators whose behavior cannot be fully verified through cryptographic proofs alone. While the protocol guarantees transaction integrity at the consensus layer, the selection of which counterparty to trust remains a social coordination problem. Users currently rely on informal reputation signals—community endorsements, historical track records, brand recognition—none of which are systematically queryable or enforceable onchain.

The crypto ecosystem loses approximately $3.8 billion annually to fraud, exit scams, and rug pulls. A significant portion of these losses occur in cross-chain contexts where users must trust intermediaries. By integrating Ethos's credibility framework, Netrun gains access to a decentralized reputation layer where participants stake economic value behind their trustworthiness. This creates measurable, comparable, and enforceable trust signals without compromising the pseudonymity properties essential to Bitcoin-native systems.

Alternatives Considered

1. Native reputation system: Building a Netrun-specific reputation protocol was rejected due to cold-start problems and the difficulty of bootstrapping trust networks from zero.
2. Centralized reputation providers: Using services like Chainalysis or TRM Labs was rejected due to centralization risks, privacy concerns, and incompatibility with pseudonymous participation.
3. Multi-sig requirements: Requiring multi-signature approvals for high-value operations was rejected as it shifts trust to key holders without providing reputation visibility.
4. Insurance protocols: Integrating coverage providers like Nexus Mutual addresses loss recovery but not prevention; reputation complements rather than replaces insurance.

Terminology

This NEP uses the following credibility unit terminology:

• •Credibility Score (CS): Composite numerical value (0-2000) representing an address's aggregate trustworthiness derived from vouches, reviews, and attestations.
• •Vouch Weight (VW): SOL-denominated stake backing a credibility claim; 1 VW = 1 SOL vouched to an address.
• •Review Sentiment (RS): Normalized score (-1.0 to +1.0) derived from textual review analysis.
• •Slash Risk (SR): Probability coefficient (0.0 to 1.0) indicating likelihood of slashing based on historical behavior patterns.

Conversion: Effective Credibility = CS × (1 + log₂(VW + 1)) × (1 - SR)

Specification

Oracle Architecture

Current Behavior:

• •No standardized method for querying offchain reputation data
• •Bridge operators selected based on TVL or manual curation
• •Governance voting weighted purely by token holdings

Proposed Behavior:

• •Deploy EthosOracle contract on Netrun mainnet with 15-minute update frequency
• •Oracle operators stake minimum 500 SOL; slashable for incorrect score reporting
• •Score data stored in merkle tree; clients verify inclusion proofs locally
• •Fallback to cached scores if oracle unavailable; 24-hour maximum staleness

Implementation Details:

• •Oracle program address: deployed at protocol-controlled address Eth0sOrclNetrun...111
• •Minimum 5 oracle operators required for quorum; 3/5 agreement on score updates
• •Score updates batched to reduce compute costs; maximum 1000 addresses per update transaction
• •Emergency pause mechanism controlled by 4/7 multisig for critical vulnerabilities

RPC Methods

New JSON-RPC methods for credibility queries:

All methods support batch queries via ethos_batch wrapper with maximum 100 addresses per request. Response times must not exceed 200ms for single queries or 2000ms for maximum batch size.

Credibility Thresholds

Thresholds are protocol parameters adjustable via governance. Initial values calibrated against Ethos mainnet score distribution (median CS: 340, 90th percentile: 780, 99th percentile: 1150).

Privacy Architecture

Credibility integration preserves Netrun's pseudonymity guarantees through:

1. Opt-in attestation: Users explicitly link Netrun addresses to Ethos profiles via signed attestations. No automatic correlation between addresses.
2. Zero-knowledge threshold proofs: Smart contracts can verify CS > threshold without learning the exact score using ZK-SNARKs generated client-side.
3. Selective disclosure: Users choose which credibility components to reveal (vouches only, reviews only, composite score, etc.).
4. Ephemeral queries: RPC nodes do not log credibility queries; responses are not cached beyond protocol-defined staleness windows.

Economic Impact Analysis

Bridge Operations

Current annual fraud losses in cross-chain bridges: ~$1.2B. With credibility-gated operator selection, projected loss reduction: 40-60% based on historical correlation between Ethos scores and operator reliability in analogous systems.

Governance Participation

Credibility-weighted voting reduces plutocratic capture by ensuring large token holders without established reputation cannot unilaterally control governance outcomes. Modeling suggests 15-25% reduction in successful governance attacks.

User Acquisition Costs

Reputation portability from Ethos reduces onboarding friction for users with established credibility. Projected 30% reduction in time-to-first-transaction for users with CS > 500.

Invariants

The following invariants must always hold:

1. Score Freshness Invariant: Credibility scores used in protocol operations MUST NOT be older than 24 hours. Operations requiring credibility checks MUST fail if oracle data exceeds staleness threshold.
2. Threshold Enforcement Invariant: Operations with credibility requirements MUST revert if the acting address fails to meet the minimum CS and VW thresholds defined in protocol parameters.
3. Opt-in Invariant: Addresses without explicit Ethos attestations MUST be treated as having CS = 0 and VW = 0. The protocol MUST NOT infer or impute credibility scores.
4. Privacy Invariant: ZK threshold proofs MUST NOT leak any information beyond the boolean result of the threshold comparison. Verifier contracts MUST reject malformed proofs.
5. Oracle Consensus Invariant: Score updates MUST achieve 3/5 operator quorum. Updates with fewer confirmations MUST be rejected by the oracle contract.
6. Slashing Invariant: Oracle operators reporting scores that deviate >10% from consensus MUST be slashed 10% of their stake. Repeat offenders (3+ slashes in 30 days) MUST be permanently removed from operator set.

Critical Test Cases

The test suite must cover:

1. Basic score query: Single address query returns correct CS, VW, and staleness within 200ms
2. Batch query: 100-address batch returns all scores within 2000ms
3. Threshold verification: ZK proof correctly validates CS > 500 without revealing score
4. Stale data rejection: Operations fail when oracle data exceeds 24-hour staleness
5. Bridge operator gating: Registration reverts for addresses with CS < 800 or VW < 50 SOL
6. Governance proposal gating: Proposal creation reverts for addresses with CS < 500
7. Vote weight calculation: Addresses with CS > 1000 and VW > 100 SOL receive 1.5x multiplier
8. Oracle quorum: Score updates with <3 operator signatures are rejected
9. Oracle slashing: Operators reporting deviant scores lose 10% stake
10. Unattested address: Queries for addresses without Ethos attestation return CS = 0, VW = 0
11. Privacy preservation: ZK proofs do not leak score information to verifier
12. Emergency pause: 4/7 multisig can pause oracle updates within single block