LlamaRisk

PT architecture

The Pendle PT implementation follows the general risk-oracle lifecycle with three independent CRE workflows:

WorkflowStored updateIntended use or agent
Market stateEmaImpliedRateUpdate in LlamaGuardOracleDiscount-rate and risk-parameter workflows
Discount ratePendleDiscountRateUpdate in RiskOracleAaveDiscountRateAgent
Risk parametersEModeCategoryUpdate in RiskOracleAaveEModeAgent

It is one oracle implementation with three calculation paths, not three unrelated oracle products.

Shared market state

The market-state workflow reads finalized Pendle state and maintains exponential moving averages for:

  • the logarithmic implied rate; and
  • the PT share of the Pendle pool.

It publishes the accepted observation as EmaImpliedRateUpdate. This path does not call AgentHub or modify Aave.

The two recommendation workflows read the latest accepted EMA record from LlamaGuardOracle. They do not depend on local workflow memory or an EMA calculation running in the same schedule cycle.

Discount-rate path

Pendle EMA + live Aave PT adapter
  → discount-rate methodology and guards
  → PendleDiscountRateUpdate
  → RiskOracle
  → AgentHub
  → AaveDiscountRateAgent
  → PT price-cap adapter

The workflow recommends the next annual discount rate. If publication and AgentHub validation succeed, the agent resolves the active PT adapter through Aave's oracle configuration and applies the bounded scalar value.

Risk-parameter path

Pendle market + EMA + live adapter + current eMode state
  → collateral-risk methodology and per-target guards
  → EModeCategoryUpdate batch
  → RiskOracle
  → AgentHub
  → AaveEModeAgent
  → Aave eMode configuration

One run can include several eligible eMode categories. Each record contains the complete (LTV, liquidation threshold, liquidation bonus) tuple for one encoded eMode ID.

Preflight and execution boundary

The two executable recommendation workflows sign their payload with the CRE consensus timestamp and simulate the exact router receiver call before submitting it. Depending on simulation availability, the preflight can also verify the expected adapter or eMode post-state.

The router independently authenticates the workflow, enforces its route and replay controls, publishes to RiskOracle, and invokes AgentHub. The workflows themselves cannot call the adapter or Aave pool.

State observed again

An executed recommendation becomes ordinary protocol state:

  • a later discount run reads the adapter's active discount rate again; and
  • a later risk-parameter run reads current eMode LTV, LT, and LB again.

This feedback comes from finalized on-chain reads, not from an assumption that a previous recommendation executed successfully.

See CRE workflows for the full runtime paths and Architecture and safety for the reusable trust boundaries.

On this page