TL;DR: Sophon has warned users to withdraw remaining assets by November 25 ahead of the planned shutdown of its standalone chain at the end of the month.

The end of a blockchain isn’t always announced with a hack or a dramatic market collapse. Sometimes it arrives as a deadline: move your tokens, claim your rewards and make sure nothing important is still sitting on infrastructure that is about to disappear.

Sophon has set November 25 as the withdrawal deadline for assets on its network, ahead of a planned permanent mainnet shutdown on November 30. The notice covers remaining balances and rewards that users may need to claim before related services go offline.

The project previously signalled a broader change in direction, away from maintaining its own chain and toward building consumer applications on Base. The final withdrawal timetable makes that strategic decision an immediate operational issue for holders.

Anyone with funds still on Sophon needs to verify the latest official instructions and the status of individual bridges and applications rather than assuming everything will migrate automatically. Shutdown announcements can attract phishing attempts, so links circulating in unsolicited messages deserve particular caution.

Sophon is one example of a wider reality for blockchain projects: operating a network has ongoing technical and economic costs. The fact that a chain can be launched does not guarantee it will remain worthwhile to support indefinitely.

For affected users, however, the lesson is more immediate. Deadlines matter, and withdrawing assets safely is more important than debating the project’s next chapter.

Written by the News Desk and edited by Samuel Rae.

TL;DR: Sophon has warned users to withdraw remaining assets by November 25 ahead of the planned shutdown of its standalone chain at the end of the month.

The end of a blockchain isn’t always announced with a hack or a dramatic market collapse. Sometimes it arrives as a deadline: move your tokens, claim your rewards and make sure nothing important is still sitting on infrastructure that is about to disappear.

Sophon has set November 25 as the withdrawal deadline for assets on its network, ahead of a planned permanent mainnet shutdown on November 30. The notice covers remaining balances and rewards that users may need to claim before related services go offline.

The project previously signalled a broader change in direction, away from maintaining its own chain and toward building consumer applications on Base. The final withdrawal timetable makes that strategic decision an immediate operational issue for holders.

Anyone with funds still on Sophon needs to verify the latest official instructions and the status of individual bridges and applications rather than assuming everything will migrate automatically. Shutdown announcements can attract phishing attempts, so links circulating in unsolicited messages deserve particular caution.

Sophon is one example of a wider reality for blockchain projects: operating a network has ongoing technical and economic costs. The fact that a chain can be launched does not guarantee it will remain worthwhile to support indefinitely.

For affected users, however, the lesson is more immediate. Deadlines matter, and withdrawing assets safely is more important than debating the project’s next chapter.

Written by the News Desk and edited by Samuel Rae.

Bitcoin Magazine

EDX Markets and VerifiedX Partner to Bring Verified Bitcoin (vBTC) to Institutional Markets

VerifiedX (verifiedx.io), a programmable layer for Bitcoin and other crypto assets, and EDX Markets (“EDX”), a Chicago-based digital asset technology firm that combines an institution-only trading venue with a central clearinghouse, announced a strategic partnership to bring Verified Bitcoin (vBTC), a tokenized form of Bitcoin, to EDX for institutional spot trading.

vBTC, VerifiedX’s flagship product, is designed to be a programmable, one-to-one backed Bitcoin asset, enabled by their layer-two protocol. As part of the partnership, EDX will join the VerifiedX network as a validator, providing EDX with direct participation in network validation and governance. The partnership will extend the relationship beyond asset trading into the underlying infrastructure supporting vBTC, while unlocking the asset for institutional traders and investors, according to a press release shared with Bitcoin Magazine. 

“Bitcoin has become a globally recognized institutional asset, yet much of its financial utility remains fragmented across exchanges, custodians, wrappers, bridges and application-layer protocols,” they wrote. The press release explained how VerifiedX works to address that fragmentation by making the bitcoin backing vBTC verifiable on-chain at a more granular level, avoiding the pooling of funds and using more advanced Bitcoin technologies than other alternatives. In turn, this makes the asset easier to program for trading, payments, treasury management, lending, and other financial applications.

