# Risk Insights & Score

PENGUARDS assigns each session key a quantitative risk score and converts the result into visual indicators that support rapid triage.

## Overall indicator (brand glow)

* The penguin emblem in the top-left corner of the header illuminates **red**, **amber**, or **green** based on the most severe active session.
* Hovering over the emblem reveals a concise status summary such as "1 critical session detected" or "All sessions meet best-practice thresholds."

![Brand glow states](/files/bvUTnxzmIrRBx45xvMof)

## Session badges

Every session card contains a badge detailing:

* **Severity label** (`Critical`, `High`, `Medium`, `Low`, `Info`).
* **Raw score** (for example, `42 / 100`).
* **Percentile rank** (for example, 42nd percentile among this wallet's sessions), which also drives the default sorting order.

## Principal risk signals

* The "Risk signals" panel lists the top contributing factors—such as "Unlimited spend permitted," "Approval target not reviewed," or "Very long / effectively no expiry."
* Selecting "View all signals" opens the complete breakdown aligned with the dimensions described below.

![Risk signal summary](/files/5aCH8aKcru1i5QsVf7MX)

## Detailed permission breakdown

Expand a session card to see:

* **Call policies:** contract address, function signature, per-use spend caps, and parameter constraints.
* **Transfer policies:** recipient/target, per-use caps, lifetime or periodic value limits (reset period shown only when `LimitType = Allowance`).
* **Fee limits & expiration:** lifetime gas budget; reset timers appear only when `feeLimit.limitType = Allowance`; expiration timestamp when applicable.
* **Registry status:** whether the call or approval is marked Allowed, Unset, or Blocked on the Abstract Session Key Policy Registry.

Tooltips give extra context, and links let you cross-check anything directly on abscan or Abstract documentation.

![Permission detail](/files/KwqxDChzMJpsQChnZF7d)

## Severity reference

* **Critical (0-29%)** - immediate remediation required (blocked approvals or open-ended permissions).
* **High (30-49%)** - significant exposure that should be tightened promptly.
* **Medium (50-74%)** - manageable but warrants revision in the near term.
* **Low (75-89%)** - largely aligned with guidance; continue periodic reviews.
* **Info (90-100%)** - conforms to best practices.

The sections below describe how those severities are produced.

## How the score is calculated

PENGUARDS mirrors Abstract's mainnet enforcement rules when computing each session's score.

### Data sources

| Source                                     | Purpose                                                                                                                                                                                     |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Session config (`createSession` payload)   | Provides signer, expiry, fee limits, call/transfer policies, constraints, and approval selectors.                                                                                           |
| Session Key Policy Registry (`0xA146…b93`) | Confirms whether each `(target, selector)` and `(token, spender)` pair is Allowed, Unset, or Blocked; the UI shows the decoded spender alongside the verdict for approvals.                 |
| Session Key Validator                      | Returns the live status (`Active`, `Expired`, `Closed`). The client computes `getSessionHash(sessionConfig)` locally and compares it with the validator's stored hash to confirm integrity. |
| Optional telemetry                         | Flags reused signers or unusually high counts of active sessions.                                                                                                                           |

Mainnet sessions run through every registry check. Testnet sessions skip the enforcement but still surface warnings so you can practise safer setups.

### Dimensions weights

| Dimension               | Weight | What earns points                                           | What reduces them                                                       |
| ----------------------- | ------ | ----------------------------------------------------------- | ----------------------------------------------------------------------- |
| Registry compliance     | 15     | Policies marked **Allowed**                                 | Blocked entries cap the total at 60; Unset gets half credit on mainnet. |
| Approval safety         | 15     | Spender is pinned **and** `(token, spender)` is **Allowed** | Missing pins, `Blocked`, or failed lookups drop to 0 and cap at 50.     |
| Constraints coverage    | 12     | Sensitive params have `Equal`/range constraints             | No metadata or unconstrained inputs score near zero.                    |
| Scope breadth           | 10     | Few targets/selectors, no generic routers                   | Broad scopes or `execute` selectors lower the score.                    |
| Native value protection | 12     | Low per-use spend and finite lifetime caps                  | Unlimited or high limits tank the score.                                |
| Fee budget              | 6      | Tight lifetime/allowance gas budgets                        | Unlimited or very high budgets score poorly.                            |
| Expiration              | 10     | Short lifetimes (≤ 24h best)                                | Long or missing expiries lose credit.                                   |
| Allowance period        | 3      | Short reset windows for `LimitType.Allowance`               | Missing or very long periods score low.                                 |
| Transfer policies       | 8      | Tight caps, or no transfer policy at all                    | Unlimited transfers hurt the score.                                     |
| Session liveness        | 5      | Validator says `Active` and hash matches                    | Expired/unknown states lose points.                                     |
| Signer reuse            | 2      | Unique signer per wallet/session                            | Reused signers for multiple wallets score zero.                         |
| Open session count      | 2      | ≤ 3 active sessions                                         | More than 3 drops to zero.                                              |

### Partial credit for approvals

* **Unset** spender in the registry ➝ partial credit (5/15) plus a warning.
* **Multi-spender allowlist** (small curated list) ➝ partial credit and a surfaced warning so reviewers notice multiple spenders.
* **Blocked or failed lookup** ➝ 0 points and the score is capped at 50.

### Hard gates ("caps")

* **Blocked registry policies** limit the overall score to 60 until removed.
* **Unsafe approvals** (spender not pinned, blocked, or lookup failed) limit the overall score to 50.

When a cap is active you'll see a badge such as `blockedRegistry` or `approvalSafetyHardGate` listed in the session detail.

### Severity mapping

Scores convert to severities using these bands:

| Score  | Severity   |
| ------ | ---------- |
| 90-100 | `Info`     |
| 75-89  | `Low`      |
| 50-74  | `Medium`   |
| 30-49  | `High`     |
| 0-29   | `Critical` |

The brand glow uses the worst severity detected so you always see the highest exposure immediately.

### Interpreting the breakdown

Inside each expanded session card you'll find:

* A per-dimension list (e.g. "Registry 12/15 - 2 Unset policies").
* Warnings for unset approval spenders, multi-allowlists, or missing constraints.
* Explorer shortcuts to review the relevant policy or transaction on abscan.

Focus on dimensions below \~50%; those usually offer the quickest wins to improve your score.

### How often the score updates

* Every time you open the popup or hit **Refresh**.
* Immediately after a revoke confirms (the session disappears or drops to 0).
* Periodically while the popup stays open, so expirations and limits stay fresh.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://penguards.zer0luck.kr/risk-insights.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.