Architecture and safety

LlamaGuard Actions separates calculation, on-chain publication, and protocol execution. Implementations can use different data sources and methodologies while reusing the same trust boundaries and contract responsibilities.

The architecture has three stages, composed of four processing steps:

1. Calculate: a deterministic Chainlink CRE workflow reads finalized state and produces a candidate recommendation.
2. Authenticate and route: the CRE Forwarder, receiver, and router verify which workflow produced the report and where it may publish.
3. Store: an approved oracle records the typed recommendation and its provenance.
4. Use or execute: monitoring and governance can read the record, while an optional constrained agent may act on it.

Calculation boundary

Each implementation defines its required data sources, methodology, parameters, and trigger. A Chainlink CRE workflow reads the required state and calculates a deterministic candidate result.

Workflows are stateless between runs. If a model needs previous observations, accepted state is stored on-chain and read again by the next execution rather than kept in local process memory.

The model compiles to WASM and is deployed with a specific workflow identity. CRE nodes reach consensus on capability results and execute the same workflow before the DON produces a quorum-signed report. More about the workflow DON, capability calls, consensus, and report model here.

A changed workflow build or deployment configuration must be deployed and authorized under the identity expected by the route before its reports are accepted. The model author cannot silently replace authorized logic.

Publication boundary

AbstractCreReceiver verifies the identity attached to a DON-signed report. For each workflow ID it stores the expected Forwarder, author, workflow name, and active state. Only a report matching the complete registered identity reaches the router.

LlamaguardRiskOracleRouter maps an authenticated workflow to its publication route:

struct Route {
    address riskOracle;
    bytes4 publishSelector;
    address agentHub;
    uint256[] agentIds;
    bool enabled;
    uint64 minDelaySeconds;
    uint64 maxStepBps;
    uint64 maxReportAgeSeconds;
}

The route determines:

• the destination oracle and publication function;
• whether the route is active;
• which AgentHub and agents may be called after publication; and
• which timing, movement, and freshness limits apply.

The router tracks state by (workflow ID, market, update type) and can enforce minimum publication delays, maximum relative steps for scalar values, maximum report age, and strict ordering by signed consensus timestamp. An implementation may apply tighter checks inside its workflow, and an execution agent validates the value again before acting.

Typed oracle storage

The destination oracle authorizes publishers and update types, stores update history, and exposes the latest record by update type and market.

A record normally contains:

• the recommended value;
• an update-type identifier;
• the affected market or parameter key;
• a reference or model identifier; and
• implementation-specific provenance and audit context.

The router does not interpret implementation-specific payloads. It forwards the typed value and context defined by the implementation's schema, allowing the shared publication architecture to carry different kinds of risk recommendations.

Execution boundary

Publication does not require automated execution. Dashboards, monitoring systems, researchers, and governance can read the stored recommendation directly.

When execution is configured, the router calls AgentHub after publication. AgentHub coordinates typed agents that understand particular update types and can call only their configured protocol targets. Reusable validation modules can enforce directional ranges, while the agent can also check freshness, replay protection, minimum delays, and protocol-specific invariants.

The CRE workflow has no general permission to modify protocol state.

Safety controls

Controls are applied at several independent boundaries. Passing a workflow check does not bypass receiver authentication, oracle authorization, or the execution agent's validation.

Bounded recommendations

Each implementation defines its own safety envelope. It may include a maximum change per update, a minimum interval, upper and lower parameter bounds, a materiality threshold, or invariants between related values. The downstream agent applies compatible limits again when automated execution is enabled.

Traceable state

Published records should retain enough information to recover their source state and methodology version. Depending on the model, this can include source-chain block numbers, observation timestamps, market identifiers, reference IDs, and encoded calculation inputs.

Freshness is implementation-specific. A downstream workflow may need to check both when an upstream observation was created and the age of the source block behind it.

Fail-static behavior

If required data is missing, stale, invalid, or outside the supported domain, the system does not invent a replacement value. The last accepted recommendation and current protocol state remain unchanged.

This protects against bad publication, but an extended outage can leave parameters unchanged while the market keeps moving. Monitoring and an operational response process are therefore part of the safety model.

Failure boundaries

These boundaries keep a valid recommendation inspectable when optional execution is unavailable.

Roles and governance

The model author can publish code and propose configuration, while protocol governance controls which workflow identities, contracts, and execution paths are authorized. Production deployments should separate authority over:

• workflow identity and route creation;
• route enablement and throttle settings;
• oracle publisher and update-type permissions;
• agent registration and validation ranges;
• pause and emergency controls; and
• ownership or governance upgrades.

Changing workflow code and tuning an exposed parameter are different operations. Replacing compiled code requires a newly authorized deployment identity. A delegated updater may still change explicitly governed registry values or route settings without gaining permission to replace the workflow or call arbitrary protocol functions.

Each implementation documents its sources, calculations, parameters, update schemas, agents, roles, and production deployments. See the Pendle PT implementation.