Security researchers and blockchain developers are raising alarms about a critical misunderstanding in how zero-knowledge proof systems handle identity verification, as a common pattern in Midnight smart contracts written in the Compact language leaves vaults and privileged functions wide open to exploitation — a vulnerability that compiles cleanly, raises no warnings, and can be bypassed in four straightforward steps.
The Compact Vulnerability
A deceptively logical pattern is circulating in early Midnight blockchain contracts that could expose digital assets to theft, according to a technical analysis published by developer Tosh on the DEV Community platform.
The flaw centres on ownPublicKey(), a function that many developers use to restrict access to privileged contract operations, such as withdrawals from a shared vault. The pattern stores an owner's public key on the ledger at contract initialisation, then checks ownPublicKey() against that stored key whenever a sensitive action is requested. It compiles without warnings and reads as logically sound.
It is, however, fundamentally broken.
The root cause lies in how Compact's zero-knowledge (ZK) circuit model treats ownPublicKey(). Rather than functioning as a verified identity claim, the function is compiled as a private_input — an unconstrained witness value that whoever generates the ZK proof can supply freely. The ZK proof guarantees only that a circuit was executed correctly with a consistent set of inputs; it does not verify that those inputs correspond to any real-world identity or key ownership.
In practice, this means the assertion ownPublicKey() == ledger.ownerKey compiles to a constraint that any prover can satisfy simply by supplying the owner's public key as their own private input — without possessing the corresponding private key.
The attack is straightforward. Because all ledger state in a Compact contract is publicly visible on Midnight's transparent ledger layer, an attacker can query the contract to retrieve the stored owner key. They then construct a CircuitContext — the object used to supply private inputs when generating a ZK proof — and set the ownPublicKey field to the stolen value. Since the constructor performs no signature verification, the attacker generates a valid ZK proof and submits a transaction that the contract accepts as legitimately owner-authorised.
The owner's key was never secret: it was stored in plaintext at initialisation.
Secure Alternatives
Proper access control in ZK contract systems requires cryptographic commitments that bind proof generation to actual key ownership — for instance, requiring the prover to demonstrate knowledge of a private key corresponding to a public key, rather than simply supplying the public key as a value. Developers working with Midnight and Compact are advised to review their access control patterns carefully before deployment.
A Parallel Problem in AI: Gating Model Inference
A separate but thematically related challenge is emerging in artificial intelligence research: how to restrict access to trained neural network models without encrypting weights or relying on external authentication infrastructure.
Researchers at MindMemory AI have published a paper introducing SpanKey, a lightweight mechanism that conditions a model's intermediate activations on secret keys during both training and inference. The system defines a low-dimensional key subspace using a basis matrix; valid keys lie within this subspace, while invalid keys fall outside it. Models trained with SpanKey are designed to produce useful outputs only when queried with a key from the correct subspace.
The researchers are candid about the system's limitations, acknowledging a failure mode they term "key absorption," in which the separation between valid and invalid key responses weakens. They explicitly note that their analytical results "are not a security theorem" and that the approach does not promise cryptographic guarantees.
SpanKey represents an early-stage exploration of a problem the machine learning community has not yet solved satisfactorily: how to enforce access control at the model level rather than the infrastructure level.
Analysis
Why This Matters
- The Compact vulnerability illustrates a broader risk in blockchain development: ZK proof systems provide strong mathematical guarantees, but only over the specific constraints encoded in a circuit. Developers unfamiliar with ZK internals may assume guarantees that the system was never designed to provide, leaving assets exposed despite code that appears correct.
- Both stories highlight a maturing concern across computing: as systems grow more sophisticated, access control logic must be grounded in cryptographic proof of key possession, not merely key knowledge — a distinction with significant real-world consequences.
- If SpanKey or similar approaches mature, they could meaningfully change how AI model licensing and access restriction are enforced, shifting control from cloud gatekeepers to model-level mechanisms.
Background
Zero-knowledge proofs, first described theoretically in the 1980s, allow one party to prove knowledge of a value without revealing it. Their adoption in blockchain smart contracts accelerated through the 2020s as platforms such as Ethereum, Zcash, and eventually Midnight sought to combine programmability with privacy. Midnight's Compact language was designed to make ZK-circuit programming accessible to a broader developer audience, but that accessibility brings risk: abstractions that hide circuit mechanics can also obscure the security properties — and non-properties — of built-in functions.
The misuse of identity-related functions in ZK contracts is not unique to Compact. Similar patterns have appeared in other ZK-based systems, where developers accustomed to traditional authentication models have incorrectly assumed that cryptographic functions imply verified identity. The broader ZK developer community has repeatedly flagged the gap between a function's name and its circuit semantics as a source of subtle, high-impact bugs.
In the AI domain, model access control has historically relied on API rate limiting, authentication tokens, and terms of service rather than technical enforcement. As open-weight models become more widely distributed and fine-tuning lowers barriers to capability extraction, there is growing academic and industry interest in mechanisms that enforce access restrictions within the model itself — an area sometimes called "model locking" or "inference gating."
Key Perspectives
Smart Contract Developers: Developers building on Midnight face a steep learning curve around ZK semantics. The ownPublicKey() pattern is intuitive precisely because it mirrors how access control works in traditional systems, where a username or public key is a meaningful identity anchor. The risk is highest for developers migrating from conventional Web2 or non-ZK blockchain environments.
Security Researchers: From a security standpoint, the Compact vulnerability represents a class of bugs that static analysis tools struggle to detect because the code is semantically valid — the error is conceptual, not syntactic. Researchers argue that ZK language designers have a responsibility to make unsafe patterns harder to express, or to surface warnings when potentially unconstrained private inputs are used in security-critical assertions.
Critics/Skeptics: Some in the ZK community caution that publications like Tosh's, while valuable, may give the impression that ownPublicKey() is categorically useless rather than simply misapplied. The function has legitimate uses in non-access-control contexts. On SpanKey, independent security researchers note that a system without cryptographic proofs of security is difficult to evaluate rigorously, and that determined adversaries with model access could probe for key subspace boundaries empirically.
What to Watch
- Whether Midnight's development team updates documentation or tooling to warn developers against using
ownPublicKey() for access control, or introduces a safer alternative with enforced key-possession proofs.
- Upcoming peer review and independent replication of the SpanKey experiments, particularly whether the key absorption failure mode can be reliably mitigated at scale beyond CIFAR-10 and MNIST benchmarks.
- The emergence of on-chain incidents or post-mortems involving Compact contracts that used the broken access control pattern — a real-world exploit would significantly accelerate developer education efforts.