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 (aDIAOracleV3 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 theOracleIntentRegistry, 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
InsidegetGuardedValue(), 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: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.
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 isOwnable. 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.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.