After Midnight

Midnight’s compiler can reject an unmarked flow from a private witness to public state while a proof provider receives the material needed to construct the proof. A replay of the Compact 0.31.1 release reproduces this protection through assignments, helpers, conditional effects and exported results. Immutable source and application-lock records trace custody outside that compiler rule. A verifier can learn little from a proof while an indexer receives a discovery key. A contract can also preserve its address while a maintenance authority changes its accepted verifier keys. Network responses add a dated observation of authority configuration to this reconstruction. Privacy depends on the relation among information, receiving processes and authorized uses. The findings establish specific capabilities and configuration differences; they do not infer ecosystem prevalence, institutional intent or the security of deployed applications from source alone.

Midnight’s Compact language treats witness-derived information as private for the purposes of its source analysis and requires explicit permission when that influence reaches a public result. This is a substantive protection. The existence of disclose() does not establish that disclosure is the default, nor that institutional access is unavoidable.

The broader question begins with a distinction between permission and custody. A developer can authorize a public result without intending to send the underlying witness to another organization. A user can keep a secret outside the verifier’s view while delegating proof construction to a service that receives private inputs. A viewing key can make records discoverable without changing the ledger’s ciphertext. Each arrangement creates a different relation among the information, its holder and a receiving process.

Nissenbaum’s contextual-integrity account helps specify what a purely private/public classification leaves unresolved: appropriate information use depends on the context and its norms of collection and distribution (Nissenbaum 2004). The analysis here does not adjudicate those norms for every Midnight application. It identifies the technical transfers to which such an assessment must attach: which attributes travel, to which process, under whose control and for which operation. Encryption and proof verification address parts of that problem, and their boundaries need to remain visible.

Local proving can keep witness material near the holder, while a remote prover can be deliberately selected and appropriately governed. A maintenance authority can preserve a contract through cryptographic changes while creating responsibilities for key protection and review. Agency depends in part on how an application allocates those capacities. Source paths identify the available arrangements; observing the deployed application establishes which one it uses.

The Compact witness-protection pass tracks witness-derived influence through the source program. A later pass removes the disclose() wrapper from the compiled representation (policy record; removal record). The wrapper marks a flow as permitted by the analysis; it is not itself a decryption operation or a transmission to an institution.

A controlled replay downloaded the official Compact 0.31.1 macOS arm64 release archive. Its SHA256, 57af9b0449aa96b2905ea3d7a175b6b42ab38d725612a9cb2d73eb4ef253cce2, matched the release API’s published digest. Both fixture programs declare a Uint<64> witness and assign its return value to exported ledger state. They differ only in wrapping the right-hand side in disclose().

Eight additional fixtures extend the result beyond a direct assignment. The same compiler rejects unmarked witness influence passed through a helper into ledger state, used to select between public ledger effects, or returned from an exported circuit. The corresponding disclosed forms compile. A private intermediate and an assertion constraining a witness also compile. The diagnostics identify undeclared disclosure rather than a syntax or type error.

These outcomes distinguish protected public outputs from permitted private computation and proof constraints. Successful proof verification can itself communicate that a constraint was satisfied, so the source check must not be read as a promise that every proposition about a witness remains hidden.

The ten fixture commands used --skip-zk, so these are compilation and emitted-representation results. The experiments do not test proof generation, circuit soundness or transaction execution. The archive and binary identity are recorded for reproduction; matching compiler passes at the cited source pin do not establish a reproducible source-to-release build.

Compact’s analysis also has an interface boundary. Imported annotations determine how a caller’s witness influence is treated, and the reference warns that another contract’s interface can permit disclosure. The selected flow tests do not prove the behavior of arbitrary contract composition, side channels, wallet state or external services.

The cited ledger’s ProofPreimage contains direct inputs, a private transcript described as the witness vector, public transcript material, binding input, a communications commitment and randomness, and a verifier-key location. The WebAssembly boundary serializes that structure before a provider call (type record; serialization record). Midnight.js labels the corresponding unsubmitted transaction data privacy-sensitive.

