TokenMark: Anonymous Trust-Marking on Blockchain

• TokenMark is a cryptographically rigorous protocol for anonymously marking blockchain addresses with trust tokens, ensuring issuer privacy and auditability.
• The system employs accountable ring signatures and Pedersen commitments over Curve25519 to achieve security properties like unforgeability, anonymity, and revocability.
• TokenMark supports efficient forensic tagging across Bitcoin, Ethereum, and NEM, offering practical on-chain deployment with measurable performance metrics.

TokenMark, formally described as the “Anonymous Trust-Marking Scheme on Blockchain Systems,” is a cryptographically rigorous protocol enabling authorized marking of blockchain addresses with trust or untrust tokens, in a manner that preserves issuer anonymity while supporting auditability, revocability, and unforgeability. The system generalizes incident-driven tagging strategies (e.g., the Mosaic token for NEM in the Coincheck breach) by allowing trusted entities to make cryptographically provable, yet unlinkable, attributions about addresses across cryptocurrencies, with opening powers delegated only to designated auditors. The protocol’s core is an accountable ring signature (ARS) construction (after Bootle et al., ASIACRYPT 2015), augmented by Pedersen commitments, implemented over Curve25519, and efficient for deployment on Bitcoin, Ethereum, and NEM (Sato et al., 2020).

1. System Model and Security Objectives

TokenMark assumes an underlying public or permissioned blockchain supporting arbitrary data payloads in transactions. The model comprises four active entities:

• Token Admitter: An entity (with ARS keypair $(pk_i, sk_i)$) authorized to tag blockchain addresses as "trustworthy" or "untrustworthy." Each issuance ties to a designated auditor.
• Token Submitter: An agent (distinct from the Admitter) that embeds issued tokens $(M, \sigma)$ into blockchain transactions, paying necessary on-chain fees.
• Token Verifier: Any party wishing to validate on-chain tokens’ authenticity and issuance by an authorized Admitter.
• Auditor: Holder of an opener keypair $(opk_j, osk_j)$ able to “open” ARS-signatures on tokens attributable to $opk_j$.

The system targets four formal security properties:

• Anonymity: Only the (designated) Auditor (and the Token Submitter) can learn the identity of the Admitter for a given token. The ARS scheme ensures that, for a ring of size $N$, adversaries with all but one signing and opening keys cannot distinguish the signer beyond probability $1/2 + \text{negl}(\lambda)$.
• Auditability: Only the designated Auditor can provably open a valid signature to the unique Admitter, and signatures cannot be forged to frame honest Admitter.
• Unforgeability: Adversaries (even corrupting all but one Admitter and the Auditor) cannot forge valid marks for an honest Admitter w.r.t. verification.
• Revocability: Only the original Admitter is able to issue revocations of previously issued tokens, based on binding commitment to unique randomness per issuance.

2. Entity Roles and Cryptographic State

The scheme delineates strict key and state requirements:

• End Users: Own addresses subject to marking; not actors in issuance or protocol cryptography.
• Token Admitter $i$: Maintains $(pk_i, sk_i)$ (ARS keys), auditor selection $j$, and secret $r_\mathsf{link}$ for revocation. Stores sufficient local state to re-generate opening evidence.
• Token Submitter: Receives finalized $(M, \sigma)$ from the Admitter and is entrusted to embed this without knowledge of $sk_i$ or $r_\mathsf{link}$.
• Designated Auditor $j$: Possesses $(opk_j, osk_j)$; can run ARS.Open to recover the issuer of any token designating $opk_j$.
• Non-Designated Auditors: Hold opener keys for other indices; cannot open signatures outside their assignment.

3. Cryptographic Primitives and Pseudocode

The scheme employs two cryptographic blocks:

• Accountable Ring Signature (ARS): Realized in a prime-order group $G$ (Curve25519), following Bootle et al., permitting proofs of one-out-of-$N$ knowledge and designated opener tracing. Public parameters include group generators $(g, h_1, \dots, h_N)$ and ElGamal public key $ek = g^\tau$.
• Pedersen Commitment: Used for linking value $r_\mathsf{link}$, foundation for issuer-controlled revocation. Standard commitment and opening as $C = g^{r_\mathsf{link}} h_\mathsf{com}^{dec}$.

Key ARS Algorithms (LaTeX pseudocode given in the reference):

