An account that is a name, not a seed phrase
Midnight Passport is the identity and account layer for the Midnight network. You are alice.passport.night: created with a passkey instead of a seed phrase, usable from any of your devices, recoverable after losing all of them, and held by a contract that only your proofs can move. This site shows how the system works and exactly where the work stands.
Four things that are true right now
The account standards are upstream
MIP-0012 (contract custody) and MIP-0013 (multi-key authorisation) are published in the Midnight improvement-proposal repository as Proposed, with a reference implementation whose conformance suites pass.
Standards → ValidatedZero-token onboarding works
A user holding no tokens at all had their account contract deployed and their first calls paid by a sponsor, end to end on a production node. No airdrop prerequisite exists.
The sponsorship experiment ↗ ValidatedLosing every device is survivable
The recovery reference tranche is merged. Guardians retain their own keys, with no per-account shares to store; a two-phase signature gate and veto window precede finalisation. Upstream proposal #339 and integration review remain open.
How recovery works → In deliveryDemo v5.2 is released
Published 29 September with browser installation guidance. Staging and production expose its build marker; release notes and deployment-workflow provenance need reconciliation. Reference feature PRs are still in review.
Release and integration status →Three doors, by role
Midnight Foundation & partners
- Where the work stands — standards, components, and the dated evidence trail.
- The demo release status — current observations and integration work.
- What we need from the ecosystem — four concrete asks.
Wallet & dApp engineers
- How a Passport account works — the whole system on one screen, then the lifecycle.
- Start implementing — the reading order and the reference implementation.
- The architecture map — where the components live and who they talk to.
Standards community
- The MIP register — every proposal, its upstream lifecycle, and its evidence.
- Comment upstream — review is what moves the keystone pair toward acceptance.
- The full plan — the promises, each component’s design record (its canvas), the dependencies, and the open decisions.
Where the work stands
A component is specified when a standard or draft documents its design, decided when a choice is recorded, an open decision when the design space is still live, and in design otherwise. These labels do not imply implementation, release or completed review; the linked evidence and upstream lifecycle record those separately.
Full 1 October reconciliation: issues, PRs, releases and next actions ↗
Compact 0.35 baseline
Recovery, unshielded grant evidence and key-regeneration drafts are also on main. Deployment waves retain the 15,000-byte verifier budget.
Open PR #175Real passkey account control
A Safari passkey approved an account-key rotation on localnet under the bounded WebAuthn profile. Broader browser and PRF support remain.
Open PR #176Caller-bound grants
Immediate-caller pins passed on-node checks, including refusal of a fabricated-caller proof. Schema v3 and P-256 integration need review.
Draft PR #177Viewing-key sharing
192-byte inbox envelopes restored test devices that spent before and after rotation. Automated PASS with software credentials and synthetic PRF. Nicolas reviews the draft first; a dApp/grant journey is separate work.
The evidence trail
Newest first; every entry is backed by an artefact — an experiment against a real node, a merge in the upstream proposal repository, or a decision record. Component chips open the component’s design record (its canvas) in place; experiment links go to the code.
Show the earlier evidence
What we need from the ecosystem
Adoption is the point: a standard nobody else implements is shelfware. These are the four concrete things the wider ecosystem can do next.
Acquire passport.night
The decided name shape (alice.passport.night) hangs on the Foundation holding the parent domain in the upstream name service and offering sub-domains free, first come, first served.
Review MIP-0012 and MIP-0013
Both keystone standards are open for comment upstream, with the errata the implementation surfaced already folded in; ecosystem review is what moves them toward acceptance.
The register, with upstream links →Build the second implementation
The reference implementation exists and its conformance suites pass. A second, independent implementation by another team is the remaining evidence the standards’ path to Active calls for.
Start here →Sponsors, committees, reviews
Zero-token onboarding needs a substitutable sponsor-operator model; the signing standard needs a FROST committee demonstration and its cryptographer review.
Engage: comment in the upstream discussions ↗ where the standards live, or open a workspace issue ↗. The full engagement surface, with direct links to each proposal, is on Standards.