The partnership is expected to support a range of institutional strategies, including:

• Bitcoin trading and price discovery through institutional spot markets;
• Cross-market arbitrage and liquidity strategies between BTC and vBTC markets;
• Treasury and balance-sheet mobility, allowing Bitcoin capital to move between trading and programmable environments;
• Borrowing, lending and yield strategies built around Bitcoin-backed capital;
• On-chain liquidity and financial applications native to VerifiedX;
• EVM composability through vBTC.b, the canonical representation of vBTC for supported EVM environments, allowing Bitcoin capital to participate in broader decentralized financial markets while preserving a direct redemption path to underlying Bitcoin.

Through EDX, market participants will gain a new venue for trading vBTC within an institutional market structure designed around aggregated liquidity, central clearing and capital-efficient settlement.

“Bitcoin does not need another financial abstraction. It needs infrastructure that allows the asset itself to do more,” said Jay Pollak, Head of Strategy at the VerifiedX Foundation. “Bringing vBTC to EDX is important because it connects programmable Bitcoin capital with market infrastructure purpose-built for sophisticated institutions. An allocator should be able to trade Bitcoin, deploy it, move it across financial environments, and ultimately redeem back to Bitcoin without losing the fundamental ownership characteristics that made Bitcoin valuable in the first place.” 

“EDX joining as a validator makes this partnership even more meaningful. This is not simply about adding another trading pair. It connects institutional trading infrastructure directly with the network infrastructure underneath the asset,” Pollak added. As a validator, EDX gets maximum sovereignty over the signing and governance of the vBTC they are responsible for, while also becoming a node in Bitcoin and the VerifiedX layer. 

Aside from their home page at VerifiedX.io, the company has a dedicated block explorer as well as a Discord, X profile, and GitHub repo. They can also be contacted via email at info@verifiedx.io.

Bitcoin Magazine has a financial relationship with VerifiedX. This article was not commissioned or reviewed by VerifiedX and reflects the independent judgment of the author.

This post EDX Markets and VerifiedX Partner to Bring Verified Bitcoin (vBTC) to Institutional Markets first appeared on Bitcoin Magazine and is written by Juan Galt.

TL;DR

• Optimism has released op-supernode v1.0.3 as an optional operator update.
• The release tightens validation around hardfork activation times and rejects invalid post-genesis fork ordering in custom rollup configs.
• Existing chains in the Superchain registry are not affected by the configuration issue described in the release notes.

Optimism’s latest supernode release is a small update with a very specific purpose: stop bad hardfork schedules from being loaded in the first place.

op-supernode v1.0.3 was published October 1 as an optional release for operators. It adds stricter validation of hardfork activation times in virtual-node rollup configurations.

There is no new indexing engine, state-sync overhaul or memory-leak fix in the official notes. The change is about configuration correctness.

Two post-genesis forks cannot share the same activation time

Under the new checks, op-supernode refuses to load a virtual node configuration that activates two hardforks at the same timestamp after genesis.

The rule applies from Jovian onward, and every later fork is checked for correct ordering. Forks that activate at or before genesis can still share a timestamp.

Optimism says chains already present in the Superchain registry are unaffected. The risk sits with custom rollup configurations that encode an invalid sequence.

That is a sensible place for software to fail loudly. An operator would rather discover a bad upgrade schedule when the node starts than after several components begin interpreting the chain differently.

Bitcoinist has covered the growing complexity behind the Superchain through interoperability testing on Sepolia and the governance work around Super Root dispute games.

More chains mean more configuration risk

The OP Stack’s success creates an operational challenge.

When one codebase supports many independent chains, teams can customise parameters, upgrade timing and infrastructure. That flexibility is valuable, but every extra configuration surface is another place for human error.

Stricter startup validation is one of the simplest ways to contain that risk.

