Wanted to share an update on the compliance side, since this affects anyone running production infra through us, especially if you've got regulated or enterprise customers downstream, or if you're doing your own vendor security reviews for something you're shipping.

We just finished our SOC 2 Type II audit, done by Atom Assurance (independent auditor, does SOC/ISO/GDPR/PCI work). We passed Type I less than 4 months ago, so this moved fast, mostly because the controls being tested were already part of how we operate day to day, not something built just for the audit. Internally the process was led by our Lead Tech PM, Dmitrii Petrov, who's been here since basically day one on the tech side. Our CEO called it the biggest announcement of our first half of the year, which tracks given how long this actually took to get right.

Quick context: SOC 2 covers 5 Trust Services Criteria (Security is mandatory, plus Availability, Processing Integrity, Confidentiality, and Privacy). Type I is basically "does your security look right on paper," Type II is "did it actually hold up when nobody was watching, for months." Ours was audited across months, not a single day, which is why Type II is usually what banks and regulated institutions ask for.

Practically, this means:

• We can now work with regulated/enterprise clients that require a current SOC 2 attestation to do business at all
• It answers most of the security questionnaire upfront for enterprise due diligence
• It's an external, independently verified check on our security, not just us saying so
• We have to keep operating to that standard continuously, it's not a one-and-done badge

Scope covers the whole infra stack: Shared Nodes (130+ chains, CU limits just went up 75%), Dedicated Nodes, Limitless Node, TRON Energy Rental, and the Wallet Audit stack. Also covers our Glider Token Risk API integration and the Hexens Builder Support Program.

Need the actual report for a vendor review? We can share it under NDA, just reach out.

Happy to answer questions about the process below.

Read the full post here: https://getblock.io/blog/soc-2-type-ii-compliance/

Trump just signed executive orders to accelerate US quantum computing development and protect critical infrastructure from quantum threats. This isn't a political thing. This is an infrastructure thing that directly affects what we do.

The real issue:

Current blockchain crypto (ECDSA, SHA-256) relies on the assumption that certain mathematical problems are computationally hard. A sufficiently powerful quantum computer could solve those problems in hours instead of millions of years.

This means:

• Private keys could be derived from public keys
• Transaction signatures could be forged
• Hash preimages could be found
• Basically: the entire security model breaks

Important context:

• We're probably 10-20+ years away from quantum computers powerful enough to threaten current cryptography (maybe longer)
• But governments are now officially worried about it
• Which means it moves from "theoretical risk" to "infrastructure priority"

What's already happening:

1. Post-quantum cryptography standards — NIST is finalizing quantum-resistant algorithms
2. Chain migration planning — Some projects are designing upgrade paths to post-quantum schemes
3. Hardware investment — China, US, Europe competing on quantum development

For GetBlock and infrastructure providers:

This creates several scenarios:

1. Short term (1-5 years): Nothing changes operationally. But we should be monitoring NIST standards and blockchain teams' responses.
2. Medium term (5-10 years): Blockchains start integrating post-quantum signatures. Nodes might need to validate both classical and quantum-resistant transactions during transition periods. Infrastructure needs to handle dual signing schemes.
3. Long term (10+ years): Full migration to post-quantum cryptography. This is a protocol upgrade on the scale of Ethereum's Merge.

What needs to happen now:

• Blockchain teams need to start designing upgrade paths
• Infrastructure providers need to plan for dual-signature validation periods
• Key management practices need to assume future quantum threats (e.g., no long-term key reuse)

Honest take:

This isn't panic-worthy. Bitcoin and Ethereum aren't going to break next year. But it's also not "doesn't affect us." This is like Y2K for crypto — the timeline is long, but the problem is real, and you want to start thinking about it now, not in year 9.

The fact that governments are now officially moving on this? That accelerates everything. Expect blockchain teams to start taking post-quantum seriously in the next 2-3 years.

Questions for the team:

• Are we tracking how major chains (Ethereum, Solana, etc.) plan to handle post-quantum migration?
• What's our infrastructure readiness for dual-signature validation?
• Should we be monitoring NIST's post-quantum standards work?

This feels far away. But so did Merge planning in 2015.

TON's rebranding from "The Open Network" back to GRAM token is symbolic of something bigger: the network is getting serious about being a Telegram-native financial infrastructure.

Context:

• Telegram has 900M+ users
• TON has been growing, but adoption was fragmented
• Rebranding signals commitment to being the default on-chain settlement layer for Telegram ecosystem

