After Midnight

The Compact language reference describes witness data as private and requires a declaration when witness-derived influence reaches a public result. The witness-protection pass performs an abstract interpretation over that influence.

In the compiler source, disclose() clears the wrapped expression’s witness taint and the next compiler pass removes the syntax. In the paired 0.31.1 fixture, emitted JavaScript and ZKIR contain the ledger assignment without the wrapper.

The paired test covers a direct witness-to-ledger assignment. The compiler pass operates over a broader dataflow graph whose conclusions depend on imported interface annotations. Asymmetric access, mandatory revelation, and compliance interfaces arise later through circuit design, credentials, key distribution, and services.

Compact tracks dataflow represented in source and trusts the disclosure annotations exposed by imported interfaces. The language reference warns that a call into another contract can disclose a witness-derived value when the callee’s interface permits it. Cross-contract behaviour, external services, wallet state, and key custody sit outside that compiler view.

disclose() governs compiler permission, a viewing key governs ciphertext discovery, and an application credential governs the proposition released. Each mechanism assigns authority at a different layer.

Where compilation settles whether witness-derived influence may reach a public result, transaction construction settles which process receives the material needed to prove it.

The ProofPreimage type includes direct inputs, a private transcript described in source as the private witness vector, public transcript inputs and outputs, a binding input, the communications commitment and its randomness, and a verifier-key location. The WebAssembly boundary serializes that structure before a provider call.

Midnight.js documents UnsubmittedTxData as privacy-sensitive in its transaction model, and describes its unprovenTx as material the proofs were designed to keep confidential.

The Midnight.js HTTP proof-provider client packages the serialized preimage and sends it to /check or /prove. The client accepts HTTP and HTTPS, which makes remote preimage delivery possible, and warns when a remote URL uses HTTP. Endpoint ownership and transport security are deployment properties.

The wallet takes a materially different route. Its WebAssembly prover constructs proofs in a browser worker after obtaining circuit material and parameters. The preimage enters a worker on the selected device. The application source records identify HTTP-provider construction from a connected wallet’s prover URI in the ZKLoan and Leaderboard browser paths. Live endpoint selection remains unobserved, leaving the route taken by any deployed instance outside this record.

The process receiving the preimage belongs inside the privacy boundary. Its operator, endpoint selection, authentication, transport, logging, crash reporting, browser environment, proxies, and cloud controls determine the custody actually delivered.

Proof generation can keep witness material outside verifier view while wallet discovery later grants decryption capability to another process.

The examined indexer exposes a connect(viewingKey) mutation that returns a session identifier. Its API decoder accepts a Bech32m-encoded shielded secret encryption key, deserializes it, and exposes the secret to the domain layer. At rest, the server encrypts that key with ChaCha20-Poly1305, computes a deterministic hash for deduplication, and redacts it from debug output. That hash lets the wallet storage path reconnect the same wallet record and issue a fresh session.

During indexing, the server-side path reconstructs the shielded secret key and tests whether it can decrypt the guaranteed or fallible coin material in each transaction. ChaCha20-Poly1305 covers stored bytes, while relevance testing uses the reconstructed secret in the service process.

The connect(viewingKey) mutation accepts one shielded secret encryption key and evaluates transaction relevance across the subscribed wallet stream. Project documentation describes transaction-specific disclosure, and that description differs from the granularity of this API. Transaction-selective application credentials remain possible at the application layer.

Shielded Wallet 3.0.2 follows a different synchronization path. Its synchronization source subscribes to global Zswap events using a cursor and replays them locally with the wallet’s secret keys. The unshielded wallet supplies its public address. The examined code contains a server-side viewing-key filter and a client-side event filter, each attached to its own software surface.

The indexer schema includes contract addresses, public state, maintenance authority, entry points, events, commitments, nullifiers, and ciphertexts. The ledger contains public transcripts and declared effects.

The source exposes a mixed execution surface: ciphertexts and commitments coexist with public contract state, transcripts, effects, events, and maintenance authority. Any privacy claim must name its object: witness, private state, ciphertext, commitment, nullifier, public transcript, contract state, event payload, unshielded balance, network metadata, or key custody.