The same philosophy appears elsewhere in the stack. Recent op-batcher upgrades have tightened compatibility with upcoming Ethereum changes, while op-node releases are also validating hardfork ordering more aggressively.

Optional does not mean irrelevant

The release is optional because existing registered chains are not affected.

For teams running custom configurations, however, the new checks can expose mistakes that previously passed silently. Those operators need to correct invalid schedules before upgrading.

For everyone else, v1.0.3 is a good example of what mature blockchain infrastructure increasingly looks like: fewer dramatic hard forks, more guardrails designed to stop small configuration errors from becoming chain-level incidents.

—

This article was written by the News Desk and edited by Samuel Rae.

TL;DR

• Optimism has released op-reth v2.5.0 and recommends it for all op-reth operators.
• The update removes two legacy pre-Bedrock import commands and patches security issues in `rustls` and `imbl` dependencies.
• Operators relying on the removed import workflow need to switch to the Bedrock state-bootstrap process before upgrading.

Optimism’s latest op-reth release is a maintenance update with two things infrastructure teams tend to take seriously: breaking command removal and dependency security patches.

Version 2.5.0 was published October 1 and is recommended for all op-reth operators.

The release does not change the economic rules of the OP Stack. It changes the software used to execute and maintain those rules.

Pre-Bedrock import commands are gone

The most visible breaking change is the removal of `import-op` and `import-receipts-op`.

Those commands were used for importing legacy pre-Bedrock OVM history. Operators who still depend on that workflow need to move to the Bedrock state-bootstrap process before upgrading, with pre-Bedrock history served from an l2geth instance.

This is the kind of cleanup mature chains eventually have to perform. Old compatibility paths are useful during migrations, but maintaining them indefinitely increases software complexity.

Bitcoinist recently covered another piece of the same maintenance cycle when Optimism shipped a required op-batcher upgrade and when native account abstraction work moved toward the OP Stack.

Two dependency vulnerabilities are patched

op-reth v2.5.0 updates `rustls` to version 0.23.45 to address RUSTSEC-2026-0285. The issue involved TLS 1.3 handshake messages being accepted at the wrong encryption level rather than the connection being closed.

The release notes state that the handshake remained authenticated, meaning the bug did not let an attacker alter or complete the handshake, but operators still get the patched dependency.

The update also moves `imbl` to 7.0.2 for RUSTSEC-2026-0292, fixing a double-free condition in a component used by the transaction pool when an element destructor panics.

Those are software-security fixes, not evidence that an OP Stack chain was actively exploited.

Infrastructure upgrades are becoming a steady operational workload

Layer 2 networks increasingly look less like a single protocol and more like a suite of coordinated programs.

Sequencers, batchers, execution clients, fault-proof components and cross-chain services all need their own release cycles. Bitcoinist’s coverage of Superchain interoperability testing shows why that stack keeps expanding.

For end users, op-reth v2.5.0 should be invisible. For node teams, the release notes are clear: update the client, account for the removed legacy commands and take the security patches.

—

This article was written by the News Desk and edited by Samuel Rae.

TL;DR

• Optimism has released Kona v1.8.0 components with fixes for derivation, proof execution, TLS and preimage handling.
• The release prevents a malformed batch from causing Kona to derive a different chain from op-node under a specific faulty-batcher condition.
• Optimism recommends the release for all chains and says kona-host should be run with the matching kona-client v1.8.0 absolute prestates.

Optimism’s Rust-based fault-proof stack has received a substantial maintenance release focused on keeping derivation and proof execution aligned with the rest of the OP Stack.

Kona host v1.8.0 was published October 1 alongside the matching client release. Optimism recommends the update for all chains.

The release is technical, but the problem it addresses is easy to understand: two pieces of verification software should not derive different answers from the same chain data.

Malformed batches get stricter treatment

After the Holocene upgrade, Kona now checks the parent hash of each singular batch against the safe head in the same way op-node does.