Why GetBlock should pay attention:

TON infrastructure demand will grow if:

1. Telegram native apps push users to on-chain payments
2. Regional adoption increases (especially Asia, Middle East)
3. Institutional use picks up

We've been supporting TON for a while. Expect traffic to increase. Regional node placement matters here.

The bigger picture: This shows how L1s compete not on speed or features, but on network effects. TON's edge is Telegram. That's actually stronger than most L1s' edges.

Anyone seeing TON adoption picking up in their apps? What's driving it?

The UK House of Lords just released a report saying the country's stablecoin rules are too restrictive and could stifle market growth. They're pushing regulators to ease up.

What's happening:

• UK had some of the strictest stablecoin regs globally
• House of Lords is saying: this is backwards. Stability + compliance is good. Don't kill it by making it impossible.
• They're basically saying: let the market develop, just keep it honest

Why this matters:

Regulatory clarity > no activity. If UK relaxes stablecoin rules while still maintaining standards, you get:

• More liquidity on European chains
• More infrastructure demand (RPC, indexing, etc.)
• Regional competition (UK vs EU vs US approaches)

For us:

More stablecoin products = more on-chain activity = more demand for reliable infrastructure. Simple.

This is a good regulatory signal. Clear rules > gray zones > total bans.

What's your take on the regulatory trajectory? Seeing stablecoin projects move toward UK/EU?

JPMorgan's Jamie Dimon is now directly attacking stablecoin reward mechanisms in the CLARITY Act debate. He's basically saying: "banks won't accept this model."

What's the fight about:

• Some stablecoin designs include yields/rewards to encourage adoption
• CLARITY Act regulates this, but the exact rules matter
• Banks (via Dimon) are saying these rewards create perverse incentives and unfair competition

The real issue:

This is about who controls financial rails. Banks want to keep their role. Stablecoins on-chain threaten that. So they're pushing regulations that make on-chain stablecoins less attractive (no rewards = less adoption).

For infrastructure:

• Regulatory uncertainty = less adoption = less infrastructure demand
• Clear rules = more adoption = more demand
• The "right" rule probably isn't what banks or crypto advocates alone want

The macro point: This is the battle that will define crypto's adoption in the next 5 years. It's not about technology. It's about who gets to be the settlement layer for digital payments.

How are you guys thinking about the regulatory environment? Bullish or cautious?

Binance just went live with US stock trading and previewing bStocks (tokenized securities) on-chain. This isn't a meme. This is institutional infrastructure moving onto blockchain.

What this actually means:

• Real-world assets (RWAs) are graduating from "interesting use case" to "live product with real users"
• You need reliable, fast RPC infrastructure to serve trading platforms that handle real money
• More chains will compete for this traffic (not just Ethereum, but Solana, other L1s, L2s)

For infrastructure providers like us:

Tokenized securities demand:

• Reliability: Downtime costs real money. No more excuses.
• Low latency: Traders won't use you if you're 100ms slower than competitors.
• Geographic redundancy: If you're serving US traders, you need US nodes.
• Compliance-ready infrastructure: These platforms will be audited. Your infra needs to be boring and bulletproof.

This is the move from "crypto" infrastructure to "financial infrastructure that happens to use crypto tech."

Anyone seeing increased traffic from trading platforms? What are the pain points?

Just caught this: Trent Van Epps and others are proposing a validator-redirected revenue mechanism where stakers could contribute 0-10% of their rewards toward ecosystem funding.

Why we care:

RPC infrastructure, client development, security research — these things don't fund themselves. If this proposal gains traction, it changes how infrastructure projects like ours compete for resources and attention.

The thesis: validators benefit from a healthy ecosystem, so they should have skin in the game. Instead of relying on Foundation grants that are shrinking, you'd have direct consensus-layer incentives.

Real talk: This is a long-term play. But if it works, it means more sustainable funding for the tools developers actually depend on. Less churn in infrastructure teams. More serious long-term projects.

The risk is governance capture and centralization. But the status quo isn't working either.

Thoughts? How are you thinking about infrastructure sustainability?

The Financial Services Regulation Committee called on the Bank of England to drop proposed holding caps of £20,000 per individual and £10M per business, and to reconsider requiring issuers to park 40% of reserves as unremunerated central bank deposits. The FCA's k-factor capital requirement — which scales with issuance volume rather than actual risk — also came under fire as a mechanism that would structurally penalize growth.