Two source paths locate that material differently. The wallet’s WebAssembly prover constructs a proof in a browser worker. The Midnight.js HTTP provider sends a serialized preimage to /check or /prove and accepts loopback or remote destinations. Its warning for remote plain HTTP does not establish who operates an HTTPS endpoint, what it records or which surrounding services can access the process (worker record; HTTP provider record).

Zero knowledge limits what the verifier learns from the proof under its security assumptions. It does not, by itself, conceal the preimage from the process entrusted to construct that proof. Conversely, an HTTP-provider capability does not establish that a deployed application sends secrets to a remote operator. Endpoint selection must be observed at the relevant deployment.

The official ZKLoan and Leaderboard examples illustrate this distinction. Their examined browser paths construct an HTTP proof provider from the connected wallet’s prover URI. Statements about data remaining on the user’s machine therefore require an account of that selected URI and its locality, rather than an inference from the presence of zero-knowledge code (ZKLoan record; Leaderboard record).

ZKLoan also supplies an epistemic boundary. Its example attestation API checks field presence and signs caller-supplied credit attributes; its circuit verifies a signature under the registered provider key. The signature establishes a relation to that key. Establishing the truth of the attributes requires a separate attestation basis. The examined handler contains no authentication step, but this source observation is not a report of an exploited production service (API record; circuit record).

The cited indexer exposes a connect(viewingKey) mutation accepting a shielded secret encryption key and returning a session identifier. It encrypts stored key material, hashes it for deduplication and reconstructs the secret during server-side relevance tests. At-rest encryption protects one storage boundary; processing the reconstructed key is another (decoder record; storage record; scan record).

A wallet-session key used to test transaction relevance differs from a token revealing one selected transaction or proposition. Transaction-selective credentials can be designed at the application layer, but their properties cannot be read into a session API accepting a broader discovery key. “Selective disclosure” needs an object and a scope.

The examined Shielded Wallet 3.0.2 code takes another path: it subscribes to global Zswap events using a cursor and filters locally with wallet secrets. The unshielded wallet supplies its public address (local filtering record). These source paths provide alternatives with different custody arrangements. They establish neither the proportion of users on each route nor a ranking of deployed wallet privacy.

Public and concealed fields also coexist. The cited indexer schema exposes contract addresses, public state, entry points, events, commitments, nullifiers, ciphertexts and maintenance authority. Public transcripts carry declared effects. An application can protect witness contents while making other relations observable. Evaluating that design requires specifying the protected attribute and the information available in the surrounding record (public surface record).

A private contract remains usable only while the network accepts the relevant proving and verification machinery. Midnight’s Contract Maintenance Authority can change its committee and insert or remove verifier keys. The cited semantics permit the contract address, application ledger state and balance to persist across an authorized key change (capability record). Address continuity therefore does not identify an unchanged accepted circuit.

The default depends on the entry point. The raw ledger constructor creates an empty maintenance committee with threshold one, which cannot authorize an update. The cited high-level deployment helper samples a signing key when its optional input is omitted. The resolved Compact.js package also implements a one-member, threshold-one authority in that case (ledger record; helper record; package record).

A new retrieval reconstructed nine selected deployment sites in official application and scaffold repositories. Each selected call omits the optional signing key. Eight repositories supply a lockfile: seven resolve Contracts 4.1.1 and Compact.js 2.5.1; Counter resolves Contracts 4.0.4 and Compact.js 2.5.0. The corresponding package archives and integrity values were recovered, and their implementing members were re-extracted. Create-mn-app’s template declares package versions, but a generated application’s lockfile is unavailable. This is a purposive source comparison, including test paths, not an ecosystem prevalence estimate.

