How it works
LlamaGuard Actions separates risk calculation, recommendation publication, and protocol execution. This shared lifecycle applies even when individual implementations use different data sources, methodologies, schedules, and execution modules.
The shared lifecycle
1. Observe finalized state
An implementation reads the market, protocol, and configuration data required by its methodology. Source identifiers, block numbers, and timestamps can be retained so the resulting recommendation can be traced back to its inputs.
2. Evaluate a documented methodology
A deterministic workflow converts the observed state into a candidate recommendation. The model and its configuration are specific to the oracle family: a supply-cap oracle, for example, would not use the same inputs or equations as a collateral-risk oracle.
The workflow compiles to WASM for execution in Chainlink CRE. Before it can publish, the candidate must pass the implementation's source-freshness, timing, deviation, and movement checks. An ineligible evaluation completes without a new value.
3. Publish and store
Chainlink CRE DON nodes execute the same workflow against the same agreed capability results. A report is produced only after the network reaches consensus, and the on-chain Forwarder verifies the quorum-signed report. The receiver then verifies the expected Forwarder and complete workflow identity before routing it to an approved oracle contract.
The oracle records a specific update type rather than an unstructured message. Its value, market key, model or reference identifier, and additional audit context give monitoring systems, governance, and execution agents a stable interface.
4. Use or execute
The record may be used for monitoring, governance, or automation. An automated agent independently checks freshness, replay protection, timing, ranges, and protocol-specific constraints before it changes protocol state.
Verifiable off-chain computation
CRE moves the deterministic calculation off-chain without turning it into an opaque operational service. A protocol can authorize an exact workflow identity in the same way it authorizes an on-chain integration.
The model author cannot silently replace an authorized workflow. A changed build or deployment configuration must be deployed and authorized under the identity expected by the route before its reports are accepted. Separately delegated updater roles may still tune explicitly governed registry or route parameters within their defined permissions.
Publication and execution
The on-chain recommendation is the primary output of LlamaGuard Actions. It can exist without an automated executor and can be reviewed or consumed by several systems.
When an execution path is configured, it sits downstream of publication. A valid record remains available if the agent has no eligible action or if execution fails. The workflow itself does not receive unrestricted permission to modify the target protocol.
Fail-static behavior
An evaluation can succeed without producing an on-chain update. If required data is missing, stale, outside the methodology's domain, or insufficiently different from the latest value, the oracle publishes nothing. The last accepted value remains in place until another eligible recommendation is produced.
Fail-static behavior prevents the system from inventing a value under uncertainty. It also means monitoring and operational response remain important: a prolonged lack of updates may require investigation even though no invalid value was published.
Each implementation supplies its own sources, methodology, update schemas, schedule, publication checks, and optional execution modules. See the Pendle PT implementation for a system built on this lifecycle.