For the complete documentation index, see llms.txt
Identity on Midnight
This page covers three identity projects in the midnightntwrk GitHub organization: Midnight Passport, the did:midnight decentralized identifier (DID) method, and the Midnight verifiable credentials libraries. They are at very different stages. You can build with did:midnight and the credentials libraries now, as 0.x packages on npm. Midnight Passport is in development, with a demo and no published SDK. The sections below explain what each project is, how it relates to Compact smart contracts and DApps, and where it stood in early October 2026.
These projects release often. Each project's section ends with a status line that records what the project's repository, documentation, and npm packages said on the date it gives. For anything newer, check the project documentation linked in each section.
Identity projects at a glance
The sections after the table explain each project. For identity checks that need none of them, see Identity in your own contracts.
| Project | What it is | Can you build with it? | Project documentation |
|---|---|---|---|
| Midnight Passport | A passkey-based identity and account layer, in development | No. Passport has no published SDK or package on npm, and its demo runs only on Stagenet, a separate test network that runs a ledger 9 release candidate. | Passport plan and status |
did:midnight | A DID method that keeps each on-chain DID Document in its own Compact smart contract | Yes, as 0.x packages on npm. The method specification is a draft. | Midnight DID documentation |
| Verifiable credentials libraries | Compact and TypeScript building blocks for credentials and presentations that circuits can check | Yes, as 0.x pre-1.0 packages on npm. You define the credential family and the trust policy. | Midnight Verifiable Credentials documentation |
Midnight Passport
Midnight Passport is a user-facing identity and account layer that Input Output is developing in the open for Midnight. In its design, a person signs up with a passkey instead of a seed phrase and gets a human-readable .night name. They can use the account from any of their devices and recover it after losing all of them. The Passport repository holds the plan, the research behind it, a reference account contract, and demos. It is not a product you can integrate.
Smart contracts. In the design, each account is a Compact smart contract that holds its owner's assets. Each device has its own key, and the contract checks a signature from an enrolled device before it moves funds. Three Midnight Improvement Proposals (MIPs) describe the core of this model: MIP-0012 for contract custody of Midnight-native assets, MIP-0013 for multi-key account authorization, and MIP-0022 for account recovery. All three have the status Proposed. In the MIP process, that means the MIP editors have not accepted them, and no network upgrade has deployed them. Passport's reference account contract builds with Compact toolchain 0.35.0 (with --feature-zkir-v3) and Compact runtime 0.20.0, which target ledger 9. It doesn't build with the versions in the compatibility matrix.
DApps. In the design, a DApp gets a scoped, revocable grant, such as a spending cap for one token. The account contract enforces that scope in its circuits. Passport has no packages on npm: the Passport SDK repository holds requirements and a draft design, and none of its packages has a release. The @midnight-ntwrk/midnight-vc-passport package on npm isn't part of Midnight Passport. It's a prerelease credential family that models a passport document as a verifiable credential. To choose a wallet for your DApp's users, see the community wallets overview.
Demo. The latest release in the Passport demo repository is v5.2 (29 September 2026). It runs only on Stagenet, a separate Midnight test network that runs a ledger 9 release candidate. Because the demo is a ledger 9 build, it can't open accounts on Preview or Preprod, which run ledger 8. It refuses Mainnet by design, because its signing keys come from browser passkeys. The demo repository describes it as a working prototype, not the final product, and not audited.
Relation to the other projects. Selective disclosure of a person's attributes is one of the promises in Passport's v1.0 plan. The project's status file of 1 October 2026 says a Passport integration with Midnight DIDs and verifiable credentials is not complete.
Status on 9 October 2026: in development. The project's status file, dated 1 October 2026, lists SDK integration, interoperability, cryptographic review, and formal assurance as active work. MIP-0012, MIP-0013, and MIP-0022 have the status Proposed, the SDK is at the planning and specification stage, and the demo runs only on Stagenet.
Decentralized identifiers (did:midnight)
A decentralized identifier (DID) is an identifier that its controller creates and updates without a central registry. It resolves to a DID Document that lists public keys and service endpoints. The did:midnight method is a DID method for Midnight, with a reference implementation in the midnightntwrk/midnight-did repository. Its method specification is a draft that targets a method-specific profile of W3C DID Core 1.0. The project notes that its conformance evidence has a limited scope and isn't a W3C certification or endorsement.
Smart contracts. Creating a ledger-backed did:midnight DID deploys a new instance of the DID contract, a Compact smart contract. The contract's address becomes the identifier. The contract's public ledger state holds everything needed to rebuild the DID Document, including its keys, verification relationships, and services. Each update is a circuit call that the controller authorizes with a Jubjub Schnorr signature over that exact operation. Recovering the controller key is the one exception: a separate recovery key authorizes it. The DID API makes the controller's signature locally, with a controller secret that it stores as private state. The controller's secret key never goes on-chain or to a proof server, and holding the contract's proving keys doesn't let anyone else update the DID.
A did:midnight identifier takes one of these forms:
did:midnight:<network>:<contract-address>
did:midnight:offchain:<state-hash>
did:midnight:offchain:<state-hash>:<encoded-state>
In the first form, <network> is undeployed, devnet, testnet, mainnet, preview, or preprod. The <contract-address> is the contract address as 64 lowercase hexadecimal characters. The offchain forms identify a DID Document whose state never goes to the ledger. The short form carries only a hash of that state. The long form also carries the encoded state, so it resolves on its own. For the encoding, see section 2.1 of the specification.
DApps. Create, update, and resolve DIDs through the TypeScript API in @midnight-ntwrk/midnight-did-api. The project's README says integrators must not call the contract's exported mutation circuits directly, because the API validates inputs that the contract can't check. A separate repository, midnightntwrk/midnight-did-resolver, holds a resolver service and a DID manager. Both are release candidates with public Docker images, and the repository's Docker demo is for evaluation, not production deployment.
Privacy. A DID Document on the ledger is public and linkable by design. Anyone can resolve it, and its contract address ties every update to the same identifier. The specification says DID Documents must not carry personal data, including in service endpoints and aliases. It recommends binding a DID to a real-world identity with verifiable credentials instead. Where linkability matters, use a separate DID for each unrelated context. An offchain long-form DID isn't private either: anyone who sees it can decode the state it carries.
Getting started. The packages install from npm and need Node.js 24 or later. The project built the published DID contract with Compact toolchain 0.31.1, and the contract checks for Compact runtime 0.16.0. Those are the versions in the compatibility matrix for Preview, Preprod, and Mainnet. The project's quickstart creates a DID on a local standalone network, adds keys, and resolves the DID Document. If you install from npm instead of a source checkout, the quickstart sends you to the 0.6.0 packages. Version 0.7.0 changes the encoding of Jubjub key coordinates, so also read the project's Migrating to 0.7 guide.
The DID API's built-in endpoint profiles don't cover every network. There's no Preview profile. The Preprod and Mainnet profiles still point at the Midnight-hosted endpoints, which Midnight has retired. On 13 October 2026, the hosted indexers for both networks answered every request with an HTTP 410 ENDPOINT_DECOMMISSIONED error. For the endpoints to use instead, see Migrating from the Midnight-hosted endpoints. To change a profile's endpoints, pass them in code to ProfileConfig, or to MainnetConfig for Mainnet. The project's network endpoints page lists the profiles and their default endpoints. The environment variables on that page are the names the project's examples use, and the API doesn't read them. The project's compatibility page gives the full tested baseline.
Status on 3 October 2026: version 0.7.0 (21 September 2026) of @midnight-ntwrk/midnight-did, @midnight-ntwrk/midnight-did-api, @midnight-ntwrk/midnight-did-contract, @midnight-ntwrk/midnight-did-domain, and @midnight-ntwrk/midnight-did-jubjub-schnorr. The method specification is a draft. The project's security policy says its CI, scanning, and reviews are not a substitute for an independent production security audit. The resolver and DID manager are at release candidate 0.1.0-rc.3.
Verifiable credentials
A verifiable credential is a set of claims that an issuer signs about a subject. The holder keeps the credential and later presents it, or a proof about it, to a verifier. The Midnight Verifiable Credentials project publishes a core specification and three packages for credentials and presentations that Compact circuits can check:
@midnight-ntwrk/credential-model: TypeScript metadata and validation for credential families and their claim schemas.@midnight-ntwrk/credential-compact: Compact structures and proof checks that your contract includes. It's a library, not a deployable contract.@midnight-ntwrk/credential-did-midnight: an optional binding that checks a credential's signing key against adid:midnightverification method that your application resolves and passes in. On ledger 8, its circuits can't call the DID contract, so they don't show that the method is still current.
Smart contracts. Your contract includes the credential-compact source and checks, in a circuit, that a Jubjub Schnorr signature covers the exact credential or presentation body. Each signature belongs to one context, such as issuance or presentation, and a signature made for one context fails in any other. The packages also provide holder and status bindings. Your credential family defines the claims, classifies each one as direct, selectively disclosed, committed, or predicate-only, and implements its predicates. In credential-model metadata, each claim's disclosure is public, selective, committed, or predicate-only. A predicate proves a statement about a claim, such as an age being over a threshold, without disclosing the claim.
What it leaves to you. A valid proof shows only that a given Jubjub key signed the exact body. It doesn't show that the issuer is trustworthy or that the issuer's DID authorizes the key. It also doesn't show that the credential is still valid or that a presentation is fresh. Your application decides which issuers and verifiers to trust, and it handles credential status, replay protection, trusted time, transport, and wallets. The specification defines no issuance or presentation protocol, wallet, or DApp Connector API. The project's composition guide adds that on ledger 8, synchronous cross-contract calls aren't available. A contract that consumes credentials keeps its trusted signer decisions in its own state instead.
Getting started. The packages are ESM-only pre-1.0 APIs that need Node.js 24 or later. The Compact source in 0.2.0 and 0.3.0 compiles with Compact toolchain 0.31.1, the version in the compatibility matrix. Toolchains 0.34.0 and 0.35.0, which target ledger 9, reject it with a type error in proofs.compact: incompatible types Field and Uint<0..1> for equality operator. Running compact update without a version installs the newest toolchain, which was 0.35.0 on 3 October 2026. To install 0.31.1 and make it your default, run compact update 0.31.1. The project's quickstart installs one exact stable version with pnpm add -E and describes a separate, guarded path for evaluating the npm rc tag. On 9 October 2026, the quickstart's commands still pinned 0.2.0, and the npm latest tag was 0.3.0. Pin exact versions, as the quickstart advises.
Status on 5 October 2026: version 0.3.0 (5 October 2026) of @midnight-ntwrk/credential-model, @midnight-ntwrk/credential-compact, and @midnight-ntwrk/credential-did-midnight, with 0.3.0-rc1 (29 September 2026) still under the npm rc tag. Versions 0.2.0 and 0.3.0 both target Compact runtime 0.16.0. The core specification is a normative working draft, version 0.2.
Identity in your own contracts
Many identity checks don't need any of these projects. You can build them into your own Compact contract with these patterns:
- Authenticating a caller with a derived identity: let only one caller run a circuit, by deriving the caller's identity from a secret that only they know.
- Restricting a circuit to a group: let any member of a group run a circuit without revealing which member.
- ZK Loan attestation API: accept data that a trusted party vouches for, by verifying the party's Jubjub Schnorr signature in a circuit. The tutorial writes this pattern by hand and doesn't use the credentials packages or their formats.