Mel integration

This is the “why it isn’t a federated dead end” document. It maps Mel’s three load-bearing ideas — Global Namespace, offchain name non-equivocation, and light-client-first verification — onto where they plug into Tenure, and states honestly what is built and tested versus what is the cutover still to come. The mechanics live in Directory integration; this page is the argument and the roadmap.

Federated versus confederal — and why the difference is existential

• Federated means a fixed set of operators that must be trusted. To believe a credential, a verifier trusts the specific registrar that served it. One operator lying, disappearing, or being compromised breaks every party that depended on it. A federated employment-verification network is just a credit bureau with more logos — the trust still terminates in an operator. That is the doomed shape.
• Confederal means independent registrars and attesters that do not have to trust each other, coordinated by a shared, verifiable namespace with non-equivocation. Trust terminates in canonical state and mathematics, not in any operator. A registrar can be swapped, audited, and convicted of misbehavior with a portable proof, and the employer owns the identity that survives the switch.

Tenure is built confederal. The verify predicate is pure and offline; the bundle is self-contained; a registrar that equivocates is convicted by a portable misbehavior proof; an employer can leave for a new registrar and be rediscovered through the directory. Mel is the step that removes the last place where trust still terminates in a provider’s key.

The three Mel ideas and where each plugs in

1. Global Namespace maps onto the Tenure keyspace

Tenure already lives inside an untyped global key space, with three naming conventions of its own — the same layering nullspace uses for human-readable usernames:

Name	Binds	Owner
Employer Record	an employer to its current registrar — address and key — plus digests of its descriptor and KYB attestation	the employer key
Head Checkpoint	an employer to its latest signed head, the freshness anchor	registrar and employer, co-owned
Attester Record	an attester registry entry: organisation, methods, status	the attester key

Mel’s Global Namespace is the decentralised, light-client-verifiable home for exactly these names. Today they live in the directory’s sparse-Merkle key/value store; at cutover they become Mel namespace entries — same names, same records, same proofs.

2. Offchain name non-equivocation: key state and header chain today, Mel for prevention

Non-equivocation means a name cannot be shown differently to different parties, and cannot be rolled back. Tenure implements the nullspace shape of this today:

• Each key commits, in its Merkle leaf, to the whole of its state: the highest accepted nonce, the owner set, and the value.
• An update must be signed by a member of the current owner set and carry a nonce strictly greater than the highest accepted so far — so a replayed old update, such as re-pointing an employer’s record at a registrar that employer just fired, the name-rollback attack, is dead on arrival. A red-team exercise replays a captured pre-transition update and it is rejected.
• Owner sets give sovereignty: the employer co-owns its head checkpoint and can evict a dead registrar without that registrar’s cooperation.
• The directory signs a hash-chained header over every root, so two conflicting roots at the same height form a portable misbehavior proof — the same machinery that convicts an equivocating registrar.

That yields equivocation detection. Mel turns detection into prevention: “is this root canonical?” stops being “trust the anchor key” and becomes a light-client check against a public ledger, so a conflicting root cannot be canonical in the first place.

3. Light-client-first: the verifier and wallet as light clients

Today the verifier’s offline path reads the employer record, the head checkpoint, and the attester record from the directory, verifies a Merkle proof under a signed root, and anchors freshness on the directory head — with the registrar and its mirrors fully dead. Trust terminates in the directory’s anchor key.

Mel’s light-client-first design replaces that anchor: the verifier becomes a Mel light client and confirms the one true employer-to-registrar binding and the current head with a compact light-client proof, trusting no operator and running no full node. This is the property that makes verification permissionless and trustless at the same time — the confederal finish line.

The cutover — what changes, what does not

Because a single adapter is the only part of the system that talks to a directory at all, the Mel migration is a backend swap behind that seam, not a protocol migration.

Does not change — these were built to the nullspace and Mel shape on purpose:

• the three published records and their canonical domain-tagged encoding;
• the key-state model — highest-accepted nonce, owner sets, Merkle-committed state — and the canonical update tuple;
• the sparse-Merkle hashing: keyed BLAKE3 with distinct domain keys for data blocks and interior nodes, and zero-collapsed empty subtrees, exactly as nullspace specifies, so there is no re-hashing migration. This was aligned early, while no production directory existed, precisely so the cutover needs no new genesis and no client resync;
• compressed bitmap proofs, the audit-replay path, and cross-language test vectors.

Does change at cutover:

• the directory backend: reference or hosted directory becomes a Mel Global Namespace client;
• the root of trust: the directory’s anchor key becomes Mel light-client verification, with the header chain as the seam it plugs into;
• the equivocation posture: detection, a portable proof after the fact, becomes prevention, a non-canonical root rejected at read time.

