Prior art and reuse candidates

Comparison date: 2026-09-09. Implementation links pin revisions; website and whitepaper references record the material inspected on that date. Every source cited below was fetched at its pinned revision and read against the claim it supports.

The inspected projects provide substantial precedent for Singular's architecture and mechanics. No ready-made implementation of its complete contract was established in this bounded comparison. This is not a novelty claim, security audit or exhaustive search. Source inspection does not establish deployed behavior.

What Singular is trying to be

Singular is a component, not an application. A third party supplies one parameter — its application policy ID — and receives its own registry of unique keys with the representative NFT lifecycle managed end to end: minted into a certified application output on Insert, burned on retirement, burned and the key made available again on Delete. Nothing about the keys, the application's state or its business rules belongs to Singular.

That is the axis on which the prior art has to be read, and most of it fails before authorization is reached. A registry welded to one application is not reusable by anyone else at any price short of forking and rewriting it; the code inspected below is mostly of that kind, however good it is at its own job. MPFS is the exception and the model: it is application-agnostic, anyone may create a cage, and its single blocking difference from Singular is that every cage has an owner.

Two further layers are worth keeping apart. The authenticated-map layer — a key set whose whole state fits in one datum and whose changes are proved on-chain — has working implementations that Singular can adopt; an equivalent registry would not be disqualified merely because it uses a different authenticated-set representation. The registry contract layer — who may change the map, what an entry certifies about an application output, and what token custody is coupled to a transition — is where every inspected system diverges.

Candidate	Reusable by an unrelated application?	Relevant precedent	Gap against Singular's intended contract
MPFS cage	Yes — application-agnostic; anyone mints a cage from a consumed seed	Owner-held MPF root, request UTxOs carrying Insert/Delete/Update, phase-gated retraction, fold applying one proof per request	Every root transition requires the state owner's signature; keys carry opaque bytes with no representative NFT, no application-bound certification and no terminal retirement
AdaDomains	No — registry validators are domain-specific and not published	Separate name registry and application state; pooled mint requests; local address changes	Published architecture does not establish action-bound certification or distinct permanent retirement/reusable deletion; inspected SDK supplies resolution, not registry validators
ADA Handle DeMi	No — Handle-specific settings, effects and allowed minters throughout	MPF-backed order fulfillment and burn/delete mechanics	Inspected mint and burn paths both require an allowed-minter signature and Handle-specific effects; no matching generic certified terminal-request lifecycle established
Distributed Set	Partly — a generic byte-string set parameterised by a required mint or stake script	Generic byte-string set and configurable required mint/stake script	Hook checks invocation in the set-changing transaction; the node validator does not itself preserve membership; no staged certified-request and representative lifecycle supplied
CIP113 implementation	Partly — a standard with configurable issuance and transfer credentials	Registry authentication, configurable issuance and transfer credentials	Registry keys are derived token policy IDs; live withdrawal delegation and shared programmable custody differ; nodes are inserted and updated but never removed, so registration is permanent and no reusable deletion exists
Masumi registry-v2	No — internal to the payment service	Consumed-input-derived NFT identity and versioned token operations	Uniqueness comes from a spent output reference rather than absence in a set; supplies no application-selected key absence or Active/Over registry contract

MPFS

MPFS is the nearest system to Singular and the one whose reuse must be answered explicitly, because Singular's map layer is MPF and the protocol specification already records, among its open decisions on transaction shapes and libraries, that old MPFS proofs are not proof of Singular's protocol. It is also the one candidate built as a component rather than as somebody's application: a cage is created by whoever consumes the seed, carries no application-specific rule, and serves whatever that creator puts in it. That posture is the one Singular copies. The difference is a single design decision inside it.

The inspected on-chain revision is cardano-mpfs-onchain at 34a5bfb. A cage is one NFT locked at the script address whose datum carries the MPF root. state.ak mints the cage token from a consumed seed, folds pending requests into a new root under Modify, and burns the cage under End. request.ak governs request UTxOs with Contribute, Retract and Sweep. shared.ak holds the authorization and phase predicates, and types.ak defines the request record and the map operations.

