PT architecture
The Pendle PT implementation follows the general risk-oracle lifecycle with three independent CRE workflows:
| Workflow | Stored update | Intended use or agent |
|---|---|---|
| Market state | EmaImpliedRateUpdate in LlamaGuardOracle | Discount-rate and risk-parameter workflows |
| Discount rate | PendleDiscountRateUpdate in RiskOracle | AaveDiscountRateAgent |
| Risk parameters | EModeCategoryUpdate in RiskOracle | AaveEModeAgent |
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 adapterThe 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 configurationOne 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.