A private contract remains usable only while the network accepts its verifier keys. Midnight makes that accepted set mutable through Contract Maintenance Authority.

Contract Maintenance Authority can replace its committee and insert or remove verifier keys for contract operations. The maintenance semantics apply an authorized update to an existing contract record. Its address, application ledger state, and balance can persist while the accepted verifier-key set changes.

The public guide says updatability is disabled by default. The raw ledger constructor creates an empty maintenance committee with threshold one.

The high-level Midnight.js deployment path samples a private signing key when the optional input is absent and forwards it into deploy construction. Independently, the low-level Compact.js fallback samples a signing key when its optional input is absent and constructs a one-member committee with threshold one. Application lockfiles determine which package pair a deployment actually uses.

Across the nine official application and scaffold repositories examined, every deployment call omits the optional signing key. Six repositories expose a user-facing path. Hello World, Battleship, and Private Party contain the examined calls in tests.

Seven locked repositories resolve Contracts 4.1.1 with Compact JS 2.5.1, and Counter resolves Contracts 4.0.4 with Compact JS 2.5.0. Replayed package members show that both resolved profiles generate a one-key, threshold-one authority when the signing-key input is absent. Create-mn-app declares Contracts and Protocol 4.1.1 in its template manifest. Its generated-application lockfile is unavailable.

A generated authority remains usable only while its private key is deliberately retained and protected. In the Private Party manual test function, deploy data contains the generated maintenance signing key, the test proves and submits the deployment, and the subsequent persistence call stores application private state. Nothing in the examined function persists that maintenance key.

Counter takes a different path. It encrypts private state and stored maintenance keys with a password derived from the public coin key. Password entropy derives from that public value. Base64 encoding and appended punctuation are deterministic formatting. Exploitation still requires the encrypted database and relevant public key.

Applications should publish the maintenance committee, threshold, key-generation path, storage arrangement, recovery procedure, and each verifier-key transition. Wallets and indexers should surface those records beside the contract address. Contract identification requires the address, authority history, and accepted verifier-key set.

The examined node source starts AURA for block authorship, GRANDPA for finality, and the BEEFY commitment service. Its authority-selection path consumes Cardano-derived candidate registrations, permissioned-candidate data, and an epoch nonce.

The selection code combines the Cardano epoch nonce with the Midnight epoch and draws from registered and permissioned candidates. That source tree’s production profile includes a Cardano node, db-sync, and Postgres. The follower failure paths stop proposal construction when Cardano data is stale. Verification retries an indeterminate Cardano reference and rejects after its configured retry count.

The system-parameter pallet stores the Midnight-side D parameter, which supplies the registered and permissioned seat counts used in committee selection, and gives Root authority to update it. Authority selection consumes those counts alongside the Cardano-derived inputs.

A point-in-time mainnet observation ran from 2026-07-27 00:00:29 through 00:01:31 UTC and reached finalized head 1,866,780, Cardano epoch 645, and sidechain epoch 991728. The queries returned 130 permissioned entries, zero registered entries, and thirteen distinct sidechain keys, each repeated ten times. D-parameter and AURA results refer to finalized block 1,866,780. Committee and Ariadne results refer to the reported epochs. A GRANDPA authority result and the original response bodies are unavailable.

The thirteen keys identify cryptographic identities. Operator control, beneficial ownership, and organizational independence remain unresolved. The May 2026 tokenomics whitepaper separately says that thirteen institutional-grade operators produced blocks at launch, including two operated by the Foundation and eleven operated by parties contracted by it (physical page 50, printed page 49). The whitepaper does not map those operators to the observed keys.

The examined mainnet chain specification lists six Council keys and nine Technical Committee keys. The development runtime requires at least two thirds of each body and approval from both bodies before dispatching as Root. That same source path can change system parameters and replace the Cardano addresses or policy identifiers used for governance observation. Live membership and source-to-runtime correspondence remain unresolved, which confines these counts and thresholds to the examined specification and the development runtime rather than to the membership in force at any observed block.

