In its announcement of the Ledger 9 upgrade, Midnight said the release adds native Keccak-256 hashing, ECDSA signatures, BIP-44 wallet derivation, contract-to-contract calls, public contract events and ZKIR V3, an upgraded format for packaging zero-knowledge programs. The same announcement says the network bypassed its normal Preprod soak period, while documentation for some capabilities is still being completed.
That combination creates a larger migration risk than a routine node upgrade. The new features expand what applications can do, but they also change the interfaces between contracts, wallets, indexers, SDKs and operational tooling.
From private transactions to contract composition
A contract-to-contract call lets one contract invoke another as part of an application flow. That matters because a financial application rarely consists of one isolated operation. A lending protocol may need to check collateral, update a position, calculate a fee and record an event. A private payment application may need to interact with an exchange, a vault or a stablecoin contract.
Under Ledger 8, developers could build privacy-preserving logic, but the ability to compose that logic directly on-chain was more limited. Ledger 9 gives contracts a native execution path for multi-step interactions. The feature does not by itself prove that an application is secure or private. It supplies the execution structure. Privacy still depends on what each contract reveals, what its zero-knowledge circuit proves and which values are made public.
Public contract events provide the other side of that structure. Events are records emitted by contract execution for applications and indexing systems to consume. They can expose a deliberately selected fact, such as a state transition or a completed action, without requiring every application state value to become public. That is useful for wallets, dashboards and compliance systems, although selective disclosure is only as precise as the event schema and the information it contains.
External signing and custody
Keccak-256 and ECDSA broaden the cryptographic vocabulary available to Midnight contracts. Keccak-256 is widely associated with Ethereum-compatible systems, while ECDSA is the signature scheme used by many existing wallets and custody platforms. Midnight said the additions are intended to make external asset connections and institutional signing systems more practical.
BIP-44 derivation standardizes how hierarchical deterministic wallets derive accounts and addresses from a seed. Adding it at the network and tooling level can reduce friction for wallet providers that already organize accounts using that convention. It does not mean every wallet or custodian becomes compatible automatically. Providers still need to implement the correct derivation path, signing flow and transaction format.
The practical result is a more plausible route toward private stablecoins, shielded decentralized finance and applications that move information or value across chains. These are use cases enabled by the interfaces, not products delivered by the upgrade itself. A stablecoin still needs issuance controls, redemption arrangements and a policy for disclosures. A shielded DeFi protocol still needs circuits that prove the required conditions without leaking more state than intended.
The migration is part of the feature
Midnight’s Ledger 9 technical release notes describe required SDK and tooling migrations alongside the ledger changes. They also identify full indexer re-indexing requirements and known issues involving shielded-coin calls, fees and verifier-key maintenance. A verifier key is the public material used to check proofs for a particular zero-knowledge circuit. If that material changes or is handled incorrectly, proof verification can fail even when the application logic is unchanged.
The indexer transition is not a cosmetic database update. The Midnight Indexer v4.4.101 release notes describe breaking database-layout changes, event indexing and a required re-index from genesis. Wallet and DApp operators therefore need to verify that their indexer version matches Ledger 9 and rebuild historical data rather than assuming an existing database can be reused.
This is particularly important for applications that treat indexer data as part of their user-facing state. A wallet balance display, transaction history or event-driven automation can appear correct while silently missing records if the indexer has not processed the new schema and event model from the beginning of the chain.
A rushed release path
The release also attracted a critical response from OpenZeppelin. In issue 836 on the Compact contracts repository, OpenZeppelin maintainer 0xisk described the Ledger 9 migration as blocking the release process because it required coordinated changes across the ledger, Midnight.js, the on-chain runtime, simulators, test utilities and live node images. The issue restricted the release to a beta tag while Mainnet remained on Ledger 8.
That is the only response identified in the supplied material, so there is no opposing view to present here. The criticism concerns coordination and release readiness, not a demonstrated failure of Ledger 9’s cryptographic design.
Midnight’s decision to bypass Preprod makes migration discipline more important. Developers should test contract-to-contract calls, event handling, wallet derivation, signature verification and proof packaging against the Ledger 9 toolchain before treating a deployment as routine. Operators should also plan the indexer re-index and validate fees, shielded-coin calls and verifier-key handling.
Ledger 9 changes the shape of Midnight’s privacy stack. Its significance lies in the connections between primitives, contracts, wallets and indexing systems. Whether that becomes a functioning private financial ecosystem will depend less on the feature list than on how carefully developers assemble and test those connections.
Jared Zimmerman is not a person. No notebook, no deadlines, no face behind the name — just a byline this newsroom publishes under. Here is the production line underneath it, because a name beside a portrait reads like a journalist, and this one is not one.
The models. Writing: gpt-5.6-luna and gpt-5.6-terra. Out on the live web: gpt-5.6-terra and gpt-5.6-luna. Pictures: gpt-image-1 and flux. Swap one in the newsroom and this line swaps with it — it is read off the machines, not typed here.
How a story is made
- Research. The searching model reads around the story, pointed at primary sources — the filing, the post, the repository — rather than at somebody else's write-up of them.
- Writing. The writing model drafts it against what was found, at Jared Zimmerman's usual length and in Jared Zimmerman's usual register.
- The loop. A reviewer reads the draft and sends it back with notes. Then reads it again. A piece can go round several times before it leaves the building.
- Enrichment. A quotation has to appear word for word on the page it is taken from. A chart may only use figures that appear in the source it cites. Whatever fails is dropped, and the reason is kept.
- Fact check. A last pass hunts for claims the article makes and its sources do not.
- A human stop. Sensitive subjects are held for a person to read before publication, and a person can kill any of it at any point.
If that sounds less like a newsroom and more like a factory: quite. It is called Press Factory.
This article was generated using AI and published automatically without human pre-publication review.
How this article was made
The article was produced by the Grandmonts Media News Engine using automated research, drafting and verification workflows. No human editor reviewed the article before publication. Grandmonts Media remains responsible for the published content. Errors can be reported at office@grandmonts.cz.