A compatibility route is only useful when its answers are true. snarkOS v4.10.1 replaces a locally maintained historical-state implementation that could resurrect deleted values, while the rest of the stack makes its own boundaries clearer: V20 now has a mainnet height, the SDK has a new default gateway, and Kraken can fund USDCx directly on Aleo.

I like the direction. Compatibility is still present, but nobody has to pretend the old architecture was sound.

Historical state stops pretending

The headline change is snarkOS testnet v4.10.1, a snarkOS-only point release built on snarkVM 4.10.0. There is no new consensus rule here. Validators that do not expose historical REST routes have no reason to upgrade for this release.

RPC operators do.

The old history Cargo feature maintained local tables for historical mapping values, then exposed them through /history/ and /staking/rewards. That sounds sensible until deletion enters the picture. The tables did not record deleted keys, so a value that once existed could remain visible forever in historical answers after the live state had removed it.

credits.aleo/unbonding makes the bug painfully concrete. Suppose an account starts unbonding at height 21,900,000 and claims the completed unbond later. A query above the claim height should return no pending unbond. The old table could keep returning the earlier value, making the claim look unfinished at every later height.

Bad history is worse than missing history. An unavailable endpoint fails loudly. A stale answer slides into an exchange accounting system, an indexer's database, a staking dashboard, or a tax report with the shape of valid data.

PR #4458 removes that local implementation and introduces --history-compat-mode. When enabled, snarkOS keeps the established /history/ and /staking/rewards route shapes but obtains the answers from Provable's historical staking API. Existing clients can keep their request format. The node operator now has an explicit upstream dependency.

That trade is honest. An operator enabling compatibility mode is no longer claiming that one snarkOS database can reconstruct historical staking state correctly. Availability, latency, rate limits, and trust for those routes now include the Provable service. Operators should monitor them separately from ordinary node RPC health, because a node can be healthy while its history upstream is unavailable.

The release lands on testnet first. PR #4460 keeps snarkVM pinned to the v4.10.0 testnet revision and carries no activation-height change. A mainnet point release is expected after testnet validation. Until then, the operational split is simple: consensus nodes stay put; testnet RPC providers serving the old history routes should test the runtime flag and update their alerts.

Two underlying snarkVM fixes explain why patching the old tables was not attractive. The storage path mixed incompatible height encodings, and its schema did not preserve deletions. Once the data model has forgotten an event, a cleaner REST handler cannot recover it. The source of truth has to change.

V20 gets a mainnet height

Aleo Stack v4.10.0 is the mainnet release carrying V20. Activation is set for block 22,175,000, estimated around September 22 at 07:40 UTC when the release was prepared. Height is authoritative. The clock estimate will drift with block production.

The matching snarkVM release PR preserves mainnet V19 at height 21,342,000 and adds V20 at 22,175,000. Testnet activated V20 at 19,374,000 on September 6, giving operators more than two weeks of live rehearsal before the mainnet boundary.

Readers of the September 4 digest will recognize the rules. Leader blocks get a conservative spend limit. A subdag is capped at 40 certificates. V20 also tightens validation around encodings and deployment checks. Mainnet is now scheduled to enforce the same behavior.

Activation heights are better than vague upgrade windows. Exchanges can freeze maintenance around a block range. Validators can verify their binary before the boundary. Indexers can label data by consensus version instead of guessing from wall-clock time.

There is still a hard edge. A validator on software that does not understand the active rules can reject valid blocks or build invalid ones after height 22,175,000. Operators should confirm the binary version and network before the activation block, rather than treating the version number in a container tag as proof. Check the running process.

The release also patches rustls past RUSTSEC-2026-0285. Security fixes bundled with a consensus release create an awkward incentive to upgrade quickly, but the fixed activation height limits ambiguity about which build belongs on mainnet.

SDK and tooling move together

Provable SDK v0.11.10 changes the default base URL from https://api.provable.com to https://edge.provable.com/api. The swap reaches the Rust DEFAULT_URL, live tests, generated references, create-leo-app templates, guides, and the project website. New applications will enter through Edge unless they choose another endpoint.

Edge is key-optional. Passing a lone API-key string selects API-key mode and sends X-API-Key; the client does not try to mint a JWT first. That behavior follows the authentication cleanup covered in the V19 digest.

Changing a default host is easy in code and real in production. Allow lists, egress policy, DNS monitoring, origin-scoped caches, and dashboards may still name api.provable.com. Teams that inject their own endpoint will see no automatic move. Teams relying on SDK defaults may see traffic shift as soon as they update the package.