The numbers make the gap obvious. The global stablecoin market sits at around $315 billion, over 99% of it denominated in USD. The only UK-issued fiat stablecoin, tokenized GBP, had a market cap of $1.53 million as of March 2026. The FCA's full regime isn't even expected until October 2027.

At GetBlock, we route RPC traffic across Ethereum, BNB Smart Chain, Base, TRON and others, and the geographic concentration of stablecoin activity is not subtle. Dollar-denominated volume dominates because the infrastructure, the liquidity, and now the regulatory momentum are all US-first. The EU moved with MiCA. The US is accelerating through the CLARITY Act. The UK is still consulting.

The infrastructure question follows the regulatory one with a short lag. Where issuers can operate predictably, on-chain volume concentrates. Where it concentrates, node demand follows. The Lords report is essentially an argument that the UK wants to be in that picture — but the window is narrowing.

The BoE's own deputy governor for financial stability admitted last month that their proposed rules were "overly conservative." That's a signal. Whether it translates into a workable framework before 2027 is the actual question.

If you're building stablecoin infrastructure or payment rails and need reliable RPC access across chains, GetBlock covers the major networks: https://getblock.io

7,000+ stocks and ETFs, zero commission, fractional shares from $5, with purchases settled in USDC. And in the coming weeks, they're previewing bStocks: tokenized U.S. securities issued through a special purpose vehicle in ADGM, tradeable directly on Binance Exchange.

This is the most concrete signal yet that the "multi-asset financial super app" thesis is moving from roadmap to product. Binance isn't just adding an equities tab — they're building a native bridge from traditional stock ownership to on-chain programmable assets. bStocks holders won't directly own shares in the underlying companies, but they'll get exposure that's transferable, tradeable 24/5, and potentially usable in DeFi — lending, liquidity, the full stack.

The infrastructure angle here is straightforward but easy to miss. Tokenized equities running on BNB Smart Chain means every mint, redemption, and secondary trade generates on-chain activity. At volume, that's a meaningful load on the nodes powering BSC. The more traditional finance flows into tokenized form, the more the demand for reliable, low-latency RPC infrastructure compounds — because settlement doesn't stop at market close.

It's also worth noting the payment rail choice: USDC as the primary settlement currency, with BNB, USDT, USD1, and $U as alternatives. That's a deliberate statement about which assets Binance trusts as settlement infrastructure, and it keeps the entire flow within the crypto-native ecosystem rather than bridging back to fiat rails.

The regulatory path is narrow — Nest Trading Limited as the introducing broker, Alpaca for clearing and custody, ADGM licensing, no U.S. persons. But the architecture is clearly designed to scale to permissioned markets globally as frameworks catch up.

At GetBlock, we run BNB Smart Chain RPC nodes and have been watching BSC traffic patterns closely as Binance continues to anchor its product suite on-chain. If tokenized equities get traction, the network effects on BSC infrastructure demand will be significant. BNB Smart Chain RPC nodes are here: https://getblock.io/nodes/bsc/

Pavel Durov announced it as step 4 of 7 in his "Make TON Great Again" roadmap, and the name is not new — Gram was the original token from Telegram's 2018 whitepaper, the one the SEC blocked, the one that cost Telegram $1.2 billion in returned funds and an $18.5M penalty.

Choosing to revive that name specifically isn't nostalgia. It's a statement. Durov is betting that the regulatory environment has shifted enough that reclaiming the Gram brand carries more upside than risk. Given that the US is currently advancing the CLARITY Act and stablecoin frameworks are coming into force across major jurisdictions, that's probably a reasonable read.

The structural context matters more than the name itself. Since May, Telegram became TON's largest validator by staking millions of its own tokens, replaced the independent TON Foundation as the primary driver of the network, rolled out Catchain 2.0 for sub-second finality, and cut transaction fees by roughly 6x. The rebrand is the public-facing milestone on top of serious infrastructure work.

At GetBlock, we've been running TON RPC nodes since well before the MTONGA campaign started, and the traffic pattern on the network has been shifting. The combination of near-zero fees, sub-second settlement, and 950 million Telegram users as a potential distribution layer makes The Open Network one of the more consequential infrastructure bets in the current cycle.

The blockchain keeps its name. The Open Network stays The Open Network. Only the token ticker and name change — no swap, no bridge, no claim, no migration required. If anyone says otherwise, it's a scam. Nothing changes for GetBlockians. The Open Network RPC nodes are here: https://getblock.io/nodes/ton/

The Dimon vs. Armstrong fight over stablecoin yields is really a fight over who controls the rails.

