Overview
The Pendle PT implementation is made up of three independent Chainlink CRE workflows. They do not form one monolithic oracle: one workflow maintains a shared market observation, while two downstream workflows turn that observation into different Aave recommendations.
| Workflow | Responsibility | On-chain output | Protocol effect |
|---|---|---|---|
| Market state | Smooth the Pendle implied rate and pool proportion | One EmaImpliedRateUpdate in LlamaGuardOracle | None; this is input state for the other workflows |
| Discount rate | Keep the bounded PT adapter price aligned with the smoothed market signal | One PendleDiscountRateUpdate in RiskOracle | The configured discount-rate agent can update the PT adapter |
| Risk parameters | Recalculate Aave eMode LTV, liquidation threshold, and liquidation bonus | Zero or more EModeCategoryUpdate records in RiskOracle | The configured eMode agent can update eligible categories |
How they fit together
The market-state workflow publishes the common observation first. The discount-rate and risk-parameter workflows later read the latest finalized EmaImpliedRateUpdate from the configured write chain and preserve that update's ID and source-block provenance in their own records.
Because the workflows are independently scheduled, a downstream run may use the previous accepted EMA record while a newer EMA report is still in flight. Freshness checks make this explicit and prevent an old observation from being used indefinitely.
Common execution model
All three workflows:
- start from a deployment-owned six-field cron schedule;
- validate their deployment-owned JSON configuration with Zod;
- use the CRE consensus timestamp from
runtime.now()as the evaluation time; - read finalized EVM state;
- calculate a deterministic result; and
- either return without writing, fail closed, or submit a DON-signed report.
There is no canonical deployment target, schedule, address set, or gas limit. Those values belong to each deployment. Methodology parameters that must be governable across workflows—such as EMA span, freshness, model version, and discount deviation threshold—are read from PTParameterRegistry.
Two publication paths
The market-state workflow writes through the configured LlamaGuard receiver into LlamaGuardOracle. Its output is an observation only and does not call AgentHub or Aave.
The two recommendation workflows use the guarded execution path:
CRE report → LlamaguardRiskOracleRouter → RiskOracle → AgentHub → Aave agentBefore submitting a recommendation report, the workflow simulates the exact router call. A rejected simulation prevents the write. When a report is accepted on-chain, the router also enforces its registered workflow route, report ordering and age, throttles, and AgentHub wiring. The workflow therefore recommends a value; the contracts decide whether that recommendation is admissible and executable.
Submission is not finality
A successful CRE writeReport response means the transaction was included. The workflow does not immediately claim finality, because finalized reads can legitimately lag behind the submitted transaction.
Failure and skip behavior
Expected conditions such as a matured PT, a disabled market, a stale EMA, a minimum-delay gate, or a value inside its publication deadband return without a write. Invalid shared state, a failed required read, an invalid mathematical domain, or a rejected receiver execution fails closed.
The risk-parameter workflow has one additional isolation boundary: a shared snapshot failure stops the whole batch, but a target-specific eMode failure drops only that target so that other healthy targets can still be evaluated.