How Covantic works, in plain words

Step 1 — Read the agent's history

When you ask for a quote, the scorer fetches the agent wallet's last 100 transactions, its token balances and its account details. It uses a pool of Solana RPC providers, with Helius as a backup. If none of them answer, the assessment fails with an error — the scorer never makes up a score.

At the same time it records every outgoing transfer the agent made. That record is used later to set the agent's spending limits (Step 5).

Step 2 — Score 15 separate signals

Each signal looks at one kind of risk and gives it a score from 0 to 1. The signals fall into five groups. The percentage next to each one is its weight — how much it counts in the final score. The weights add up to 100%.

Step 3 — Combine the signals, trusting thin data less

Some signals need a minimum amount of data before they mean anything. For example, the failure rate needs at least 10 transactions and the activity-spike check needs 20. If an agent has only 5 transactions, the failure-rate signal counts at half its weight. The final score is a weighted average of all 15 signals using these adjusted weights. A wallet with no history at all gets a neutral 0.5.

The scorer also reports a sub-score for each of the five groups and an overall confidence level, so you can see why an agent scored the way it did.

Step 4 — Put the agent in a tier, and set the price

The price is a yearly rate, charged only for the time you are covered:

premium = coverage × tier rate × (days covered ÷ 365)

1,000 USDC of cover · MEDIUM tier (2.5%) · 7 days
= 1,000 × 0.025 × 7 ÷ 365
= 0.48 USDC

Step 5 — Work out the agent's spending limits (the “envelope”)

Agent-error cover needs a line between “normal” and “a mistake”. Covantic draws that line from the agent's own history, not from what the buyer says. It looks at the size of the agent's outgoing transfers and takes the 95th percentile — the size that 95% of its transfers stay under. Then:

• Single-transfer limit = 5 × that 95th percentile.
• Hourly limit = 3 × the single-transfer limit, over any one hour.
• The agent needs at least 5 recorded transfers. With less history there is nothing to measure “normal” against, so agent-error cover doesn't apply yet (exploit, oracle and governance cover still work).

the agent usually sends up to 200 USDC per transfer (95th percentile)
single-transfer limit = 5 × 200  = 1,000 USDC
hourly limit          = 3 × 1,000 = 3,000 USDC

Step 6 — Write the result on-chain

The raw score stays off-chain, but the tierand a fingerprint (hash) of the envelope are written into an on-chain “risk attestation” account for the agent. Only the Covantic oracle key can sign it, and it expires after at most 1 hour. When you buy, the program reads the tier from this account — never from the buyer — and refuses if it is missing, expired or doesn't match the envelope. A quote also needs an assessment less than 10 minutes old, so prices always reflect recent behaviour.

Finally, the pool must be able to afford the cover. You can't buy more cover than the agent actually holds, or more than the pool's free capacity (two times the staked USDC, minus cover already sold). If the pool's backing falls below 50% of all active cover, no new policies can be sold. HIGH-tier agents need at least 100%.

The four covered events

Big transfers, failed transactions or unexplained balance drops are logged, but on their own they never open a claim. Only one of the four events above can.

How the watchers find them

There are two ways an event reaches the protocol:

• The sweep (main path). Every 2 minutes a watcher goes through the insured agents (up to 50 per pass). For each one it reads the latest transactions from the last 15 minutes and screens them for, in this order: governance changes, exploits, then spending-limit breaches. A second watcher re-checks swap prices on the same 2-minute cycle. On every pass the sweep also writes fresh balance and authority “checkpoints” to chain — these are the reference readings used later to prove a loss.
• Push alerts (fast path). Helius sends a webhook the moment a watched wallet makes a transaction, so an event can be picked up in seconds instead of waiting for the next sweep.

If one transaction looks like several things at once, the most specific one wins: governance attack, then exploit, then oracle manipulation, then agent error.

Wide net first, then a strict check

The first screen is deliberately loose, so nothing real slips through. For example, it flags any drop of 25% or more, any change of account ownership, or any trade more than 1% off the market price on at least $50. Being flagged is not the same as being paid.

Each flag then goes to a strict checker built for that event type. It rebuilds the transaction from raw chain data and answers: was this really covered, and how much was lost? For oracle claims it needs at least 3 price sources that agree within 2% of each other before it trusts “the real price”.

Three possible outcomes

Proven on-chain payouts are live today for exploits, agent errors and governance attacks. Oracle-manipulation claims are detected and judged, but go to review until the signed Pyth price feed is connected in production.

01

The event is screened and judged

A watcher flags a suspicious transaction. A separate, strict checker for that trigger type then rebuilds what happened from raw chain data and decides whether it is a covered loss and how large it is. Losses below 0.1 USDC are ignored.

02

The claim is opened on-chain

