Scheduled Update

Data is updated at fixed, predictable intervals (e.g., every block, every 5 minutes). This determinism allows smart contracts to rely on the update schedule, enabling features like time-weighted average prices (TWAPs) and reducing front-running opportunities compared to on-demand updates.

By batching updates for multiple assets into a single transaction, scheduled updates amortize gas costs across all users. This creates predictable operational expenses for oracle operators and minimizes the per-update cost for the network, making it economically viable for high-frequency data.

Updates are typically performed by a decentralized network of keepers or oracle nodes. These actors are incentivized to call the update function, often through a reward mechanism, ensuring liveness and censorship resistance without relying on a single centralized entity.

The scheduled interval acts as a heartbeat, providing a clear liveness guarantee. If an update is missed, protocols can implement circuit breakers or fallback logic. This is critical for risk management, as it defines the maximum acceptable data staleness.

Major decentralized exchanges like Uniswap use scheduled updates to publish time-weighted average prices (TWAPs) to a central oracle contract. This provides manipulation-resistant price feeds for lending protocols (e.g., Compound, Aave) to use for collateral valuation and liquidations.

Unlike pull oracles where data is fetched only when a contract requests it, scheduled updates use a push model. This trades potentially lower latency for higher reliability and cost structure, making it ideal for baseline reference data consumed by many contracts.

A scheduled update is a backward-compatible soft fork activated at a specific block. Unlike a hard fork, which creates a permanent chain split, a scheduled update requires all nodes to upgrade but does not invalidate previous blocks. This allows for smoother, coordinated upgrades like Ethereum's London (EIP-1559) or Bitcoin's Taproot activation.

Scheduled updates use precise activation triggers:

• Block Height: The upgrade activates at a specific block number (e.g., Bitcoin's Taproot at block 709,632).
• Timestamp: Activates at a specific Unix time, common in Proof-of-Stake chains.
• Miner/Validator Signaling: Nodes signal readiness before activation, creating a grace period for the network to reach consensus on the upgrade.

Implementing a scheduled update requires extensive off-chain coordination. Proposals are debated in forums, specified in EIPs (Ethereum) or BIPs (Bitcoin), and approved by core developers. Node operators, miners, and wallet providers must then deploy the new client software before the activation deadline to ensure network consensus.

Scheduled updates provide critical advantages for blockchain maintenance:

• Predictability: Developers and users know exactly when changes will occur.
• Reduced Risk: Coordinated activation minimizes the chance of accidental chain splits.
• Ecosystem Alignment: Exchanges, wallets, and dApps can prepare their infrastructure in advance, ensuring a seamless user experience.

• Ethereum London Upgrade: Activated at block 12,965,000, introducing EIP-1559's fee market change.
• Bitcoin Taproot: Activated at block 709,632, enhancing privacy and smart contract functionality.
• Cardano Vasil Hard Fork: A scheduled hard fork that upgraded the Plutus smart contract platform at epoch 365.

Node operators are the final arbiters of a scheduled update. They must download, verify, and run the updated client software. If a supermajority of hashing power or stake upgrades, the new rules are enforced. Operators who fail to upgrade are left on the obsolete chain, which typically becomes worthless, creating a strong economic incentive to participate.

A scheduled update's security depends on the governance process. Key risks include:

• Proposal spam that overwhelms voters.
• Vote buying or collusion to pass malicious code.
• Low voter turnout leading to minority decisions.
• Timelock circumvention if parameters are set incorrectly.

These can turn a routine upgrade into a takeover event.

Even well-intentioned code introduces risk. Security focuses on:

• Smart contract audits for the new upgrade logic.
• Formal verification of critical state changes.
• Integration testing with live forked networks.
• Grace periods and emergency stops to allow time for community review and a safe rollback if bugs are found post-deployment.

If nodes disagree on adopting the update, the network can fork. Mitigations include:

• Overwhelming consensus thresholds (e.g., 95%+ of validators).
• Long lead times for client software updates.
• Backward compatibility modes where possible.

A contentious hard fork, like Ethereum's DAO fork or Bitcoin's SegWit2x proposal, can permanently split the network and its security.

Updates often change network parameters (e.g., block size, gas costs, inflation rate). Incorrect settings can destabilize the system:

• Economic security loss from setting staking rewards too low.
• Network congestion from miscalculated gas limits.
• Unintended centralization due to new hardware requirements.

These require extensive modeling and often a trial period on a testnet.

The mechanism for activating the upgrade is a critical attack surface.

• Multisig controls for upgrade contracts should be time-locked and transparent.
• Social consensus must back the technical mechanism to avoid "code is law" failures.
• Validator/client coordination is essential to avoid nodes running incompatible versions, which can cause slashing or downtime.

Security vigilance must continue after the update goes live.

• Monitoring for anomalous activity like sudden changes in validator set or transaction patterns.
• Prepared incident response plans for quick reaction to exploits.
• Bug bounty programs specifically for the new code paths.
• On-chain metrics to track the health and security budget of the network under the new parameters.