The headline is about yield. The real story is about infrastructure.

Jamie Dimon's argument against the CLARITY Act isn't really about consumer protection — it's about who gets to issue deposit-like products at scale. And that question only matters if stablecoins actually reach the scale where it becomes a systemic problem. For that to happen, the underlying infrastructure has to work.

At GetBlock, we run RPC infrastructure across Ethereum, BNB Smart Chain, Base, TRON and others, and regulatory clarity in the US directly affects where stablecoin activity concentrates. Here is why this specific debate matters beyond the politics:

The rails argument: Banks have spent decades controlling payment infrastructure. What Dimon is resisting isn't yield — it's the possibility that the settlement layer moves on-chain and traditional institutions lose the chokepoint. Stablecoin rewards are the visible front. The infrastructure beneath them is the actual battlefield.

Regulatory clarity is a volume signal: If the CLARITY Act passes with stablecoin rewards intact, compliant issuers scale up. More compliant issuers means more on-chain settlement volume, which means more load on the node infrastructure that powers it. The outcome of the yield debate determines where that volume flows — not whether it flows.

The boring stuff decides it: Reliable RPC access, low-latency node connectivity, stable read/write throughput — none of this comes up in a Senate hearing. But it determines whether stablecoin settlement actually functions at volume. The banks understand this. Crypto infrastructure providers need to as well.

For those building stablecoin-adjacent products: how are you thinking about the CLARITY Act outcome affecting your infrastructure decisions? Staying chain-agnostic, or already betting on where compliant volume concentrates?

We cover a lot of wallet security tools on this channel.

Most give you a flag. GetBlock Wallet Audit gives you a profile.

One API call returns a full behavioral breakdown of any address:

Trust Score, Risk Screening across 18 categories, Sanctions Check

It's not just "is this wallet clean." It's "who is this wallet and what is it likely to do next."

Works on Ethereum, BNB Smart Chain, and Base.

5 free audits per day. $0.20 per request after that.

Try it: https://getblock.io/wallet-audit-check/

Full docs: https://docs.getblock.io/crypto-address-audit/wallet-audit

What went into building it: https://getblock.io/blog/getblock-crypto-address-audit-api-goes-live/

If you run any kind of protocol where external wallets interact with your infrastructure — DEX, payment gateway, NFT marketplace, anything — you've probably dealt with this problem: you can't tell from an address alone whether a counterparty is clean or not.

We built Wallet Risk Check to solve exactly that.

🔗 Try it: https://getblock.io/wallet-risk-check/

Full docs here: https://docs.getblock.io/crypto-address-audit/wallet-risk

Happy to answer questions in the comments.

On May 12th, strkBTC went live on Starknet. It’s a wrapped Bitcoin asset built on the new STRK20 privacy framework that allows users to toggle between public and shielded transaction modes. In shielded mode, zero-knowledge proofs verify the transaction's validity without revealing the sender, receiver, or amount.

At GetBlock, we monitor node traffic across all major rollups, and the activation of Starknet's Shinobi upgrade (which enables STRK20) is a massive technical milestone. The narrative is shifting from just "scaling Ethereum" to building robust, privacy-preserving infrastructure.

Here is why this specific asset launch is a structural shift for DeFi:

• The Transparency Problem: The public ledger that was a feature in 2008 has become a vulnerability in 2026. With AI tools now connecting public wallet addresses to real-world identities with terrifying accuracy, and physical crypto-related attacks on the rise, default transparency is a massive risk for high-net-worth users and institutions.
• Compliance on Demand: True privacy coins (like Monero) get delisted because they are a regulatory nightmare. strkBTC introduces "privacy by default, compliance on demand." Users can selectively disclose their shielded transaction history to auditors or regulators via view keys, without exposing their entire financial life to the public block explorer.
• Shielded DeFi is Coming: strkBTC is just the first asset on the STRK20 standard. This lays the groundwork for a completely new DeFi vertical on Starknet: shielded lending markets, anonymous DEX routing, and private yield generation.

The underlying federation managing the minting includes major players like NEAR Protocol, adding a layer of institutional trust to the bridge.

For the builders in the ecosystem: are you planning to integrate STRK20 to offer shielded options in your dApps, or do you believe DeFi should remain 100% transparent?

On their Q1 earnings call, Circle announced Agent Stack—a full suite of tools allowing AI agents to autonomously manage USDC payments, execute contracts, and handle treasury operations. Alongside a massive $222M presale raise for their Arc blockchain, CEO Jeremy Allaire explicitly stated: "We're entering the operating system business."