The arrangement carries a continuity obligation as well as an authority. Generating a key is not the same as retaining it. The examined Private Party manual test receives a maintenance signing key, proves and submits the deployment, and then persists application private state without persisting that key in the same function. That identifies a handoff to examine, rather than establishing an actual lost-key incident or the behavior of every surrounding program (key custody record).

Counter presents a different issue. Its cited storage password is derived deterministically from a public coin key. The resolved private-state provider encrypts private state and stored maintenance keys through that password-backed layer and warns against public material. Obtaining an encrypted database and the relevant public key remains necessary for the exposure described by this design observation (password record). No exploitation or deployed-user impact is established.

The institutional question is how an application makes this authority understandable and durable. A custody statement should identify the committee, threshold, key-generation and storage path, recovery arrangement and verifier-key history. A user deciding whether to rely on a contract needs more than its address; the authority capable of changing its accepted operation matters as well.

The source chain extends beyond the application. The cited node starts AURA, GRANDPA and BEEFY services. Its selection machinery consumes Cardano candidate data and an epoch nonce alongside Midnight’s D parameter. Development code gives Root authority over system parameters and supports federated approval through Council and Technical Committee bodies. These are source-level mechanisms; the cited chain specification’s keys and thresholds are not automatically the deployed membership at a later block (service record; selection record; governance record).

The new network collection preserves a more complete point-in-time observation. The responding endpoint returned finalized hash 0x8eb072a6592b2d6e91767580a892918b25893ce60e356086c631a25687dec3b0, whose header number was 3,060,710. Fixed-hash calls returned runtime specVersion 1000300 and code hash 0x39568eeb0802fa59d74ac0bc5c7ab62fc05c23ea947937458a4b011558516138. The node reported client version 1.0.400-c338b9ac. The public repository API did not resolve that client suffix; no source-to-runtime bridge is inferred.

At that hash, D specified 130 permissioned entries and zero registered entries. AURA and GRANDPA runtime API responses each decoded to 130 authority entries under 13 distinct keys, each occurring ten times; GRANDPA’s entries carried unit weights. An epoch-scoped committee response separately reported the same multiplicity. Authority entries are not independent organizations. The result makes that measurement distinction concrete without alleging an attack or identifying control of the keys.

The freshly retained tokenomics PDF identifies itself as May 2026, version 1.81. On printed page 45, physical PDF page 46, it states that the Foundation operates two of thirteen federated nodes and contracts and pays the other operators (Midnight Network 2026, 45). This is the project’s institutional account, not an independently reconstructed mapping from organizations to the queried cryptographic keys. Both records matter, and their relation remains unverified.

Public-service access changed during the same period. The current documentation source says the Midnight-hosted Mainnet and Preprod endpoints were retired and directs users to token-authenticated Blockfrost services. The live documentation request returned 429; the exact repository source at 61f60097aef76c946a151b4bbb9357af7cf5123f was recovered instead. The documentation also says the old Mainnet RPC may continue answering temporarily. It did answer the observation above. Availability of that retired endpoint does not establish a supported future access route.

This migration is relevant to provisioning and access, while proving custody remains a separate question. A provider serving public state is not thereby shown to receive a user’s proof preimage or discovery key. A complete application account must connect its node, indexer, prover and wallet paths rather than infer one recipient from another service’s hostname.

Kachina formalizes a class of private smart contracts through state transition, explicit leakage and dependency functions in an ideal NIZK setting over a simplified ledger. Its stated interaction and construction limits matter when connecting that model to implementation (Kerber et al. 2021; model records). A refinement argument from Compact, ZKIR, the prover, wallet, indexer and runtime to that model is not established by this study. Structural resemblance supplies no such argument.