The May 2026 text of proposed MPS-0030 describes a small federated committee and treats permissionless entry, quantitative takeover thresholds, and recovery under shrinking participation as ongoing research and implementation work. Development source contains registered-stake-pool machinery, and live registered participation remains unverified.

The development runtime source also disables its on-chain GRANDPA and BEEFY equivocation-report paths. Off-chain detection and deployed runtime correspondence remain unresolved.

The development branch contains features absent from the source candidate indicated by the node’s client metadata. Available repository history leaves their ancestry unresolved. Until a reproducible client and runtime mapping exists, either tree can describe possible implementation behaviour without identifying the code executed on the observed network.

Project documentation distinguishes two Cardano-to-Midnight paths. In a User Transfer, Cardano-side cNIGHT sent to the illiquid-circulation-supply (ICS) address makes the corresponding Midnight-side mNIGHT, less fees, claimable by the recipient. The documented Reserve Transfer path releases corresponding mNIGHT from the Midnight Reserve for block rewards. The handler in the source candidate indicated by client metadata maps valid user, reserve, and invalid-recipient cases into ledger system transactions.

At 2026-07-27 00:00:41 UTC, the checkpoint query for finalized block 1,866,780 returned 0x00, or SCALE-encoded None. The provider in the source candidate indicated by client metadata enters Inert when the checkpoint or main-chain script configuration is absent. Runtime identity, raw response bytes, and source-to-Wasm correspondence remain unavailable.

The Cardano deployment report identifies reserve and illiquid-supply validator hashes. In the examined reserve-contract source, logic_merge accumulates Cardano ADA and cNIGHT from all consumed inputs at the guarded credential. It then requires a continuing output at the guarded address to retain at least those accumulated amounts.

At 2026-07-27 00:01:42 UTC, the Cardano observation records the original outputs as unspent and reported logic hashes as matching the deployment report. Cardano and Midnight were queried separately. If the Cardano state is accurate at its observation time and the reported hash identifies the deployed validator logic, a direct Reserve-to-ICS decrease fails the cited preservation rule. Neither an atomic cross-chain observation nor a preserved raw Koios response is available.

The development branch contains a dedicated bridge pallet, governance-approved Cardano transaction hashes, and Treasury routing for unapproved User Transfers. The source candidate indicated by client metadata contains invalid-recipient routing and predates the approval-set surface. Runtime identity is unresolved for both, which leaves each tree a candidate description of implementation behaviour rather than a record of the code executed at the observed head.

A later checkpoint or validator upgrade can change these conditions. A present-state claim requires fresh Midnight and Cardano observations, preserved raw responses, and executable source correspondence.

The Kachina model formalizes private smart contracts through a state-transition function, explicit leakage, and dependency functions. Its central theorem applies to a defined contract class in an ideal non-interactive zero-knowledge (NIZK) hybrid world over a simplified ledger. Concrete constructions outside the core class require a separate equivalence or emulation argument. The paper limits its general interaction treatment to small closed sets of non-malicious contracts and describes the design as largely theoretical.

Kachina’s theorem ranges over its own contract class, leakage model, and simplified ledger. Applying it to Compact, ZKIR, the prover stack, wallet custody, indexer behaviour, the consensus runtime, or arbitrary contract composition requires a refinement argument that is currently absent.

The ledger specification excludes a security proof for complete Midnight behaviour and leaves system transactions, cost, events, and concrete formats incomplete. The implementation has private and public transcript structures and declared effects. Structural resemblance supplies no refinement proof from that implementation to Kachina’s model.

The examined Zswap implementation contains segments, contract-owned coins, transient coins, and an intent structure. Because the cited 2022 Zswap paper was unavailable in a form that allowed stable page-level verification, no claim here depends on its theorem statements. The implementation’s source shape cannot substitute for the proof scope of that paper.

The proof implementation record describes a customized PLONK-family system using the Kate–Zaverucha–Goldberg (KZG) polynomial-commitment scheme over the BLS12-381 curve and a historical relationship to Halo2 components. Its security case must address the customized transcript, commitment, challenge, and recursion code actually present.