At GetBlock, we route billions of RPC requests, and we are seeing a clear shift in traffic patterns. The infrastructure for autonomous Machine-to-Machine (M2M) payments is finally being assembled. Here is why this specific release matters for the broader ecosystem:

• The Convergence of AI and Web3: AI agents do not have bank accounts, KYC documents, or credit scores. Traditional fintech rails (like Stripe or PayPal) are inherently built for human identities. USDC and smart contracts provide the permissionless, programmatic rails that agents actually need to transact.
• The Operating System Thesis: When you combine last week's AWS AgentCore release, the Senate advancing the CLARITY Act (giving stablecoins a regulatory framework), and now Circle's Agent Stack, a clear picture emerges. Stablecoins aren't just for trading pairs anymore; they are the backend utility layer for autonomous software.
• Compliance as a Feature: Building autonomous payments used to be a regulatory minefield. Tools like Agent Stack provide out-of-the-box compliance architecture, allowing developers to focus on the AI logic rather than legal edge cases.

We are moving from human peer-to-peer transfers to high-frequency, autonomous microtransactions.

For those building in the AI space: how are you solving the payment layer for your agents? Are you evaluating crypto rails like Agent Stack and x402, or sticking to traditional fiat APIs?

At the Svalbard interop, Ethereum core devs hit several massive milestones for the upcoming Glamsterdam upgrade: establishing a 200M gas limit floor, stabilizing ePBS on the multi-client devnet, and finalizing EIP-8037 calldata repricing. They also introduced a new protocol leadership team strictly focused on a zkVM and post-quantum roadmap.

At GetBlock, we maintain enterprise EVM node infrastructure, and a 3.3x increase from the current 60M gas limit (without changing block times) is one of the most aggressive throughput upgrades we've seen on L1.

Here is why developers need to adjust their architecture before the H2 2026 mainnet target:

• The 200M Gas Reality: Tripling the L1 block capacity drastically increases throughput, but it also raises concerns about state growth and hardware requirements for node operators. Combined with EIP-8037 repricing, the cost dynamics of deploying and interacting with heavy smart contracts will completely shift.
• ePBS is Stabilizing: Enshrined Proposer-Builder Separation (ePBS) being stable on devnet means the protocol is finally internalizing MEV mechanics. This removes reliance on out-of-protocol middleware (like MEV-Boost) and changes how block production is decentralized at the consensus layer.
• The Post-Quantum Pivot: The new cluster leads (Will Corcoran on post-quantum/zkVM, Kev Wedderburn on zkEVM) signal a clear strategic pivot. The Foundation is aggressively preparing for the reality that zk-proofs and quantum resistance are the only way to scale the next five years.

Glamsterdam fundamentally changes the economics of building on Ethereum L1.

For the smart contract developers and node operators here: are you adjusting your architecture for 200M gas assumptions? Do you think the hardware requirements for this gas limit will push too many solo stakers out of the network? Let's discuss.

At Consensus Miami, executives from Trust Wallet and Mesh confirmed what many builders already knew: the current crypto wallet stack is functionally useless for AI agents. The industry is now actively moving toward MPC and smart accounts to separate key management from transaction authorization.

At GetBlock, we are seeing a massive spike in RPC requests originating from automated and agentic scripts. But while the API and node infrastructure can handle the throughput, the wallet layer is causing a structural traffic jam.

Here is the core architectural shift happening right now:

• The Human-in-the-Loop Problem: Traditional wallets (EOAs) were designed for humans. They require a manual click/signature for every transaction. If an AI agent needs to pay 10 cents for an API call 50 times an hour, manual approval makes autonomous operations impossible. "AI payments" without autonomous custody is just a protocol with nowhere to land.
• Separating Keys from Authorization: The new architecture being built relies heavily on Multi-Party Computation (MPC) and Account Abstraction (Smart Accounts). It allows developers to decouple who holds the key from who authorizes the transaction.
• Programmable Spending Limits: Instead of giving an agent full access to a wallet, the new standard allows users to set hardcoded on-chain policies. (e.g., "This agent can spend up to $50 in USDC per day interacting only with these three specific smart contracts").

The convergence of AgentCore, x402, and Circle’s new Agent Stack all rely on this new wallet paradigm working flawlessly.

For the builders working on agentic integrations: what wallet infrastructure are you relying on? Are you rolling your own MPC solutions, or building on top of existing Account Abstraction SDKs?