Operation	Description	Output
ARS.Setup	Parameter generation (group, bases, ElGamal key)	$(pp = (G, p, g, \{h_i\}, ek), \tau)$
ARS.KeyGenOpener	Auditor opener key generation	$(opk, osk)$
ARS.KeyGenUser	Admitter key generation	$(pk, sk)$
ARS.Sign	Sign message $M$ for ring $R$, auditor $j$	Signature $\sigma$
ARS.Verify	Verify ring signature	$0/1$
ARS.Open	Designated audit “open”	$(pk^*, \rho)$ or $\bot$
ARS.Judge	Verifies audit open proof	$0/1$

Pedersen commitment and open procedures also provided in pseudocode.

4. Protocol Workflow

Issuance:

1. Admitter samples fresh $r_{\mathsf{link}} \leftarrow \mathbb{Z}_p$ and $$C \leftarrow \mathsf{Com.Commit}(\mathsf{crs}, r_{\mathsf{link}})$$.
2. Chooses ring $R$ of Admitter keys (size $N$), includes own $pk_i$.
3. Selects Auditor index $j$, publishes $opk_j$ in the message.
4. Constructs on-chain message $M$:

$$M = (\text{TargetAddress}, \text{Flag} \in \{\mathsf{good}, \mathsf{bad}\}, opk_j, \text{ExpiryTime}, C, \text{AuxText})$$

1. Computes $$\sigma \leftarrow \mathsf{ARS.Sign}(opk_j,\, M,\, R,\, sk_i)$$.
2. Sends $(M, \sigma)$ to Token Submitter.

Revocation:

• To revoke, Admitter reveals $(r_{\mathsf{link}}, dec)$ corresponding to $C$ in a new signed message $M_{\mathsf{revoke}}$, uniquely linkable to the original issuance.

Blockchain Embedding:

• Token Submitter checks all validity conditions, then embeds $(M, \sigma)$ using appropriate blockchain payload mechanism (e.g., OP_RETURN, smart contract data).

Verification:

• Token Verifiers extract $(M, \sigma)$ and run $\mathsf{ARS.Verify}$.

Trace/Audit:

• Only the designated Auditor runs $\mathsf{ARS.Open}$ to extract $pk_i$, optionally publishing an opening proof for public judgment.

5. Security Arguments

TokenMark’s security derives strictly from its ARS and Pedersen primitives:

• Anonymity: Full anonymity of the ARS precludes adversarial identification of a signer within a ring, even in the presence of all other Admitter keys and non-designated opener keys. Pedersen commitment to $r_{\mathsf{link}}$ does not leak information.
• Auditability: Traceability is enforced as $\mathsf{ARS.Open}$ with the correct opener key always retrieves the unique issuer. Non-frameability is ensured since the ARS prohibits constructing signatures openable to arbitrary keys.
• Unforgeability: The ARS unforgeability property ensures no adversary can create valid $(M, \sigma)$ for an uncorrupted Admitter without $sk_i$.
• Revocability: Only the Admitter with opening $(r_{\mathsf{link}}, dec)$ of the commitment $C$ can successfully revoke, enforced by Pedersen binding and hiding.

6. Performance and Deployment Considerations

Implemented over Curve25519, TokenMark’s ARS and Pedersen operations feature:

• Ring size: $N=16$.
• Signature size: $\approx 1.4\, \mathrm{KB}$.
• Timings (per operation, MacBook Pro, 2.3 GHz Intel i5):
  • Sign: $13.7\,\mathrm{ms}$
  • Verify: $11.0\,\mathrm{ms}$
  • Commitment/Open: $0.0072\,\mathrm{ms}$

On-chain footprint and costs:

Blockchain	Full Embed $(M,\sigma)$	Hash+URL Embed
Bitcoin	1.6 KB, $\approx 0.042$ BTC ($\approx€290$)	2 outputs, $0.004$ BTC ($\approx€27$)
Ethereum	46,888 gas, $0.0000938$ ETH ($\approx€0.015$)	—
NEM	2 tx, $2.8$ XEM ($\approx€0.10$)	1 tx, $0.007$–$0.009$ (€)

These metrics demonstrate practical deployment on Ethereum and NEM; Bitcoin costs are higher and may be justified for high-value forensic marks.

7. Application Domain and Generality

TokenMark is universally applicable to any cryptocurrency supporting arbitrary transaction payloads, demonstrated on Bitcoin, Ethereum, and NEM. Its trust and audit overlay provide general mechanisms for marking, forensic attribution, and trust-support infrastructure, decoupled from core consensus rules or native token implementations. The protocol achieves equivalent or superior functionality to the Mosaic tagging approach for NEM, without centralizing linkability or exposing volunteer/issuer identities, thus offering a robust, privacy-preserving foundation for regulatory and community-driven address attribution (Sato et al., 2020).