Status: built versus pending

Capability	State
Pure offline-verifiable bundle, no registrar needed	Built, shipped
Registrar equivocation yields a portable misbehavior proof	Built, tested
Registrar switch — export and import — plus rediscovery	Built, tested
Directory: trustless reads, key-state ownership, nonces, write proof-of-work, compact proofs	Built, tested, nullspace-exact
Directory: durable across restarts, with the tree rebuilt and root-checked on load	Built, tested
Directory: offline verification with the registrar and its mirrors dead	Built, demonstrated end to end
Light-client header-chain verification in the browser client, confirming the served root is the tip of the anchor’s append-only chain	Built, tested
Quorum-witness freshness, the anti-suppression defence	Built, against reference witnesses
A swappable directory backend, so Mel can drop in behind the adapter	Built — the seam and a placeholder Mel backend exist
Directory enabled in the live pilot	Pending — optional and off by default; the current pilot deployment is registrar-only
Mel Global Namespace client, replacing the anchor with a light-client root	Pending — the seam, data model, and drop-in point are built; the remaining backend method bodies are future work, gated on Mel’s release
Equivocation prevention via a Mel-anchored canonical root	Pending — requires the Mel client above

What Mel changes — and what it does not

Names bind keys; keys do not go away

A tempting misreading: once names are global, employers and workers will not need a key — they just enter their name. Not so, and the distinction matters. A Mel name is bound to an owner key set. The name is the public pointer; the key is the authority. To act as a name — sign a payroll batch, re-point an employer binding at a new registrar — the actor must hold a key in that name’s owner set. If a name could be used by merely typing it, anyone could impersonate anyone and the system collapses.

What Mel changes is UX and continuity, not custody:

• Names replace raw identifiers. Users type human-friendly, globally discoverable names instead of identifiers, addresses, and public keys — the name is the address.
• Owner sets give recovery and rotation behind a stable name. Recovery co-signers can be added, a key rotated, or a lost or compromised key evicted, all without changing the public name. Keys become rotatable and recoverable — never absent.

The analogy is a domain name bound to a TLS key. The name is typed; the key proves control. Nobody logs in with just a domain name. Here too: the name is identity, the key is control.

What light clients are for, and who runs them

Who runs them: verifiers such as landlords and lenders, worker wallets, the self-hosted verify page, and third-party integrators — anyone who needs the canonical answer without trusting an operator or running a full node.

What they give Tenure:

• Trustless discovery — resolve a name to its current registrar, head, and key with a compact proof, with no trusted directory or anchor.
• Trustless freshness — confirm that a head is the latest one and not a suppressed older one, against the canonical chain.
• Trustless attester status — confirm from canonical state that a KYB attester is active and not revoked, rather than from a list that must be trusted.

What can be built on them: a genuinely trustless verify page — enter a name, get a verdict, with no server and no anchor; wallet auto-discovery of the new registrar after a switch; third-party verifiers who trust Mel rather than Tenure’s registrar; and witness and monitoring networks that light-client-verify heads. The light client is what lets an ecosystem verify credentials without Tenure in the loop at all.

What offchain non-equivocation buys

It kills the attacks that would otherwise make a confederal network unreliable:

• Split view — a registrar cannot show a fresh head to the worker and a stale head, hiding a revocation or termination, to the verifier.
• Name rollback — when an employer fires one registrar and moves to another, neither that registrar nor an attacker can replay the old binding to keep pointing at the departed registrar.
• Impersonation and squatting — a name cannot be claimed or updated by a party that does not own it.

Why this matters here specifically: the entire value of the credential is that the verifier sees the true current state — the right employer-to-registrar binding, the right head, not revoked. Non-equivocation turns “the registrar showed me X” into “X is the one canonical state”, which is the difference between a credential that can be lent or leased against and one that cannot.

It also composes with the rule that a signed head commits to the revocation-set root: that commitment makes the head carry the revocation state, and non-equivocation makes that head the one canonical head. Together, a revoked credential cannot be passed off as valid — even by a registrar colluding with the holder. See Verification.

The one honest caveat

In the current pilot the directory is off, so verification leans on the live registrar — which feels federated. That is a deployment choice, not an architectural one. The confederal machinery — offline bundles, misbehavior proofs, registrar switching, and the whole directory with trustless reads — is built and tested but not yet switched on, and the data model is already Mel-shaped. Turning the directory on, then swapping its backend for Mel’s Global Namespace, is the roadmap; because the seam and the hashing were built to nullspace exactly, that is a backend change rather than a rewrite.

Tenure is not a federated dead end. It is the confederal core plus the Mel seam, with the last trust anchor left as the thing Mel removes.