A layered overview of the ARK minting and resolution cycle, dARK APIs, the private blockchain, distributed metadata preservation, and multi-site architecture.
How the flow works
Minting begins by reserving an identity. It continues with the URL and metadata submission, their decentralized preservation, and ARK publication.
Minter assigns a new identity within an enabled NAAN.
The URL and metadata are submitted; dARK preserves them across several nodes and records the ARK.
The API confirms Published status; Resolver provides the URL and metadata, and Minter receives subsequent changes.
If the resource moves to another platform, the institution updates the destination and keeps the same ARK.
Authorities and NAANs
dARK calls an authority an institution—or its governance-designated representative—enabled to register identifiers. Each authority is linked to one or more NAANs, the prefixes representing its institutional identification spaces.
In LA Referencia’s first phase, national nodes act as designated authorities. A later phase will allow institutions themselves to mint through the API.
Governance recognizes the institution or the national node representing it.
Each prefix defines the institutional spaces it may operate in.
Minter validatestes the authority and NAAN before reserving or updating an ARK.
The cycle within Minter
The state lets the sender track minting progress. The main path goes from Reserved to Draft and finally Published. Select each state to see what happens.
Minter generated the identifier and keeps it reserved while awaiting the URL and metadata.
Minter received the information and internal processes prepare its preservation and registration.
The metadata were preserved and the record was confirmed on the blockchain for public resolution.
Minter received a new URL or metadata version and repeats the preservation and registration process.
The owning authority deactivated the ARK. This operation is irreversible and the record cannot be changed.
Behind the states
Reservation and information submission take place through Minter. Internal processes then preserve metadata, register the ARK, and update its state.
dARK APIs
Minter and Resolver are the two user-facing interfaces. Behind them, Admin, workers, dark-core-lib, and Store coordinate operations with blockchain and IPFS.
It allows users to reserve, complete, and update ARKs, as well as check their status.
It allows users to open the current destination, view information, and retrieve preserved metadata.
Admin registers authorities on the blockchain. Minter maintains local state, coordinates preservation, and publishes the record through contracts. Resolver queries the chain and, when metadata are requested, retrieves them through Store API.
Core technology · Blockchain
dARK’s private blockchain records authorities, their permissions, and every creation or update of an ARK. The same ordered history is maintained across validator nodes, providing trust and traceability to the service. A blockchain node is a machine that keeps a copy of the record and participates in the network; validator nodes also take part in confirming blocks.
It is not Proof of Work. Unlike cryptocurrencies that make anonymous participants compete to solve calculations, dARK identifies its validators in advance and uses their agreement to add operations to the record.
External reference: Hyperledger Besu documentation on QBFT ↗.
Core technology · IPFS
Metadata are preserved at two levels. L1 gathers basic metadata and the internal data dARK needs to manage the ARK in a JSON document, and includes L2’s CID to maintain the link with the original record. L2 retains the original metadata record. L1’s CID is linked to the ARK on the blockchain.
Multi-site architecture
The model distributes applications, blockchain nodes, and storage across sites connected by private networks. Each site contributes infrastructure to the same dARK service, so the network can continue even if only one site remains operational temporarily.
The architecture is designed to distribute sites across public and private infrastructure in different countries. This diversity helps keep copies and services available during the temporary loss of a site and supports the long-term survival of information. Store API works with local storage nodes and remote propagation occurs within the single global IPFS cluster.
How the dARK Resolver works
Resolver queries the record and responds in three ways. Select each option to see its path.
dARK within global ARK resolution
The global ARK registry maintains an N2T—Name to Thing—rule for each NAAN. In spaces managed by dARK, that rule directs the request to dARK Resolver. N2T specifies which service responds; it does not store metadata.
GET /api/v1/arks/ark:/12345/abc123It looks up the registered address and opens the resource in its current repository.
GET /api/v1/arks/ark:/12345/abc123?infoIt presents the public information associated with the ARK.
GET /api/v1/arks/ark:/12345/abc123?metadataIt retrieves the original version of the preserved metadata.
The outcome
dARK coordinates minting, decentralized preservation, verifiable registration, and public resolution through specialized services.
Technical documentation
dARK is evolving continuously. The documentation describes components, contracts, APIs, states, metadata preservation, and infrastructure operation. The stable version and complete code will be available to the community by the end of 2026.