Concept paper v1.0
Domain-as-namespace

root

wunderwaffe.store
Voucher lifecycle

Domain-rooted namespace

Identity vouchers,
anchored by a domain

A conceptual framework in which a storefront domain acts as the namespace root for issuing verifiable, revocable credential tokens that bind product provenance to on-chain attestations — without depending on a centralized registry. See the linked resource

Storefront root → voucher → attestation

One namespace, no central registry
Credentials that can be proven,
and withdrawn

Namespace root

The storefront domain is treated as the root of an identifier namespace, so each issued voucher inherits a readable, owner-controlled path.

Verifiable tokens

Each voucher is a token whose claims can be checked against its issuer, issuance record and current status rather than a private database.

Revocable status

Revocation is designed as a first-class state, so a voucher can be invalidated without deleting the history that surrounds it.

Issuance

A voucher is minted under the domain namespace and bound to a specific product reference.

Provenance

On-chain attestations record the statements made about that product, so the provenance trail is inspectable.

Verification

Anyone holding the voucher can check its issuer path, claims and status without contacting a central authority.

Revocation

When a claim no longer holds, the voucher is marked revoked, and the earlier record remains visible as history.

Framework outline

A storefront domain as the root of trust

The idea is deliberately narrow. A domain already carries ownership, continuity and a public address that visitors understand. This framework asks whether that same address can serve as the namespace root for identity vouchers, removing the need for a separate registry of issuers.

Read about the linked resource
01
Root
The storefront domain defines the namespace in which vouchers are named.
02
Voucher
A credential token is issued under that root for a particular product.
03
Attestation
Claims about provenance are recorded on-chain and linked to the voucher.
04
Revocation
A voucher can be withdrawn while its issuance record stays readable.

Lifecycle

Four states

From issue to revocation

The lifecycle is intentionally simple. Each step produces a record that later steps can reference, which keeps the history of a voucher legible even after it stops being valid.

01

Issued

02

Attested

Scope

What the framework does not assume

This is a design concept, not a live service. It makes no claims about existing deployments, partners or outcomes, and it does not propose a specific network or token standard.

  • No centralized registry is required for naming.

  • The domain remains the owner-controlled anchor point.

  • Attestations are statements, not guarantees of quality.

  • Revocation preserves history rather than erasing it.

Open questions

Linked resource

A referenced page outside this concept note

Visit chinazes.space
in this tab

This concept note points to an external destination, chinazes.space, as a supplied reference. This page shows the link only: no description of that site's contents, ownership or claims is stated here, and nothing on this page vouches for what the destination contains. A visitor may follow the link to inspect that resource directly at its own address. The anchor above opens it in the same browser tab.

Mechanics

How a voucher is put together

Namespace path

The voucher identifier is composed under the storefront domain.

Because the path derives from the domain, a reader can tell who issued the voucher without consulting a separate issuer list. The domain's continuity becomes the continuity of the namespace.

Root
Product binding

Each voucher names the product it describes.

The binding connects a physical or catalogue item to a credential, so provenance claims belong to something specific rather than to a general brand statement.

Bind
Attestation link

On-chain statements reference the voucher.

Attestations are separate records that point back to the credential. Multiple statements can accumulate over time without rewriting the voucher itself.

Link
Status check

A reader resolves the voucher to its current state.

Verification returns whether the voucher is active or revoked, which claims were attested, and under which domain root it was issued.

Check
Design goals

Three properties the model aims for

Follow the link
to chinazes.space

Issuer legibility

A voucher's origin should be readable from its identifier alone.
Anchor
domain root
Reader
buyer or auditor
Output
issuer path
Registry
not required
Open resource

Revocation clarity

A withdrawn credential should be visibly withdrawn, not silently dropped.
State
active or revoked
History
retained
Update
a new record
Deletion
not implied
Open resource

Provenance evidence

Claims about a product should point to statements that can be inspected.
Claim
product statement
Record
on-chain attestation
Subject
the voucher
Scope
as stated
Open resource
Concept status
Draft framework
Terminology

Words used in this note

Namespace root: the domain under which voucher identifiers are formed.
Credential token: the issued object that carries a product's identity claims.
Attestation: a recorded statement linked to a voucher.
Revocation: the change of a voucher's status to withdrawn.
Registry: a central issuer list this framework seeks to avoid.
Provenance: the set of claims describing where a product came from.
Still a concept

Read the framework with its limits in mind

Assumption

Domain ownership remains stable over time.

If a domain changes hands, the meaning of vouchers issued under it needs to be addressed in the design.

Root continuity Issuer path Status rules Record retention

Assumption

Attestations describe what an issuer asserts.

An attestation is evidence of a statement, not independent proof that the statement is true.

Statement source Claim scope Reading limits Plain language

Assumption

Readers can resolve a voucher to its status.

Verification depends on a resolution path that should stay available, documented and free of ambiguity.

Resolution Availability Documentation Clarity
Summary

The framework in two parts

Part one Naming

The domain does the naming work

By treating the storefront domain as the namespace root, the framework avoids a separate issuer registry while keeping voucher names readable and attributable.

Part two Evidence

Attestations carry the claims

Provenance statements live in on-chain attestations linked to the voucher, and revocation updates status without erasing the record of issuance.

A concept, not a deployment

This page describes a design idea for domain-anchored identity vouchers. It does not describe a running service, and it makes no claims about real products or issuers.

Visit the linked resource