BRC-115Draftv1.0

Identity-Linked Deterministic Token Verification Framework

When a token carries compliance rules, two wallets checking it must reach the same answer or transfers will be accepted by one and refused by the other. This pins the check down step by step so the outcome is never in doubt.

Jake Jones9 Mar 20264 min read

Why: Wallets need a way to confirm that an identity-restricted token is being spent by its rightful, verified owner without exposing extra personal data or relying on a central authority.
What: BRC-115 is a set of rules for verifying identity-linked token transfers on Bitcoin SV using only deterministic key derivation, cryptographic commitments, and SPV proofs, with no overlay network or outside validator.
How: A wallet checks, in strict order, that the token's encoding, commitment, and SPV proof are valid, then confirms the identity certificate is present and its signing key was derived per BRC-42 from the certificate root, and finally evaluates the transfer against a compliance profile before accepting or rejecting it.

What this lets you do

Detect whether a token is identity-linked
Verify a spending key was derived correctly from a certificate root
Reject transfers that fail any step of a fixed verification order
Enforce compliance profiles like age or region gating
Reveal only selected certificate fields instead of the whole identity

Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.

Reference for an AI

Everything an assistant needs to answer questions about BRC-115 accurately, including what it depends on.

The specification

Read the original

Abstract

BRC-115 defines a deterministic, SPV-verifiable framework for identity-linked token transfers on Bitcoin SV. It specifies how wallets verify compliance requirements using BRC-0042 key derivation, BRC-0107 commitments, and BRC-0108 identity bindings — without relying on overlay networks or external validators.

This standard ensures identity-restricted token transfers remain interoperable, decentralized, portable, and enforceable while enabling selective privacy, regulatory compliance, and recovery options within the original peer-to-peer Bitcoin model.

Motivation

Existing BSV token standards provide token encoding (BRC-0092), verifiable state transitions (BRC-0107), and identity metadata (BRC-0108). However, none define:

How identity-based constraints are enforced
How signatures bind identities to transaction lineage
How SPV wallets validate compliance without a trusted intermediary
How field-level revelation is performed and verified consistently

BRC-115 introduces a unifying rule set that makes identity-restricted token usage deterministic, verifiable, and portable between software implementations.

Architecture Overview

flowchart TB

    Wallet["Wallet / Client Logic"]
    Core["Protocol Enforcement Layer"]
    Ledger["SPV Proof / Bitcoin Ledger"]

    Wallet -->|Enforces BRC-115| Core
    Core --> Ledger

    subgraph Stack["Verification Stack"]
        D["BRC-0092:<br/>Base Token Encoding"]
        C["BRC-0107:<br/>Commitment Verification"]
        B["BRC-0042:<br/>Deterministic Key Derivation"]
        A["BRC-0108:<br/>Identity Certificate Link"]
    end

    Core --- Stack

Terminology

Term	Definition
Identity-Linked Token (ILT)	A token output containing a valid BRC-0108 certificate hash.
Compliance Profile	A structured set of rules defining identity requirements for token usage.
Derivation Scope	The deterministic key domain created using BRC-0042.
Selective Revelation Bundle	A minimally sufficient encrypted proof package revealing only required certificate fields.
SPV Proof Package	A format containing transaction data plus Merkle proof (optionally BRC-0067-formatted).

Normative Rules

1. Identity Binding

A token SHALL be treated as identity-linked if:

The token output contains a BRC-0108 certificate hash, AND
The spending signature is produced using a key derived per BRC-0042 from the certificate root.

If either condition is not met, BRC-115 SHALL NOT apply.

2. Deterministic Key Derivation

All operational keys MUST be derived using:

BRC-0042(master_certificate_entropy, assetId, purposeId)

Use of BIP-32, SLIP-10, hardened derivation paths, or external hierarchical schemes is NOT permitted.

3. Signature Requirements

Identity-linked token transfers MUST be signed using:

SIGHASH_SINGLE | SIGHASH_ANYONECANPAY

Exceptions are permitted ONLY in:

Custodial batch aggregation
Minting
Time-locked recovery workflows

Such exceptions MUST be explicitly signaled using BRC metadata.

4. Protocol Signaling

BRC-115 shall activate under a hybrid signaling model:

Implicit activation: Any transaction using identity metadata (BRC-0108) and BRC-0042-derived signatures SHALL be treated as BRC-115-compliant.
Explicit activation (optional): A protocol identifier MAY appear in metadata (e.g., 0115, 0115.1) for version governance.

Explicit signaling supersedes implicit interpretation.

5. Mandatory Verification Flow

A compliant verifying wallet MUST validate in the following order:

Token encoding validity (BRC-0092)
Commitment integrity (BRC-0107)
SPV validity (Merkle proof)
Identity certificate presence & authenticity (BRC-0108)
Deterministic derivation match (BRC-0042)
Compliance profile evaluation (rules + selective revelation)

Failure at any stage MUST reject the transfer.

Compliance Profiles

Profile	Required Identity Level	Typical Use
Open	None	Standard fungible tokens
Identity-Present	Certificate exists	Membership, access tokens
Restricted	Field-level selective revelation	Age verification, region gating
Regulated	Certificate type + rules	Securities and compliance tokens
Recovery-Capable	Secondary derivation	Lost-key account recovery

Verification Process

flowchart TD
  A[Parse Token] --> B[Commitment Check]
  B --> C[SPV Check]

  C --> D{Identity Linked?}

  D -->|No| H[ACCEPT]

  D -->|Yes| E[Certificate + Key Binding Check]
  E --> F[Compliance Profile Enforcement]
  F --> G{Accept?}
  G -->|Yes| H2[ACCEPT]
  G -->|No| I[REJECT]

Reference Implementation Guidance (Non-Normative)

Developers SHOULD:

Cache certificates to avoid repeated revelation requests
Use temporary encryption keys for field-level exchanges
Display meaningful compliance failure messages to improve UX
Support offline verification when proof bundles are present

Test Vectors

Vector 1 — Valid Identity-Linked Transfer

Expected Result: Accept

Vector 2 — Invalid Key Derivation

Expected Result: Reject

Vector 3 — Identity Valid, Compliance Failed (e.g., age restriction)