Methodology Registry

The core logic for calculating a metric—such as a Total Value Locked (TVL) formula or a risk score algorithm—is deployed as immutable smart contract code. This creates a permanent, verifiable record of the methodology's rules. Each update is deployed as a new version, creating a complete, auditable history of changes. This prevents retroactive manipulation and allows users to verify which version was used for any historical calculation.

Each registered methodology includes structured metadata that defines its purpose, inputs, and configurable parameters. This typically includes:

• Name and description of the metric.
• Required input data sources (e.g., specific oracle feeds, on-chain contract states).
• Adjustable parameters (e.g., lookback periods, weighting schemes) that can be tuned without changing core logic.
• The output data type (e.g., integer, decimal, score range). This standardization enables automated discovery and interoperability between different systems.

Changes to a methodology's logic or parameters are not controlled by a single entity. Instead, upgrades are governed through a decentralized autonomous organization (DAO) or a multi-signature wallet. Proposal and voting mechanisms ensure that updates reflect community consensus, enhancing the system's credibility and resistance to capture. This governance layer is critical for maintaining the methodology's integrity as market conditions and data needs evolve.

Every calculation performed using a registered methodology can be traced back to its exact source code version and input data. This creates a complete audit trail. Analysts and auditors can independently re-execute the logic with the same historical inputs to verify the output. This feature is fundamental for regulatory compliance, risk management, and building trust in derived data like credit scores or collateralization ratios.

Because methodologies are standardized on-chain primitives, their outputs can be securely used as inputs for other protocols. For example, a lending protocol can trustlessly integrate a registered health factor calculation. A derivatives platform can build a product based on a registered volatility index. This composability eliminates redundant logic development and creates a network effect where verified methodologies become foundational building blocks for DeFi and beyond.

The Methodology Registry stores data computation logic as immutable smart contract code or hashed specifications on-chain. This creates a permanent, tamper-proof audit trail for all data feeds. Any changes or upgrades to a methodology require a new on-chain registration, allowing analysts to verify the exact logic used for any historical data point and detect unauthorized modifications.

To prevent centralized control and unilateral changes, methodology upgrades are typically governed by a decentralized autonomous organization (DAO) or a multi-signature wallet. This process involves:

• Proposal and Voting: Stakeholders or token holders vote on proposed methodology changes.
• Timelocks: Enforced delays between proposal approval and execution, allowing users to react.
• Grace Periods: A window where data consumers can migrate to new methodologies before old ones are deprecated.

Each registered methodology must explicitly declare its data sources (e.g., specific API endpoints, on-chain pools) and aggregation logic (e.g., median, TWAP). This transparency allows for independent verification of the data's origin and the computation's correctness. It mitigates risks like single point of failure in a source or hidden biases in the aggregation method.

Registries integrated with oracle networks often implement slashing mechanisms to penalize nodes that deviate from the registered methodology. This aligns economic incentives with honest reporting. Security is enforced through:

• Bonding: Node operators stake collateral (e.g., tokens).
• Fault Proofs: Provable deviations from the methodology trigger slashing.
• Reputation Systems: Performance history affects future rewards and responsibilities.

Robust registries define failure modes and fallback procedures within the methodology specification itself. This includes:

• Heartbeat Monitoring: Detection of stale or frozen data.
• Deviation Thresholds: Automatic triggers if reported data deviates beyond a predefined bound from other sources.
• Backup Methodology Activation: A secure process to switch to a pre-approved, simpler calculation method (e.g., falling back to a single trusted source) during emergencies.

While the registry itself is typically permissionless to read, write access for registering or updating methodologies is strictly controlled. Role-based access control (RBAC) is implemented at the smart contract level to define who can propose (e.g., whitelisted addresses), approve (e.g., governance contract), and execute changes. This prevents spam and unauthorized registry pollution.

A Data Feed is the live, on-chain data stream produced by applying a registered methodology to source data. It is the final, consumable output for smart contracts.

• Composition: A feed aggregates data from multiple sources (e.g., exchanges) using a defined aggregation logic.
• Key Property: Feeds are tamper-resistant and updated at regular intervals or upon significant price deviation.
• Example: The ETH/USD price on a specific blockchain, updated every 10 seconds.

An Oracle Network is the decentralized infrastructure of nodes responsible for executing methodologies, sourcing data, and submitting attested results on-chain.

• Role: It provides the security, redundancy, and liveness guarantees for the data feeds.
• Execution Layer: The network's nodes fetch raw data, run the computation defined in the methodology, reach consensus on the result, and broadcast the final value.
• Examples: Chainlink Decentralized Oracle Networks (DONs), Pyth Network's publisher network.

An Attestation is a cryptographically signed proof from an oracle node or network that a specific data point is correct according to the agreed-upon methodology.

• Function: It provides cryptographic accountability. The signature can be verified on-chain to prove the data originated from an authorized node.
• On-Chain Format: Often takes the form of a signed transaction or a signature in a data payload.
• Security: Enables slashing mechanisms if a node attests to incorrect data, backing the system's security with economic stakes.

The Aggregation Function is the specific algorithm within a methodology that combines multiple source data points into a single, canonical value for the feed.

• Purpose: To mitigate outliers, manipulation on a single source, and provide a robust median or volume-weighted average.
• Common Types: Median, Time-Weighted Average Price (TWAP), Volume-Weighted Average Price (VWAP).
• Example: A methodology may specify: "Take the median price from sources A, B, and C, discarding outliers beyond 2 standard deviations."

A Data Source is an individual, off-chain origin of raw data that is fetched and used as input for a methodology.

• Types: Can be centralized exchanges (CEXs), decentralized exchanges (DEXs), APIs from traditional finance institutions, or other real-world data providers.
• Redundancy: Methodologies typically specify multiple, independent sources to prevent a single point of failure.
• Verification: Oracle nodes must cryptographically verify the authenticity of data received from a source (e.g., via TLS notarization).

Upkeep refers to the automated, periodic execution of a methodology by the oracle network, while a Heartbeat is a regular update that confirms liveness.

• Upkeep Cycle: The scheduled process where nodes collect data, compute the result, and submit it on-chain, ensuring the feed is fresh.
• Heartbeat Update: A transaction submitted at a fixed interval (e.g., every hour) even if the price hasn't changed, proving the oracle is active and monitoring.
• Deviation Threshold: Many feeds also update when the price moves beyond a predefined percentage, ensuring accuracy during volatility.