The oracle files the claim on the policy. The policy switches to “Claim pending” and the clock for the lock period starts. Only one claim can be open per policy. The policy holder can also file a claim themselves.

03

The lock period passes

The claim waits 1 to 6 hours depending on the trigger (see the table below). This window lets a mistaken claim be caught before money moves. It is the only delay in the process.

04

The program checks the proof itself

A proof instruction runs for the trigger type. The program does not take the oracle’s word for the amount: it reads its own balance and authority checkpoints, the policy and, for oracle claims, the signed Pyth price. It then works out the largest amount it is allowed to pay.

05

USDC moves in the same transaction

If every check passes, the vault sends USDC straight to the policy holder’s USDC account in that same transaction. The policy is marked “Claim paid”, and a proof record is written on-chain, so a policy can only ever be paid once.

Lock periods

The lock is a short safety wait between opening a claim and paying it. It is the only delay built into the process, and it differs by event type:

On devnet the locks are shortened to 30 seconds for demos. In a recorded devnet run, a policy that cost 0.29 USDC paid out 500 USDC 47 seconds after the event.

How much is paid

The program works out the largest amount it is allowed to pay from its ownreadings, and the payout can never be larger than the policy's coverage:

• Exploit — up to how far the balance actually fell.
• Oracle manipulation — up to the gap between the fill price and the Pyth price, times the quantity.
• Governance attack — up to the balance lost or the funds seized.
• Agent error — the wholeovershoot above the spending limit. The limit works like a deductible: normal spending is the agent's own business, and everything past the line is covered.

single-transfer limit      1,000 USDC   (from the envelope above)
a bug makes the agent send 4,000 USDC in one transfer
overshoot = 4,000 − 1,000  = 3,000 USDC

with 5,000 USDC of cover  → pays 3,000 USDC
with 2,000 USDC of cover  → pays 2,000 USDC (capped at coverage)

Where the money comes from

All USDC sits in one vault account controlled by the program. Inside it, the protocol keeps three separate balances, and a payout draws on them in this order:

1. The protocol treasury (built from 10% of every premium) pays first.
2. The reserve fund (20% of every premium) pays next.
3. Staker deposits are used only once both of those are empty. Every staker then loses the same percentage of their stake.

The USDC always goes to the policy holder's USDC account — the wallet that bought the policy — not to the agent. After payment the policy is closed as “Claim paid”, its cover is released from the pool, and an on-chain proof record makes a second payout on the same policy impossible. If the vault ever held less than the payout, the transaction would fail entirely rather than pay a partial amount.

Built-in safety rules

Where each premium goes

Step by step

01

Deposit USDC

Connect a wallet on the Staking page and stake any amount of USDC above zero. The program opens a position account for your wallet that records how much you staked. There is no LP token to manage.

02

Earn on every policy sold

The moment anyone buys a policy, 70% of the premium is split between all stakers in proportion to their stake at that moment. Your reward is ready right away — there is nothing to wait for.

03

Claim whenever you want

Rewards pile up as “pending” and you claim them with one click. They are not added to your stake automatically; you choose whether to re-stake them.

04

Withdraw in two steps

Request an unstake, wait 48 hours, then withdraw. While you wait, your stake still earns premiums and still backs claims. The cooldown stops someone from pulling out just before a known claim pays.

How much can you earn?

Your earnings depend on how much cover people buy while you are staked, and on your share of the pool. There is no fixed interest rate. Roughly:

yield ≈ 70% × premiums paid in a year ÷ total USDC staked

pool: 100,000 USDC staked · you stake 10,000 USDC (10% share)
premiums collected this month: 2,000 USDC
  stakers’ 70%          = 1,400 USDC
  your 10% of that      =   140 USDC
  as a yearly rate      ≈   140 × 12 ÷ 10,000 = 16.8%

The risk you take

Staking is underwriting: you are the insurer. If payouts ever exceed everything in the treasury and the reserve, the rest comes out of staker deposits. Every staker loses the same percentage, so nobody can dodge a loss by being first to leave.

a 5,000 USDC payout · treasury + reserve hold 1,000 USDC
  1,000 USDC comes from the treasury and reserve
  4,000 USDC comes from stakers = 4% of a 100,000 USDC pool
  your 10,000 USDC stake becomes 9,600 USDC

Withdrawal rules

• 48-hour cooldown. You request an unstake for your whole position, wait 48 hours, then withdraw. Your stake keeps earning — and keeps backing claims — during the wait.
• The pool must stay solvent. Staked USDC must always cover at least 50% of all active policies. If your withdrawal would break that line, you get the free part now and can take the rest later, as policies expire, without a new cooldown.
• Always reachable. An emergency pause blocks new stakes and payouts, but never unstaking or claiming rewards.