I keep coming back to a simple question on days like this. If a price feed’s official support window closes, who is still asking that feed for a number that matters? Not in a slide deck. Not in an old integration page. In a live market that still has to decide what collateral is worth, or how a vault should be weighted. Today is that day on Solana. The stated technical support date has arrived, and the public record is messier than a headline wants it to be.
What Today’s Deadline Actually Changes
A company can stop supporting software and still leave traces everywhere. That is the awkward part. An announcement can deprecate implementations overnight and still leave onchain accounts sitting in programs that have not been touched in months. I have found that readers often treat a sunset date like a light switch. In practice it is closer to a notice pinned on a workshop door. The tools may keep turning for a while. They may not. You only know if you look at the workbench.
The wind-down message landed days earlier. Core development work was described as ending. Integrators were told to move. Other oracle names were offered as destinations. September 25 was framed as the last day of existing support. That is an operational milestone. It is not, by itself, proof that every feed froze at midnight. It is also not proof that every protocol once listed as a user still depends on that source today.
Perhaps the most interesting aspect is how quickly a customer logo becomes a risk story. A provider that sold feeds had every reason to name known users. Those names are historical claims. They are not a live inventory. If you want a serious answer to “who still relies on its prices,” you have to separate three layers of evidence and refuse to mash them together.
- A marketing or integration page that shows a relationship once existed
- Technical docs or code that show a program still knows how to read a feed type
- Live market configuration plus recent update history for that exact market
Only the third layer can support a claim that a named market still used the threatened feed on the deadline. Even then you need the fallback rule. A stopped primary source is not automatically a frozen market. Some designs keep moving with a backup weight or a second oracle path. Some do not. The difference is not academic. It is the difference between a paused borrow button and a reward split that quietly uses last-known assumptions.
A Listed Integration Is Not An Active Feed
On-demand oracles make this even slipperier. An application can create or call the data it needs. A price becomes available through accounts. Documentation can tell you that a protocol knows how to read a given feed. It may not tell you which option a particular bank currently selects. An SDK can support an oracle type long after the last reserve switches away. A website can change while a live account keeps the old address.
That is why I get uneasy when someone treats four famous names as one exposure bucket. One project may use a feed for a single market. Another may keep it as a fallback. A third may retain code after the live path already moved. The defensible unit of analysis is a specific market or vault and its configured feed at a specified time. Without that unit, “funds at risk” is just total value locked wearing a costume.
A count of feed accounts measures infrastructure. A count of configured markets measures dependency. A count of positions touching those markets measures economic exposure. Those three numbers are not interchangeable.
In my experience, people skip the middle number. They jump from a logo to a dollar figure. That leap feels decisive. It is usually sloppy. A feed can exist without an active borrower. A price can update without a consuming market. Dormant code can still mention a provider. None of that equals a live health check that still reads the sunset feed.
Two Protocols, Two Very Different Stories
Public pages for one restaking and tip-distribution design still describe the sunset oracle as a pricing source for vault weights. Assets in linked vaults are weighted with those prices. The same pages describe backup weights when feeds are unavailable. That is a real design, and it is a narrower job than people assume. Weighting vault assets for a distribution system is not the same job as marking collateral in a lending bank. Failure paths differ. Severity differs. A logo list pretends they do not.
Here is the catch. The overview that names the feed also carried a last-updated marker measured in months, not days, when checked against the deadline. Age changes the use of a document. It can show you where to look. It cannot prove the present program still points at the same accounts. Teams update onchain state without rewriting a page. Teams also leave pages untouched while the old path remains live. Both are possible. Without a current statement or a look at recent transactions, a named live dependency stays unverified.
Release notes in public code have mentioned retrying oracle gateways during keeper work. That is integration evidence. It is not a census of every vault that still carries value. Code keeps compatibility paths for a long time. The live question is smaller and harder. Do recent price updates still target an account used by a vault that matters? Does that account still advance after support ends?
Now flip to a major lending stack. Its oracle table can still list pull feeds and venue variants among supported setups. It can say a caller must crank a pull feed just before use. The same table can list push feeds and aggregated accounts as other options. A casual reader sees the old row and assumes every bank still uses it. The table is a menu. It is not tonight’s dinner ticket.
A September program note is more current and more useful. Developers were told to upgrade an SDK before an early-September date because banks would start moving to new oracle setups. The release added multiple variants that do not depend on the winding-down provider. Those paths include aggregator feeds and exchange-rate style pricing for certain liquid staking and principal tokens. The note does not claim every bank finished the move by today. It does show a public route away from the threatened dependency before the shutdown notice even landed.
The Quiet Second Failure Mode
Migrations have a habit of breaking the neighbor, not the patient. Older SDKs may fail to decode a bank configured with a new oracle enum value. One unsupported value can block client initialization and bank reads, not only an action on that single bank. Changing an oracle can fix an infrastructure dependency and, in the same breath, break an integrator who did not update software.
That warning is concrete. It is not evidence that any particular app already suffered it. It is evidence that “the feed is fine” and “the market is fine” can both be true while a dashboard still throws an error. If you are auditing this week, check software versions with the same seriousness you check oracle addresses. A failed transaction is not automatically an oracle outage. Sometimes it is a decoder that never learned the new enum.
Cross-venue margin makes the same point louder. Unified interfaces across several Solana lending and trading venues mean an oracle change has to be read correctly in more than one place. I would not claim an outage from that fact alone. I would claim that version drift is now part of oracle risk, whether people like that sentence or not.
Why An Aggregator Label Does Not End The Hunt
Some lending markets do not point at a single provider brand. They point at an onchain aggregator that copies values from multiple oracle accounts into one feed and validates updates under preset rules. A feed can support a large set of prices. The mapping between an index and a token pair may not live entirely onchain. A downstream program can point at the aggregator while the aggregator itself leans on other sources for the selected asset.
Seeing an aggregator in a bank configuration is a starting point. It is not the finish line. The September lending note lists aggregator setups among options that do not depend on the sunset provider for the new path it describes. That still does not mean every deployment on every date excludes every older source. Aggregators change inputs. A complete check needs the consumer’s selected account and the source mapping used to fill that entry.
New institutional vaults on the same broader lending ecosystem make the point in a different way. Fresh stablecoin vaults arriving in September show why naming an entire protocol as exposed is unsound. A cash-like vault, a liquid staking reserve, and a tokenized equity market can use different oracle paths. If those new vaults have not been verified against the sunset feed, they do not belong in a count of affected positions. Leave them out. Guessing is not analysis.
Trace order that actually holds up: 1. Consumer program and market address 2. Selected oracle type and account 3. Aggregator entry, if any 4. Underlying source for that entry 5. Latest successful update and max age 6. Fallback source and trigger 7. Value that actually depends on that price
What A Stale Price Can Do, And What It Cannot
Consequence depends on the consumer. A lending program generally needs a price to set collateral value and borrowing capacity. If it rejects an old value, an action may fail or a market may pause under its own rules. If it accepts stale data, a borrower might transact against a number that no longer matches the outside market. A fallback can keep the market open while changing the update rhythm or the confidence rule. Documentation plus onchain configuration decide which path applies. Analogies do not.
Pull feeds that must be cranked before use put work on the integrator. The transaction path has to carry a fresh update. Push feeds are kept current by other infrastructure. Aggregated accounts use a selected entry index. Moving between these types changes the extra accounts a transaction needs and the code that checks them. The SDK warning is one visible example of those changes reaching application software.
For vault weighting in a tip and restaking flow, public docs describe backup weights for unavailable feeds. Whether those backups keep reward allocation honest through a long outage is a live-config question, not a sentence you can settle from a paragraph written months ago. If independent operators keep a feed updating after the company stops support, no fallback may fire at once. If updates stop and the backup is active, operations may continue with a different method. Conditional paths. Not a prediction of the system’s present state.
An unrelated oracle incident elsewhere this month produced liquidations after a bad print. That story matters as a reminder that bad prices have economic teeth. It is not evidence of an incident here. A shutdown notice should not be turned into a liquidation claim by analogy. The sign of an actual event would be stale timestamps, failed settlement, a protocol pause, or identified losses. None of those has been verified against this deadline for the named designs above.
Faster slots can carry a new price sooner when one exists. They cannot invent a price when the node supplying it stops.
Solana’s move toward much tighter slot times changed how quickly blocks arrive. It did not guarantee that an external source still publishes. A protocol’s freshness test may be measured in slots, wall-clock time, or another rule. A change in network pace can change how developers interpret old feed configs. It does not rescue a dead publisher.
Who Actually Has To Move
The operator publishes or coordinates data. The consuming protocol chooses the account its program reads and the limits it places on that price. A lending market often needs governance or an admin to change oracle addresses. Front ends and third-party bots then have to build transactions with the right extra accounts. Users may only notice a rejected borrow or a paused market, long after the operator and the protocol already made their technical calls.
An operator ending support does not automatically rewrite a customer’s program configuration. That is why the notice urged users to migrate. Integration owners have to act. If a market already moved to another provider before the wind-down note, today’s support date has no direct effect on that market. If it still selects the old feed and has no working backup, the feed’s behavior after today is the concrete issue.
I’ve found that the strongest counter to panic is not “everything is fine.” It is “applications can design redundancy, and some already documented it.” A lending stack published new setups that do not need the sunset provider. A vault system documented backup weights. An on-demand model can also leave some infrastructure running through independent gateways even after a core contributor stops. The notice did not publish a verified halt schedule for every account. I have not seen primary evidence of a universal cutoff.
There is still a continuity problem for any protocol that built its own fallback. A backup price can prevent a full stop while pricing an asset less often or from a different set. For reward distribution, a temporary backup weight may keep epoch accounting moving while the allocation leans on the backup’s assumptions. For a lending market, the fallback can change the price inside a health check. Those are not claims about current settings at any named protocol. They are claims about what a maintainer should disclose before users can judge whether a migration is operationally complete, not merely whether transactions still land.
Delayed Breakage Is The Part People Underprice
A provider wind-down can look quiet on day one and messy on day twelve. Code written to request on-demand prices may succeed while an independent gateway answers, then fail when that gateway is retired or operators stop updating one asset. One successful transaction after the deadline does not prove continued service. You want several timestamps. The same discipline applies to a failed transaction. One user’s error may come from a stale SDK or missing accounts rather than a dead oracle.
There is a limit to the reassurance, and I would rather say that out loud. A fallback described nine months earlier needs validation against current state. A migration option described in September is not proof every bank took it. The documents give credible reasons not to assume catastrophe. They also leave a measurable gap. The fair conclusion is narrower than both the promotional version and the alarmist version. Public pages identify candidate dependencies and escape routes. A current market-by-market configuration audit is still required to establish remaining exposure.
| Evidence type | What it can show | What it cannot show |
| Provider user list | A relationship existed | Today’s live feed choice |
| Current technical docs | Supported types and fallbacks | Which market selected which type |
| SDK release notes | Migration paths and decoder breaks | That every bank finished moving |
| Old overview pages | Where to inspect next | Present onchain accounts |
| Live account state | Actual dependency and freshness | Nothing useful if you skip it |
The Inventory That Is Still Missing
Comparing an old four-name user list with current primary documents produces two verified documentary findings and one large absence. Vault-weighting docs still name the sunset oracle and a fallback for unavailable feeds, with an overview that is months old. A September lending upgrade describes multiple new setups independent of that oracle and warns about an SDK break if integrators stay on old versions. An aggregator repository explains why a brand on a consumer config cannot identify every upstream source.
That work does not produce a count of live unmigrated feeds. It does not produce user funds exposed. It does not produce an outage at any named protocol. Public pages do not contain a synchronized deadline snapshot of all oracle accounts, latest successful updates, fallback settings, and amounts supported by each market. Claiming a dollar total from protocol-wide deposits would be indefensible. Whole-protocol assets do not necessarily share one oracle.
A proper count uses the market as the row, not the protocol as the row. For each active lending bank, derivative market, or reward vault, record the program address, selected oracle type, oracle account, backup source if any, latest successful price update, maximum permitted age, and the value of positions that actually depend on that particular price. Duplicate markets that share one oracle account should not be counted as distinct feeds. One market using two independent oracles should not be counted as wholly dependent on either without reading fallback logic. The timestamp of the configuration matters because an admin can change a feed after you looked.
This method also explains why a true historical statement such as “this stack once supported hundreds of feeds” is not enough. Infrastructure is not dependency. Dependency is not exposure. If you collapse those words, you get a viral chart and a weak argument.
There is a further step when the source is an aggregator. The consumer may identify an aggregated account and an entry index. The mapping may point onward to one or more providers. An update in the aggregated account after today proves an aggregator produced a value. It does not prove the sunset oracle supplied the underlying price. You need the selected entry and source configuration for that update. Where token-pair labels are not fully stored onchain, external maintainer notes may be required. If that mapping is unavailable, record unknown. Do not silently attribute the print to the brand you hoped to confirm.
A Practical Watchlist For The Next Few Days
If you actually care about this, and not only about the headline, the work is unglamorous. Compare each active bank or vault’s configured feed with documented accounts tied to the sunset provider. Check whether an identified feed still publishes fresh values after today. Look at the source and freshness limit used if a primary feed falls behind. Watch recent program transactions. Did borrowing, settlement, or tip distribution still complete for that market? Look for a dated maintainer note that names a migration, a pause, or a remaining dependency, and that ties the claim to an account or program address.
- Write down the observation time. A screenshot without a slot or clock becomes stale fast.
- Record the market address before you record the brand name.
- Separate decoder errors from missing price updates.
- Treat fallback activation as its own event, not as “no impact.”
- Refuse protocol-wide dollar claims unless every market shares the feed.
The lending upgrade note said a bank using a new oracle enum can make an older SDK fail to initialize a client even if a user never touches that bank. The instruction to move to a newer SDK landed before the early-September migration start, weeks before the support deadline. That timing is useful. It suggests at least one large integrator treated vendor exit as an engineering calendar item, not a surprise fire drill. It still does not close the inventory gap.
Questions People Will Keep Asking Anyway
When did support end? The shutdown note arrived on September 19 and pointed to September 25 as the end of existing technical support. Implementations were described as deprecated immediately. That calendar is clear. The onchain consequence is not automatically clear.
Did every feed stop today? The support deadline alone does not establish that. You need current transaction and feed timestamps. I would not say they all stopped. I also would not say they all continued. Both sentences would be doing work the public record has not done.
Does the vault-weighting system still use the feed? Documentation still names it. The overview is old. Pages do not prove the live configuration on the deadline. That is an unsatisfying answer. It is also the honest one.
Did the lending stack leave the feed? The September upgrade documents new setups that do not depend on it and says banks began moving from early September. It does not state that every bank completed a migration. If someone tells you the whole protocol is clear, ask which banks they checked.
Why can a migration break an SDK? Older clients may not recognize new enum values. One bank configured with a new variant can make initialization fail. Newer SDK versions were published to handle those variants. This is unglamorous. It is also how a lot of “oracle incidents” start in support chats.
Is an aggregator independent of every external oracle? No. It aggregates values from other accounts. Its presence in a consumer config does not identify every upstream source without the entry mapping. If that sentence sounds picky, good. Picky is the job.
How can a user check a market? The market’s configured oracle account, latest update, and fallback settings beat a historical provider list every time. Protocol announcements help when they name a market and an address. Vague reassurance does not.
Have losses been verified from this shutdown? No losses at a named protocol were verified for this piece. An earlier incident at another venue cannot prove one occurred here. This is educational analysis, not a trading instruction.
What I Keep Telling Myself About Vendor Exits
Crypto has a habit of treating infrastructure brands like weather. Sunny until it is not. Then everyone wants a single number. How much TVL. How many liquidations. Which token dumped. Vendor exits rarely arrive as a single number. They arrive as a pile of configs that drifted at different speeds.
I do not find that comforting in a soft way. I find it clarifying. If you run a market, you own the account your program reads. If you build a bot, you own the SDK version and the extra accounts you pass. If you are a user, you own the habit of checking whether a paused market is a risk control or a neglected migration. None of that is glamorous. All of it is more useful than arguing about a logo.
There is also a cultural tell. Teams that publish migration enums, SDK floors, and fallback weights before a vendor posts a wind-down note are telling you they treat oracles as load-bearing. Teams that only update a homepage after the fact are telling you something else. I would rather read the first kind of document, even when it is dry. Dry documents age better than confident threads.
Will some feeds keep updating through independent operators? Maybe. On-demand designs make that possible. Will some markets discover this weekend that a crank path nobody exercised in weeks is now the only path? Also possible. The point of writing this on the deadline is not to call the ending. The point is to keep the question at the right resolution. Market, account, timestamp, fallback, value. Repeat until the story either appears or fails to appear.
If you only remember one thing, remember this. Today’s date ends official support. It does not, by itself, end every price. It also does not leave every historical user equally exposed. The live inventory is still the missing document. Until someone publishes that inventory with addresses and times, the honest headline stays slightly unfinished. Who still relies on those prices? The protocols that still point at them. The only way to name them with confidence is to look, market by market, after the clock has already moved.