Legacy callers were almost broken along the way. PR #1409 restores JWT behavior for clients that remain on api.provable.com, including callers that assign an externally minted token through AleoNetworkClient.jwtData. The cached proving token had become origin-scoped, and the directly assigned field was no longer folded into auth configuration. A new compatibility suite pins the old wire behavior.

Keeping that path is the right call. A gateway migration should not quietly reinterpret a public authentication field. Edge can become the default while older integrations retain their contract long enough to migrate on purpose.

Elsewhere, snarkOS is making bulk readers cheaper. PR #4447 adds height-range routes for block hash, header, and state-root data. PR #4455 adds confirmed transactions over a range, preserving an empty array for a block with no confirmed transactions. Consumers no longer need to download a roughly 337 KB block, almost all authority data, merely to obtain its hash.

The REST work now has route-level tests from PR #4448. Those tests immediately paid rent: PR #4450 fixes missing resources that were reported through the wrong status path and makes v1 errors identifiable. End-to-end route tests are mundane engineering. I trust them more than a polished API diagram.

Node internals got useful fixes too. snarkVM PR #3438 prevents speculative public-fee reads from blocking atomic_speculate on the same per-map mutex. Fleet data had shown 21 to 23 of 30 validators stalling together for about 50 seconds while the affected thread consumed almost no CPU. PR #3436 adds connect and stall bounds to remote parameter downloads, so a dead mirror cannot leave startup parked forever.

Leo shipped 4.4.4. Its focused fix reconstructs local dependency constructors before generic helpers are removed or program scopes are assembled. The previous ordering could panic during constructor checksum generation when local dependencies called shared helpers or resolved generic arguments later in compilation. Small release. Good fix.

Ecosystem rails get practical

Kraken enabled USDCx deposits and withdrawals on Aleo on September 16. USDCx is backed 1:1 by USDC held in Circle xReserve. Minting and redemption use cryptographic attestations tied to the Circle-managed contract rather than a conventional third-party bridge.

Direct exchange funding removes a tedious hop. A user can withdraw USDCx onto Aleo without first sourcing another asset, moving it to a separate venue, then finding a bridge. Fewer steps mean fewer addresses to mistype and fewer services that can pause the route.

Privacy applies on Aleo. Kraken states that sender, receiver, and amount are encrypted by default for USDCx transactions on the network; the same asset on another network does not inherit Aleo's privacy properties. That boundary matters for payroll and vendor settlement, where revealing a payment graph can expose salaries or commercial relationships.

Funding support does not mean every Kraken feature is live everywhere. Geographic restrictions can apply, and app trading waits for Kraken's liquidity conditions. Users must select the Aleo network when depositing. Sending through an unsupported network can lose the funds.

The listing also gives Shield Swap a more believable funding path. Private markets need usable entry and exit rails. Protocol design alone cannot fix a stablecoin that is awkward to acquire.

No fresh Aleo governance vote surfaced in the repository activity reviewed for this digest. The concrete governance-adjacent change is ARC-0022 PR #144, which exports MerkleProof, IARC22, and IARC22Freezelist for Leo 4.4.3 consumers while keeping helpers and constants private. That is interface maintenance, not a policy decision, and it should be described that way.

A wider pattern connects the week's work. Privacy infrastructure is being judged by its operational edges now: exchange custody, selective disclosure, stablecoin reserves, gateway authentication, and reproducible historical queries. Regulators and institutions care about those edges because they define who can verify what, and under which authority. Aleo's August policy work on stablecoin customer identification made a similar case for scoped disclosure rather than universal transaction exposure.

Looking ahead

Block 22,175,000 is the immediate checkpoint. Mainnet operators should be on v4.10.0 before V20 activates, then watch certificate density, leader-block spend behavior, finalization latency, and peer agreement across the boundary.

History RPC providers have a different job. They should test v4.10.1 on testnet, measure the added upstream latency, and decide what error contract clients receive when Provable's historical service is unreachable. Returning stale local data is no longer an acceptable fallback.

SDK users should inventory explicit and implicit gateway configuration before taking v0.11.10. Record which host receives each authentication mode, retain a regression test for injected JWTs, update network policy for edge.provable.com, and pin the package version during rollout.

Kraken's USDCx route is live now. The next useful evidence will be boring and measurable: reliable deposits, predictable withdrawals, enough liquidity for trading, and wallets that make the network choice hard to get wrong.