Documentation

RLAR Protocol Docs

Technical documentation for integrating, submitting data to, and validating on the RLAR Protocol.

Overview

RLAR is a decentralized security oracle that delivers on-chain risk scores for DeFi smart contracts. Protocols integrate RLAR to make automated, security-aware decisions — adjusting parameters, filtering strategies, or warning users based on real-time security data.

The protocol has three layers: the Record Layer (immutable data registry), the Reference Layer (dynamic scoring engine), and the Oracle Interface (on-chain feed for consuming protocols).

Quick Start

Install the RLAR interface package and query your first Risk Score in minutes.

npm install @rlar/contracts

Import the interface in your Solidity contract:

import {IRLAROracle} from "@rlar/contracts/interfaces/IRLAROracle.sol";

contract MyProtocol {
    IRLAROracle public rlar;

    constructor(address _rlar) {
        rlar = IRLAROracle(_rlar);
    }

    function checkRisk(address target) external view returns (uint8) {
        (uint8 score, , ) = rlar.getRiskScore(target);
        return score;
    }
}

Interface

The primary interface for consuming Risk Scores:

interface IRLAROracle {
    /// @notice Get the current Risk Score for a contract
    /// @param target The contract address to query
    /// @return score Risk Score from 0 (highest risk) to 100 (lowest risk)
    /// @return lastUpdated Timestamp of last score update
    /// @return confidence Data density metric (number of independent submissions)
    function getRiskScore(address target)
        external view
        returns (uint8 score, uint40 lastUpdated, uint16 confidence);

    /// @notice Get Risk Score with full metadata
    /// @return score, lastUpdated, confidence, auditCount, incidentCount, dependencyScore
    function getRiskScoreDetailed(address target)
        external view
        returns (uint8, uint40, uint16, uint8, uint8, uint8);

    /// @notice Check if a contract meets a minimum score threshold
    function meetsThreshold(address target, uint8 minScore)
        external view
        returns (bool);
}

Note: uint8 score returns values in the range 0-100, where 100 represents the highest security confidence and 0 represents the lowest. Values above 100 are not possible.

Querying Scores

There are three primary methods for consuming Risk Scores:

Basic Query

Returns score, timestamp, and confidence. Suitable for most integrations.

(uint8 score, uint40 updated, uint16 conf) = rlar.getRiskScore(targetAddress);

Threshold Check

Boolean check for score minimum. Gas-efficient for simple gates.

require(rlar.meetsThreshold(collateral, 60), "Below security threshold");

Detailed Query

Returns full score breakdown for advanced integrations that need granular data.

(uint8 score, uint40 updated, uint16 conf,
 uint8 audits, uint8 incidents, uint8 depScore)
    = rlar.getRiskScoreDetailed(targetAddress);

Subscriptions

Oracle access requires an active subscription paid in RLAR tokens. Subscriptions are per-protocol (one subscription covers all queries from your contract addresses).

Tier	Queries/Month	Fee (RLAR/month)
Starter	10,000	500
Growth	100,000	2,500
Enterprise	Unlimited	10,000

Bootstrap Discount: During Phase 1 (first 12 months post-launch), all tiers are available at 50% discount for early integrators.

Events

The Oracle emits events on score updates, enabling off-chain monitoring:

event ScoreUpdated(
    address indexed target,
    uint8 oldScore,
    uint8 newScore,
    uint40 timestamp
);

event ThresholdBreached(
    address indexed target,
    uint8 score,
    uint8 threshold,
    address indexed subscriber
);

Submitting Data

Security researchers, auditors, and protocol teams submit structured security data to the Record Layer.

interface IRLARRecord {
    function submitAuditReport(
        address target,
        bytes32 contentHash,      // SHA-256 of full report
        uint8 severityFindings,   // 0=clean, 1=low, 2=medium, 3=high, 4=critical
        bool remediationConfirmed
    ) external;

    function submitIncident(
        address target,
        bytes32 contentHash,
        uint8 severity,
        uint256 fundsAtRisk       // in USD (18 decimals)
    ) external;

    function submitConfigChange(
        address target,
        bytes32 configHash,
        uint8 changeType          // 0=admin_key, 1=upgrade, 2=dependency, 3=other
    ) external;
}

Submission Types

Type	Description	Weight in Score
Audit Report	Full security audit findings and remediation status	High
Incident Disclosure	Exploit, vulnerability disclosure, or near-miss report	High (negative)
Config Change	Admin key, proxy upgrade, or dependency change observation	Medium
Dependency Update	Changes in underlying contract dependencies	Low-Medium

Stake Requirements

Submission Type	Minimum Stake (RLAR)	Slashing Rate
Audit Report	5,000	Up to 30%
Incident Disclosure	2,000	Up to 50%
Config Change	500	Up to 20%
Dependency Update	500	Up to 20%

Slashing distribution: 70% to successful challenger, 30% to validator committee.

Becoming a Validator

Validators participate in dispute resolution when submissions are challenged.

Parameter	Value
Minimum Stake	10,000 RLAR
Lock Period	90 days
Committee Size	5-9 validators per dispute
Max Single Entity	20% of committee stake
Selection	Random, weighted by stake (quadratic dampening)

Dispute Resolution

Any staked participant may challenge a submission during its challenge period. The process:

1. Challenger posts counter-evidence and stakes minimum 50% of original submission's stake.

2. A committee of 5+ validators is randomly selected.

3. Each validator independently evaluates the evidence and submits a score.

4. Scores are aggregated via stake-weighted median with quadratic dampening.

5. If the challenge succeeds: submitter is slashed (70% to challenger, 30% to committee). If the challenge fails: challenger's stake is slashed (100% to committee).

Timeline: Tier 1 (whitelisted) submissions: 24-hour observation. Tier 2 (open) submissions: 72-hour challenge period. Committee resolution: 48 hours from challenge filing.

Scoring Algorithm

Risk Scores are computed using a hybrid model:

Final Score = (Base Score × 0.4) + (Assessed Score × 0.6)

Base Score (on-chain deterministic):
  Contract Maturity    10%  — log(days_since_deploy)
  Admin Key Config     10%  — 5-tier rubric (0/25/50/75/100)
  Upgrade Volatility    8%  — penalty for >4 upgrades/quarter
  Dependency Risk       7%  — weighted avg of dependency scores
  Code Verification     5%  — verified source = 100, unverified = 0

Assessed Score (validated off-chain):
  Tier 1 sources: 24h observation, full weight
  Tier 2 sources: 72h challenge, 80% weight if unchallenged

Constraints:
  Max delta: ±15 per epoch (7 days)
  Smoothing: EMA-30 blending
  Decay: -2 points/month without new data

Protocol Parameters

Parameter	Value	Governance
Epoch Duration	7 days	DAO vote
Max Score Delta	±15 per epoch	DAO vote
Score Decay	-2/month	DAO vote
Attestation Interval	6 hours	DAO vote
Min Node Operators	7 per round	DAO vote
Consensus Threshold	5 of 7 matching	DAO vote
Tier 1 Observation	24 hours	DAO vote
Tier 2 Challenge	72 hours	DAO vote
Governance Quorum	10% circulating	Fixed
Proposal Threshold	100,000 RLAR	DAO vote
Timelock	48 hours	Fixed

Contract Addresses

Testnet (Sepolia) — Coming Q3 2026
Mainnet deployment planned for Q4 2026. Contract addresses will be published here upon deployment.

Getting Started

Integration

Data Submission

Validation

Reference