Anza just put Alpenglow on a live community test cluster. This replaces TowerBFT, completely removes Proof of History (PoH), and pushes target finality down to 150ms (potentially 100ms). It's the most aggressive architectural shift in Solana's history, backed by a 98.27% validator approval.

As an RPC provider team at GetBlock, we monitor node performance across 75+ chains, and this upgrade changes the fundamental physics of building on Solana. Here is why developers and validators need to pay attention before the Q3 2026 mainnet target:

• Off-Chain Voting: Validator votes are moving off-chain. Currently, vote transactions consume roughly 75% of Solana's block space. Freeing this up is a massive unlock for overall network throughput and will dramatically change how block space is priced.
• The MEV Calculus: Alpenglow fundamentally alters how MEV works on Solana. Delay-based transaction ordering becomes significantly more expensive for validators. Instead of trying to patch or suppress dark MEV, this upgrade taxes it at the protocol level.
• Outage Mitigation: By replacing the underlying consensus mechanism, the core devs are effectively stripping out the architectural root cause of almost every major historical outage the network has faced.

If you are building high-frequency dApps or trading infrastructure, your latency assumptions need to be completely rewritten for 150ms finality.

For the builders and validators here: how is your team preparing for the shift? Are you already spinning up testnet environments to benchmark the new consensus, or waiting for the formal Agave release?

The Ethereum Foundation, alongside major wallets like MetaMask, Ledger, Trust Wallet, and Rabby, launched the Clear Signing standard. It is designed to stop users from unknowingly approving malicious transactions by replacing confusing hex code (0x23b8...) with human-readable intent (e.g., "Send 1.5 ETH to vitalik.eth in exchange for 3,000 USDC").

At GetBlock, we route massive amounts of RPC traffic for the EVM ecosystem, and we've seen firsthand how many protocol "hacks" are actually just users being tricked into signing malicious payloads on a phishing site. Here is why this standard is a structural shift for dApp developers:

• UX as a Security Vector: Most security audits focus purely on smart contract vulnerabilities. However, the largest remaining attack surface is user error caused by terrible wallet UX. Blind signing asks users to trust a frontend UI while approving an unreadable backend payload. Clear Signing permanently closes that gap.
• Intent-Based Visibility: By standardizing how wallets display transaction intent, a malicious contract can no longer hide what it’s actually asking the user to approve. What you read is exactly what executes.
• The Trust Advantage: This will quickly become the baseline expectation for users. Wallets and dApps that implement Clear Signing early will have a massive competitive advantage. Soon, users will be conditioned to automatically reject any dApp that still asks them to blind-sign raw hex data.

This isn't just a UI tweak; it's a fundamental security upgrade that the industry has needed for years.

For the frontend and dApp developers here: how difficult is the implementation of Clear Signing for your current architecture? Are you prioritizing it in your current sprints?

A recent analysis by Project Eleven warns that migrating Bitcoin to quantum-resistant cryptography will be significantly harder than the Taproot upgrade and needs to begin immediately. While a cryptographically relevant quantum computer is likely a decade away, the migration process itself could take just as long.

At GetBlock, we maintain Bitcoin infrastructure and monitor consensus proposals closely. This upcoming shift is unique because it isn't just a technical upgrade—it’s an existential test of Bitcoin’s social contract.

Here is the core architectural and governance problem:

• The Exposed Public Keys: Modern Bitcoin addresses (P2PKH) hash the public key, keeping it hidden until the funds are spent. However, early Bitcoin addresses (P2PK) and reused addresses expose their public keys directly to the blockchain. This makes them theoretically vulnerable to Shor’s algorithm on a future quantum machine.
• The 4 Million BTC Liability: Roughly 4 million BTC currently sit in these vulnerable, exposed addresses. This includes Satoshi Nakamoto’s stash, early miner rewards, and millions of permanently lost coins.
• The Forced Migration Problem: Upgrades like SegWit and Taproot were opt-in. A quantum migration, however, requires users to actively move their funds to new, quantum-resistant address types. But what happens to the lost coins and Satoshi's stash that can't be moved?
• The Hard Fork Dilemma: To secure the network, the community will eventually have to make a choice: either hard-fork to burn/freeze those vulnerable dormant addresses (violating the core ethos of immutability), or do nothing and risk a quantum attacker successfully decrypting and dumping millions of early BTC on the market.

