On August 26, Pyth Core introduced a major infrastructure upgrade. The new architecture preserves compatibility at the Hermes API and on-chain ABI layers, but the underlying verification model changes significantly: the previous path relied on Pythnet and a 13-of-19 Wormhole Guardian signature threshold, while the new design uses five independent routers with a 3-of-5 quorum.
From an application developer’s perspective, this may look like a relatively smooth infrastructure migration. At MoveBit, we think the more interesting security question is not whether the new Pyth Core remains API-compatible, but whether the protocol consuming it still operates under the same trust assumptions.
From a security perspective, however, it exposes a much deeper issue:
Stable ABI does not imply a stable trust boundary.
The interface may remain unchanged. Consumer code may not change at all. Yet the answer to a much more important question—why should this price be trusted?—has changed.
For Sui protocols that depend on external oracles, the security boundary therefore cannot stop at get_price(), freshness checks, or confidence intervals. It also has to include oracle versions, verification paths, package identity, and dependency lifecycle.
We can describe this class of dependency as Oracle Version Coupling.
1. Same ABI, Different Trust Root
Dependency reviews often treat compatibility and security compatibility as roughly the same thing.
If an upgrade preserves function signatures, keeps the ABI compatible, leaves price feed IDs unchanged, and requires no modification to consumer logic, engineers may reasonably conclude that migration risk is limited.
But the Pyth Core upgrade shows why that assumption is incomplete.
The previous trust path can be simplified as:
Pythnet → Wormhole Guardians 13 / 19 signatures → Pyth Core → Consumer
The new architecture instead looks more like:
5 Independent Routers → 3 / 5 quorum → Pyth Core → Consumer
From the consumer’s point of view, the same price feed may still arrive through an almost identical interface. Yet the security assumptions behind that price have changed.
So an oracle upgrade review should not stop at:
ABI Diff
API Diff
Storage Diff
It should also include:
Trust-Root Diff
Security reviewers should ask: Who now produces the data? Who can attest to it? What quorum is sufficient? What exactly does the verifier prove? Which failure assumptions changed between versions?
API compatibility tells us whether the system can still be called. Trust-root compatibility tells us whether we can still trust the result for the same reasons.
Those are fundamentally different questions.
2. On Sui, Package Identity Becomes Part of Security State
The Pyth migration is particularly interesting on Sui because consumers reference concrete package identities rather than an abstract upgradeable endpoint that can always be switched transparently on their behalf.
A simplified dependency chain looks like this:
Hermes → Price Payload → Pyth Package → Pyth State → Consumer
Under stable conditions:
Old Hermes × Old Verifier ✓
New Hermes × New Verifier ✓
But during migration, a combination such as:
New Hermes × Old Verifier ✕
may fail.
Nothing has necessarily been compromised. There is no forged price, no signature bypass, and no corrupted state.
Instead, the system enters a more subtle failure mode:
Version-valid components can still form an invalid system state.
This is why a package ID should not be treated as mere deployment metadata when critical financial operations depend on it.
If borrow, liquidate, redeem, or settle depends on a specific external package, then the identity and lifecycle of that package have effectively become part of the protocol’s runtime security state.
That is the practical significance of Oracle Version Coupling.
3. A Dependency Does Not Need Your UpgradeCap to Affect Your Critical Path
Traditional access-control reviews focus on capabilities such as:
UpgradeCap AdminCap PauseCap TreasuryCap
The goal is to answer a familiar question:
Who can change the protocol?
But external dependencies create another control plane that may not appear anywhere in the protocol’s own authority graph.
Consider a lending protocol that directly binds liquidation logic to a particular Pyth package:
Pyth does not hold the lending protocol’s UpgradeCap. It cannot modify the lending code
Yet if the Pyth package lifecycle changes in a way that makes this historical call path unusable, liquidation may still stop working.
This leads to a more useful security observation:
A dependency does not need your UpgradeCap to change the reachability of your critical state transitions.
The right concept here is not “external upgrade authority” in the strict capability sense. It is Dependency-Controlled Availability.
And that dependency can expand the protocol’s real:
Effective Upgrade Surface
The protocol’s visible authority graph may look like:
Protocol Admin → Protocol Upgrade
But the operational reality may be closer to:
This is also why hard-coding a specific oracle implementation inside core business logic is fragile.
A better pattern is to keep verification at the transaction-construction layer—for example, inside a Programmable Transaction Block—using the currently valid verifier, and let the protocol consume the resulting verified state:
The protocol should ideally depend on the semantic statement:
“This price has been validly verified.”
rather than:
“This price must be verified by Verifier V1.”
A useful design principle here is:
Pin semantics, not implementations.
This does not eliminate dependency risk, but it prevents implementation identity from being unnecessarily embedded into core financial logic.
This is why MoveBit’s review of oracle-dependent Sui protocols goes beyond price correctness and contract-level integration. The dependency graph itself—package identity, verification assumptions, migration states, and critical-path availability—needs to be treated as part of the protocol’s attack surface.
4. Oracle Upgrades Should Be Audited as Distributed State Transitions
Once we accept this model, an oracle upgrade can no longer be reviewed as a simple transition from one package to another:
Old Package → New Package
The real dependency graph is broader:
Data Infrastructure → Hermes → Signed Payload → Verification Package → State Object → Consumer Protocol
This exposes another important distinction:
Blockchain atomicity ends at the transaction boundary; oracle atomicity extends across the dependency graph.
A PTB can execute atomically. But an oracle migration may also involve backend deployment, SDK upgrades, endpoint switching, package migration, state-object updates, and consumer configuration. Those operations do not automatically share the same atomic boundary.
That means the most important security target is often not the state before or after the upgrade, but the states in between.
A focused review should cover three areas.
Trust-Root Diff: Did the signer set, quorum, verification assumptions, or failure model change?
Dependency-Identity Diff: Does critical business logic directly depend on a package identity that can become obsolete?
Migration-State Testing: What happens under mismatched combinations such as New Data × Old Verifier or Old Data × New Verifier? Does the protocol fail closed, fail open, continue consuming stale data, or recover safely?
For lending and perpetual protocols, this matters especially because a version mismatch may begin as an availability problem but later become an economic one if stale prices remain usable or liquidations stop executing.
The security target should therefore be:
Before Upgrade ✓
During Upgrade ✓
After Upgrade ✓
—not merely proving that the two stable endpoints work.
5. Practical Recommendations
For Sui protocols that depend on upgradeable oracles, a few implementation principles can materially reduce version coupling.
First, separate verification from consumption. Keep the specific verifier implementation outside core financial logic where possible, and let the protocol consume verified price state rather than a hard-coded package call.
Second, design a degraded mode for oracle failures. If verification becomes unavailable, the protocol should generally block risk-increasing actions such as new borrowing or leverage while still allowing risk-reducing actions such as repayment or adding collateral.
Third, test migration intermediates explicitly. Do not validate only the pre-upgrade and post-upgrade configurations. Intentionally test mismatched data/verifier combinations and make sure the system fails safely and has a clear recovery path.
The goal is not to prevent dependencies from ever changing. It is to ensure that dependency evolution does not silently rewrite the protocol’s security boundary.
Conclusion
At MoveBit, we believe oracle security should be reviewed as part of the protocol’s full dependency lifecycle—not only at deployment, but through upgrades, migrations, and failure states.
The question is no longer just whether a price is correct. It is whether the protocol can continue to verify and consume that price safely as the infrastructure around it evolves.
Stable interfaces are useful. Stable security assumptions matter more.