Blockchain markets run around the clock, but the assets many of them track do not. Stock exchanges close at night, on weekends, and on holidays, leaving on-chain applications without a reliable price.
Until now, protocols had a few poor options: freeze markets, rely on the last known price, or build their own valuation tools. Chainlink 24/7 aims to remove that problem by supplying one continuous price series per asset.
How Chainlink 24/7 WorksThe service blends two sources. When traditional markets are open, it uses prices from regular and extended sessions. When they shut, it switches to an off-hours reference built from perpetual futures quotes.
Chainlink says the system pulls quotes from multiple futures venues, removes stale inputs and limits the influence of outliers. Importantly, the weekend price reflects derivatives trading rather than actual transactions on closed exchanges.
Lending protocols can read prices published directly onchain through Data Feeds. Trading platforms and prediction markets can use Data Streams for faster updates, which also flag the current market session so apps can adjust risk settings.
Aave Horizon Adopts the FeedsAave is the launch partner, integrating the feeds into Horizon, its lending platform for institutions. Horizon lets qualified investors borrow against tokenized assets, and the rollout begins with tokenized versions of heavily traded US stocks.
Reliable weekend prices matter for lenders because collateral values need to stay current to manage liquidation risk, even when stock exchanges are offline.
Building on Earlier Pricing ProductsThe launch follows Chainlink’s January debut of 24/5 pricing for US stocks and ETFs, which covered pre-market, regular, post-market and overnight sessions. The company says that weekday infrastructure now supports over $1.6 billion in tokenized stocks.
With the new weekend layer, Chainlink is moving toward full-time coverage as tokenized equities and other real-world assets continue to expand onchain.
Aave Labs has clarified that its proposed V3.8 security upgrade would preserve flash-loan liquidations. The October 23 response addresses how a reentrancy guard would interact with existing integrations.
TL;DR: Aave’s proposed V3.8 guard excludes flash-loan entry points. Governance approval and security audits remain pending.
The proposal, posted October 21, adds a guard to Pool operations. Such guards constrain the ability of an external callback to enter protected contract functions again before an earlier call finishes. Aave Labs says flashLoan() and flashLoanSimple() would be excluded, allowing their callbacks to keep invoking Pool actions, including liquidations.
A smart contract receiving a flash loan needs time within the transaction to do something with the borrowed assets. Aave’s developer guide describes a sequence in which the Pool transfers assets, calls the receiver contract and then checks settlement conditions.
For a simple flash loan, the receiver must make the amount borrowed plus the required fee available for repayment. If the transaction cannot meet its conditions, it reverts. The broader flash-loan interface can cover multiple assets and, under permitted conditions, open a collateral-backed debt position.
Those mechanics explain why the scope of a guard matters. A liquidation integration may need to borrow an asset, repay an unhealthy position and complete the rest of its transaction before settlement. Blocking every subsequent Pool interaction indiscriminately would interfere with that sequence.
The important design question is which routes back into the protocol are intentional. A useful security boundary must account for the transaction patterns that integrations depend on, including calls that occur after assets have left the Pool but before repayment is checked.
The proposed implementation uses transient storage introduced through Ethereum’s EIP-1153. That storage remains available during a transaction and is discarded when the transaction ends. It can therefore carry temporary lock state to track whether a protected operation is already running.
The specification identifies reentrancy locks as a use case and explains why transient storage can cost less than writing temporary state to permanent storage. For a heavily used DeFi protocol, the design question includes the cost imposed on ordinary transactions as well as the protection added by the guard.
Aave’s proposed path includes feedback, a Snapshot vote, security review and an on-chain improvement proposal. Certora and additional reviewers are expected to assess the changes before that final step.
For integrators on Ethereum and other affected networks, the clarification provides a concrete compatibility point to check against the eventual code. The reviewed implementation must preserve the intended transaction sequence while enforcing the new boundary. A statement of design intent is useful during that work; deployed behavior will depend on the implementation governance ultimately accepts.
Written by the News Desk and edited by Samuel Rae.
Aave’s first externally curated V4 markets are live on Ethereum, according to Sentora’s October 22 launch explanation. The curator says it is managing active borrowing markets for RLUSD, PYUSD and OUSD within a governance-approved deployment.
TL;DR: Aave’s first externally curated V4 markets are live on Ethereum with Sentora managing strategy and risk settings. Borrowing options include RLUSD, PYUSD and OUSD.
Sentora manages collateral rules, risk parameters, interest-rate curves and oracle configurations. Those responsibilities put practical decisions about lending conditions with an outside specialist while retaining the framework of Aave governance.
Aave V4 divides the system between hubs and spokes. The protocol’s liquidity documentation describes a hub as the central settlement and accounting layer holding assets. Spokes are specialized smart contracts through which users interact with a market’s collateral, borrowing and liquidation logic.
This arrangement lets different markets draw on an underlying liquidity pool while applying different conditions. Governance controls how much capacity a spoke receives. Credit limits constrain borrowing, and supply limits constrain additions, giving the system ways to limit activity without requiring every market to use the same collateral policy.
For a borrower, that makes the identity of the market relevant. Two markets built on the same protocol can offer different assets, borrowing capacity and liquidation conditions. A shared brand or common liquidity source alone does not establish that their positions will behave alike during a sharp market move.
For suppliers, the practical comparison is between the income offered and the market rules that produce it. A higher rate can be attractive, but it also makes it important to inspect which borrowers can access the liquidity and what happens if collateral values deteriorate.
Sentora has also extended its Risk Radar to cover the V4 structure. The monitoring system separates hub, spoke and asset views, with tools for comparing caps against usage and showing where borrowing is concentrated. A governance tracker records changes to assets and parameters.
The company gives a practical example of how a limit works: a spoke that reaches its borrowing cap cannot draw additional funds until capacity becomes available through repayment or an approved increase. That restriction is relevant even when users can see liquidity elsewhere in the wider system.
For DeFi users assessing the new markets, the launch creates another set of decisions to examine. The curator’s collateral choices matter alongside the protocol’s contract design; the market’s allocated capacity matters alongside the total liquidity headline. Monitoring can make those differences visible, although a dashboard cannot remove losses from an unsuitable collateral policy.
The first rollout provides a live test of that division of responsibility: Sentora sets market strategy, Aave supplies the lending framework, and governance determines the boundaries within which the markets operate.
Written by the News Desk and edited by Samuel Rae.
Login