> ## Documentation Index
> Fetch the complete documentation index at: https://www.diadata.org/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Guardian (Validation Layer)
The Guardian is a validation layer that protects a feed at its source, before any price is attested and propagated to destination chains. It is implemented by the `DIAOracleV2Guardian` contract, which sits in front of a base DIA oracle and returns a price only when a configurable number of independent guardians corroborate it, within the deviation and freshness bounds set for that read. The Guardian is enabled per asset. When it is enabled for an asset, every destination oracle receives the Guardian-protected value for that asset, because the check happens once, at the source, on the value that gets attested.
## Key components
The Guardian is made up of three parts. The base oracle is the underlying DIA feed being validated, typically the Meta Oracle (a `DIAOracleV3` meta-contract that aggregates the individual feeds), referenced on the Guardian by `baseDIAContractAddress`. The guardians are a set of independent addresses registered on the contract, each associated with its own reference value for an asset, which the contract resolves through an asset registry set as `assetRegistryAddress`. The guarded read is the `getGuardedValue()` entrypoint, which compares the base value against the guardian values and applies deviation, freshness, and corroboration checks before returning a result.
## How it works
The Guardian is read as part of the attestation flow that feeds destination oracles.
When the Guardian is not enabled for an asset, the Attestor reads the latest price directly from the Meta Oracle, signs (attests) it, and submits the signed price to the `OracleIntentRegistry`, from where the destination oracles consume it.
When the Guardian is enabled for an asset, the Attestor reads the price from the `DIAOracleV2Guardian` contract instead of the Meta Oracle. The Guardian internally reads the price from its configured base contract (typically the Meta Oracle) and evaluates it against its validation rules. If the Guardian is not triggered, it returns the price, the Attestor signs it, and the signed price is submitted to the `OracleIntentRegistry` as normal. If the Guardian is triggered, it returns no price, so the Attestor produces no attestation and no new price propagates to the destination oracles, which keep their last attested value until a valid price is available again.
### Validation logic
Inside `getGuardedValue()`, the contract reads the value for the requested key (for example `BTC/USD`) from the base oracle, and the corresponding value from each registered guardian, resolved through the asset registry. For each guardian, the internal `guardianDiffBips()` helper measures how far the guardian value deviates from the base value, expressed in basis points. A guardian counts as a match when its value is within `maxDeviationBips` of the base value, and values older than `maxTimestampAge` are treated as stale and excluded. The read passes only when the number of matching guardians is at least `numMinGuardianMatches`. If that threshold is met the contract returns the value and its timestamp, and if it is not met the Guardian is considered triggered and returns no price, represented as `(0, 0)`.
## Guard parameters
The guarded read is parameterized per call, so each asset can be protected with its own deviation, freshness, and corroboration thresholds:
```text theme={"system"}
function getGuardedValue(
string memory key,
uint256 maxDeviationBips,
uint256 maxTimestampAge,
uint256 numMinGuardianMatches
) external view returns (uint128 value, uint128 timestamp);
```
The three bounds are supplied by the caller, in practice the Attestor, typically from per-asset configuration:
* `maxDeviationBips`: the maximum allowed deviation between the base value and a guardian value, in basis points, where 10000 equals 100%, so 500 equals 5%.
* `maxTimestampAge`: the maximum age, in seconds, before a value is treated as stale and ignored.
* `numMinGuardianMatches`: the minimum number of guardians that must corroborate the value for the read to succeed.
When the check fails, `getGuardedValue()` returns `(0, 0)`, and it does not revert. This is intentional, because a revert would fail the caller rather than signal a controlled outcome. A (`0, 0)` result is the trigger signal: the Attestor treats it as an absence of a valid price and withholds attestation, so a faulty or stale value is never propagated rather than being surfaced as a real price.
## Roles
The Guardian is `Ownable`. The owner configures the contract, manages the guardian set, and can repoint the contract at a different base oracle with `changeBaseDIAContract()` or a different registry with `changeAssetRegistry()`. Guardians are the independent addresses whose values are used for cross-checking, and they do not administer the contract.
## Registering and removing guardians
The owner curates the set of guardians that participate in validation. `addGuardian()` registers a guardian address together with a human-readable name, and a given address can only be added once. `removeGuardian()` removes a guardian from the active set, after which subsequent reads no longer consider that guardian. The current set can be inspected through the `activeGuardians` list and the `guardianNames` mapping, and a `GuardianAdded` or `GuardianRemoved` event is emitted on each change.
## Value format
As with other feeds in the DIA stack, the guarded value is a USD price with 18 decimals, returned alongside the UNIX timestamp of the value.
You can find all of the deployed contracts on Lasernet for Lumina components [here](https://www.diadata.org/docs/guides/dia-deployments).
## Key Benefits
**Independent validation.**
Feeds are cross-checked against a curated set of independent guardians, so a single faulty, stale, or manipulated value cannot be attested on its own.
**Protection at the source.**
Because the check runs on the value before it is attested, enabling the Guardian for an asset protects every destination oracle at once, with no per-chain integration required.
**Configurable safeguards.**
Deviation, freshness, and corroboration thresholds are set per asset, letting protection be tuned to each feed's risk profile without changing the guardian set.