Input Output
ARC · Delivery · Continuous

Standards & feature-complete v1.0

Where the register stands: two standards published upstream (MIP-0012, contract custody; MIP-0013, multi-key account authorisation), two problem statements merged, three upstream standards adopted, and six proposals in the pipeline, two of them drafted (signature schemes; scoped grants and dApp connection). Every MIP (Midnight Improvement Proposal) names an external co-author or committed reviewer from the start, so what we ratify is a shared standard, portable across wallets; cryptographer and formal-methods reviews are scheduled against component stability, not against a Passport-internal calendar.

The demo and the standards are one body of work at two speeds — the demo side lives at The October demo →

For implementers: start here

  1. Read MIP-0012 — how a contract holds and releases unshielded and shielded value, with authorisation abstracted to one seam.
  2. Then MIP-0013 — the device set, revocation epochs, the bootstrap, and the seam instantiated with in-circuit Schnorr over JubJub.
  3. Clone the reference implementation — both standards in one deployment, with the conformance suites the standards require and an independent bit-exact Rust signer.
  4. Build your signer first — it needs only JubJub arithmetic and SHA-256, no Midnight stack, so approval is separable from proving from day one.

A second, independent implementation is the standards’ remaining path-to-Active evidence — if you build one, say so in the upstream discussions. Toolchain versions are pinned in the reference implementation’s manifests; keep the prover and ledger payload formats version-paired, which is the first skew a fresh build hits.

Pipeline

The MIP pipeline

Sequenced by dependency. Every MIP names an external co-author or committed reviewer from the start — that is what makes it portable across wallets rather than a Passport-shaped specification. STD-03 is a cryptographic prerequisite that ships before any MIP that hashes user state. Each card carries its upstream lifecycle state and links its evidence.

A note on identifiers: four-digit ids (MIP-0003, MIP-0007, MIP-0008, MIP-0012, MIP-0013) are upstream-assigned numbers. Short ids (MIP-4 to MIP-10) are workspace pipeline labels for proposals not yet filed, which carry the literal mip-xxxx filename until an upstream editor assigns a number at merge. STD-03 is likewise a workspace label: the domain-separation registry deliverable, whose problem statement is upstream as MPS-0027.

Reviews

Cryptographer & formal-methods sign-off

Scheduled against component stability, not against the calendar. Each review unblocks downstream specification work; together they form the "defensible against external review" bar that v1.0 must meet.

Component Touch point Reviewer Trigger State
Coverage

Promise → MIP map

Which MIPs lock down which promises. A promise without at least one MIP carrying it is a promise the standards body does not yet hold. This section is the audit trail for "is the standards path complete enough to call v1.0 feature-complete?".

Symbiosis

Shared with the MVP

The demo consumes pinned contract builds while reference implementation and standards work continue. Use the 1 October status report for merged work, open upstream submissions (#338/#339), feature PRs and release evidence. The original demo picks are retained as planning history.

Engage

Both keystone MIPs are Proposed upstream and open for review. Three errata the implementation surfaced are merged, and two measured gaps in MIP-0013 (a weak-key rejection, and a device identity so that removal revokes a device) are recorded with a remedy proposed; beyond those, what remains is exactly the ecosystem scrutiny that moves a proposal toward acceptance. Comment where the standards live; file issues where the plan lives.