Optimism says the previous check always passed. In a narrow case where a faulty batcher produced a malformed batch, Kona could therefore derive a different chain from op-node.

The team notes that fault proofs are unaffected unless the batcher actually misbehaves. Still, matching derivation behavior across clients is exactly the sort of consistency requirement fault-proof systems depend on.

That fault-proof roadmap is also visible in Super Root dispute-game governance and Superchain interoperability testing.

Execution errors are handled more carefully

Kona v1.8.0 also changes what happens when proof execution runs into errors.

A block is now replaced with a deposit-only block, or dropped in older conditions, only when the payload is actually invalid. Errors such as missing preimage or witness data now stop execution instead of being treated as proof that the payload itself was bad.

That sounds subtle, but fault proofs need to distinguish “I cannot complete this computation” from “this computation proves the block is invalid.”

The release also updates the EVM implementation, patches a TLS dependency and improves preimage-server error handling.

The OP Stack is becoming more client-diverse

Optimism’s infrastructure increasingly includes multiple implementations and proof systems rather than one canonical piece of software.

Client diversity can improve resilience, but it also creates a new requirement: independent implementations have to agree precisely on state transitions and edge cases.

The same maintenance burden is visible in Optimism’s required op-batcher releases and other operator updates.

Kona v1.8.0 is therefore less about a flashy new feature and more about making sure the verification layer behaves predictably when the inputs are ugly. In fault-proof infrastructure, that is exactly where reliability matters most.

—

This article was written by the News Desk and edited by Samuel Rae.

TL;DR

• Optimism has released op-node v1.19.8 and recommends it particularly for sequencer operators using `–l2.follow.source`.
• The release fixes recurring slow block builds around L1-origin transitions and strengthens validation of hardfork activation ordering.
• Sepolia OP Stack operators must be on op-node v1.19.5 or later before the October 6 Glamsterdam hardfork.

Optimism has shipped a focused op-node update aimed at keeping sequencers fast and configuration mistakes from turning into upgrade problems.

Version 1.19.8 was released October 1 and is recommended particularly for sequencer operators running with `–l2.follow.source`.

This is not a user-facing OP token event. It is the kind of infrastructure release that matters precisely because most users should never notice it.

The release targets slow blocks at L1-origin transitions

Optimism says sequencers will now prefetch each new L1 head’s block and receipts as soon as the head is observed.

Previously, operators using the follow-source configuration could hit recurring slow block builds when the L1 origin changed and the required data had not already been fetched through local derivation.

The new behavior moves that work earlier. If the prefetch fails, op-node logs a warning and falls back to the normal fetch path.

That is a narrow change with an obvious operational benefit: fewer avoidable delays in the component responsible for ordering Layer 2 transactions.

The wider OP Stack maintenance cycle already includes the recent required op-batcher v1.17.0 release and the rollout of Superchain interoperability on Sepolia.

Hardfork configs get stricter checks

The second major change is defensive.

op-node now refuses to start when a custom rollup configuration activates Jovian or a later hardfork at the same post-genesis timestamp as the preceding fork, or when later forks are scheduled out of order.

Optimism says chains already included in the Superchain registry are not affected. The checks matter mainly for custom configurations that could otherwise encode an invalid upgrade sequence.

That becomes more relevant as the OP Stack accumulates more named network upgrades and more independent chains use the software.

Bitcoinist has also covered Upgrade Proposal 20 and Super Root dispute games, part of the same trend toward a more complex multi-chain fault-proof environment.

Sepolia operators have a deadline

The release notes also warn operators on Sepolia OP Stack chains that they must run op-node v1.19.5 or newer before the Glamsterdam hardfork on October 6.

That requirement is separate from whether every operator needs v1.19.8 specifically.

For ordinary users, there is no wallet migration or action to take. For sequencer and node teams, the release is another reminder that Layer 2 reliability depends on keeping a growing stack of infrastructure components aligned with Ethereum and with each other.

—

This article was written by the News Desk and edited by Samuel Rae.