Four facts from that source decide the comparison.

• Every spend of the state UTxO runs validateOwnership before the redeemer is examined, and that function requires the datum's single owner verification key hash among the transaction's signatories. Both Modify and End sit behind it.
• Map entries are Operation values over ByteArray: Insert(value), Delete(value), Update(old, new). The cage mints exactly one token — its own state NFT — and no token is minted, burned or moved per key.
• A request carries requestToken, requestOwner, the key, the operation, a tip and submitted_at. It commits to no application policy, no output shape and no approval; the only requester-side authorization anywhere in the validators is the Retract signature.
• Requests are governed by time. Contribute requires Phase 1 or rejectability, Retract requires the requester's signature inside Phase 2, and Sweep lets the owner clear any request that is not processable against the current state.

Why Singular cannot adopt MPFS unchanged

Singular requirement	What MPFS supplies	Gap
No owner, requester or folder may gate a fold	validateOwnership on every state spend	A registry built on the cage inherits an actor gate the specification forbids: no entry enters or leaves the map without one key holder's signature
Representative supply is coupled to every transition	One cage NFT for the whole map	Nothing is minted per key, so no outstanding token can carry a registration into an application output, and no burn can be coupled to a transition
Over is terminal	Update(old, new) rewrites a value; Delete frees the key	Retirement could only be a value convention, enforced by the owner's signature rather than by a witness; terminality and reusable deletion stay indistinguishable on-chain
A request is certified by, and bound to, its application	Request datum with key, operation, tip and requester	No action asset, no configured application policy, no commitment to an initial output, destination or datum; approval has no place to live
Withdrawal of a pending Insert is application-authorized	Retract inside the Phase 2 window	Cancellation is a requester's timed right, not an application-authorized Withdraw bound to the exact pending request and its refund effects
A terminal request keeps its representative until completion	Sweep clears non-processable requests	A pending Singular Update/Delete holds a live representative that no sweep may release; the owner-sweep power has no Singular analogue
Registry permanence	End burns the cage token	The owner can destroy the entire map

The phase design is worth separating from the verdict. MPFS uses time windows to keep the oracle's fold and the requester's retraction from racing, which is a real solution to a problem Singular shares. It is unavailable here for the same reason the rest is: the windows are exclusive to a named oracle, and Singular has none. In its place, Singular resolves races inside the fold — an Insert is checked against absence in the applicable successive registry state, and admission of a request asserts nothing about the key.

What remains reusable from MPFS

The map layer and its off-chain machinery transfer; the authorization model does not. The fold shape — one proof per request applied against successive roots — is the shape Singular's permissionless fold requires. Off-chain, cardano-mpfs-offchain at 0f82465 supplies a cage indexer, a proof-bearing REST API, client transaction builders and cross-target verifiers over the same trie. Component-level reuse still needs its own evaluation: none of it was written against Singular's request or custody rules, and the decision on transaction shapes and shared libraries remains open.

Evidence and useful boundaries

AdaDomains. The whitepaper, sections 3–4 describes separate registry/domain state, pooled requests and address changes. Section 3.1 puts the list of minted domains in the datum of a one-shot registry token; section 3.3 records the two limits that follow — one minting transaction per registry per block, and roughly 1600 short domains before the 16kB transaction limit binds; section 4.1 answers them by hashing names and splitting registries dynamically, and section 4.2 by a pooling layer in which the user who triggers minting must mint every pooled request belonging to that registry. Project resolution documentation describes reading the domain datum. The inspected resolver SDK at 302235c supplies resolution code. These establish architectural precedent and a public resolver, not an inspected generic registry implementation. A root-hash map moves that size limit off the key set, but it does not decide Singular's batch policy, which remains an open decision. Historical throughput assertions are not adopted here.

