Risk-parameter workflow

The pendle_risk_parameters_oracle workflow calculates Aave eMode loan-to-value (LTV), liquidation threshold (LT), and liquidation bonus (LB) recommendations. It evaluates each eligible eMode independently and publishes the changed, admissible targets together in one bulk report.

Target selection

Two configurations define the evaluation set:

• PTParameterRegistry supplies the governed list of eMode category IDs for the PT.
• Deployment-owned targets[] supplies the methodology definition for each supported category, including its LT cap and LB floor.

The workflow evaluates the intersection. A registry category without a matching target definition is skipped with a warning; a deployment target absent from the registry is not evaluated.

Consistent finalized snapshot

The workflow pins one finalized block per chain and groups reads into Multicall3 layers. Every source-chain call uses the same source block, and every control-chain call uses the same write-chain block. If both roles use one chain, they share the pinned block.

The shared snapshot contains:

• Pendle market tokens, balances, scalarRoot, logarithmic implied rate, and expiry;
• the SY exchange rate and stored PY index used to calculate market proportion;
• the PT registry entry and latest EMA record;
• the live Aave PT adapter address, discount rates, and maturity;
• current LTV, LT, and LB for each configured eMode;
• the router route and per-target publication timestamps;
• AgentHub registration, enablement, delay, and last-injection state; and
• per-market or default LT, LTV, and LB ranges from RangeValidationModule.

Shared required-read failures stop the run. Optional target-local failures mark only that eMode as ineligible.

Global gates

The whole run returns without a write when:

1. the Pendle market has matured;
2. the registry entry is disabled; or
3. the EMA observation time or its source block is older than emaFreshnessSeconds.

Before evaluating targets, the workflow also verifies that the router route is enabled and points to the configured RiskOracle, bulk-publish selector, and AgentHub. A route mismatch stops the entire batch.

Per-target calculation

For each eligible eMode category, the workflow:

1. verifies that its snapshot reads succeeded;
2. enforces the router's per-target minimum publication delay;
3. requires a registered, enabled AgentHub agent and range-validation module;
4. loads non-zero directional ranges for LTV, LT, and LB;
5. applies the collateral-risk methodology to the shared EMA, Pendle curve state, adapter state, and target caps/floors;
6. bounds the proposed movement; and
7. applies the deployment's LT, LTV, and LB publication deadbands.

AgentHub's minimum delay is checked against the last successful injection for that eMode. This is separate from the router's last-publication delay; both must pass.

Movement and invariant handling

LT and LB are clamped independently using their active directional range allowances. The allowances may be absolute or relative on-chain; the workflow converts them into absolute basis-point limits for the current value.

LTV is then derived from the bounded LT:

LTV = max(LT - 200 bps, 0)

It is not independently clamped, because that would break the fixed LT/LTV relationship. Instead, the derived LTV must fit its own active directional range or the target is dropped as ltvRangeRejected.

Independent LT and LB clamps can violate Aave's joint constraint:

LT × (10,000 + LB) ≤ 10,000²

When necessary, the workflow fits the pair back into this invariant while respecting the movement envelope, then derives LTV again. It also verifies LTV ≤ LT ≤ 10,000 and the valid integer domains before building an update.

Publication deadband

The deployment defines separate relative deviation thresholds for LT, LTV, and LB. The deadband is measured from current state to the unclamped methodology target, not merely to this run's step-limited value.

This allows a large model divergence to keep moving on-chain parameters toward the target one bounded step at a time. If the deadband were measured only after clamping, a threshold larger than the maximum step could suppress every run permanently. When any parameter meets its threshold and the bounded tuple actually changes state, the full (LTV, LT, LB) tuple is eligible for publication.

Batch construction

A per-target calculation, guard-read, or payload-build failure drops that target and leaves the others intact. If no targets remain, the workflow returns a structured no-write summary.

Every included target becomes one EModeCategoryUpdate:

All included records are encoded into one bulk report. Before submission, the workflow simulates the exact router call and expects getEModeCategoryCollateralConfig() to return each proposed tuple after execution. A rejected simulation prevents the entire batch write.

On successful delivery, the router publishes the records to RiskOracle and can invoke the configured Aave eMode agent through AgentHub. The workflow itself never calls the Aave pool.