How Ripcord works

Overview

Ripcord is two things working together:

• A risk scanner. Every major protocol is scored on two independent axes and weighted by the value actually at risk, so you can see what's most exposed.
• An auto-exit guardian. Arm a position and Ripcord watches it for the on-chain signals that precede a drain — then rescues it to your wallet before the attacker's transaction clears.

The two halves connect through coverage: the scanner tells you what's exposed, and the guardian acts on the subset it can actually protect. The result is a single view that runs from "here is the risk" to "here is what I can do about it" — scoring spans major EVM and Solana protocols, while automated exit currently focuses on EVM lending positions.

It is non-custodial end to end: Ripcord never takes possession of your assets, never asks for a deposit, and the only thing it can ever do with a position is return it to you. Everything below explains how that holds even if Ripcord itself were compromised.

The two-track threat

Most risk tools measure one thing at one moment. Ripcord tracks two clocks ticking against the same on-chain funds — one already running, one approaching — and scores both, because the assets exposed today are largely the assets exposed later.

The two compound. A protocol with a single exposed upgrade key is both an easy machine-speed target now and a guaranteed casualty once signatures break — so Ripcord scores each axis independently rather than collapsing them into one number, letting you see which threat dominates for a given protocol.

Dual-risk scoring

Each protocol receives two scores from 0–100 (higher = more exposed), each with a confidence so "low risk" is never confused with "couldn't assess."

Quantum axis

Driven first by who controls upgrades: an immutable contract is safest, then a timelock (a delay buys reaction time), then a multisig (several keys, but all forgeable once signatures break), then a single externally-owned key — one exposed public key away from full compromise.

That control structure is multiplied by the chain's key-exposure baseline. Chains where the address is the public key have keys exposed from the first transaction; chains that only reveal a public key when an address spends sit lower; and it's all weighted by how much value those keys can actually move.

Mythos axis

Driven by attack surface — the things an automated attacker probes for:

• Audit coverage & source verification — unaudited or unverified code is cheaper to analyze and likelier to hide a flaw.
• Upgradeability — a mutable implementation is a single point where logic can be swapped under depositors.
• Code complexity — more surface, more places for a bug to live.
• Bridge / oracle reliance — cross-chain messaging and external price feeds are among the highest-value, most-targeted components in DeFi.

Priority & the fail-cautious rule

Value-at-risk is the dollar value plausibly controllable by the exposed privileged keys — not raw TVL, but the slice an attacker could actually move. Protocols are then ranked by priority = value-at-risk × the worse of the two axes, so attention flows to where the most money meets the most risk.

Every score carries a confidence, and scoring is deliberately fail-cautious: when a fact can't be determined — say an upgrade controller can't be classified — Ripcord treats it as risky and lowers confidence, rather than assuming it's safe. Under-stating risk is the one error a risk tool must not make.

Coverage tiers

A risk score is only half the story — the other half is what you can do about it. The Explorer tags every protocol with one of three tiers, so the dashboard never implies more protection than exists:

Coverage expands over time: protocols move up the tiers as watch rules and exit adapters are added. A protocol's tier is independent of its risk score — a high-risk protocol may be merely scored, and a moderate one fully auto-exit.

How auto-exit works

Auto-exit is built on account abstraction (ERC-4337). Instead of trusting Ripcord with your keys, you grant it a narrow, revocable permission your wallet enforces for itself. Three steps:

The safety invariant

This is the heart of the design. The session key is constrained by your account's own validator — not by a promise in our code. It can call exactly one function, the lending pool's withdraw(asset, amount, to), with the recipient to hard-bound to your address and zero native-token value.

Those constraints are checked on-chain at execution time, by your smart account, every time. A request that deviates — a different recipient, a different function, a token transfer — is rejected before it can run. So it doesn't matter whether the key leaks, the keeper is malicious, or our servers are fully compromised: none of them can rewrite what the key is allowed to do.

Exposure Check

When an exploit is unfolding, the thread traces the attacker within the hour — but the individual holder's real question, "am I affected?", almost never gets answered. Exposure Check answers it directly.

Paste any wallet — no connection, no signature, no arming. Ripcord checks the address's balances and lending positions across the protocols it tracks, then cross-references the live control-change signals on exactly those protocols, and returns one of three verdicts:

• Exposed — active threat: you hold something in a protocol showing a live control-change alert right now.
• No active threats: you hold tracked protocols, none currently alerting.
• No tracked holdings: this wallet holds nothing Ripcord currently tracks.

Honest limits

Auto-exit is a race, not a guarantee. Detect → simulate → sign → submit is a multi-step sprint against the attacker's transaction, and it only wins when the attack leaves room to run:

• Wins when the exploit leaves a window — timelocked governance attacks (hours of warning), an upgrade and a drain in separate transactions, or an admin-key handoff that precedes the drain.
• Loses atomic same-block exploits (nothing to react to between the malicious action and the drain) and private-mempool attacks that expose no on-chain trigger beforehand.
• Detects a class, not everything — the watchtower watches for control-structure changes (upgrades, admin/ownership moves). A pure logic or price-oracle exploit that emits no such event won't trip it.
• Coverage is a curated set of high-value protocols, not the entire market, and it grows over time.

None of this weakens the safety invariant — a missed attack simply means no exit fired; it can never mean your funds went somewhere they shouldn't. We'd rather state these limits plainly than overpromise.