ADA Handle DeMi. At 1b5623c, mint/burn validation traverses MPF proofs and checks an allowed minter. The check is symmetric: can_mint_demi_handles requires the selected allowed_minter among the signatories, and can_burn_demi_handles requires any settings minter, so deletion from the root is gated exactly as issuance is. Order validation supplies execution, cancellation and refund conditions, including a distinct-output binding that prevents one owner output from satisfying several refunds. Mechanical overlap is useful; replacing application and governor rules is substantive work.

Distributed Set. The validator at 4b0547a and utilities authenticate set changes with current mint/withdrawal invocation. The set is a linked list of sorted-value nodes, each holding its own node NFT, rather than a hashed map: its state lives in as many UTxOs as it has nodes, and a node is split when it grows. Its plain spend branch checks sortedness, the head and tail anchors, the node NFT and the unchanged datum fields, and carries a TODO where a check that existing values survive would go — so membership preservation rests entirely on the configured mint or stake script, not on the set validator. The sources also target the pre-cardano/transaction Aiken standard library, which reuse would have to migrate. They do not supply Singular's prior-action receipt and NFT custody lifecycle.

CIP113. At 1e83ed9, the registry, issuance policy and programmable base provide relevant authentication and policy-binding techniques: a key must be the policy ID derived from the issuance template parameterised with its minting logic, registration requires that logic's withdraw-0, and custody is dispatched through a credential read live from the protocol-params datum. The registry's redeemers are RegistryInit and RegistryInsert, and its spend handler admits a node NFT mint only with a positive amount, otherwise requiring a continuing output — a registered key is never removed. Their live delegation and custody contract would require substantive adaptation.

Masumi. The registry-v2 mint policy at ce96026 addresses generated asset identities and versioning: an asset name is a nonce byte, the hash of a consumed output reference and a three-byte version, an update burns a token and mints its successor at version plus one, and a burn needs only possession. That is a different uniqueness problem from a registry of application-selected keys; no shared state records which keys are taken.

CIP89's beacon pattern is also relevant precedent for minting that certifies an application UTxO: a beacon is minted only into a valid application output, burned when that output is spent, and never circulates. Singular's representative is the opposite in one respect that matters — it is held, moved between an application's own successive outputs, and carried into a terminal request — so the beacon rule cannot be adopted as stated, only its minting-time certification. A complete uniqueness, request and retirement protocol remains additional work.

The authenticated map layer

This layer is the one part of Singular with ready implementations. The Aiken merkle-patricia-forestry library supplies on-chain proof verification, and is what both DeMi and MPFS build on; haskell-mts supplies the matching off-chain trie, proof generation and persistent storage. Choosing among these, or a different authenticated-set representation, does not resolve any of the open decisions, which are about certification, custody and retirement, not about how membership is proved.

Retirement and reuse of a key

Singular needs two ways for a registration to end, and the distinction is what makes the lifecycle worth managing centrally. Delete burns the representative and returns the key to absence, so a later approved Insert may register it again. Update burns the representative and writes Over, which is terminal: the key is retired permanently and no later Insert can revive it. Permanent retirement is the requirement that came from Singular's first consumer, where an identity must be able to end without its name being reissued to someone else.

That requirement is not local to this project. CIP113 arrives at the same permanence from the other direction: its registry nodes are inserted and updated but never removed, so every registration it accepts is permanent whether or not permanence was wanted. Distributed Set leaves removal to the configured hook and specifies neither mode. MPFS supplies Delete, which frees the key, and nothing that retires one. No inspected system offers both modes under one contract, chosen per transition by the application that owns the entry.

Coverage boundary

These candidates warrant component-level evaluation once a reuse target is concrete. License compatibility, toolchain fit and correctness require their own checks; this comparison grants none of them. Reading a validator establishes what its source says, not what a deployment does. Singular remains a design with unimplemented conformance obligations. Continue with the naming walkthrough or protocol specification.