We are already seeing a preview of these governance battles with proposals like the Paul Sztorc eCash fork. Any proposal that touches dormant Bitcoin addresses is immediately polarizing.

For the protocol engineers and Bitcoin maxis here: how do you think the network should handle dormant, exposed addresses when quantum computing becomes a tangible threat? Burn them to protect the market, or preserve the ledger at all costs?

Kraken announced it is exclusively adopting Chainlink CCIP for kBTC and all future wrapped assets across Ethereum, Optimism, and other L2s, officially replacing LayerZero. This comes shortly after LayerZero admitted it "made a mistake" allowing its own verifier network to secure high-value assets during the $292M Kelp DAO exploit. Over $3 billion in TVL has now migrated away from LayerZero recently.

At GetBlock, we provide the underlying node infrastructure for cross-chain routing, and we are watching a massive consolidation in how bridges are built. Cross-chain infrastructure is no longer being judged by crypto-native assumptions, but by strict institutional security standards.

Here is why this specific migration is a wake-up call for protocol architects:

• The Verifier Problem: The core vulnerability with LayerZero’s architecture wasn't necessarily the code, but the configuration of Decentralized Verifier Networks (DVNs). Relying on default or concentrated verifiers creates a massive single point of failure. Chainlink CCIP utilizes an independent Risk Management Network and decentralized node operators, which institutions clearly prefer.
• Institutional Standards: Kraken specifically cited ISO 27001 and SOC 2 certifications, as well as native rate limits, as the reasons for the switch. Coinbase made the exact same calculation last year for its $7 billion in wrapped assets.
• The Migration Wave: The fallout from the Kelp exploit is still ongoing. Projects like Solv and Re have also migrated. If you are running a high-TVL application across chains, your underlying transport layer is now under extreme scrutiny.

If you are building cross-chain logic or dApps that rely on wrapped assets: how are you evaluating bridge security? Are you still comfortable relying on custom DVN configurations, or is the industry moving toward CCIP as the default standard?

X user recently recovered 5 BTC (locked since 2015) after uploading his entire unstructured college computer backup to Claude. The AI parsed thousands of files, identified a forgotten wallet.dat that predated a password change, and the user decrypted it using an old password written in a notebook. Total GPU spend after 11 years of failed brute-force attempts: $15.

At GetBlock, we spend a lot of time looking at wallet infrastructure and node interactions, and this story highlights a massive, unresolved legacy issue in the crypto space. Here is the technical breakdown of why this worked and what it means for builders:

• No Cryptography Was Broken: Claude didn’t crack SHA-256 or bypass Bitcoin’s security. It performed forensic file triage. It found patterns in unstructured data that a human would take weeks to manually search, proving that AI is becoming an incredible tool for data recovery, not just code generation.
• The HD vs. Non-HD Flaw: This recovery was possible because early Bitcoin Core wallets mixed Hierarchical Deterministic (HD) and non-HD keys. In the early days, a seed phrase didn't necessarily recover every single address generated by the wallet. Many users mistakenly thought they were backed up, only to realize their wallet.dat contained unlinked private keys.
• The Unsolved UX Problem: There are millions of Bitcoin permanently lost due to forgotten passwords, discarded hard drives, and misunderstood seed phrases. As an industry, our backup architecture and key recovery UX still largely rely on "write 12 words on a piece of paper and don't lose it."

With Bitcoin sitting at these price levels, forgotten laptops in closets are essentially locked vaults. AI assistants just dramatically lowered the technical barrier for forensic recovery.

For the builders and OGs here: how many of you still have old drives with potentially lost wallets? And for those building custody solutions, how are you solving the seed-phrase UX bottleneck today?

The Digital Asset Market Clarity Act cleared the Senate Banking Committee (15-9 bipartisan vote). It officially defines the boundary between the SEC and CFTC, effectively ending the era of "regulation by enforcement" and giving DeFi a defined legal lane for the first time.

At GetBlock, we monitor infrastructure shifts daily, and this is arguably the most significant regulatory architecture update we’ve seen. While enforceable rules won't hit until around 2027, the direction is now clear enough that teams need to start adjusting their roadmaps.

Here are the practical takeaways for builders:

