Blind-Signed Vouchers and Anonymous Access Credentials

AeroNyx needs two privacy properties at the same time:

A node should be able to verify that a user is allowed to use the service.
A node should not be able to link that service use back to a wallet, account, payment event, or social identity.

Blind-signed vouchers are the credential layer for that separation. They let AeroNyx issue anonymous access credentials: a user can prove service rights, while the Rust privacy node validates only a signed voucher and does not learn who originally received it.

This is different from blind relay:

Concept	What it protects	What the node sees
Blind relay	Message or packet content	An opaque encrypted blob plus limited routing metadata.
Blind-signed voucher	Linkability between payment/account identity and service use	A verifiable credential, not the wallet or account that obtained it.

Together they support a stronger commercial privacy model: content remains encrypted, and access rights do not need to expose the user's identity to the relay node.

Why this matters

Commercial privacy infrastructure has to solve authorization without turning authorization into surveillance.

Without anonymous access credentials, a node or service operator could be tempted to log:

which wallet paid
which account requested access
which node session consumed that access
which time window or region that usage occurred in

That would create a linkable trail between identity and network activity. Blind-signed vouchers are designed to break that link.

High-level flow

The simplified flow is:

text

User wallet/account -> Issuer -> blind-signed voucher -> Rust privacy node

The client creates a voucher message and blinds it locally.
The issuer checks whether the user has rights to receive a voucher.
The issuer signs the blinded message without seeing the final voucher value.
The client unblinds the signature and stores a usable voucher.
The Rust privacy node verifies the voucher signature when service access is requested.
The node sees a valid credential, but it cannot derive the original wallet or account from that credential.

The exact implementation may rotate keys, use epochs, enforce quotas, and apply replay protection. Those operational details matter, but the core privacy goal stays the same: authorization without identity linkage at the relay node.

What it does not hide

Blind-signed vouchers are not magic anonymity for every layer. They do not hide:

the fact that a node received a valid voucher
aggregate usage counters
capacity consumption
abuse or replay attempts
service-region and timing signals visible to the node

They are specifically for unlinking issuance identity from later credential redemption.

Relationship to AeroNyx Privacy Protocol

AeroNyx combines multiple privacy layers:

Layer	Role
End-to-end encryption	Protects message and content plaintext.
Blind relay	Keeps relay nodes from reading encrypted payloads.
Rotating onion keys	Avoid long-term identity keys becoming per-hop decryption keys.
Two-hop path proof	Shows that multi-hop relay foundations are alive without exposing route metadata.
Blind-signed vouchers	Let nodes verify service rights without seeing wallet or account identity.
Aggregate observability	Gives operators health and capacity signals without exposing user-level activity.

The important product idea is that AeroNyx does not treat privacy as one feature. It treats privacy as a set of boundaries across content, routing, identity, payment, storage, and operations.

Difference from wallet blind signing warnings

In crypto wallets, "blind signing" often means approving a transaction whose details the user cannot fully inspect. That is risky and unrelated to the voucher concept described here.

AeroNyx blind-signed vouchers mean the issuer signs a blinded credential so the final credential is unlinkable. The user is not being asked to approve an unknown transaction. The goal is anonymous authorization, not opaque transaction approval.

Operator and nodeboard guidance

nodeboard should show voucher and access-health information as aggregate operational state:

valid voucher count
invalid voucher count
missing or malformed voucher count
replay or duplicate redemption counters
issuer mode or key epoch
last observation time

nodeboard should not show:

wallet-level usage
raw voucher secrets
per-user redemption history
traffic destinations
DNS contents
social graph relationships

Current product boundary

AeroNyx already uses blind-signed voucher concepts in the privacy-network access path. The documentation should describe the model as an access-credential privacy layer, while implementation details such as issuer key rotation, epoch policy, quota rules, replay windows, and failure codes should remain versioned engineering contracts.

The safe public claim is:

AeroNyx uses blind-signed vouchers as anonymous access credentials so nodes can verify service rights without linking privacy-network sessions to wallets or accounts.

Threat model

Blind-signed vouchers reduce linkability between issuance and redemption, but the broader system must still protect against:

issuer-side over-collection
voucher replay
voucher sharing or resale
compromised nodes
timing correlation
region or capacity side channels
weak client storage

For this reason, vouchers must be combined with blind relay, encrypted payloads, careful logging policy, bounded telemetry, and privacy-safe nodeboard views.

Developer checklist

When adding or changing voucher code, developers should verify:

The node validates voucher signatures without needing wallet identity.
Voucher secrets are never logged.
Failure reasons are coarse enough for privacy but clear enough for operators.
Replay protection exists.
Issuer keys and epochs are versioned.
Backend analytics remain aggregate.
nodeboard displays health, not per-user redemption trails.

The result should feel commercial and operable while preserving AeroNyx's blind-node invariant.