The Compact 0.31.1 fixture records one enforceable boundary: an unmarked witness-derived ledger write is rejected. From that point onward, privacy depends on which process receives the preimage, which wallet or indexer holds discovery keys, which fields the contract emits publicly, which authority may replace verifier keys, and which network controls govern execution. Formal claims apply only where a correspondence argument connects those implementation layers to the model.

A privacy system should publish a custody statement as ordinary technical documentation:

Risk analysis follows custody. Remote proving makes the operator, transport, and service environment material, while on-device proving makes browser and device integrity material. Maintenance authority makes key custody and recovery material. Each boundary needs a named receiving process, controller, and failure mode.

The inquiry spans thirty-one public repositories covering the Compact compiler, ledger, proof system, SDK, wallet, indexer, node, architecture, applications, governance proposals, Cardano reserve contracts, partner-chain tooling, token distribution, and the Kachina source. The source records identify the exact source states and artifacts.

The application comparison follows every deployment call found in nine selected official application and scaffold repositories. ZKLoan, Leaderboard, Private Party, and Counter supply the cases on attestation, prover configuration, and key custody. The application source records preserve the package and path details behind those conclusions.

The compiler test uses the Compact 0.31.1 macOS arm64 release archive and a paired fixture that differs only by the disclose() wrapper. It inspects both the compiler result and the emitted JavaScript and ZKIR. Matching source passes were identified. Upstream release metadata and reproducible source-to-binary correspondence remain unavailable.

Formal sources include Kachina, PLONK, the proof-system version selected by the ledger lockfile, and the trusted-setup repository. Institutional and architectural context comes from the project’s tokenomics paper and proof-of-stake sidechain paper. Claims unique to the Zswap and sidechain papers are excluded because their exact editions could not be verified at page level. Independent replay of the trusted setup remains outstanding.

The network evidence is a point-in-time observation centered on finalized block 1,866,780, with committee results scoped to Cardano epoch 645 and sidechain epoch 991728. Cardano reserve state was queried separately. The original response bodies are unavailable. Reproducible compilation, deployed runtime identity, organizational ownership, atomic cross-chain state, setup replay, and formal implementation correspondence remain unresolved.

Four evidence layers carry the results above, and they do not substitute for one another. A pinned source revision establishes what code can do. An executed release archive establishes what the Compact 0.31.1 macOS arm64 binary did on the paired fixture, a result no pinned source revision attests. Retained archives and lockfiles establish which package members a declared profile resolves when an optional input is absent. A point-in-time query establishes what an endpoint returned inside its window. None of the four identifies the code that executed on the observed network, and none supports a causal claim about operator conduct or intent.

Every result above therefore holds at the layer of source capability, executed release-archive behaviour, release-mapped package resolution, or reported observation. Authority over disclosure, decryption, verifier keys, block production, and reserve movement falls inside that domain. Adoption, market structure, operator identity, the security of any deployed instance, and the behaviour of any contract this survey did not open fall outside it.

The thirteen distinct sidechain keys returned in the observed session identify cryptographic identities rather than organizations, and the tokenomics whitepaper’s operator description is not mapped to them. The nine examined applications record what official code does, and they carry no weight as a sample of third-party deployment practice. Kachina’s theorem ranges over its own contract class, leakage model, and simplified ledger, so it settles nothing about Compact, ZKIR, the prover stack, wallet custody, indexer behaviour, the consensus runtime, or arbitrary contract composition until a refinement argument connects them.

One claim carries the analysis: the Compact 0.31.1 rule rejects an unmarked witness-derived ledger write, and every mechanism after it locates authority in a named process, key holder, or committee rather than in that rule. Five observations would defeat it. Four resolve against the pinned sources or a repeated query; the fifth requires an atomic cross-chain observation that this record does not hold and that Method and Limits leaves unresolved.

The first four conditions resolve against a pinned source revision or a repeated network query rather than against a statement of intent, and the fifth waits on a preserved cross-chain record this survey did not obtain. A revised project description of proof locality, a fresh marketing claim about in-browser proving, or a governance proposal reaching a later status would leave all five findings standing.