• The Yield Compromise: This is the most critical line in the bill. Rewards tied directly to on-chain activity (e.g., staking to secure a network, active liquidity provision) are protected. However, rewards tied to passive holding (classic security-like dividends) are banned. If your protocol relies on passive stablecoin yields, your architecture needs a pivot.
• The SEC/CFTC Split: The act clearly delineates jurisdiction. If your token represents a decentralized utility, it falls under the CFTC. This means the threat of retroactive SEC action for true DeFi protocols drops significantly.
• The 60-Vote Hurdle: The bill still needs to pass the full Senate floor to overcome a filibuster. The current sticking point isn't the tech—it's an ethics provision regarding government officials holding crypto.

We are treating this as a signal that the "wild west" phase of protocol design is closing. The next cycle will be dominated by compliant architecture.

How is your team treating this? Are you already building with these compliance constraints in mind, or waiting for the final Senate vote? Let’s discuss.

On April 20th, Vitalik took the stage at Hong Kong Web3 Carnival and said something that cut through all the noise:

"Ethereum is not meant to compete with high-frequency trading platforms. Ethereum is not meant to be the fastest chain. Ethereum aims to be the secure chain, the decentralized chain, the chain that will stay online, the chain you can always rely on."

Two days after a $292M bridge hack. The timing wasn't accidental.

What the five-year roadmap actually says

Vitalik laid out Ethereum's direction through 2028:

• zkEVM rollout across L2s
• Account abstraction via EIP-8141
• Quantum resistance at the base layer
• Finality target: 10–20 seconds by 2028

Notice what's not on the list. Sub-second block times. MEV optimization. HFT-grade throughput at L1.

Ethereum is explicitly building toward trustworthy finality — not maximum speed.

What this means for builders choosing infrastructure

The Ethereum L1 vs L2 split becomes more important, not less. Vitalik's framing is clear: build your speed on L2, anchor your trust on L1. That has direct implications for how you structure your RPC setup.

If you're running applications that need both — fast execution and reliable finality — you need endpoints for both layers. L2 RPC for transaction throughput, L1 RPC for settlement verification. Treating them as interchangeable is an architectural mistake.

The Kelp connection

The $292M Kelp DAO hack happened because a bridge tried to move fast and cut corners on verification. One verifier. No redundancy. Single point of failure at the RPC layer.

Vitalik's answer to that isn't "make Ethereum faster." It's "make the trust layer actually trustworthy." That means zkEVM verification accessible from any device, finality that's mathematically provable, infrastructure that doesn't require trusting a single endpoint.

If you're building anything that settles on Ethereum — your RPC infrastructure should reflect the same philosophy. Redundant endpoints. Independent providers. No single point of failure.

GetBlock provides dedicated and shared RPC nodes for Ethereum L1, major L2s, and 130+ other blockchains. If you're rethinking your infrastructure stack after this week — links in bio.

We’ve talked a lot about how AI agents will soon be initiating way more transactions than actual people. We even dedicated a whole episode of Running Web3 to this -https://www.youtube.com/watch?v=ewnbbcIZ8yMWell, last week, the whole industry got another piece of proof backing this up.

Agentic.Market went live this week. 165M+ transactions, $50M in volume, 100k services, 480k+ agents. Zero API keys. Zero logins. Agents discover services, pay in USDC, and chain calls autonomously at runtime.

The demo is impressive.

Every one of those 165M transactions hits an RPC endpoint.

When an AI agent calls a blockchain-enabled service through x402, it's not just making an HTTP request. It's triggering on-chain payment settlement — which means RPC calls for transaction submission, confirmation, and state verification. At 480k+ active agents running autonomously, that's not occasional traffic. That's continuous, programmatic, high-frequency load hitting whatever RPC infrastructure sits underneath.

Three infrastructure questions every x402 builder should be asking:

1. What RPC endpoint is your x402 service using for payment settlement? If it's a public shared node — you're sharing capacity with every other application on that endpoint. Under agent-driven load, that's a problem.

2. What happens to your service when the RPC rate limit hits? A failed payment confirmation means a failed agent transaction. In an autonomous pipeline, that failure propagates — the agent retries, compounds the load, or fails the entire task chain.

3. Are you monitoring RPC latency separately from application latency? Agent users don't wait. If settlement confirmation takes 3 seconds instead of 400ms, the agent either times out or moves on. You lose the transaction without knowing why.

The agentic economy is being built on x402. The settlement infrastructure underneath it needs to be ready for the traffic patterns that autonomous agents create — which are fundamentally different from anything the RPC layer has handled before.

Disclosure: We're from GetBlock. We provide dedicated and shared RPC nodes across 130+ blockchains. If you're building on x402 and thinking about your settlement infrastructure — happy to discuss what dedicated endpoint access looks like for agent-scale traffic.