The ledger specification itself excludes a proof of complete Midnight behavior and leaves parts of the system outside its scope. The implementation contains private/public transcripts, declared effects and a richer Zswap structure. Zswap supplies a relevant distinction between stages of information use: partial swap transactions expose the asset imbalances needed for matching, while balanced transactions conceal amounts and types under its model. Its authors leave integration with private smart contracts as an open question (Engelmann et al. 2022, 508–509). That result concerns the specified transaction construction and adversarial view; it establishes no correspondence with the current Midnight implementation or the custody of an application’s proving material.

Cryptographic and audit records deserve equally specific treatment. The pinned proof family uses PLONK-related machinery and KZG commitments over BLS12-381. Fixed proof constants for particular Zswap and DUST operations do not establish constant size for arbitrary contract proofs. A development IVC module’s stated folded-step behavior does not establish its integration into the separately examined ledger lock. The trusted-setup repository documents ceremony lineage and a verification procedure; its full multi-gigabyte contribution chain was not replayed here. Remediation notes and unaudited-library disclaimers describe named scopes and revisions (Gabizon et al. 2019; proof record; dependency record; setup record; audit record).

The compiler fixtures establish selected source-analysis behavior, package members identify default-generation code, and live responses record what one endpoint returned for a fixed hash and named epochs. Joining those observations into an application privacy claim still requires the application’s actual information path.

The method combines release-compiler fixtures, pinned source paths, application lockfiles and package members, and dated network responses. These establish different parts of the information path: permitted source influence, material supplied to a prover, discovery-key processing, maintenance defaults and returned authority configuration. The comparisons do not join those parts into an observed deployed application.

The application comparison follows nine selected official deployment call sites, including tutorials and tests. It establishes neither dominant third-party practice nor private-state handling in a deployed instance. The compiler experiments comprise ten fixtures on a named macOS release: four rejected unmarked flows and six accepted disclosed, private-intermediate or predicate cases. They make no whole-language soundness claim. The network sample uses one still-answering retired endpoint; it is not an independent validator census, and epoch queries are kept distinct from fixed-block calls.

An application-level follow-up could join four records: its compiled public effects, the actual proof-provider destination, discovery-key custody and maintenance-authority history. That would turn an architectural possibility into an observed information path. Consent, recipient obligations, retention and recovery could then be evaluated in their application context. Separately, contract-level measurements could examine which maintenance authorities are retained, exercised or lost. Neither prevalence nor institutional motive should be supplied by a repository count.

Midnight’s compiler protection is real at the tested boundary. Programmable privacy then depends on further allocations: who constructs the proof, who can discover records, which public effects an application produces, who maintains its accepted verifier keys, and which institutions keep the network and its access services operating.

An application privacy claim must identify the information encountered by its verifier, proof service and key-holding indexer, together with the authority that can change its accepted verifier keys. Observing those arrangements would permit an assessment of agency, appropriate use and continuity in a particular application. The source reconstruction identifies what to inspect; it leaves that claim about practice open.

The cited implementation distinguishes User Transfers, which support recipient claimability, from Reserve Transfers, which distribute Midnight reserve value for block rewards. Candidate source maps a missing bridge checkpoint or main-chain script configuration to an inert provider state. Development source contains an additional approval-set mechanism. These are different source states whose relation to a deployed runtime must be established separately (flow record; configuration record).

On the Cardano side, the examined reserve validator accumulates ADA and cNIGHT from consumed inputs at the guarded credential and requires a continuing output preserving at least those amounts. That is a statement about the cited validator logic. Testing an actual Cardano transaction would require the complete inputs, outputs and relevant script identity; it does not require an atomic Midnight observation merely to evaluate the Cardano-side rule (preservation record).

A stronger joined claim about reserve consumption and Midnight issuance would need both sides' records and their correspondence. The historical July summaries recorded an empty checkpoint and an unspent Cardano reserve at separate times, but their raw responses were not retained. This revision does not promote those summaries into current bridge-state evidence or repeat them as a reproducible cross-chain observation. The source-level result remains useful: execution and continuity depend on external data and on authorities that configure how those data are recognized.